[Prometheus] 모니터링 push/pull configuration

https://steve-mushero.medium.com/push-vs-pull-configs-for-monitoring-c541eaf9e927

Push vs. Pull Configs for Monitoring

 

Push

• Traditional system에서 흔히 사용
  - ex) Nagios / Zabbix
• Metric이 중앙에서 정의됨
• 지정된 host / agent로 push
• 종종 auto-discover가 가능하나, 이 또한 중앙에서 정의됨
• 중앙 시스템이 boss
  - agent들이 중앙 시스템의 config를 따름

 

Pull

• Agent 자체가 모니터링 설정을 포함
  - ex) Datadog / collectd / Prometheus
• Agent가 기능을 가짐
  - 무엇을 수집해야하는지 인지
  - 무엇을 중앙 시스템에 push해야하는지 인지
• 중앙 시스템에서 에이전트로부터 설정값 또는 metric 메타데이터를 가져옴
• Agent가 boss (Agent-defined configs)
  - 중앙 시스템이 agent들의 config 따름

 

차이점

• Push system
  • 중앙 모니터링 시스템
    - metric에 대한 모든 정보를 가지고 있음
    - 누가 가지고 있는지, 그것이 무엇인지 등등
• Pull system
  • 중앙 모니터링 시스템
    - 아는 게 거의 없음
    - 무엇이 오는지, 언제 오는지, 누가 보내는지
  • 이를 알리기 위해 사용되는 것
    - Prometheus : 이름
    - Datadog : 관련 내용 공유

 

Push의 장점

• 중앙화
  • 변경이 쉬움
• 원하는 항목 지정으로 수백개의 metric을 가져올 수 있음
  • flexible & dynamic
  • real-time
• template을 통해 새 host/service를 빠르고 쉽게 정의
  • new host monitoring의 복잡도를 낮춤
  • 검증된 best practices를 그대로 사용 가능
• graph / map / alert이 명확함
  • 모든 데이터, 타입, 단위가 미리 알려진 상태이기 때문

 

Pull의 장점

• ad-hoc / unplanned metric 수집
  
  • 같은 metric도 다른 unit / tag 등으로 수집 가능
  • 언제든 이러한 형태의 metric 추가 가능
• 더 현대적으로 tag / metadata 등을 수집
  • metrics / event / event log 등의 경계가 사라지고 혼합
  • 풍부한 query / visualization / 문제 해결이 가능

 

Pull의 단점

• 중앙 시스템이 metric에 대한 정보가 없음
  • 이를 보완하기 위해 Datadog은 agent와 중앙 시스템이 정보를 공유
  • 제한적이고 확장이 어려움
    - Dynamic하지만, 어떤 host에 어떤 metric이 있는지 query를 날려 확인해봐야함