Pushgateway를 써야 할 때

Pushgateway를 써야 할 때 (When to use the Pushgateway)

프로메테우스는 기본적으로 풀(pull) 모델, 즉 프로메테우스가 타깃을 스크랩하는 방식을 써요. 하지만 스크랩할 수 없는 잡이 있어요. 그럴 때는 Pushgateway라는 중간 서비스로 메트릭을 푸시할 수 있어요. 이 문서는 Pushgateway를 언제 사용해야 하는지, 그리고 왜 일반적인 메트릭 수집에 무작정 쓰면 안 되는지 설명해 드려요.

결론부터 말하면, Pushgateway는 정말 제한된 경우에만 권장해요. 이 문서를 읽고 나면 Pushgateway의 함정(pitfalls)을 이해하고, 언제 써야 하고 언제 대안을 써야 하는지 빠르게 판단할 수 있을 거예요.

출처: 문서

본문

Pushgateway는 스크랩할 수 없는 잡에서 메트릭을 푸시할 수 있게 해 주는 중간 서비스예요. 자세한 내용은 메트릭 푸시하기를 보세요.

Pushgateway를 사용해야 할까요? (Should I be using the Pushgateway?)

우리는 특정 제한된 경우에만 Pushgateway 사용을 권장해요. 일반 메트릭 수집을 위해 프로메테우스의 평소 풀 모델 대신 Pushgateway를 무작정 사용할 때는 여러 함정이 있어요.

  • 단일 Pushgateway를 통해 여러 인스턴스를 모니터링할 때, Pushgateway는 단일 실패 지점(single point of failure)이자 잠재적 병목(bottleneck)이 돼요.

  • 프로메테우스의 자동 인스턴스 상태 모니터링, 즉 (모든 스크랩에서 생성되는) up 메트릭을 잃게 돼요.

  • Pushgateway는 푸시된 시리즈를 절대 잊지 않고, 그것을 Pushgateway API로 수동 삭제하지 않는 한 영원히 Prometheus에 노출해요.

마지막 점은 잡의 여러 인스턴스가 instance 라벨 같은 것으로 Pushgateway에서 메트릭을 구분할 때 특히 관련돼요. 인스턴스의 메트릭은 원래 인스턴스가 이름이 바뀌거나 제거돼도 Pushgateway에 남아 있어요. 이것은 메트릭 캐시로서의 Pushgateway의 수명주기가 메트릭을 푸시하는 프로세스의 수명주기와 근본적으로 분리돼 있기 때문이에요. 이를 프로메테우스의 평소 풀 방식 모니터링과 대조해 보세요: 인스턴스가 (의도적이든 아니든) 사라지면, 그 메트릭도 자동으로 함께 사라져요. Pushgateway를 사용할 때는 그렇지 않아서, 이제 낡은(stale) 메트릭을 수동으로 삭제하거나 이 수명주기 동기화를 스스로 자동화해야 해요.

보통 Pushgateway의 유일한 유효한 사용 사례는 서비스 수준 배치 잡(service-level batch job)의 결과를 캡처하는 것이에요. "서비스 수준" 배치 잡은 특정 머신이나 잡 인스턴스와 의미적으로 관련이 없는 잡이에요(예: 전체 서비스에 대해 여러 사용자를 삭제하는 배치 잡). 그런 잡의 메트릭은 특정 머신이나 인스턴스의 수명주기를 푸시된 메트릭에서 분리하기 위해 머신이나 인스턴스 라벨을 포함하지 말아야 해요. 이것은 Pushgateway에서 낡은 메트릭을 관리하는 부담을 줄여 줘요. 배치 잡 모니터링 모범 사례도 참고하세요.

대안 전략 (Alternative strategies)

인바운드 방화벽이나 NAT 때문에 타깃에서 메트릭을 풀링하지 못한다면, Prometheus 서버를 네트워크 장벽 안쪽으로 옮기는 것을 고려해 보세요. 우리는 일반적으로 모니터링되는 인스턴스와 같은 네트워크에서 Prometheus 서버를 실행하는 것을 권장해요. 그렇지 않으면 Prometheus가 방화벽이나 NAT를 가로지를 수 있게 해 주는 PushProx를 고려해 보세요.

머신과 관련된 배치 잡(예: 자동 보안 업데이트 cronjob이나 구성 관리 클라이언트 실행)에는 결과 메트릭을 Pushgateway 대신 Node Exporter의 textfile 컬렉터로 노출하세요.

더 알아보기 (Learn more)