[Prometheus, Grafana] 모니터링 시스템 구축 방법과 대시보드 개선

📝 모니터링 대시보드 개선 및 지표 추가 기록

서비스 안정성과 장애 대응력을 높이기 위해 주요 지표들을 추가하였습니다.

1. 실시간 API별 트래픽 분석표 패널 생성

도입 이유

기존의 Mean(평균) 지표는 소수의 사용자가 겪는 극심한 지연(Long Tail)을 반영하지 못하는 평균의 함정 발생 가능

ex. 대다수 사용자가 0.1초의 응답을 받아도, 특정 요청이 10초가 걸릴 경우 평균값은 실제 사용자 경험보다 훨씬 낮게 측정되어 장애 감지가 늦어질 수 있음.

• 요청 처리 시간 지표 고도화
  • P95 (95th Percentile): 하위 5%를 제외한 대다수 사용자가 체감하는 최악의 속도를 모니터링
• 기대 효과: 일시적인 네트워크 지연이나 특정 API의 성능 저하를 통계적으로 유의미하게 파악할 수 있음.

2. 에러율(Error Rate) 및 상태 코드 가시화

도입 이유

단순 요청 수(RPM) 그래프는 요청의 성공 여부를 구분하기 어려움.

ex. 서버에 치명적인 오류가 발생해 모든 요청이 500 에러를 반환하고 있음에도, 요청 수가 급증하면 이를 서비스 활성화로 오해할 수도 있음.

• HTTP Status Code 분류: 4xx(클라이언트 오류), 5xx(서버 오류)를 시각적으로 구분
• 에러 발생 알림 기준: 최근 1분간 에러 발생 빈도를 계산하는 PromQL 적용
• 기대 효과: 서비스 가용성(Availability)을 실시간으로 확인하고, 배포 직후나 트래픽 폭증 시 즉각적인 장애 인지가 가능함.

sum by (status) (increase(http_server_requests_seconds_count{status=~"4..|5.."}[1m])) > 0

3. DB 커넥션 풀(HikariCP) 상태 모니터링

도입 이유

DB 커넥션 풀 고갈: Spring Boot 기반 애플리케이션에서 성능 저하의 가장 흔한 원인

⇒ 대시보드에서 하드웨어 자원(CPU/RAM)만 볼 경우, DB 연결을 기다리느라 응답이 멈춘 상황을 분석하기 어려울 수 있기에 이를 도입함.

• 주요 모니터링 지표:
  • hikaricp_connections_active: 현재 활성 상태인 커넥션
  • hikaricp_connections_pending: 커넥션 할당을 기다리며 대기 중인 스레드 수
• 기대 효과: 응답 지연의 원인이 애플리케이션 로직인지, DB 연결 병목인지 명확히 구분하여 인프라 증설이나 쿼리 최적화 등의 의사결정 근거로 활용 가능

---

추가 고려 사항

• 대시보드 구축 후 모니터링 과정에서 UNKNOWN으로 기록된 401, 400 에러들이 다수 관측됨.
  • 해당 요청들은 Spring Security의 Filter Chain 단계에서 즉시 차단된 악성/비인가 요청 ⇒ 비정상적인 요청이 비즈니스 로직(Controller)까지 진입하여 자원을 소모하기 전에 앞단(Filter)에서 효율적으로 거부되고 있다는 뜻..
• 지표들 기반으로 코드 수정점 발견 시 코드 개선 필요
  
  이에 따른 코드 개선점에 대해 다음 글에서 설명하도록 하겠다.