[Spring Boot] 모니터링 왜 필요한가?(Prometheus+Grafana)
1. 모니터링, 왜 필요한가?
프로젝트를 완성했다.
테스트 코드도 작성했고, CI CD 파이프라인도 잘 작동했고,
postman으로 배포 서버 API 수기 테스트도 성공했다.
배포를 무사히 마치고 며칠 뒤....
서버는 응답이 없었고, 정작 나는 언제부터 꺼졌는지 알지 못했다.
고가용성이 높은 서비스를 만들기 위해서는 Auto Scale-out, 테스트 코드 그리고 Massege Queue 같은 "예방 전략"도 중요하지만, 모니터링과 알림을 통한 "관측 전략"도 필수적이다.
아무리 안정적인 서버를 구축하더라도,
문제는 반드시 발생한다.
중요한 건 “문제가 발생했는가”가 아니라
“언제, 얼마나 빨리 인지했는가”다.
모니터링과 Alert이 잘 구성된 시스템은
문제가 발생하자마자 신호를 받고,
영향이 커지기 전에 대응할 수 있다.
2. 메트릭이란?
Observability(관측 가능성) : 서버 안에서 무슨 일이 일어나는지 파악할 수 있는 능력
크게는 3가지의 관측 지표가 있다.
Metrics → 숫자로 상태를 본다
Logging → 사건의 맥락을 추적한다
Tracing → 요청의 흐름을 따라간다Logging과 Tracing도 정말 중요한 지표이지만, Metric을 중심으로 설명하려 한다.
Metric을 한마디로 "시스템 상태를 숫자로 표현한 측정값"이다.
아래와 같은 데이터가 흔히 모니터링 전략에서 수집하는 Metric 데이터이다.
CPU 사용률 (70%)
메모리 사용량 (1GB)
초당 요청 수 (RPS: 120)
에러율 (1.2%)
응답 시간 (200ms)숫자로 표현된 값이기에 쉽게 수치화가 가능하며, 수치화된 시계열 데이터를 토대로 Prometheus와 Grafana 전략을 통해 시각화가 가능해진다.
Micrometer (측정 -> Metric)
↓
Prometheus (시계열 저장)
↓
Grafana (시각화)3. 어떤 메트릭을 수집할 것인가?
흔히 RED method와 USE method 전략이 있다.
RED method는 API 측면을 모니터링하고,
지표 의미
Rate 초당 요청 수
Errors 에러 비율
Duration 응답 시간USE method는 시스템적인 측면을 모니터링한다. CPU, Memory, Network 사용률 등이 있다
지표 의미
Utilization 이용률 또는 사용률
Saturation 포화도
Errors 에러4. Micrometer + Prometheus + Grafana 전략
스프링에는 Micrometer 외부 라이브러리를 활용하여 쉽게 Metric을 수집할 수 있다.
메트릭 설명
http_server_requests_seconds API 응답 시간, 에러율
hikaricp_connections_active DB 커넥션 풀 사용 중
hikaricp_connections_pending 커넥션 대기 중 요청
jvm_memory_used_bytes JVM 힙 사용량
process_cpu_usage CPU 사용률
jvm_gc_pause_seconds GC pause time하지만 Micrometer 혼자서는 해당 Metric을 저장할 수 없다.
이를 시계열 형태로 저장해주는 역할이 Prometheus이다.
Prometheus는 주기적으로 Micrometer로부터 Metric을 Pull받아오는 형식이다.
그리고 이 데이터를 통해 시간 그래프를 만드는 것이 Grafana의 역할이다.
[앱] 이상 수치 발견
├─ Micrometer ──→ Prometheus ──→ Grafana (숫자 메트릭) -> discord 알림
└─ Logback ──────→ Loki ────────→ Grafana (텍스트 로그)
↑
하나의 Grafana에서
메트릭 + 로그 동시에 확인
[외부] (서버 장애 시)
Uptime Kuma ──→ /actuator/health 30초마다 ──→ discord 알림