공부하다보니 service monitor와 pod monitor에 대한 개념이 빈약하다고 느껴 정리를 해야겠다는 생각이 들었다.
각 개념을 설명하고 두 모니터의 차이를 비교해서 적을 것이다.
PodMonitor란?
PodMonitor는 “파드 자체를 직접 선택해서(PodSelector)” 메트릭을 수집하는 리소스이다.
즉,
- 대상이 Service 로 추상화되어 있지 않거나,
- 애초에 Service가 없는 Pod에서 직접 메트릭을 scrape 하고 싶을 때 사용한다.
Pod 단위로 접근하므로 다음 특징을 갖는다.
PodMonitor 특징
- Pod의 "레이블"을 기준으로 타겟 선택
- Pod 내부의 containerPort 또는 annotation 기반 포트를 scrape
- Sidecar 방식으로 exporter를 띄운 구조에서도 유용
PodMonitor를 쓰면 유용한 경우
- Service 없이 배포된 Pod
- StatefulSet 등으로 여러 Pod가 있을 때 각 Pod를 개별적으로 scrape 하고 싶을 때
- Exporter가 Pod 내부에서 바로 노출되고 외부 Service 필요가 없을 때
ServiceMonitor란?
ServiceMonitor는 “Service에 연결된 엔드포인트”를 통해 메트릭을 수집하는 리소스이다.
즉,
Prometheus가 직접 Pod를 바라보는 것이 아니라,
Service → Endpoints → Pod 로 이어지는 Kubernetes 기본 구조를 그대로 활용한다.
ServiceMonitor 특징
- Service의 selector 를 참조하여 Pod를 간접적으로 선택한다.
- 고정된 서비스 엔드포인트(Service IP) 기준으로 안정적인 scraping
- LoadBalancer, ClusterIP 등 서비스 타입과 무관하게 동작
ServiceMonitor를 쓰면 좋은 경우
- 이미 애플리케이션이 Service로 관리되고 있고 안정적 Endpoints 접근이 필요한 경우
- 여러 Pod를 하나의 Service로 묶어 scrape 하는 경우
- Production 환경처럼 안정적인 접근 경로가 필요한 경우
PodMonitor vs ServiceMonitor 차이
| 구분 | PodMonitor | ServiceMonitor |
|---|---|---|
| 선택 기준 | Pod label 직접 참조 | Service label을 통해 간접적으로 Pod 선택 |
| scrape 경로 | Pod IP 직접 접근 | Service → Endpoint → Pod 접근 |
| 서비스 필요 여부 | 필요 없음 | 반드시 Service 필요 |
| 대상 변경 안정성 | Pod IP 변하면 영향 큼 | Service가 IP 변화를 추상화함 |
| 사용 적합 상황 | 테스트, exporter sidecar, 서비스 없는 Pod | 운영 환경, 안정적 서비스 트래픽 구조 |
예시 YAML 파일로 예시 비교
PodMonitor 예시
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: myapp-podmonitor
namespace: monitoring
spec:
selector:
matchLabels:
app: myapp
namespaceSelector:
matchNames:
- default
podMetricsEndpoints:
- port: metrics
interval: 15s- selector 로 Pod 레이블을 선택
- podMetricsEndpoints 로 Pod의 포트를 직접 지정
- Service 없이도 동작 가능
ServiceMonitor 예시
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: myapp-servicemonitor
namespace: monitoring
spec:
selector:
matchLabels:
app: myapp
namespaceSelector:
matchNames:
- default
endpoints:
- port: metrics
interval: 15s- selector.matchLabels: Service의 레이블을 선택
- Service가 선택된 후 Endpoints 를 통해 Pod로 연결됨
- 안정적이고 운영환경에서 선호됨
어떤 상황에서 무엇을 선택하면 좋을지
PodMonitor 선택
- 개발환경 / 테스트환경
- 따로 Service를 만들지 않은 Pod
- Pod가 자주 재생성되고 label 기반으로만 추적하고 싶을 때
- Sidecar exporter 구조
ServiceMonitor 선택
- 운영 환경 (Production)
- 애플리케이션이 안정적인 Service abstraction 위에서 돌아갈 때
- LoadBalancer, NodePort, ClusterIP 등 서비스 경로를 유지해야 할 때
- 대부분의 Kubernetes 애플리케이션 모니터링
결론
Pod Monitor은 Pod 자체를 직접 바라보는 모니터링 방식이며,
Service Monitor은 Service를 통해 안정적으로 Pod를 바라보는 방식이다.
둘 다 Prometheus Operator에서 사용되는 CRD이지만
대상이 무엇인지, 접근 경로를 어디를 기준으로 하는지에 따라 기술적으로 분명한 차이가 있다.
운영환경에서는 보통 ServiceMonitor가 더 적합하며,
개발환경이나, Service가 없는 Pod, 또는 Sidecar exporter를 붙인 구조는
PodMonitor가 더 유연하게 활용된다.
참고자료
[프로메테우스 공식 깃허브 홈페이지 - Service Monitor, Pod Monitor]
https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/getting-started/design.md#servicemonitor
