메트릭 타입

메트릭 타입

메트릭을 설계하다 보면 "카운터로 할지 게이지로 할지" 같은 고민이 먼저 떠오르죠. Prometheus 계측 라이브러리는 네 가지 핵심 메트릭 타입을 제공해요. 이 글에서는 각 타입이 무엇을 표현하는지, 그리고 네이티브 히스토그램과 클래식 히스토그램의 차이까지 정리해드릴게요.

출처: Prometheus 공식 문서 — Metric types

알아두면 좋은 배경

네이티브 히스토그램을 제외하면, 이 네 타입은 현재 계측 라이브러리 API와 노출 프로토콜에서만 구분돼요. Prometheus 서버는 아직 타입 정보를 활용하지 않고, 네이티브 히스토그램을 제외한 모든 타입을 부동소수점 값의 "타입 없음(untyped)" 시계열로 평탄화해요. 반면 네이티브 히스토그램은 특수한 복합 히스토그램 샘플의 시계열로 수집돼요. 앞으로 Prometheus가 다른 메트릭 타입도 복합 타입으로 다룰 수 있게 될 수 있고, 단순 부동소수점 샘플의 타입 정보를 영속화하는 작업도 진행 중이에요.

카운터(Counter)

카운터는 누적되는 메트릭으로, 단일 단조 증가 카운터를 나타내며 값이 증가하거나 재시작 시 0으로 리셋될 뿐이에요. 예를 들어 서빙된 요청 수, 완료된 작업 수, 오류 수를 표현할 때 써요. 값이 줄어들 수 있는 것을 카운터로 노출해선 안 돼요. 예를 들어 현재 실행 중인 프로세스 수에는 카운터를 쓰지 말고 게이지를 써야 해요.

게이지(Gauge)

게이지는 임의로 오르내릴 수 있는 단일 숫자 값을 나타내는 메트릭이에요. 온도나 현재 메모리 사용량 같은 측정값에 주로 쓰이지만, 동시 요청 수처럼 오르내릴 수 있는 "개수"에도 쓰여요.

히스토그램(Histogram)

히스토그램은 관측값(보통 요청 지속 시간이나 응답 크기)을 설정 가능한 버킷(bucket)에 세어 기록해요. 관측된 모든 값의 합(sum)도 함께 제공하죠. 그래서 히스토그램은 본질적으로 "버킷형 카운터"라고 할 수 있어요. 다만 분포의 현재 상태를 나타내는 경우도 있는데, 그럴 땐 게이지 히스토그램이라 불러요. 보통의 카운터형 히스토그램과 달리 게이지 히스토그램은 계측 프로그램이 직접 노출하는 일이 드물고 계측 라이브러리에서 아직 쓸 수 없지만, 최신 protobuf 노출 형식과 OpenMetrics에는 표현돼요. 카운터 히스토그램에 rate 함수를 적용한 결과는 카운터에 rate를 적용한 결과가 게이지인 것처럼, 게이지 히스토그램이 돼요.

히스토그램에는 근본적으로 다른 두 버전이 있어요. 최신 **네이티브 히스토그램(native histograms)**과 오래된 **클래식 히스토그램(classic histograms)**이 그것이에요.

  • 네이티브 히스토그램은 각 샘플이 관측의 count와 sum을 동적 버킷 집합과 함께 나타내는 복합 샘플로 노출·수집돼요.
  • 클래식 히스토그램은 여러 단순 부동소수점 샘플 시계열로 구성돼요. 기본 메트릭 이름을 <basename>이라 하면 다음 시계열을 만들어요.
    • 누적 카운터 버킷: <basename>_bucket{le="<upper inclusive bound>"}
    • 모든 관측값의 총합: <basename>_sum
    • 관측된 이벤트 수: <basename>_count (위 <basename>_bucket{le="+Inf"}와 동일)

네이티브 히스토그램은 일반적으로 클래식 히스토그램보다 훨씬 효율적이고 해상도가 높으며, 계측 중 버킷 경계를 명시적으로 설정할 필요가 없어요. 네트워크로 전송될 때(예: Prometheus 원격 쓰기 프로토콜을 통할 때) 원자성도 제공하죠. 클래식 히스토그램은 구성 시계열이 독립적으로 전송되기 때문에 부분 전송 문제가 있을 수 있어요. 네이티브 히스토그램의 버킷 스키마는 해상도가 바뀌어도 언제나 서로 집계 가능한 반면, 버킷 경계가 다른 클래식 히스토그램은 일반적으로 집계가 불가능해요. 사용 중인 계측 라이브러리가 네이티브 히스토그램을 지원한다면(현재는 Go와 Java가 해당), 클래식보다 네이티브를 선호하는 게 좋아요.

클래식 히스토그램을 어쩔 수 없이 써야 한다면, 네이티브 히스토그램의 이점 중 일부를 얻을 방법이 있어요. **커스텀 버킷 경계를 가진 네이티브 히스토그램(NHCB, Native Histograms with Custom Bucket boundaries)**이라 불리는 특수한 형태로 Prometheus가 클래식 히스토그램을 수집하도록 설정할 수 있죠. NHCB는 일반 네이티브 히스토그램과 같은 복합 샘플로 저장되어, 일반 네이티브 히스토그램과 비슷한 효율성과 원자적 네트워크 전송을 제공해요. 다만 버킷은 클래식과 같은 배치를 그대로, 계측 중 정적으로 설정된 형태로 유지돼요.

히스토그램(또는 히스토그램의 집계)에서 분위수(quantile)를 계산하려면 histogram_quantile() 함수를 써요. 클래식과 네이티브 모두에 동작하며 문법이 약간 달라요. 히스토그램은 Apdex 점수를 계산하는 데도 적합해요. 클래식 히스토그램의 버킷은 <basename>_bucket{le="<upper inclusive bound>"}처럼 개별 시계열로 표현되므로 직접 연산할 수도 있어요. 단, 버킷은 **누적(cumulative)**이어서, 각 버킷은 라벨로 주어진 상한 경계 이하의 모든 관측값을 센다는 점을 기억하세요. 네이티브 히스토그램에서는 histogram_fraction() 함수(관측 비율 계산)와 트림 연산자(trim operators, 원하는 관측 대역 필터링)로 주어진 경계 안의 관측값을 볼 수 있어요.

참고: Prometheus v3.0부터 클래식 히스토그램의 le 라벨 값은 수집 시 OpenMetrics Canonical Numbers 형식을 따르도록 정규화돼요.

서머리(Summary)

서머리는 히스토그램과 비슷하게 관측값(보통 요청 지속 시간·응답 크기)을 샘플링해요. 관측값의 총 개수와 합을 제공하면서, 슬라이딩 시간 창 위에서 설정 가능한 분위수를 계산해요. 기본 메트릭 이름을 <basename>이라 하면 스크랩 시 여러 시계열을 노출해요.

  • 관측 이벤트의 스트리밍 φ-분위수(0 ≤ φ ≤ 1): <basename>{quantile="<φ>"}
  • 관측된 모든 값의 총합: <basename>_sum
  • 관측된 이벤트 수: <basename>_count

φ-분위수, 서머리 사용법, 히스토그램과의 차이에 대한 자세한 설명은 histograms and summaries 문서를 참고하세요.

참고: Prometheus v3.0부터 quantile 라벨 값은 수집 시 OpenMetrics Canonical Numbers 형식을 따르도록 정규화돼요.

더 알아보기