Prometheus 현대화: 복합 유형을 위한 네이티브 스토리지

Source: Prometheus Blog

지난 1년 동안, Prometheus 커뮤니티는 이전에는 논란이 되거나 실현 가능하지 않을 것이라고 여겨졌던 여러 흥미롭고 야심찬 변화를 위해 열심히 일해 왔습니다. 외부에서는 그 변화가 거의 눈에 띄지 않을 수도 있습니다(예: OpenClaw Prometheus 플러그인이 아니라서 죄송합니다 🙃). 그럼에도 불구하고 Prometheus 개발자들은 자연스럽게 Prometheus를 어느 정도 일관된 미래 방향으로 이끌고 있습니다. 하나씩 조각을 맞추다 보니, 오픈소스 프로젝트로서는 상상도 못했던 목표에 점점 더 가까워지고 있습니다!

이 글은 (희망컨대!) 새로운 및 기존 Prometheus 사용자와 개발자에게 흥미로울 수 있는 몇 가지 야심찬 변화를 공유하는 블로그 시리즈의 시작입니다. 이번 글에서는 복합 타입을 위한 네이티브 스토리지라는 아이디어에 초점을 맞추고자 합니다. 이는 시간이 지나면서 쌓인 많은 문제들을 정리하는 작업입니다. 초기 채택 방법이나 기여 방법에 대한 인라인 링크를 꼭 확인해 보세요!

주의: 면책 조항: 이 글은 Prometheus 유지보수자로서 개인적인 관점에서 재미로 작성한 개요입니다. 언급된 변화 중 일부는 아직 Prometheus 팀에 의해 공식 승인되지 않았으며, 일부는 실제 운영 환경에서 검증되지 않았습니다.
참고: 이 글은 인간이 작성했으며, AI는 오로지 문법 및 미관상의 수정을 위해 사용되었습니다.

Source: …

클래식 표현: 원시 샘플

아시다시피, Prometheus 데이터 모델(서버, PromQL, 프로토콜)은 게이지, 카운터, 히스토그램, 요약을 지원합니다. OpenMetrics 1.0은 여기에 gaugehistogram, info, stateset 유형을 추가했습니다.

놀랍게도, 오랫동안 Prometheus의 TSDB 저장 구현은 명시적으로 깔끔하고 단순한 데이터 모델을 가지고 있었습니다. TSDB는 float64 값과 int64 타임스탬프만을 포함하는 문자열‑라벨이 붙은 원시 샘플의 저장 및 조회를 허용했으며, 메트릭 유형에 전혀 의존하지 않았습니다.

메트릭 유형은 인간과 PromQL을 위한 최선‑노력 도구를 위해 TSDB 위에 암시적으로 부여되었습니다. 간단히 말해, 이러한 유형 저장 방식을 클래식 모델(또는 표현)이라고 부릅시다. 이 모델에서는:

원시 유형

복합 유형

여기서 재미가 시작됩니다. 클래식 표현에서는 복합 메트릭이 원시 부동소수점 샘플들의 집합으로 표현됩니다.

Histogram – 특정 필수 접미사와 le 라벨을 가진 카운터들의 그룹:

foo_bucket{le="0.0"}      0
foo_bucket{le="1e-05"}    0
foo_bucket{le="0.0001"}   5
foo_bucket{le="0.1"}      8
foo_bucket{le="1.0"}     10
foo_bucket{le="10.0"}    11
foo_bucket{le="100000.0"}11
foo_bucket{le="1e+06"}    15
foo_bucket{le="1e+23"}   16
foo_bucket{le="1.1e+23"} 17
foo_bucket{le="+Inf"}    17
foo_count                17
foo_sum               324789.3

gaugehistogram, summary, stateset 유형도 동일한 논리를 따릅니다 – 단일 메트릭을 구성하는 특수 게이지 또는 카운터들의 그룹.

클래식 모델은 Prometheus 프로젝트에 큰 도움이 되었습니다. 저장 구현을 크게 단순화시켜 Prometheus가 가장 최적화된 오픈‑소스 시계열 데이터베이스 중 하나가 될 수 있게 했으며, 동일한 데이터 모델을 기반으로 하는 분산 버전이 Cortex, Thanos, Mimir 등 프로젝트에서도 사용되고 있습니다.

클래식 모델의 제한 사항

복합 타입을 위한 네이티브 스토리지 살펴보기

클래식 모델은 네이티브 히스토그램의 도입으로 도전받았습니다. TSDB는 단순 부동소수점이 아닌 복합 히스토그램 샘플을 저장하도록 확장되었습니다. 우리는 이를 네이티브 히스토그램이라고 부르는 편인데, 이는 TSDB가 이제 전체(희소 및 지수형) 히스토그램을 원자적이고 복합적인 샘플로 네이티브하게 저장할 수 있기 때문입니다.

그 시점에서 일반적인 지혜는 여기서 멈추는 것이었습니다. “클래식” 히스토그램을 대체하도록 설계된 특수 고급 히스토그램은 복합 샘플을 사용하고, 나머지 메트릭은 계속해서 클래식 모델을 사용합니다. 새로운 네이티브 모델에 맞춰 다른 복합 타입을 일관되게 만들면 사용자에게 매우 파괴적이며, 작업량과 위험이 너무 커집니다.

일반적인 반론은 사용자가 결국 클래식 히스토그램을 자연스럽게 마이그레이션할 것이며, 네이티브 히스토그램이 제공하는 더 강력한 버킷팅과 낮은 비용 때문에 요약(summary)은 덜 유용하다는 것이었습니다.

불행히도 네이티브 히스토그램으로의 마이그레이션에는 시간이 걸리는 것으로 알려져 있습니다:

• PromQL 변경 – 네이티브 히스토그램을 쿼리하려면 약간의 구문 조정이 필요합니다.
• 클라이언트 변경 – 애플리케이션은 새 히스토그램을 사용하도록 메트릭을 정의하거나 기존 메트릭을 편집해야 합니다.
• 레거시 소프트웨어 – 오래된 소프트웨어는 무기한 프로덕션에 남아 있을 수 있으며, 절대 마이그레이션되지 않을 수도 있습니다.

그 결과, Prometheus는 클래식 히스토그램을 단순히 폐기할 수 없으며, 모든 하위 솔루션은 클래식 모델을 계속 지원해야 합니다.

네이티브 히스토그램, NHCB, 그리고 완전한 복합 샘플 모델을 향한 길

배경

네이티브 히스토그램은 TSDB와 그 생태계를 새로운 복합‑샘플 패턴으로 끌어올렸습니다. 이러한 변화 중 일부는 모든 복합 유형에 적용될 수 있었으며, 네이티브 히스토그램은 네이티브 지원이 제공하는 수많은 이점을 엿볼 수 있게 해주었습니다.

“기존 복합 메트릭의 네이티브 대응물을 추가해서 교체할 수 있을까요? 가능하면 투명하게요.”

2024년에 트랜잭션성과 효율성을 위해 Native Histogram Custom Buckets (NHCB) 를 도입했습니다. 이는 명시적인 버킷을 네이티브하게 저장하는 개념으로, 네이티브 히스토그램 복합‑샘플 데이터 구조를 재사용합니다.

• 효율성 – NHCB는 기존 표현 방식보다 최소 30 % 더 효율적이며 기능적 동등성을 제공합니다.

• 채택 장벽 – 두 가지 실용적인 문제가 도입을 늦추었습니다:

  1. 확장(NHCB → 기존) 은 간단합니다.
  2. 결합(기존 → NHCB) 은 종종 불가능합니다.
     • 스크레이프 시 변환 비용이 높습니다.
     • Remote‑write “푸시”가 히스토그램을 샤드나 순차 메시지로 나눌 수 있어 결합이 불가능합니다.
     • 이 때문에 OpenTelemetry‑collector 사용자는 prometheusreceiver에서 추가 오버헤드를 경험합니다 – OpenTelemetry 모델은 복합‑샘플 모델을 엄격히 따르기 때문입니다.

소비 차이 (PromQL)

기존 히스토그램 예시

foo_bucket{le="0.0"} 0
# …
foo_bucket{le="1.1e+23"} 17
foo_bucket{le="+Inf"} 17
foo_count 17
foo_sum 324789.3

NHCB 표현

메트릭 이름은 이제 foo이며 _bucket 접미사가 없습니다.

# New syntax (native)
histogram_quantile(0.9, sum(foo{job="a"}))

# Old syntax (expanded)
histogram_quantile(0.9, sum(foo_bucket{job="a"}) by (le))

결과

• 텍스트 포맷에 대한 “보는 것이 곧 쿼리하는 것” 규칙이 위배됩니다 (OpenMetrics 2까지).
• 다른 Prometheus 출력(페더레이션, remote‑read, remote‑write)에서도 유사한 문제가 나타납니다.

Note: Prometheus 클라이언트 데이터 모델(SDK)과 PrometheusProto 스크레이프 프로토콜은 이미 복합‑샘플 모델을 사용하고 있습니다!

투명한 네이티브 표현

커뮤니티 방향

Prometheus 커뮤니티는 다음 두 가지 아이디어에 수렴하고 있는 것으로 보입니다:

1. 스토리지 계층에서 완전 복합‑샘플 모델로 전환 – 모든 관련 이점을 얻기 위해.
2. 사용자가 (예: 스크레이프 시) 클래식에서 네이티브 형태로 전환하도록 허용 – 마이그레이션을 용이하게 하고, 이중‑모드 프로토콜 변경을 피하며, 클래식 모델을 가능한 한 빨리 폐기하기 위해.

진행 중인 작업 및 기여 방법

PromQL 호환성 예시

# New syntax – works directly on the NHCB "foo"
histogram_quantile(0.9, sum(foo{job="a"}))

# Old syntax – expands the NHCB to classic representation
histogram_quantile(0.9, sum(foo_bucket{job="a"}) by (le))

대안 (예: 특수 라벨 또는 주석)도 논의 중입니다.

완전히 구현되면 파이프라인은 언제든지 투명하게 네이티브 형태로 전환할 수 있습니다.

요약

Prometheus를 네이티브 복합‑타입 세계로 이동하는 것은 어려우며 시간이 걸릴 것입니다:

• 성능 특성이 균일하고 예측 가능한 샘플 크기에서 메트릭 타입에 따라 달라지는 크기로 전환됩니다.
• 코드 아키텍처가 더 복잡해집니다 – 여러 샘플 타입을 유지하는 것이 이미 어려운 것으로 입증되었습니다.

그럼에도 불구하고, 커뮤니티는 필요한 프로토콜 업데이트, 호환성 레이어 및 스토리지 변경 작업을 활발히 진행하고 있습니다. OpenMetrics 2.0, Remote Write 2.0, 혹은 호환성 모드에 대한 여러분의 기여는 이 전환을 원활하고 지속 가능하게 만드는 데 필수적입니다.

업데이트 및 기회

왜 이것이 중요한가

최근 작업을 통해 깨끗하고 실행 가능한 경로가 밝혀졌으며, 이는 다음과 같은 명확한 이점을 제공합니다:

• 기능
• 트랜잭션성
• 신뢰성
• 효율성

이러한 개선은 비교적 가까운 미래에 기대되며—매우 흥미진진합니다!

참여 방법

• 다이렉트 메시지로 Slack에서 저에게 연락하세요.
• #prometheus‑dev Slack 채널에 질문을 올리세요.
• 관련 이슈에 댓글을 달고, PR을 만들며, PR 검토를 하세요 (가장 큰 영향을 미치는 작업입니다!).

2026년 KubeCon EU – 암스테르담에서의 Prometheus

Source: …

Future Topics (Work‑in‑Progress)

No promises, but help is welcome! Below is a non‑exhaustive, random‑order list of areas we plan to cover in upcoming posts.

• Native start‑timestamp feature – cleanly unlocks native delta temporality without hacks (e.g., re‑using gauges, extra metric types, or label annotations like __temporality__).
• Optional schematization of Prometheus metrics – tackles stability problems in metric naming/shape, building on OpenTelemetry semantic conventions.
• Metadata storage improvements – enhances the OpenTelemetry Entities and resource‑attributes storage/consumption experience.
• Extended scrape/pull protocols – aligns Prometheus with the recent OpenMetrics ownership move.
• TSDB Parquet effort – a joint initiative from the three LTS project groups (Cortex, Thanos, Mimir) aimed at high‑cardinality use cases.
• PromQL extensions – experiments with pipes, variables, and new SQL‑transpilation ideas.
• Governance changes – ongoing updates to project governance.

See You in Open‑Source!

Feel free to reach out, contribute, or simply follow the journey. Your participation makes all of this possible.