Push vs Pull - 모니터링 데이터 수집 방식

모니터링 시스템은 크게 Pull/Push 방식이 있다.

Push와 Pull의 기본 개념

• Push: 데이터를 가진 곳에서, 필요한 곳으로 보내준다.
• Pull: 데이터가 필요한 곳에서, 가진 곳에 접속하여 데이터를 긁어간다.

Push 방식 - Nagios, Zabbix

메트릭은 중앙에서 정의되고 할당된 에이전트에 푸시된다.
수집된 데이터는 에이전트가 중앙 서버로 보낸다.

Pull 방식 - Prometheus, Datadog, collectd

에이전트 자체에 메트릭 정보가 포함되어 있다.
에이전트는 메트릭을 수집하며, 중앙 시스템으로 데이터 전송을 위한 정보가 보통 에이전트에 포함되어있다.
수집된 데이터는 중앙서버가 에이전트에서 긁어간다.

Pull vs Push

Push 방식은 중앙집중형이기에, 중앙 모니터링 시스템이 데이터 수집 항목, 수집할 서버를 모두 관리하고 있다.
반면 Pull 방식은 분산형으로, 중앙시스템은 에이전트가 보내주는 데이터를 긁어갈 수만 있으며, 어떤 데이터를 수집할지 중앙에서 변경할 수 없다.

두 방식의 장단점은 관점에 따라 다르다.
수 많은 관점들이 있겠지만, 일부 관점들을 서술하자면 아래와 같다.

수집 대상이 Auto-scaling 등으로 가변적일 경우, Push 방식이 Pull 방식보다 유리하다.
만약 새로운 수집 Host가 추가될 경우, Push방식에서는 Host가 Data-Backend로 수집데이터를 보내주기에, 전송된 데이터를 받기만 하면된다. 하지만 Pull 방식에선 Data-Backend가 수집 Host로 접속하여 데이터를 긁어가야 하기에, 중앙서버에서 pull해갈 Host/Service의 목록들을 관리하여야 한다.

수집 대상의 유연성 측면에서는 Pull 방식이 Push 방식보다 유리하다.
Pull 방식에서 중앙서버는 데이터를 수동적으로 긁어가기만 하기에, Pull system에서 Data-Backend는 언제든지 새로운 데이터(unplanned metrics)들을 수용할 수 있으며 모든 메트릭을 요청할 수 있도록 구현되어있다. 하지만 Push 방식에선 메트릭을 중앙에서 정의하고 에이전트로 푸시하는 구조이며, 새로운 메트릭 수용을 위해서는 중앙 서버에서 해당 변경사항을 반영해줘야한다.

보안 측면에서는 Push가 Pull보다 유리하다
Pull방식은 수집 대상 서버에서 중앙 폴러가 접근할 수 있는 포트, IP 등을 수신 대기해야 한다.

HA 측면에서 Pull이 Push 방식보다 유리하다.
Data-Backend에서 장애가 발생하더라도, Pull 방식에선 수집 Host에 영향이 없으나 Push 방식에선 데이터 전송 재시도 등 Host에 영향이 생긴다.