3

Prometheus을 사용하여 시간이 지남에 따라 서버에 대한 요청 수를 추적하려고합니다. 내 서버는 Google Compute Engine을 사용하여 가로로 자동 크기 조정되므로 내 측정 항목을 원격 푸시 게이트웨이로만 푸시 할 수 있습니다. 내 서버는 언제든지 삭제되고 다시 생성됩니다.자동 확장 서버에서 요청을 추적하기위한 Prometheus

문제는 새 서버를 만들 때마다 또는 카운터 인스턴스가 파이썬 클라이언트 라이브러리 the count value is reset to 0을 사용하여 만들어 질 때입니다. 그래프가 항상 증가하는 대신 위아래로 움직이는 것을 볼 수 있습니다.

enter image description here

때 자동 scalled 환경에서 프로 메테우스를 사용하여 요청의 총 수를 추적 할 수있는 적절한 방법은 무엇입니까?

편집 : 조금 다른 시나리오에서 정확히 같은 문제에 대한 또 다른 게시물,이

. Prometheus how to handle counters on server. 서버가 어떻게 든 카운터 상태를 스스로 추적해야합니다. 프로 메테우스는 그 시점에서 보내거나 푸시하거나 푸는 모든 값을 기록합니다. 즉, 서버가 단순히 counter.inc()을 호출하면 카운터 값이 항상 올라가지는 않습니다. 즉,이 문서의 다음 문은 클라이언트 라이브러리 측면에만 적용됩니다.

카운터는 한 번만 올라간 단일 숫자 값을 나타내는 누적 메트릭입니다.

답변

2

내 서버가 자동 scalled 구글 컴퓨 트 엔진을 사용하여 수평이 될 것이기 때문에, 나는 단지 원격 푸시 게이트웨이로 내 메트릭을 푸시 할 수 있습니다. 내 서버는 언제든지 삭제되고 다시 생성됩니다.

그건 사실이 아닙니다. 서비스 검색을 사용하여 노드를 자동으로 검색하고 일반적인 Prometheus 방식으로 노드를 계측 및 모니터링 할 수 있습니다.

pushgateway

만 서버의 존재가 동적이기 때문에 서버가 제거되기 전에, 프로 메테우스 시간에 데이터를 검색 할 수 https://prometheus.io/docs/practices/pushing/

+0

참조, 서비스 수준 일괄 작업을위한 것입니다. 그러나 이제 문제는 내 카운트 값이 인스턴스와 레지스트리에 누적 될 수 없다는 것입니다. 대신 당겨 사용하면이 문제가 해결됩니까? 매번 레지스트리를 재 작성하는 이유는 레지스트리를 재사용하면 어느 시점에서 푸시 게이트웨이에서 500 개의 서버 오류가 발생하기 때문입니다. – Andy

+0

모니터링에는 많은 인종이 있습니다. 서버를 너무 많이 가져 와서 너무 많은 양의 샘플을 잃어버린 경우에는 오실로스코프를 줄이기 위해 자동 스케일링의 히스테리시스를 조정해야합니다. 집계는 카운터의 비율을 취한 다음 그 값의 합계를 취하는 문제입니다. –

+0

나는 당신에게 요점이 있다고 생각합니다. 결과를 종합하여 총계를 얻을 수 있습니다. 이 질문을 받아 들일 수 있도록 대답 해 주시겠습니까? 진동에 관해서는 작은 인스턴스를 사용하여 기계 비용을 최소화하려고합니다. 부작용은 트래픽 상태에 따라 빠르게 변합니다. – Andy