푸시 게이트웨이
1.10.0
Prometheus Pushgateway는 임시 및 배치 작업이 해당 측정항목을 Prometheus에 노출할 수 있도록 하기 위해 존재합니다. 이러한 종류의 작업은 폐기될 만큼 오랫동안 존재하지 않을 수 있으므로 대신 해당 측정항목을 Pushgateway로 푸시할 수 있습니다. 그런 다음 Pushgateway는 이러한 측정항목을 Prometheus에 공개합니다.
우선, Pushgateway는 Prometheus를 푸시 기반 모니터링 시스템으로 전환할 수 없습니다. Pushgateway 사용 사례에 대한 일반적인 설명은 Pushgateway 사용 시기를 읽어보세요.
Pushgateway는 명시적으로 집계자나 분산 카운터 가 아니라 메트릭 캐시입니다. statsd와 유사한 의미가 없습니다. 푸시된 측정항목은 영구적으로 실행되는 프로그램에서 스크래핑을 위해 표시하는 것과 정확히 동일합니다. 분산 계산이 필요한 경우 Prometheus statsd 내보내기 프로그램과 함께 실제 statsd를 사용하거나 prom-aggregation-gateway를 살펴볼 수 있습니다. 더 많은 경험이 수집되면 Prometheus 프로젝트는 언젠가 Pushgateway와 별도로 또는 어쩌면 일부로서 기본 솔루션을 제공할 수 있을 것입니다.
시스템 수준 지표의 경우 일반적으로 노드 내보내기의 텍스트 파일 수집기가 더 적합합니다. Pushgateway는 서비스 수준 지표를 위한 것입니다.
Pushgateway는 이벤트 매장이 아닙니다. Prometheus를 Grafana 주석의 데이터 소스로 사용할 수 있지만 릴리스 이벤트와 같은 추적은 일부 이벤트 로깅 프레임워크에서 발생해야 합니다.
얼마 전 제안된 거의 모든 사용 사례가 우리가 강력히 권장하지 않는 안티 패턴으로 판명되었기 때문에 푸시된 측정항목에 대해 "시간 초과" 또는 TTL을 구현하지 않기로 결정했습니다. prometheus-developers 메일링 리스트에서 최신 토론을 따라가실 수 있습니다.
릴리스 페이지에서 해당 플랫폼에 맞는 바이너리 릴리스를 다운로드하고 tarball의 압축을 풉니다.
소스에서 직접 컴파일하려면 작동하는 Go 설정이 필요합니다. 그런 다음 제공된 Makefile을 사용합니다( make 입력).
가장 기본적인 설정의 경우 바이너리를 시작하면 됩니다. 수신 대기할 주소를 변경하려면 --web.listen-address 플래그(예: "0.0.0.0:9091" 또는 ":9091")를 사용하십시오. 기본적으로 Pushgateway는 측정항목을 유지하지 않습니다. 그러나 --persistence.file 플래그를 사용하면 푸시된 지표가 지속될 파일을 지정할 수 있습니다(Pushgateway를 다시 시작해도 유지되도록).
prom/pushgateway Docker 이미지를 사용하여 Pushgateway를 배포할 수 있습니다.
예를 들어:
docker pull prom/pushgateway
docker run -d -p 9091:9091 prom/pushgateway Pushgateway는 일반적인 방법 중 하나를 사용하여 Prometheus가 스크레이핑할 대상으로 구성되어야 합니다. 그러나 스크랩 구성에서는 항상 honor_labels: true 설정해야 합니다 (자세한 설명은 아래 참조).
Prometheus 클라이언트 라이브러리에는 등록된 측정항목을 Pushgateway로 푸시하는 기능이 있어야 합니다. 일반적으로 Prometheus 클라이언트는 Prometheus 서버의 스크래핑에 대한 측정항목을 수동적으로 제공합니다. 푸시를 지원하는 클라이언트 라이브러리에는 클라이언트 코드에서 호출해야 하는 푸시 기능이 있습니다. 그런 다음 아래 설명된 API를 사용하여 측정항목을 Pushgateway에 적극적으로 푸시합니다.
Prometheus 텍스트 프로토콜을 사용하면 별도의 CLI가 제공되지 않을 정도로 메트릭 푸시가 매우 쉽습니다. 단순히 curl 같은 명령줄 HTTP 도구를 사용하세요. 여러분이 선호하는 스크립팅 언어에는 여기에서도 활용할 수 있는 HTTP 기능이 내장되어 있을 가능성이 높습니다.
텍스트 프로토콜에서 각 줄은 줄 바꿈 문자('LF' 또는 'n'이라고도 함)로 끝나야 합니다. 다른 방법으로 라인을 끝내면(예: 'CR'('r'), 'CRLF'('rn') 또는 패킷 끝만 사용하면 프로토콜 오류가 발생합니다.
푸시된 측정항목은 여러 라벨의 그룹화 키로 식별되는 그룹으로 관리되며, 첫 번째 라벨은 job 라벨이어야 합니다. 그룹은 웹 인터페이스를 통해 쉽게 검사할 수 있습니다.
라벨 값에 특수 문자가 포함된 내용은 아래 URL 섹션을 참조하세요.
예:
{job="some_job"} 으로 식별된 그룹에 단일 샘플을 푸시합니다.
echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
유형 정보가 제공되지 않았으므로 some_metric 유형은 untyped 입니다.
{job="some_job",instance="some_instance"} 로 식별된 그룹에 더 복잡한 것을 푸시합니다.
cat <유형 정보와 도움말 문자열이 어떻게 제공되는지 확인하세요. 해당 줄은 선택 사항이지만 더 복잡한 경우에는 강력히 권장됩니다.
{job="some_job",instance="some_instance"} 로 식별된 그룹의 모든 지표를 삭제합니다.
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
{job="some_job"} 으로 식별된 그룹의 모든 측정항목을 삭제합니다(이전 예의 {job="some_job",instance="some_instance"} 그룹에 있는 측정항목은 포함되지 않습니다. 해당 측정항목에 동일한 직업 라벨):
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job
모든 그룹의 모든 지표를 삭제합니다(명령줄 플래그 --web.enable-admin-api 통해 관리 API를 활성화해야 함).
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
Prometheus 서버는 스크랩된 각 지표에 job 레이블과 instance 레이블을 첨부합니다. job 라벨의 값은 스크랩 구성에서 비롯됩니다. Pushgateway를 Prometheus 서버의 스크랩 대상으로 구성할 때 아마도 pushgateway 와 같은 작업 이름을 선택하게 될 것입니다. instance 라벨의 값은 스크랩된 대상의 호스트와 포트로 자동 설정됩니다. 따라서 Pushgateway에서 스크랩된 모든 메트릭에는 Pushgateway의 호스트와 포트가 instance 라벨로, job 라벨이 pushgateway 로 포함됩니다. Pushgateway에 푸시된 측정항목에 첨부했을 수 있는 job 및 instance 라벨과의 충돌은 해당 라벨의 이름을 exported_job 및 exported_instance 로 바꾸면 해결됩니다.
그러나 이 동작은 일반적으로 Pushgateway를 스크래핑할 때 바람직하지 않습니다. 일반적으로 Pushgateway에 푸시된 지표의 job 및 instance 레이블을 유지하려고 합니다. 그렇기 때문에 Pushgateway의 스크랩 구성에서 honor_labels: true 설정해야 합니다. 원하는 동작이 가능해집니다. 자세한 내용은 설명서를 참조하세요.
이로 인해 Pushgateway에 푸시된 측정항목에 instance 라벨이 포함되지 않는 경우가 발생합니다. 푸시된 측정항목은 종종 서비스 수준에 있으므로 특정 인스턴스와 관련이 없기 때문에 이 경우는 매우 일반적입니다. honor_labels: true 사용하더라도 처음에 instance 라벨이 설정되지 않은 경우 Prometheus 서버는 instance 라벨을 첨부합니다. 따라서 측정항목이 인스턴스 라벨 없이(그리고 그룹화 키에 인스턴스 라벨 없이, 아래 참조) Pushgateway로 푸시되면 Pushgateway는 이를 빈 인스턴스 라벨( {instance=""} )과 함께 내보냅니다. instance 레이블이 전혀 없지만 서버가 인스턴스 레이블을 부착하는 것을 방지합니다.
Pushgateway는 동일한 /metrics 엔드포인트를 통해 자체 측정항목과 함께 푸시된 모든 측정항목을 노출합니다. (자세한 내용은 노출된 지표에 대한 섹션을 참조하세요.) 따라서 모든 지표는 서로 일관성이 있어야 합니다. 동일한 이름의 지표는 다른 그룹에 푸시되더라도 동일한 유형을 가져야 하며 중복이 없어야 합니다. 즉, 동일한 이름과 동일한 라벨 쌍을 가진 측정항목입니다. 불일치로 이어질 수 있는 푸시는 상태 코드 400으로 거부됩니다.
그러나 일관성 없는 도움말 문자열은 허용됩니다. Pushgateway는 성공적인 도움말 문자열을 선택하고 정보 수준에서 이에 대해 기록합니다.
레거시 참고 사항: Pushgateway 자체 push_time_seconds 측정항목의 도움말 문자열이 v0.10.0에서 변경되었습니다. 지속성 파일을 사용하면 이전 버전의 Pushgateway에 푸시된 메트릭을 v0.10.0 이상의 Pushgateway로 만들 수 있습니다. 이 경우 위에서 언급한 로그 메시지가 표시됩니다. 이전에 푸시된 각 그룹이 삭제되거나 새 푸시를 수신하면 로그 메시지가 사라집니다.
푸시 중에 수행되는 일관성 검사는 스크래핑 중에 발생하는 것과 동일합니다. 일반적인 사용 사례에서는 푸시보다 스크래핑이 더 자주 발생합니다. 따라서 푸시 타임 확인의 성능 비용은 관련이 없습니다. 그러나 Pushgateway의 많은 양의 지표가 빈번한 푸시와 결합되면 푸시 기간이 엄청나게 길어질 수 있습니다. 이 경우 명령줄 플래그 --push.disable-consistency-check 사용을 고려할 수 있습니다. 이는 푸시 중 일관성 확인 비용을 절약하지만 일관되지 않은 측정항목 푸시를 허용합니다. 스크레이핑 중에 검사가 계속 발생하므로 일관성 없는 측정항목이 Pushgateway에 저장되어 있는 한 모든 스크레이핑이 실패합니다. 따라서 플래그를 설정하면 일관되지 않은 단일 푸시로 인해 Pushgateway가 비활성화될 위험이 있습니다.
시간 t 1 에 측정항목을 푸시하면 Prometheus가 동일한 타임스탬프 t 1 로 측정항목을 긁을 것이라고 믿고 싶을 수도 있습니다. 대신 Prometheus가 타임스탬프로 첨부하는 것은 Pushgateway를 긁는 시간입니다. 왜 그렇습니까?
프로메테우스의 세계관에서는 언제든지 지표를 스크랩할 수 있습니다. 스크랩할 수 없는 측정항목은 기본적으로 존재하지 않습니다. Prometheus는 다소 관대하지만 5분 내에 측정항목에 대한 샘플을 얻을 수 없으면 해당 측정항목이 더 이상 존재하지 않는 것처럼 동작합니다. 이를 방지하는 것이 실제로 Pushgateway를 사용하는 이유 중 하나입니다. Pushgateway는 임시 작업의 지표를 언제든지 스크랩 가능하게 만듭니다. 푸시 시간을 타임스탬프로 첨부하면 해당 목적이 무산됩니다. 왜냐하면 마지막 푸시 후 5분이 지나면 메트릭이 Prometheus에게 더 이상 긁힐 수 없는 것처럼 오래되어 보일 것이기 때문입니다. (프로메테우스는 샘플당 하나의 타임스탬프만 알고 있으므로 '푸시 시간'과 '스크래핑 시간'을 구별할 방법이 없습니다.)
다른 타임스탬프를 첨부하는 것이 적합한 사용 사례가 없고 많은 사용자가 잘못 연결하려고 시도하므로(이를 지원하는 클라이언트 라이브러리가 없음에도 불구하고) Pushgateway는 타임스탬프가 있는 모든 푸시를 거부합니다.
타임스탬프를 푸시해야 한다고 생각되면 Pushgateway 사용 시기를 참조하세요.
실패한 푸셔 또는 최근에 실행되지 않은 푸셔에 대해 더 쉽게 경고할 수 있도록 Pushgateway는 마지막 성공 및 실패한 POST / PUT 의 Unix 타임스탬프와 함께 push_time_seconds 및 push_failure_time_seconds 측정항목을 각 그룹에 추가합니다. 이는 해당 이름으로 푸시된 측정항목을 재정의합니다. 두 지표 중 하나의 값이 0이면 그룹이 성공하거나 실패한 POST / PUT 본 적이 없음을 의미합니다.
모든 푸시는 HTTP를 통해 수행됩니다. 인터페이스는 모호하게 REST와 비슷합니다.
Pushgateway가 수신 대기하는 기본 포트는 9091입니다. 경로는 다음과 같습니다.
/metrics/job/{//}
job 레이블 값으로 사용되며 그 뒤에는 다른 레이블 쌍( instance 레이블을 포함하거나 포함하지 않을 수 있음)이 옵니다. URL 경로로 정의된 라벨 세트는 그룹화 키로 사용됩니다. 요청 본문에 이미 설정된 라벨(일반 라벨, 예: name{job="foo"} 42 )은 URL 경로에 정의된 라벨과 일치하도록 덮어쓰여집니다!
job 또는 레이블 이름 뒤에 @base64 가 붙는 경우 다음 작업 이름 또는 레이블 값은 URL 및 파일 이름 안전 알파벳을 사용하여 RFC 4648에 따라 base64로 인코딩된 문자열로 해석됩니다. (패딩은 선택 사항이지만 빈 레이블 값을 인코딩하려면 단일 = 필요합니다.) 이는 다음 경우를 처리할 수 있는 유일한 방법입니다.
/ 포함된 작업 이름 또는 레이블 값. 그렇지 않으면 일반(또는 URI로 인코딩된) / 경로 구분 기호로 해석되기 때문입니다.// 또는 후행 / 사라지기 때문에 빈 레이블 값입니다. 빈 job 이름은 유효하지 않습니다. 빈 레이블 값은 유효하지만 거의 유용하지 않습니다. base64로 인코딩하려면 // 또는 후행 / 피하기 위해 하나 이상의 = 패딩 문자를 사용해야 합니다.다른 특수 문자의 경우 일반적인 URI 구성 요소 인코딩도 작동하지만 base64가 더 편리할 수 있습니다.
이상적으로는 클라이언트 라이브러리가 접미사 및 인코딩을 처리합니다.
예:
그룹화 키 job="directory_cleaner",path="/var/tmp" 사용하려면 다음 경로가 작동 하지 않습니다 .
/metrics/job/directory_cleaner/path//var/tmp
대신, 레이블 값에 base64 URL 안전 인코딩을 사용하고 레이블 이름 뒤에 @base64 를 붙여 표시하세요.
/metrics/job/directory_cleaner/path@base64/L3Zhci90bXA
인코딩을 처리하는 클라이언트 라이브러리를 사용하지 않는 경우 인코딩 도구를 사용할 수 있습니다. 예를 들어 명령줄 도구인 base64url (Debian 패키지 basez )이 있는데, 이를 curl 과 결합하여 다음과 같은 방법으로 명령줄에서 푸시할 수 있습니다.
echo 'some_metric{foo="bar"} 3.14' | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/directory_cleaner/path@base64/$(echo -n '/var/tmp' | base64url)
job="example",first_label="",second_label="foobar" 와 같은 빈 레이블 값이 포함된 그룹화 키를 사용하려면 다음 경로가 작동하지 않습니다 .
/metrics/job/example/first_label//second_label/foobar
대신 = 패딩 문자를 포함하여 다음 경로를 사용하십시오.
/metrics/job/example/first_label@base64/=/second_label/foobar
그룹화 키 job="titan",name="Προμηθεύς" URI 인코딩을 사용하여 "전통적으로" 표현될 수 있습니다.
/metrics/job/titan/name/%CE%A0%CF%81%CE%BF%CE%BC%CE%B7%CE%B8%CE%B5%CF%8D%CF%82
또는 보다 컴팩트한 base64 인코딩을 사용할 수 있습니다.
/metrics/job/titan/name@base64/zqDPgc6_zrzOt864zrXPjc-C
Prometheus 설명 형식(text 및 protobuf)의 최신 버전은 측정항목 및 라벨 이름에서 전체 UTF-8 문자 집합을 지원합니다. Pushgateway는 명령줄 플래그 --push.enable-utf8-names 설정된 경우 이름에 특수 문자만 허용합니다. URL 경로의 일부인 레이블 이름에 특수 문자를 허용하기 위해 플래그는 특정 인코딩 메커니즘도 활성화합니다. 이는 위에서 설명한 레이블 값 의 base64 인코딩과 유사하지만 기술 및 역사적 이유로 인해 세부적으로 다르게 작동합니다. 이전과 마찬가지로 클라이언트 라이브러리는 일반적으로 인코딩을 관리해야 합니다. 다음과 같이 작동합니다:
U__ 로 시작합니다._1F60A_ 와 같이 유니코드 값 주위에 밑줄로 인코딩됩니다.__ 로 인코딩됩니다.U__ 로 시작하는 경우 이러한 문자도 인코딩해야 하므로 U___55_____ 가 됩니다. (즉, U__ + _55_ ( U 의 경우) + __ + __ ).U__ 로 시작하지만 유효하지 않은 시퀀스(예: U__in_xxx_valid )를 포함하는 라벨 이름은 변경되지 않고 그대로 유지됩니다. 예를 들어 "foo.bar"="baz" 레이블은 다음과 같이 인코딩됩니다.
/metrics/job/example/U__foo_2e_bar/baz
이 인코딩은 라벨 값에 대한 base64 인코딩과 호환됩니다.
/metrics/job/example/U__foo_2e_bar@base64/YmF6
이 방법에는 적절하게 처리되지 않는 극단적인 경우가 있다는 점에 유의하십시오. 인코딩 메커니즘을 인식하지 못하는 푸셔는 다른 레이블 이름의 유효한 인코딩 버전이기도 한 레이블 이름을 사용할 수 있습니다. 예를 들어 푸셔가 라벨 이름 U__foo_2e_bar 사용하려고 하지만 U___55_____foo__2e__bar 로 인코딩하지 않는 경우 Pushgateway는 U__foo_2e_bar foo.bar 로 디코딩합니다. 이것이 --push.enable-utf8-names 플래그를 통해 디코딩이 선택되는 주된 이유입니다.
PUT 방식 PUT 측정항목 그룹을 푸시하는 데 사용됩니다. URL에 지정된 그룹화 키가 있는 모든 측정항목은 PUT 으로 푸시된 측정항목으로 대체됩니다.
요청 본문에는 구분된 바이너리 프로토콜 버퍼 또는 간단한 일반 텍스트 형식(둘 다 버전 0.0.4, 데이터 표시 형식 사양 참조)으로 푸시할 측정항목이 포함되어 있습니다. 두 변형 간의 구별은 Content-Type 헤더를 통해 수행됩니다. (프로토콜 버퍼에는 application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited 값을 사용하세요. 그렇지 않으면 텍스트 형식이 대체 수단으로 시도됩니다.)
성공 시 응답 코드는 200, 202 또는 400입니다. 200 응답은 기존 측정항목 그룹을 바꾸거나 새 측정항목 그룹을 생성하는 성공적인 푸시를 의미합니다. 요청의 형식이 잘못되었거나 푸시된 측정항목이 다른 그룹에 푸시된 측정항목과 일치하지 않거나 Pushgateway 자체의 측정항목과 충돌하는 경우 400 응답이 발생할 수 있습니다. 설명은 응답 본문에 반환되고 오류 수준에 기록됩니다. 202는 --push.disable-consistency-check 플래그가 설정된 경우에만 발생할 수 있습니다. 이 경우 푸시된 측정항목은 대기열에 추가될 뿐 일관성이 확인되지 않습니다. 그러나 위에서 설명한 것처럼 불일치로 인해 스크랩이 실패하게 됩니다.
드문 경우지만 Pushgateway가 이미 푸시된 일관되지 않은 측정항목 집합으로 끝날 수도 있습니다. 이 경우 원인이 이전에 푸시된 측정항목인 경우에도 새 푸시도 일관성이 없는 것으로 거부됩니다. 해당 상황에서 벗어나려면 문제가 되는 측정항목을 삭제하세요.
protobuf 형식을 사용하는 경우 한 번의 푸시로 중복된 MetricFamily proto 메시지(예: 동일한 이름을 가진 두 개 이상)를 보내지 마십시오. 서로 덮어쓰게 되기 때문입니다.
Pushgateway는 푸시된 측정항목이 디스크에 유지된다는 강력한 보장을 제공하지 않습니다. (서버 충돌로 인해 데이터가 손실될 수 있습니다. 또는 Pushgateway가 디스크에 전혀 지속되지 않도록 구성되어 있습니다.)
본문이 비어 있는 PUT 요청은 지정된 그룹화 키가 있는 모든 지표를 효과적으로 삭제합니다. 그러나 아래 설명된 DELETE 요청과 달리 push_time_seconds 지표를 업데이트합니다.
POST 방식 POST PUT 방법과 동일하게 작동하지만 새로 푸시된 지표와 동일한 이름을 가진 지표만 대체됩니다(동일한 그룹화 키를 가진 지표 중에서).
본문이 비어 있는 POST 요청은 push_time_seconds 지표만 업데이트할 뿐 이전에 푸시된 지표는 변경하지 않습니다.
DELETE 방법 DELETE 는 Pushgateway에서 메트릭을 삭제하는 데 사용됩니다. 요청에는 콘텐츠가 포함되어서는 안 됩니다. URL에 지정된 그룹화 키가 있는 모든 측정항목이 삭제됩니다.
성공 시 응답 코드는 항상 202입니다. 삭제 요청은 그 순간에만 대기열에 추가됩니다. 요청이 실제로 실행될 것이라는 보장이나 결과가 지속성 계층에 도달할 것이라는 보장은 없습니다(예: 서버 충돌의 경우). 그러나 PUT / POST 및 DELETE 요청의 순서는 보장됩니다. 즉, DELETE 요청을 성공적으로 보낸 다음 PUT 보내는 경우 DELETE 먼저 처리된다는 것이 보장됩니다(그 반대의 경우도 마찬가지입니다).
측정항목 없이 그룹화 키를 삭제하면 아무 작업도 수행할 수 없으며 오류가 발생하지 않습니다.
POST 또는 PUT 요청의 본문은 gzip 또는 snappy로 압축될 수 있습니다. 그렇게 하려면 헤더 Content-Encoding: gzip 또는 Content-Encoding: snappy 추가하세요.
예:
echo " some_metric 3.14 " | gzip | curl -H ' Content-Encoding: gzip ' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
echo " some_metric 3.14 " | snzip | curl -H ' Content-Encoding: snappy ' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job Admin API는 Pushgateway에 대한 관리 액세스를 제공하며 --web.enable-admin-api 플래그를 설정하여 명시적으로 활성화해야 합니다.
Pushgateway가 수신 대기하는 기본 포트는 9091입니다. 경로는 다음과 같습니다.
/api//admin/
| HTTP_METHOD | API_VERSION | 매니저 | 설명 |
|---|---|---|---|
| 놓다 | v1 | 닦음 | Pushgateway에서 모든 지표를 안전하게 삭제합니다. |
예를 들어 Pushgateway에서 모든 측정항목을 지우려면 다음을 수행하세요.
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
쿼리 API를 사용하면 푸시된 측정항목과 빌드 및 런타임 정보에 액세스할 수 있습니다.
/api//
| HTTP_METHOD | API_VERSION | 매니저 | 설명 |
|---|---|---|---|
| 얻다 | v1 | 상태 | 빌드 정보, 명령줄 플래그, 시작 시간을 JSON 형식으로 반환합니다. |
| 얻다 | v1 | 측정항목 | 푸시된 측정항목 계열을 JSON 형식으로 반환합니다. |
예를 들어 :
curl -X GET http://pushgateway.example.org:9091/api/v1/status | jq
{
"status": "success",
"data": {
"build_information": {
"branch": "master",
"buildDate": "20200310-20:14:39",
"buildUser": "[email protected]",
"goVersion": "go1.13.6",
"revision": "eba0ec4100873d23666bcf4b8b1d44617d6430c4",
"version": "1.1.0"
},
"flags": {
"log.format": "logfmt",
"log.level": "info",
"persistence.file": "",
"persistence.interval": "5m0s",
"push.disable-consistency-check": "false",
"web.enable-admin-api": "false",
"web.enable-lifecycle": "false",
"web.external-url": "",
"web.listen-address": ":9091",
"web.route-prefix": "",
"web.telemetry-path": "/metrics"
},
"start_time": "2020-03-11T01:44:49.9189758+05:30"
}
}
curl -X GET http://pushgateway.example.org:9091/api/v1/metrics | jq
{
"status": "success",
"data": [
{
"labels": {
"job": "batch"
},
"last_push_successful": true,
"my_job_duration_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Duration of my batch job in seconds",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "0.2721322309989773"
}
]
},
"push_failure_time_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Last Unix time when changing this group in the Pushgateway failed.",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "0"
}
]
},
"push_time_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Last Unix time when changing this group in the Pushgateway succeeded.",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "1.5838723477166057e+09"
}
]
}
}
]
}
Pushgateway는 자동화 및 통합을 용이하게 하는 관리 API 세트를 제공합니다.
| HTTP_METHOD | 길 | 설명 |
|---|---|---|
| 얻다 | /-/건강한 | Pushgateway가 정상일 때마다 200을 반환합니다. |
| 얻다 | /-/준비가 된 | Pushgateway가 트래픽을 제공할 준비가 될 때마다 200을 반환합니다. |
--web.enable-lifecycle 플래그를 통해 활성화할 수 있습니다.| HTTP_METHOD | 길 | 설명 |
|---|---|---|
| 놓다 | /-/그만두다 | Pushgateway의 정상적인 종료를 트리거합니다. |
또는 SIGTERM 을 Pushgateway 프로세스에 전송하여 정상적인 종료를 트리거할 수 있습니다.
Pushgateway는 구성된 --web.telemetry-path (기본값: /metrics )를 통해 다음 측정항목을 노출합니다.
push_time_seconds 및 push_failure_time_seconds 지표가 있습니다.process_...go_...promhttp_metric_handler_requests_... # HELP pushgateway_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which pushgateway was built.
# TYPE pushgateway_build_info gauge
pushgateway_build_info{branch="master",goversion="go1.10.2",revision="8f88ccb0343fc3382f6b93a9d258797dcb15f770",version="0.5.2"} 1
# HELP pushgateway_http_push_duration_seconds HTTP request duration for pushes to the Pushgateway.
# TYPE pushgateway_http_push_duration_seconds summary
pushgateway_http_push_duration_seconds{method="post",quantile="0.1"} 0.000116755
pushgateway_http_push_duration_seconds{method="post",quantile="0.5"} 0.000192608
pushgateway_http_push_duration_seconds{method="post",quantile="0.9"} 0.000327593
pushgateway_http_push_duration_seconds_sum{method="post"} 0.001622878
pushgateway_http_push_duration_seconds_count{method="post"} 8
# HELP pushgateway_http_push_size_bytes HTTP request size for pushes to the Pushgateway.
# TYPE pushgateway_http_push_size_bytes summary
pushgateway_http_push_size_bytes{method="post",quantile="0.1"} 166
pushgateway_http_push_size_bytes{method="post",quantile="0.5"} 182
pushgateway_http_push_size_bytes{method="post",quantile="0.9"} 196
pushgateway_http_push_size_bytes_sum{method="post"} 1450
pushgateway_http_push_size_bytes_count{method="post"} 8
# HELP pushgateway_http_requests_total Total HTTP requests processed by the Pushgateway, excluding scrapes.
# TYPE pushgateway_http_requests_total counter
pushgateway_http_requests_total{code="200",handler="static",method="get"} 5
pushgateway_http_requests_total{code="200",handler="status",method="get"} 8
pushgateway_http_requests_total{code="202",handler="delete",method="delete"} 1
pushgateway_http_requests_total{code="202",handler="push",method="post"} 6
pushgateway_http_requests_total{code="400",handler="push",method="post"} 2
일반적으로 push_time_seconds 예상보다 훨씬 뒤처지면 경고하는 것이 좋습니다. 이렇게 하면 실패한 푸시와 완전히 다운된 푸시를 모두 잡을 수 있습니다.
실패한 푸시를 훨씬 더 일찍 감지하려면 push_failure_time_seconds > push_time_seconds 에 대해 경고하세요.
푸시의 형식이 잘못되어 푸시가 실패할 수도 있습니다. 이 경우 지표 그룹에 도달하지 않으므로 push_failure_time_seconds 지표를 설정하지 않습니다. 해당 푸시는 여전히 pushgateway_http_requests_total{code="400",handler="push"} 로 계산됩니다. 이 지표의 rate 에 대해 경고할 수 있지만 문제가 있는 푸셔를 식별하려면 로그를 검사해야 합니다.
Pushgateway는 TLS 및 기본 인증을 지원합니다. 이를 통해 다양한 HTTP 엔드포인트를 더 효과적으로 제어할 수 있습니다.
TLS 및/또는 기본 인증을 사용하려면 --web.config.file 매개변수를 사용하여 구성 파일을 전달해야 합니다. 파일 형식은 내보내기 툴킷 저장소에 설명되어 있습니다.
TLS 및 기본 인증 설정은 스크래핑을 위한 /metrics, /metrics/...를 통해 메트릭을 푸시하는 API, /api/...를 통한 관리 API, 웹 UI 등 모든 HTTP 엔드포인트에 영향을 미칩니다.
일반 바이너리는 resources 디렉터리에 웹 파일을 포함합니다. 개발 목적으로 실행 중인 바이너리가 해당 파일을 직접 사용하도록 하는 것이 편리합니다(변경 사항의 효과를 즉시 확인할 수 있도록). 직접 사용으로 전환하려면 .promu.yml 의 flags 항목에 -tags dev 추가한 다음 make build . .promu.yml 에 대한 변경 사항을 되돌리고 make assets 입력하여 "일반" 모드로 다시 전환합니다.
관련 스타일 지침은 Go 코드 검토 주석과 Peter Bourgon의 Go: 프로덕션 환경을 위한 모범 사례의 서식 및 스타일 섹션입니다.
