Prometheus: Up & Running, 2nd Edition

4장. 박람회

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

3장에서는 주로 코드에 계측 기능을 추가하는 데 중점을 두었습니다. 하지만 생성된 메트릭이 모니터링 시스템에서 사용되지 않는다면 세상의 모든 계측 기능은 아무 소용이 없습니다. Prometheus에서 메트릭을 사용할 수 있게 만드는 프로세스를 익스포저라고 합니다.

Prometheus에 대한 노출은 HTTP를 통해 이루어집니다. 일반적으로 /metrics 경로에 메트릭을 노출하면 클라이언트 라이브러리에서 요청을 처리합니다. Prometheus는 사람이 읽을 수 있는 두 가지 텍스트 형식, 즉 Prometheus 텍스트 형식과 OpenMetrics를 지원합니다. 설명 형식을 수작업으로 생성할 수 있는 옵션이 있으며, 이 경우 덜 엄격한 Prometheus 텍스트 형식을 사용하는 것이 더 쉽습니다. 사용 중인 언어에 적합한 라이브러리가 없는 경우 이 방법을 선택할 수도 있지만, 이스케이프 이스케이프와 같은 사소한 세부 사항을 모두 올바르게 처리할 수 있으므로 라이브러리를 사용하는 것이 좋습니다. 또한 대부분의 라이브러리는 OpenMetrics와 Prometheus 텍스트 형식을 모두 사용하여 메트릭을 생성할 수 있는 기능을 제공합니다.

노출은 일반적으로 주 함수 또는 다른 최상위 함수에서 수행되며 애플리케이션당 한 번만 구성하면 됩니다.

메트릭은 일반적으로 정의할 때 기본 레지스트리에 등록됩니다. 의존하는 라이브러리 중 하나에 Prometheus 계측 기능이 있는 경우 메트릭이 기본 레지스트리에 등록되므로 별도의 작업을 수행하지 않고도 추가 계측 기능의 이점을 누릴 수 있습니다. 일부 사용자는 메인 함수에서 명시적으로 레지스트리를 전달하는 것을 선호하므로 애플리케이션의 메인 함수와 Prometheus 계측 사이에 있는 모든 라이브러리가 계측을 인식하도록 해야 합니다. 이는 종속성 체인의 모든 라이브러리가 계측에 관심을 갖고 계측라이브러리 선택에 동의한다고 가정합니다.

이 설계를 사용하면 노출이 전혀 없는 Prometheus 메트릭에 대한 계측이 가능합니다.¹ 이 경우 계측에 대한 (약간의) 리소스 비용을 지불하는 것 외에는 애플리케이션에 아무런 영향을 미치지 않습니다. 라이브러리를 작성하는 사람이라면 모니터링을 하지 않는 사용자를 위해 별도의 수고를 들이지 않고도 Prometheus를 사용하여 사용자를 위한 계측을 추가할 수 있습니다. 이 사용 사례를 더 잘 지원하기 위해 클라이언트 라이브러리의 계측 부분은 종속성을 최소화하려고 노력합니다.

몇 가지 인기 있는 클라이언트 라이브러리의 설명에 대해 살펴보겠습니다. 여기서는 클라이언트 라이브러리 및 기타 필수 종속성을 설치하는 방법을 알고 있다고 가정하겠습니다.

Python

이미 3장에서 start_http_server 을 보셨습니다. 다음과 같이 Prometheus 메트릭만 제공하는 HTTP 서버로 백그라운드 스레드를 시작합니다:

from prometheus_client ...