promkr 뉴스레터 2025년 11월호

이 호에 실린 소식 9개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2025년 소식에 있습니다.

1. Prometheus 네이티브 계측 라이브러리 사용 권고

원문: Why I Recommend Native Prometheus Instrumentation over OpenTelemetry · Julius Volz

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Julius Volz는 Prometheus에서 사용할 메트릭을 생성한다면 OpenTelemetry SDK보다 Prometheus의 네이티브 계측 클라이언트 라이브러리를 권합니다. OpenTelemetry를 모든 애플리케이션 계측에 적용하려는 선택이 Prometheus 모니터링에서도 최선인지는 따져야 한다는 주장입니다.

Volz는 OTel SDK를 전면적으로 사용하면 Prometheus를 규정하는 주요 기능 일부를 잃을 위험이 있다고 설명합니다. 메트릭 변환과 이스케이프 처리의 불편함, 그 밖의 비효율과 복잡성도 이유로 듭니다. 소개문은 이런 판단의 근거를 발표에서 설명하겠다고 예고하지만, 구체적인 기능이나 변환 사례까지 제시하지는 않습니다.

2. OpenMetrics 2.0의 텍스트 노출 형식 개선 과제

원문: Everything you need to know about OpenMetrics 2.0! · György Krajcsovits, Bartłomiej Płotka

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. 발표자들은 애플리케이션이 노출한 메트릭을 텍스트로 확인하고, 그 내용을 Prometheus 호환 시스템에 입력해 그대로 질의하는 방식을 Prometheus 설계의 중심으로 설명합니다. 기존 Prometheus 형식과 OpenMetrics 1.0은 수년간 텍스트 메트릭의 표현을 정의해 왔지만, 새 버전이 필요한 과제들이 남아 있다는 출발점입니다.

발표는 해결 방향과 작업 그룹 참여 방법을 소개하고, 개발 중인 개념을 살펴보도록 구성됐습니다. 구체적인 주제는 텍스트 노출 형식에서의 native histograms, OpenTelemetry 호환성, created timestamp 개선입니다. 복잡한 데이터 타입 가운데 native histograms를 깊이 다룬다고 안내합니다. 소개문에는 확정된 명세나 출시 일정이 없습니다.

3. Prometheus 다운샘플링의 활용과 지원 범위

원문: Downsampling in Prometheus · Jan Fajerski

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Jan Fajerski는 TSDB 데이터 다운샘플링이 과거부터 반복해서 요청된 기능이라고 설명합니다. 발표는 기능 요청의 역사와 일반적인 사용 사례를 먼저 살핀 뒤, 현재 Prometheus로 다운샘플링 요구를 해결하는 예를 다루도록 구성됐습니다.

이후에는 향후 기능과 아직 결정되지 않은 기능 요청이 어떤 새로운 구성을 가능하게 할지 살펴봅니다. Prometheus의 범위 밖으로 계속 남을 시나리오도 구분하겠다고 예고합니다. 소개문에는 구체적인 알고리즘, 명령어, 지원 일정이 제시되지 않았습니다.

4. Weaver 코드 생성으로 맞추는 계측과 대시보드

원문: Auto-generated coherent Observability · Arthur Sens, Dominik Süß

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Arthur Sens와 Dominik Süß는 메트릭이나 레이블 이름의 오타와 변경이 알림, 대시보드, 애플리케이션에 미치는 영향을 문제로 제시합니다. 오래된 알림이 조용히 작동을 멈추거나 대시보드에서 데이터가 사라지고, 계측 코드 변경 뒤 애플리케이션에 패닉이 발생하는 사례입니다.

발표자들은 메트릭과 exporter를 쉽게 만드는 특성이 Prometheus의 성장에 기여했지만, 개별적으로 늘어난 구성 요소를 수작업으로 맞추는 과정은 오류를 일으키기 쉽다고 설명합니다. 이를 개선할 도구로 코드 생성기 Weaver를 소개합니다. Weaver는 처음에 여러 언어의 SDK에서 OpenTelemetry Semantic Conventions를 도입하기 쉽게 하려는 목적으로 만들어졌습니다.

발표는 Weaver의 활용 범위를 계측부터 수집과 시각화까지 넓혀 설명하겠다고 예고합니다. Prometheus 또는 OpenTelemetry SDK, Prometheus 또는 OTel-Collector, Grafana 또는 Perses를 사용하는 경우를 모두 언급합니다. 소개문은 특정 도구 조합에 구애받지 않고 관측 관련 구성의 일관성을 높이는 방향을 제시하며, 실제 생성 코드나 설정 예시는 포함하지 않습니다.

5. Perses Go SDK와 재사용 가능한 대시보드 구성

원문: No Jsonnet? No Problem! Prometheus in Perses, Powered by Go · Saswata Mukherjee, Hélia Barroso

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Saswata Mukherjee와 Hélia Barroso는 CNCF의 개방형 대시보드 플랫폼 Perses에서 Go 코드로 Prometheus 대시보드를 구성하는 방식을 소개합니다. 메트릭 시각화 외에 Perses Go SDK, 타입 안전한 PromQL 빌더 인터페이스, Dashboard As Code 라이브러리를 주요 기능으로 제시합니다.

발표는 Perses의 Go 설정 방식과 Prometheus 연동이 어떻게 발전했는지 다룹니다. 함께 소개하는 community-dashboards는 가져다 쓸 수 있는 Go 모듈을 제공합니다. 이 모듈에는 Kubernetes, Prometheus, Thanos 등의 프로젝트를 위한 믹스인 대시보드 생성 메서드가 들어 있습니다.

kube-prometheus 스택에서 이런 구성을 도입하는 경로도 발표 범위에 포함됩니다. 소개문은 이 스택에 Perses Operator와 community-dashboard CRD가 포함돼 있으며, 이를 대체 시각화 계층으로 사용할 수 있다고 설명합니다. 실제 Go 코드나 CRD 정의는 소개문에 제시되지 않았습니다.

6. Prometheus의 OpenTelemetry 델타 시간성 지원 변화

원문: OTEL delta temporality support in Prometheus · Fiona Liao

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Fiona Liao는 OpenTelemetry와 Prometheus의 시간성 지원 차이에서 출발합니다. OpenTelemetry의 메트릭 모델은 델타 시간성과 누적 시간성을 모두 지원하지만, Prometheus는 역사적으로 누적 시간성만 지원했습니다. 그 결과 과거에는 Prometheus의 OTLP 엔드포인트로 델타 메트릭을 수집하려고 하면 거부됐습니다.

소개문은 OpenTelemetry 상호 운용성을 개선하기 위한 델타 지원에 최근 진전이 있었다고 설명합니다. 발표 범위는 과거 배경, 현재 상태, 향후 가능한 단계이며, 구현 과정의 어려움과 아직 남은 질문도 포함됩니다. 지원 버전이나 설정 방법, 해결된 문제의 구체적인 목록은 소개문에 없습니다.

7. 옵저버빌리티와 모니터링 정의의 타당성과 유용성

원문: Eight definitions of “observability” vs. “monitoring” – and why none of them work · Björn Rabenstein / Talks 2025

PromCon EU 2025 발표 소개문과 발표 목록인 「Talks 2025」를 기준으로 정리했습니다. Björn Rabenstein은 Prometheus가 인기를 얻던 때에는 드물었던 “observability”라는 말이 몇 년 뒤 널리 쓰이게 됐다고 설명합니다. 그 과정에서 어떤 사람은 Prometheus를 주요 옵저버빌리티 도구로 보고, 다른 사람은 아예 그 범주에 넣지 않는 혼란이 생겼다는 문제의식입니다.

발표는 옵저버빌리티와 모니터링을 구분하는 널리 알려진 정의와 덜 알려진 정의를 검토합니다. 각 정의가 타당한지, 얼마나 널리 쓰이고 유용한지를 평가하겠다고 예고합니다. 소개문은 Prometheus가 옵저버빌리티 도구인지 최종 답을 제시하지 않습니다. 별도 발표 목록에는 이 발표가 2025년 10월 21일 독일 뮌헨의 PromCon에서 열렸다고 기록돼 있으며, 영상과 슬라이드 링크가 있습니다. 제공된 목록에는 슬라이드 본문이 포함되지 않았습니다.

8. SAAFE 알림 분류와 장애 조사 우선순위

원문: SAAFE - A prioritized alerting model to troubleshoot your incidents · Jorge Creixell, Manoj Acharya / SAAFE Model

PromCon EU 2025 발표 소개문과 SAAFE Model 저장소의 README를 기준으로 정리했습니다. 발표자들은 Four Golden Signals, RED, USE가 시계열의 종류에 집중한다면, SAAFE는 시계열이 시스템 상태에서 무엇을 뜻하는지 분류한다고 설명합니다. Grafana Labs는 도메인 지식으로 데이터를 분석하는 자동 알림 시스템을 구축했으며, 분류와 심각도, 인스턴스 수, 발화 지속 시간을 결합해 알림의 점수와 순위를 매긴다고 밝힙니다. 당직 엔지니어는 이를 우선순위 선정, 필터링, 인과관계 추론에 사용합니다.

README는 중요한 알림에 조사 맥락을 보태는 알림을 Assertions로 정의합니다. 전체 시스템의 사건을 살핀 뒤 개별 구성 요소로 좁혀 들어가도록 돕는 방식입니다. 제안하는 순위 계산식은 score = duration * weight이며, 가중치는 info와 warning에 1, critical에 2를 적용합니다. 기존 알림에 saafe_severity와 saafe_category 레이블을 추가하는 참조 구현을 제공하며, 분류는 다음과 같습니다.

• Saturation: CPU, 메모리, 저장소, 네트워크 등 자원의 사용 정도. 과도한 사용은 장애의 원인이나 결과가 될 수 있음
• Amend: 규모 조정, 설정 변경, 버전 갱신 등 시스템 변화. 장애 원인 탐색에 필요한 변경 맥락
• Anomaly: 예상 밖의 트래픽 증가나 감소 등 패턴 변화. 그 자체가 항상 문제는 아니며 다른 분류와 함께 해석
• Failure: 필수 전제조건의 불충족. 서비스 중단, 반복 충돌, 불변 조건 위반 등 시스템 무결성에 영향을 주는 이진 상태
• Error: 서비스 요청의 미충족 또는 응답 품질 저하. 보통 집계한 뒤 기대하는 SLO와 비교

참조 구현은 Prometheus와 Grafana를 사용하지만, README는 메트릭과 알림을 지원하는 다른 환경에도 모델을 적용할 수 있다고 설명합니다. Docker가 필요한 데모는 Prometheus, Grafana, node exporter, OTEL 데모를 실행합니다. Assertions 대시보드는 활성 assertion의 시간별 변화, 합산 점수로 정렬한 job, job별 타임라인을 보여줍니다. 조사 시간 범위를 유지한 채 대시보드를 이동하는 예도 있습니다. README는 데모가 설명용이며 실제 서비스 운영에는 사용하지 말라고 명시합니다.

9. Criteo의 자동 집계와 카디널리티 축소

원문: A History of Automatic Aggregations · Raphaël Bizos

PromCon EU 2025 발표 소개문을 기준으로 정리했습니다. Raphaël Bizos는 Criteo가 여러 해 사용해 온 자동 집계의 발전 과정을 소개합니다. 여기서 자동 집계는 대부분의 메트릭에 적용되는 레코딩 룰 시스템입니다. 메트릭을 내보내는 인스턴스 같은 일부 차원을 제거해 카디널리티를 줄이고 질의 속도를 높입니다.

Criteo는 임시 해결책으로 시작한 이 방식이 수억 개의 활성 메트릭을 다루는 규모에서 백엔드 안정성과 신뢰성을 유지하는 주요 수단이 됐다고 설명합니다. 메트릭 저장 비용도 크게 줄였다는 주장입니다. 사용자가 직접 레코딩 룰을 작성할 필요가 없으며, 대부분의 팀이 규칙을 작성하거나 유지하지 않아도 된다는 뜻에서 내부적으로 “zero-effort Observability”라고 부릅니다.

발표는 시도했던 구현들과 그 과정에서 얻은 교훈, Prometheus 기반 스택에 맞춰 온 과정을 다루도록 구성됐습니다. 최신 구현은 Prometheus의 새 type 레이블을 활용한다고 소개합니다. 소개문에는 구체적인 집계 규칙이나 저장 비용 절감률, 질의 성능 측정값이 없습니다.