로그 관리와 모니터링 시스템 설계: 수집부터 알림까지

로그가 “무슨 일이 있었는지”를 보여준다면, 모니터링은 “지금 어떤 상태인지”를 보여준다.
운영 안정성을 높이려면 두 가지가 같이 있어야 한다.
이번 글은 Spring Boot 기준으로 Actuator/Micrometer, Prometheus, Grafana, Discord Alert까지 연결하는 흐름을 한 번에 정리한 내용이다.

 

---

1) 왜 모니터링이 필요한가

서비스 장애는 “터지고 나서” 대응하면 늦다.
모니터링의 목적은 현재 상태를 계속 관찰해서, 장애 전에 이상 징후를 잡는 것이다.

핵심 효과:

• 사전 예방: CPU/메모리/응답시간 이상 징후 조기 감지
• 원인 파악: 느림/에러의 병목 지점 추적
• 용량 계획: 트래픽 피크에 대비한 확장 판단

 

---

2) Actuator와 Micrometer의 역할

Spring Boot에서 메트릭 노출의 시작점은 Actuator다.
Actuator endpoint를 통해 health/metrics/prometheus 같은 정보를 외부로 노출할 수 있다.

Micrometer는 “메트릭 표준 인터페이스 + 번역기” 역할을 한다.
즉, 애플리케이션 메트릭을 Prometheus가 읽기 좋은 형태로 전달한다.

 

---

 

3) Prometheus 연결: 메트릭 수집 시작

Prometheus는 prometheus.yml 설정을 기준으로 대상 서버를 주기적으로 scrape한다.
Spring Boot의 /actuator/prometheus를 15초 간격으로 읽어오게 설정하면 기본 수집 파이프라인이 완성된다.

핵심 포인트:

• scrape_interval: 수집 주기
• metrics_path: 메트릭 endpoint
• targets: 수집 대상 주소

---

 

 

4) PromQL로 상태를 질의한다

Prometheus 데이터는 PromQL로 조회한다.
기본 문법은 “메트릭 + 라벨 조건” 구조다.

예시:

• http_server_requests_seconds_count
• http_server_requests_seconds_count{status="404"}
• jvm_memory_used_bytes{area="heap"}

PromQL을 익히면 단순 확인을 넘어 임계치 기반 경보 규칙까지 구성할 수 있다.

 

---

 

5) Grafana 연결과 대시보드 구성

Grafana는 Prometheus 데이터를 사람이 판단하기 쉬운 형태로 시각화한다.
Data Source에 Prometheus를 연결하고 대시보드 패널을 구성하면 운영 관측이 훨씬 빨라진다.

실무에서 자주 쓰는 패널:

• HTTP 요청 수/에러율
• JVM 메모리 사용량
• 응답시간 분포
• 인스턴스 상태(UP/DOWN)

 

---

 

 

6) Alerting + Discord 연동

대시보드만 보면 “확인할 때만” 이상을 알 수 있다.
그래서 실제 운영에서는 Alert Rule을 걸어 이벤트 발생 시 알림 채널로 즉시 전송한다.

예시 규칙:

• 최근 1분 동안 HTTP 400 에러 증가량이 임계치 초과
• pending 10s 이후 firing
• Contact point: Discord Webhook

이렇게 구성하면 에러 급증을 실시간으로 팀 채널에서 바로 확인할 수 있다.

 

---

7) 정리

중요한 것은 “보여주기”가 아니라 “빨리 감지하고 바로 대응하는 구조”다.
흐름을 다시 정리하면 다음과 같다.

1. Spring Boot Actuator + Micrometer로 메트릭 노출
2. Prometheus로 주기 수집
3. Grafana로 시각화
4. Alert Rule로 임계치 감지
5. Discord로 즉시 알림 전파

이 구성이 갖춰지면 장애 대응이 수동 확인 중심에서 자동 감지 중심으로 바뀐다.