Prometheus의 기본 수집 방식 (Pull)
• Prometheus 서버가 주기적으로(Target scrape interval)
각 대상(exporter, 애플리케이션)의 HTTP endpoint에 직접 요청합니다.
• 보통 /metrics 엔드포인트를 사용합니다.
• 대상이 제공하는 현재 시점의 메트릭 스냅샷을 가져옵니다.
Prometheus Server ---> HTTP GET /metrics ---> Target (Exporter/App)이 구조가 Prometheus 설계의 중심입니다.
⸻
왜 Pull 모델을 선택했는가
Pull 모델은 Prometheus 철학과 잘 맞습니다.
1. 서비스 디스커버리와 궁합이 좋음
• Kubernetes, Consul, EC2 등에서 대상이 동적으로 변해도
• Prometheus가 “누구를 수집할지”를 스스로 결정
2. 장애 격리가 쉬움
• 대상이 죽어도 Prometheus는 scrape 실패로 인지
• 대상이 Prometheus 상태를 신경 쓸 필요 없음
3. 재현성과 디버깅
• 브라우저나 curl로 /metrics 직접 확인 가능
• “이 시점에 무엇이 노출되는가”가 명확
⸻
예외: Push 방식도 존재함 (Pushgateway)
Prometheus 생태계에는 예외적으로 Push 방식이 있습니다.
Pushgateway
• 짧게 실행되는 batch job을 위한 보조 컴포넌트
• job이 직접 Prometheus로 보내는 게 아니라,
Pushgateway에 push
• Prometheus는 Pushgateway를 pull
Batch Job ---> Pushgateway <--- Prometheus (pull)중요한 점:
• Prometheus 자체는 여전히 Pull
• Pushgateway는 임시 저장소 역할
⸻
정리
• Prometheus 본체의 수집 모델은 Pull
• Push는 예외적 보완 수단
• 설계 철학상 Push 중심 모니터링 시스템과는 명확히 다름
한 줄 요약하면:
Prometheus는 Pull-first 시스템이며, Push는 특수한 경우에만 사용된다.