모니터링 시스템의 메트릭 수집 방식

모니터링 시스템에는 메트릭 수집을 위한 두 가지 방식의 메커니즘이 존재합니다. 바로 Pull 방식과 Push 방식입니다. 프로메테우스는 어떤 방식의 메커니즘을 사용하나요? 또한 Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해 보세요.

 

Metric 수집 방식: Pull vs Push

pull 기반 모니터링 시스템은 능동적으로 지표를 획득하는 모니터링 시스템으로, 모니터링이 필요한 오브젝트에 원격으로 접근할 수 있어야 한다.
push 기반 모니터링 시스템은 모니터링이 필요한 오브젝트가 적극적으로 지표를 푸시한다.

 -> 두 가지 방법에는 여러 측면에서 차이점이 크다. 모니터링 시스템의 구축 및 선택을 위해서는 두 가지 방법의 장단점을 미리 이해하고 적절한 구현 방식을 선택해야 한다.

 

 

Pull  장점

데이터를 가져올 때 서버 자체가 연결을 시작하기 때문에 데이터의 신뢰성을 확신할 수 있다.

TCP 기반 Pull 시스템에서는 메트릭에 직접 액세스 할 수 있어야 함

즉, 메트릭 데이터를 사용할 수 있는 포트는 항상 수신 대기인 반면 푸시 기반 시스템의 경우 매우 빠르게 사라지고 나타나는 임시 연결이 사용됨

또한 메트릭 데이터를 수집할 정확한 대상을 미리 알고 있기 때문에 풀 기반 시스템의 용량을 더 쉽게 계획할 수 있다. 

반면에 푸시 기반 시스템에서는 모든 종류의 시스템이 메트릭 수집 서버로 푸시할 수 있다.
 
이 문제는 데이터를 수락할 서버의 화이트리스트를 사용하여 해결할 수 있지만 대부분의 푸시 기반 시스템은 이를 지원하지 않는다. 또한 구현이 아닌 두 가지 다른 모델의 특성을 고려.

 

TCP(HTTP) 위에 pull 메서드가 있다는 것은 요청 시 데이터를 검색하고 문제를 디버그 하는 것이 매우 쉽다는 것을 의미

특히 메트릭 데이터가 Prometheus에서 사용하는 형식과 같이 사람이 읽을 수 있고 쉽게 이해할 수 있는 경우 클라이언트 측과 서버 측의 오류를 쉽게 구별할 수 있음
푸시 방법에서는 사용자가 할 수 있는 범위가 제한적이게 됨 그 이유는 어떤 측정항목도 수신하지 못한다면 다음 두 가지 중 하나를 의미하기 때문
-> 네트워크에 문제가 있는 경우
-> 클라이언트에 문제가 있는 경우

푸시(TCP/HTTP) 방식으로 웹 브라우저에서 메트릭 데이터를 찾을 수 있는 IP 주소와 포트로 이동하기만 하면 이 둘 사이를 쉽게 확인할 수 있었음

TCP 연결 재설정을 받으면 네트워크는 정상이지만 클라이언트에 문제가 있음을 의미 

응답이 없으면 네트워크에 문제가 있음을 의미

물론 이것은 포트가 닫힐 때 TCP_RST를 되돌려 보내는 클라이언트에 따라 다르지만 대부분의 기계가 작동하는 방식

 

 

Push 장점

모든 것이 클라이언트 자체에 의해 시작되기 때문에 동일한 트래픽을 다른 서버에 복제하는 것이 더 쉬워진다

둘 이상의 대상 IP 주소로 전송하기만 하면 됨
또한 모든 수신기가 동일한 정확한 데이터를 얻을 수 있음

HTTP pull 방법을 사용하는 Prometheus의 두 가지 다른 인스턴스를 가동하면 동일한 데이터가 없을 가능성이 큼
-> 타임스탬프가 다름. Graphite의 경우 타임스탬프는 데이터 내부에 인코딩되어야 합니다. (Prometheus에서는 선택 사항) 스크래핑
-> 시작 시 추가된 지터로 인해 대부분의 시간 스크래핑이 동시에 발생하지 않기 때문에 시계열 값이 다를 가능성이 가장 높습니다.

 

푸시 방법에서는 클라이언트 자체가 메트릭을 서버에 푸시한다

반면에 pull 방식에서는 서버가 주기적으로 클라이언트를 조사하고 메트릭을 수집한다

프로메테우스에서는 이것을 scrape period이라고 함. 클라이언트가 기간보다 오래 생존하지 않으면 메트릭이 손실. 이 그림은 루프가 어떻게 작동하는지 설명한다.

 

 

Prometheus 스크랩 루프 및 경고 설명

푸시 방식에서는 일괄 작업이 완료될 때마다 메트릭을 보낼 수 있으므로 이에 대한 문제가 없음
물론 프로메테우스는 pushgateway 라는 것으로 이를 해결할 수 있음
기본적으로 Prometheus의 Graphite라고도 하는 Prometheus에 의해 주기적으로 스크랩되는 메트릭 수신기
이것은 graphite-exporter 와 같은 방식으로 작동

그럼에도 불구하고 문제는 여전히 존재
예를 들어 푸시 게이트웨이가 다운되면 메트릭이 사라질 수 있음. 또는 클라이언트가 Prometheus가 긁을 수 있는 것보다 빠르게 업데이트하면 메트릭 값이 손실될 수 있음.
푸시 방식과 Graphite는 이 문제를 겪지 않음.

 

푸시 방식은 일반적으로 UDP를 사용하는 반면 풀 방식은 TCP(HTTP)를 기반을 사용

즉, 메트릭스를 추출하는 것보다 잠재적으로 메트릭스를 더 효과적으로 푸시할 수 있음
이는 UDP 연결을 관리하기 위한 오버헤드가 훨씬 적기 때문
예를 들어 피어에게 보낸 메시지가 실제로 수신되었고 올바른 순서로 수신되었는지 확인할 필요가 없음
그러나 TCP 지원이 대부분의 상용 네트워크 카드에 내장되어 있고 하드웨어 가속을 사용하는 운영 체제가 곳곳에 있기 때문에 오버헤드는 예를 들어 90년대처럼 크지 않을 수 있음

Principle and Architecture Comparison

좌측: Pull 우측: Push

 

Pull

위 그림에서 보듯이 Pull 모델의 데이터 수집 방식의 핵심은, 프로메테우스와 같은 모니터링 백엔드와 함께 일반적으로 배포되는 Pull Module이다. 핵심 구성요소는 다음과 같다.

 

Host service dsicovery(일반적으로 회사의 CMDB system을 따름), Application service discovery(Consul 등), PaaS service discovery(K8s 등)을 포함하는 Service Discovery System이다.

 

Pull module은 이런 service discovery system에 연결할 수 있는 기능이 있어야 한다. 서비스 디스커버리 파트 이외에도, Pull module은 remote end에서 데이터를 pull 하기 위한 공통 프로토콜을 사용한다. 일반적으로 pull interval, timeout interval, metric filtering, rename 및 간단한 프로세스 기능 설정을 제공한다.

 

Application-end SDK 는 풀을 위한 고정 포트를 제공한다.

 

다양한 미들웨어 및 기타 시스템이 Pull protocol과 호환되지 않으므로 Exporter에 해당하는 Agent를 개발하여 이러한 시스템의 메트릭을 풀링하고 표준 Pull interface를 제공해야 한다.

 

 

Push

Push Agent는 모니터링되는 다양한 오브젝트의 메트릭 데이터를 가져와 서버에 푸시할 수 있도록 지원한다. 모니터링 시스템과 결합된 방식으로 배포될 수 있고, 분리되어 배포될 수도 있다.

 

ConfigCenter (optional)는 모니터링 대상, 수집 간격, 메트릭 필터링, 메트릭 처리 및 remote targets와 같은 중앙 집중식 동적 구성 기능을 제공할 수 있다.

 

Application-end SDK는 모니터링 백엔드나 로컬 에이전트로의 데이터 전송을 지원한다. (일반적으로 로컬 에이전트는 백엔드 인터페이스로 구현.)

 

 

참조 레퍼런스

https://velog.io/@xgro/Push-vs-Pull

Push vs Pull

https://velog.io/@hyunshoon/Monitoring-Pull-vs-Push-%EB% 8F%99% EC% 9E%91-%EB% B0% A9% EC% 8B%9D-%EB% B0%8F-%EC% 9B%90% EB% A6% AC-%EC% 9D% B4% ED%95% B4

[Monitoring] Pull vs Push 동작 방식 및 원리 이해