prometheus는 기본적으로 scrape을 전제로 만들어졌는데, 잠깐 떴다 사라지는 k8s Job 같은건 scrape 하기 전에 종료돼 지표 수집이 어려운 점이 있다.

그래서 그런 Short-lived Job -> ? -> prometheus 식으로 지표를 받을 수 있는 무언가가 있는데, 그게 바로 Pushgateway이다.

 

그럼 그런 생각이 들 수 있다. "뭐하러 스크래핑을 하지? 지표를 그냥 모든 앱에서 prom pushgateway로 쏘면 되겠네. service discovery도 필요없고 엔드포인트 하나만 있으면 되겠구만."

하지만 앞에서도 말했다시피 prometheus는 scrape을 가정하고 짠거라서 pushgateway는 여러가지로 기존 메트릭 수집과 충돌이 나는 부분이 있다 (예를 들면 https://stackoverflow.com/a/76058986/4295499 이 답변의 예제를 보자)

pushgw에 쌓인 series는 deletion api로 명시적으로 지우지 않으면 계속 남기도 하고, push 주기는 랜덤이라 prom의 scrape 주기랑 달라서 메트릭이 역전되는 등 이상하게 보일 수 있다.

 

We only recommend using the Pushgateway in certain limited cases.
...
Usually, the only valid use case for the Pushgateway is for capturing the outcome of a service-level batch job
.

pushgw를 웬만하면 쓰지 말라는건 문서에도 강조되어 있다.

 

그런데 만약 push-based 메트릭 모니터링 시스템이 필요하다면 어떨까? 예를 들면 client-side web app의 메트릭을 수집해야 하는 경우가 있을 수 있다. 이 경우엔 서버 -> 클라 스크랩이 어렵고(또는 불가능하고), 클라에서 메트릭을 push 하는 것이 이상적이다

그래서 push-based 모니터링 시스템이 많은데, influxDB+telegraf나 pusherjs 등을 쓸 수 있겠다. 아니면 간단히 rate limiter만 붙인 vmgateway(enterprise만 가능) 같은것도 있다.

근데 이미 prometheus 시스템을 구축해놨고, 이걸 활용하고 싶다면? 또, counter / histogram 등을 합치고 싶다면, prom-aggregation-gateway가 적합하다.

 

GitHub - zapier/prom-aggregation-gateway: An aggregating push gateway for Prometheus

An aggregating push gateway for Prometheus. Contribute to zapier/prom-aggregation-gateway development by creating an account on GitHub.

github.com

사용법은 Readme에 있다

클라이언트 라이브러리는 Prometheus client 라이브러리를 쓰면 된다

 

실제 사용 예시는.. 언젠가 나중에 써본다면 올려보는걸로

반응형