Prometheus 네임스페이스 모니터링 수정
Source: Dev.to

설정
저는 Prometheus Operator와 꽤 표준적인 디스커버리 패턴을 사용해 Kubernetes 클러스터를 운영하고 있습니다:
ServiceMonitor객체- 네임스페이스 기반 스크레이프 선택
- Grafana 대시보드와 Alertmanager 규칙 연동
핵심은 Prometheus가 특정 라벨이 붙은 네임스페이스만 스크레이프한다는 점입니다.
다음은 ServiceMonitor의 간소화된 예시입니다:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: app-servicemonitor
spec:
selector:
matchLabels:
app: payments-api
namespaceSelector:
matchLabels:
monitoring: enabled
endpoints:
- port: metrics
interval: 30s
이 시점에서 네임스페이스 라벨은 사실상 모니터링 설정의 일부가 됩니다.
문제 일으키기
연습을 위해 네임스페이스에서 monitoring=enabled 라벨을 제거했습니다.
- 아무런 오류도 발생하지 않았습니다.
- 파드들은 계속 실행되었습니다.
- 메트릭은 조용히 사라졌습니다.
바로 놓치기 쉬운 종류의 실패였습니다.
무엇이 잘못됐는지 감지하기
먼저 확인한 것은 Prometheus 자체가 비정상이 아닌지였습니다:
kubectl get pods -n monitoring
kubectl logs prometheus-k8s-0 -n monitoring
모두 정상으로 보였습니다.
다음으로, Prometheus가 해당 네임스페이스에서 어떤 것을 스크레이프하고 있는지 확인했습니다:
up{namespace="payments-prod"}
결과가 없습니다. 이는 앱이 다운된 것이 아니라 Prometheus가 타깃을 스크레이프하지 않고 있다는 뜻입니다.
원인 찾기
다음 단계는 네임스페이스 자체를 확인하는 것이었습니다:
kubectl get namespace payments-prod --show-labels
출력은 다음과 같았습니다:
monitoring=disabled
ServiceMonitor가 다음을 기반으로 동작한다는 점을 기억하세요:
namespaceSelector:
matchLabels:
monitoring: enabled
Prometheus는 설정된 대로 정확히 동작하고 있었습니다. Prometheus 입장에서는 아무것도 깨진 것이 없었습니다.
해결 방법
라벨을 복구하면 충분했습니다:
kubectl label namespace payments-prod monitoring=enabled --overwrite
스크레이프 간격 내에 메트릭이 다시 나타났습니다.
신선도를 확인하는 간단한 체크:
time() - timestamp(up{namespace="payments-prod"})
다시 모든 것이 보이게 되었습니다.
왜 이것이 교묘한 실패인가
이번 연습의 흥미로운 점:
- 알림이 전혀 발생하지 않았습니다.
- 대시보드는 비어 있었지만 빨간색 경고는 없었습니다.
- Prometheus는 누락된 데이터를 “평가할 것이 없음”으로 처리합니다.
만약 이 기간 동안 실제 문제가 발생했다면 전혀 알 수 없었을 것입니다. 이것이 눈에 보이지 않는 “녹색” 시스템을 신뢰하게 만드는 이유입니다.
이후 강화 방안
누락된 메트릭에 대한 알림
텔레메트리 손실을 잡기 위해 명시적인 알림을 추가했습니다:
- alert: NamespaceMetricsMissing
expr: absent(up{namespace="payments-prod"})
for: 5m
labels:
severity: critical
annotations:
summary: "No metrics from payments-prod"
description: "Prometheus is scraping zero targets in this namespace."