모니터링 시스템은 인프라의 안정성을 책임지는 ‘파수꾼’이다. 하지만 파수꾼 자체가 병들거나 멈춘다면, 시스템 전체는 아무런 예보 없이 재난을 맞이하게 된다. 이를 방지하기 위해 모니터링 도구(Prometheus, Grafana, Alertmanager 등)의 상태를 스스로 감시하는 Self-Monitoring 체계 구축은 선택이 아닌 필수다. 본 글에서는 Prometheus 생태계를 중심으로 자가 진단 메트릭의 종류와 효과적인 대시보드 구성, 그리고 경보 설정 방안을 상세히 기술한다.
목차
- Self-Monitoring의 개념과 필요성
- Prometheus 자가 진단 메트릭 분석
- 수집 효율성 및 성능 지표
- 스토리지 및 메모리 안정성
- Alertmanager 및 Grafana 상태 감시
- 모니터링 시스템 전용 알람 설계
- 결론: “누가 파수꾼을 감시하는가?”
1. Self-Monitoring의 개념과 필요성
Self-Monitoring이란 모니터링 서버 자체의 CPU, 메모리 사용량은 물론, 데이터 수집 프로세스의 지연, 쿼리 처리 속도, 알람 전송 성공률 등을 지표화하여 관리하는 것을 의미한다.
모니터링 시스템이 중단되는 주요 원인은 다음과 같다.
- 메트릭 폭발(Cardinality Explosion): 갑자기 늘어난 라벨 조합으로 인해 메모리가 고갈되어 서버가 다운되는 경우.
- 디스크 풀(Disk Full): 데이터 보존 정책 설정 오류로 인해 시계열 데이터가 디스크를 가득 채우는 경우.
- 쿼리 부하: 무거운 Grafana 대시보드 요청이 쏟아져 Prometheus 응답이 마비되는 경우.
이러한 상황을 실시간으로 인지하지 못하면 실제 서비스 장애가 발생했을 때 아무런 데이터를 확인할 수 없는 ‘블랙아웃’ 상태에 빠지게 된다.
2. Prometheus 자가 진단 메트릭 분석
Prometheus는 기본적으로 http://localhost:9090/metrics 엔드포인트를 통해 자신의 상태를 노출한다. 이를 스스로 수집하도록 설정하여 관리해야 한다.
수집 효율성 및 성능 지표
prometheus_target_scrapes_exceeded_sample_limit_total: 샘플 제한을 초과하여 수집이 중단된 타겟의 수.prometheus_sd_discovered_targets: 서비스 디스커버리(SD)를 통해 발견된 전체 타겟 수. 이 수치가 급변한다면 인프라 설정 오류를 의심해야 한다.prometheus_engine_query_duration_seconds: 쿼리 처리 시간. 이 지표가 상승하면 대시보드 로딩 속도가 느려지고 사용자 경험이 저하된다.
스토리지 및 메모리 안정성
prometheus_tsdb_head_chunks: 현재 메모리 상에 머물고 있는 데이터 조각의 수. 이 수치는 메모리 사용량과 직결된다.prometheus_tsdb_wal_corruptions_total: 쓰기 로그(WAL) 부패 횟수. 디스크 장애나 비정상 종료를 파악하는 핵심 지표다.
3. Alertmanager 및 Grafana 상태 감시
Prometheus뿐만 아니라 알람을 전달하는 Alertmanager와 시각화를 담당하는 Grafana 역시 감시 대상이다.
- Alertmanager:
alertmanager_notifications_failed_total지표를 통해 이메일이나 슬랙으로 알람이 나가지 않는 상황을 감시해야 한다. 알람을 보냈는데 수신에 실패하는 것만큼 위험한 상황은 없다. - Grafana:
/metrics엔드포인트를 활성화하여 활성 사용자 수, 대시보드 로딩 실패 횟수, 데이터 소스 연결 오류 등을 모니터링한다.
4. 모니터링 시스템 전용 알람 설계
Self-Monitoring의 알람은 일반 서비스 알람과 분리되어야 한다. 모니터링 시스템이 죽으면 알람도 죽기 때문에, 가급적 **외부의 독립된 감시 장치(Dead Man’s Snitch 등)**를 병행하는 것이 좋다.
- Prometheus Down 알람: Prometheus가 일정 시간 동안 데이터를 수집하지 못하면 즉시 알람을 보낸다.
- 메모리 임계치 알람:
process_resident_memory_bytes가 서버 가용 자원의 80%를 넘어서면 ‘Cardinality 확인’ 경고를 발송한다. - 알람 전송 실패 알람: Alertmanager에서 알람 전송 실패 로그가 발견되면 보조 수단(예: 문자 메시지)을 통해 통보한다.
5. 결론: “누가 파수꾼을 감시하는가?”
“Quis custodiet ipsos custodes?(누가 파수꾼을 감시하는가?)”라는 고대의 질문은 현대의 SRE(Site Reliability Engineering) 환경에서도 여전히 유효하다. 완벽한 모니터링 시스템은 존재하지 않으며, 오직 자가 진단을 통해 끊임없이 자신의 상태를 보고하는 시스템만이 신뢰를 얻을 수 있다.
Prometheus의 내부 메트릭을 체계적으로 수집하고 전용 대시보드를 구축하는 것은 모니터링의 완성이자 시작이다. 서비스 인프라를 구축할 때 반드시 Self-Monitoring을 초기 단계에 포함시켜 ‘가시성 없는 장애’의 공포로부터 해방되길 바란다.
