Prometheus·Grafana·Alertmanager에서 RCA Platform의 관측 경로 확인하기

Kubernetes에 애플리케이션을 올린 뒤에는 Ready 표시 밖의 상태를 보고 싶었다. Pod가 실행 중이어도 메트릭이 수집되지 않을 수 있고, 메트릭을 수집해도 경고가 처리되는 경로는 끊겨 있을 수 있다. 그래서 Prometheus 수집 대상, Grafana 자원 사용량, Alertmanager의 현재 경고를 각각 확인했다.

이번 구성에서는 Prometheus가 메트릭을 수집하고 Grafana가 같은 환경의 시계열을 보여 준다. Alertmanager는 경고를 모아 RCA Platform으로 전달하는 경로에 들어간다.

UP 두 개는 Prometheus 복제본 두 개가 아니었다

Prometheus의 Targets에서 RCA Platform으로 범위를 좁혔다. Platform Pod 두 개의 수집 대상이 모두 UP이었다. 이 결과는 Prometheus가 각 대상의 메트릭 endpoint를 읽고 있다는 뜻이다.

여기서 숫자의 대상을 정확히 나눠야 했다. 화면의 두 개는 scrape target이고, Prometheus 서버 자체는 StatefulSet 1/1이었다. Platform을 Worker 두 대에 분산했다고 모니터링 서버까지 이중화된 것으로 설명하지 않았다. 수집 대상의 수와 관측 시스템의 가용성은 다른 항목이다.

클러스터 전체와 rca-system을 따로 봤다

먼저 클러스터 대시보드에서 CPU와 메모리, namespace별 사용량을 확인했다. 어느 namespace에 자원이 모여 있는지 보는 출발점으로 썼다. 최근 1시간 구간을 UTC 시간축으로 조회했다.

다음에는 namespace를 rca-system으로 좁혔다. Platform 두 Pod, PostgreSQL, 관찰용 Agent를 같은 화면에서 비교했다. 사용량과 requests·limits를 함께 봐야 스케줄러에 예약한 양과 실제 사용량의 차이를 읽을 수 있었다.

메모리는 CPU와 별도 화면에서 확인했다. 순간 CPU 사용량과 메모리 유지 양상은 다를 수 있기 때문이다.

Alertmanager의 현재 화면과 과거 처리 흐름을 구분했다

Alertmanager에서는 현재 Watchdog 알림을 확인했다.

Alertmanager에서 RCA Platform으로 넘어가는 전체 경로는 별도의 검증 기록을 사용했다. 앞서 제한된 합성 신호가 firing으로 들어오고, evidence 수집 요청과 analysis, report completed, upstream 해제 뒤 resolved로 이어지는 것을 확인했다. 실제 Worker 장애를 만들거나 자동 복구 명령을 수행한 시험은 아니다. 그 흐름은 뒤의 RCA 연동 글에서 ID와 상태를 중심으로 다룬다.

대시보드와 서비스 검증을 연결한 기준

이번 관측에서 확인한 것은 Platform 수집 대상 두 개의 UP, 클러스터·namespace 자원 시계열, Alertmanager의 현재 경고였다. HTTPS readiness 200, 실제 Pod imageID, DB·PVC와 기존 보고서 해시 확인은 별도 증거로 남겼다.

모니터링을 설치한 것과 운영 판단에 쓸 수 있게 정리하는 일은 달랐다. 이후 용량을 조정하거나 경고를 추가할 때도 어떤 지표를 어느 기간에 보고, 어느 서비스 검증과 연결해 판단했는지 함께 남길 생각이다. 단일 Prometheus와 단일 DB 같은 남은 장애 지점도 이 관측 결과와 분리해 관리한다.