Prometheus Pull 방식의 장점

프로메테우스의 핵심 아키텍처인 pull 방식은 서버가 주기적으로 클라이언트의 메트릭을 긁어오는 방식이다

기존의 많은 모니터링 시스템(예: Zabbix agent, Telegraf, StatsD)은 클라이언트가 서버로 데이터를 밀어넣는 push 방식을 사용햇다.

하지만 프로메테우스는 과감하게 pull 방식을 제거해속 이는 클라우드 네이티브 msa환경에서 강점으로 작용한다

push 방식은 클라이언트로부터 데이터가 오지 않을 때, 이것이 네트워크 단절 때문인지 클라이언트 서버다운 때문인지

아니면 단순히 보낼 메트릭이 없는것인지 즉각적으로 판별하기가 어려웠다.

하지만 pull 방식에서는 프로메테우스 서버가 특정 타겟에 http 요청 (보통 /metrics)를 보냈을때 응답이 없거나 실패하면 즉시 해당 타겟에 장애가 발생했음을 확신할 수 있다.

프로메테우스는 이 상태를 up 이라는 메트릭 (정상1, 실패0)으로 자동생성하여 아주 직관적이고 확실한 타겟 헬스체크를 제공한다.

flow control 부분인데 push 방식은 타겟 서버가 수천, 수만대로 늘어날경우 수많은 에이전트가 일제히 모니터링 서버로 데이터를 쏟아내는 ddos같은 상황이 발생이 가능하다.

결국 모니터링 서버 자체가 받는 트래픽때문에 과부하에 걸려 뻗어버릴 수가 있는 문제가 있는것임

반면 pull 방식에서는 데이터 수집의 주도권을 모ㄴ티러이 서버가 가지고 타겟이 아무리 많아도 프로메테우스가 자신의 처리 능력에 맞게 수집 주기를 조절하고 수집 개수를 제한할 수 있으므로

모니터링 시스템 자체가 과부하로 무너지는것을 방지할 수 잇다.

push 방식에서는 클라이언트가 모니터링 서버의 ip 주소와 포트, 인증 정보를 알고있어야 한다.

모니터링 서버 구성이 바뀌면 모든 클라이언트의 설정을 변경해야하는 끔찍한 상황이 발생한다.

하지만 pull 방식에서는 클라이언트는 그저 자신의 특정 포트로 메트릭을 노출시키기만 해두면 되기 때문에

데이터를 누가 가져갔는지 모니터링 서버가 어디에 있는지를 전혀 알 필요가 없다. 이는 각 서비스가 모니터링 인프라와 완벽하게 디커플링됨을 의미한다.

여러 대의 프로메테우스 서브를 두어 고가용성을 구성할 때 pull 방식은 압도적으로 편리하다.

클라이언트가 설정 변경 없이, 단순히 여러 대의 프로메테우스 서버가 동일한 타겟을 바라보고 각자 데이터를 긁어가게 만들면 끝이다.

push 방식이였다면 클라이언트가 두 대의 모니터링 서버로 각각 데이터를 전송하도록 트래픽을 복제하는 추가 구성이 필요했을거임.

개발자가 메트릭 수집 로직을 작성한 후 제대로 데이터가 나오는지 확인하고 시픙ㄹ땐 pull 방식은 좋다.

단순히 브라우저를 열어서 터미널에 curl http://localhost:8080/metrics 를 치기만 해도 되기때문에

프로메테우스가 수집해갈 형태를 데이터 평문으로 바로 확인이 가능하기에 복잡한 가짜 수집서버를 띄울 필요가없다.

물론 pull 방식이 만능은 아니다 타겟 서버가 방화벽/nat에 꼼꼼 숨겨져 있어 외부(프로메테우스)에 접근할 수 없는 네트워크 환경이거나

수 초만에 실행되고 종료되는 배치성 작업의 경우에는 직접 pull하기 어렵다는 치명적인 단점이 있다.

프로메테우스는 이러한 pull 방식의 한계를 극복하기위해 pushgateway라는 우회책을 제공하고 있다.