피드로 돌아가기
The Prometheus label that blew our monitoring bill out 6x
Dev.toDev.to
Infrastructure

High-Cardinality Label 제거를 통한 모니터링 비용 6배 폭증 해결

The Prometheus label that blew our monitoring bill out 6x

claire nguyen2026년 5월 29일4intermediate

Context

Prometheus 기반의 관리형 백엔드를 사용하는 환경에서 트래픽 변화 없이 비용이 급증하는 현상 발생. 고유 ID를 포함한 Label 추가로 인해 Time Series 수가 기하급수적으로 증가하며 인덱싱 부하와 비용 상승을 초래한 구조적 한계 직면.

Technical Solution

  • build_id와 같은 Unbounded Value를 포함한 Label이 생성하는 High-Cardinality 문제 식별
  • metric_relabel_configslabeldrop 액션을 적용하여 스크레이프 단계에서 문제의 Label을 강제 제거하는 파이프라인 구축
  • 고유 식별자가 필요한 상세 분석 요구사항을 Metric 저장소가 아닌 Trace 및 Log 저장소로 분리하여 데이터 저장 계층 최적화
  • 고차원 데이터 분석을 위해 Series Index에 부담을 주지 않는 Exemplars 도입 검토 및 적용
  • Label 추가 전 상한선(Upper Bound) 정의 가능 여부를 판단하는 엄격한 거버넌스 체계 수립

1. Label 추가 전 화이트보드에 해당 값의 최대 유니크 개수(Upper Bound)를 명시할 수 있는지 확인

2. `topk` 쿼리를 통해 Series 수를 가장 많이 생성하는 Metric과 Label을 정기적으로 모니터링

3. Unbounded ID가 필요할 경우 Metric Label 대신 Exemplars 또는 Distributed Tracing 연동 검토

4. 애플리케이션 코드 수정 없이 `metric_relabel_configs`를 통한 긴급 Label 제거 조치 적용

원문 읽기