Prometheus 운영 실전 가이드: TSDB, 카디널리티, Recording Rules, Federation, Remote Write

• 들어가며
• TSDB 운영의 기본: retention은 저장 정책이 아니라 비용 정책이다
• 카디널리티는 관측 범위가 아니라 설계 품질 문제다
  • 왜 high cardinality가 위험한가
  • 실무에서 지켜야 할 기준
• Recording Rules와 Alerting Rules는 분리해서 설계해야 한다
  • Recording Rules는 계산비용을 줄이는 계층이다
  • Alerting Rules는 noisy query가 아니라 운영 계약이어야 한다
• Federation과 Remote Write는 비슷해 보여도 목적이 다르다
  • Federation이 맞는 경우
  • Remote Write가 맞는 경우
• 운영팀이 반드시 문서화해야 할 항목
  • 1. 메트릭 온보딩 기준
  • 2. 룰 관리 기준
  • 3. 저장 정책
  • 4. 운영 SLO
• 실전 운영 체크리스트
• 마무리
• References

들어가며

Prometheus는 설치보다 운영이 어렵습니다. 처음에는 scrape target 몇 개와 Grafana 대시보드로 시작하지만, 시간이 지나면 거의 반드시 아래 문제가 나타납니다.

• 메트릭 수가 늘면서 TSDB 디스크 사용량이 급격히 커진다
• label 설계가 무너지면서 high-cardinality 폭탄이 터진다
• 대시보드와 알림이 같은 무거운 PromQL을 반복 실행한다
• 여러 클러스터와 여러 리전에 걸친 집계가 필요해진다
• 장기 보관이 필요해지며 federation과 remote write의 선택이 필요해진다

Prometheus 운영의 핵심은 단순히 "더 많은 메트릭을 수집"하는 것이 아니라, 어떤 메트릭을 어떤 보존 정책으로 어떤 비용 한도 안에서 유지할 것인가를 설계하는 것입니다.

TSDB 운영의 기본: retention은 저장 정책이 아니라 비용 정책이다

Prometheus의 내장 TSDB는 운영이 단순한 대신, retention과 디스크 사용량을 대충 잡으면 곧바로 비용과 안정성 문제가 됩니다.

가장 먼저 정해야 할 것은 다음 두 가지입니다.

• 로컬 Prometheus가 며칠치 데이터를 가져야 하는가
• 장기 보관이 필요하면 어디로 내보낼 것인가

대부분의 프로덕션 환경에서는 로컬 Prometheus를 짧은 고성능 운영 저장소로 보고, 장기 보관은 외부 시스템으로 분리하는 편이 안전합니다.

storage:
  tsdb:
    retention.time: 15d

운영 시 체크할 포인트는 다음과 같습니다.

• retention time과 retention size 중 무엇이 실제 제한이 되는가
• WAL과 block compaction 패턴이 디스크 여유와 맞는가
• 재시작 후 replay 시간이 너무 길지 않은가
• 디스크 IOPS와 압축률이 현재 수집량과 맞는가

Prometheus 디스크 사용량 문제는 "용량 부족"이 아니라, 대개 메트릭 설계와 scrape 범위가 이미 과도하다는 신호입니다.

카디널리티는 관측 범위가 아니라 설계 품질 문제다

왜 high cardinality가 위험한가

Prometheus에서 시계열 수는 metric name 하나가 아니라, 모든 label 조합의 곱으로 늘어납니다. 예를 들어 user_id, session_id, request_id 같은 고유값을 label에 넣으면 운영이 금방 무너집니다.

카디널리티가 높아지면 다음이 동시에 악화됩니다.

• 메모리 사용량
• 쿼리 latency
• 디스크 사용량
• compaction 시간
• rule evaluation 비용

실무에서 지켜야 할 기준

• unbounded identifier를 label로 넣지 않는다
• alerting과 dashboard에 실제로 쓰는 label만 남긴다
• exporter 기본 메트릭도 무조건 다 수집하지 않는다
• 신규 서비스 온보딩 때 label review를 필수화한다

Prometheus 운영에서 가장 비용 효율이 큰 작업 중 하나는 새 서버를 붙이는 것이 아니라, 쓸모없는 label을 제거하는 것입니다.

Recording Rules와 Alerting Rules는 분리해서 설계해야 한다

Recording Rules는 계산비용을 줄이는 계층이다

무거운 PromQL을 매번 대시보드와 alert rule에서 직접 돌리면 비용이 급격히 증가합니다. 반복 쿼리는 recording rule로 사전 계산해 두는 것이 좋습니다.

groups:
  - name: service-latency
    interval: 30s
    rules:
      - record: job:http_request_duration_seconds:rate5m
        expr: sum by (job) (rate(http_request_duration_seconds_count[5m]))

recording rule이 유용한 상황은 다음과 같습니다.

• 대시보드 여러 패널이 같은 expensive query를 공유할 때
• SLI 계산을 표준화하고 싶을 때
• federation 또는 downstream 시스템으로 가볍게 전달하고 싶을 때

Alerting Rules는 noisy query가 아니라 운영 계약이어야 한다

좋은 알림은 복잡한 PromQL보다 다음 특성을 가집니다.

• 의미가 명확하다
• 지속 시간 조건이 있다
• runbook과 연결된다
• 너무 많은 label fanout을 만들지 않는다

groups:
  - name: service-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)
          / sum(rate(http_requests_total[5m])) by (job) > 0.05
        for: 10m

for 없이 즉시 발화하는 알림은 많은 환경에서 잡음을 키웁니다. 반대로 너무 긴 for는 탐지 지연을 만듭니다. 결국 운영 팀이 감당 가능한 반응 속도와 서비스 특성을 같이 봐야 합니다.

Federation과 Remote Write는 비슷해 보여도 목적이 다르다

Federation이 맞는 경우

federation은 상위 Prometheus가 하위 Prometheus에서 선택된 집계 메트릭을 scrape해 가져오는 모델입니다.

이 방식이 잘 맞는 경우는:

• 여러 클러스터의 요약 메트릭만 상위 계층에서 보고 싶을 때
• 계층적 아키텍처로 지역별 Prometheus를 묶고 싶을 때
• raw series 전체가 아니라 집계 결과만 중앙에서 보고 싶을 때

Remote Write가 맞는 경우

remote write는 메트릭을 외부 스토리지나 long-term backend로 스트리밍 전송하는 방식입니다.

이 방식이 잘 맞는 경우는:

• 장기 보관이 필요할 때
• 중앙 multi-tenant 스토리지가 필요할 때
• 전역 쿼리와 장기 추세 분석이 필요할 때
• Prometheus 로컬 디스크를 짧게 유지하고 싶을 때

둘을 단순 비교하면 안 됩니다. federation은 계층적 집계, remote write는 외부 저장과 확장성에 더 가깝습니다.

운영팀이 반드시 문서화해야 할 항목

Prometheus는 설정 파일만 있는 도구가 아니라 운영 시스템입니다. 따라서 아래 항목은 반드시 문서화하는 편이 좋습니다.

1. 메트릭 온보딩 기준

• 어떤 metric과 label만 허용하는가
• cardinality review는 누가 하는가
• exporter 기본 메트릭은 어디까지 유지하는가

2. 룰 관리 기준

• recording rule과 alert rule owner는 누구인가
• rule evaluation interval은 어떤 기준으로 정하는가
• alert annotation에 runbook URL을 넣는가

3. 저장 정책

• 로컬 retention은 며칠인가
• remote write 대상은 무엇인가
• 장애 시 어떤 범위의 메트릭 손실을 허용하는가

4. 운영 SLO

• Prometheus query latency SLO
• target scrape success rate
• rule evaluation success rate
• TSDB disk usage upper bound

실전 운영 체크리스트

제가 운영 시 가장 자주 보는 항목은 아래입니다.

1. target scrape failure가 늘고 있는가
2. 시계열 수가 최근 배포 이후 급증했는가
3. 가장 비싼 dashboard query와 alert query는 무엇인가
4. recording rule로 치환 가능한가
5. 로컬 retention이 디스크와 재시작 시간을 압박하는가
6. federation과 remote write 목적이 섞여 있지 않은가

Prometheus는 대시보드가 아니라, 메트릭 경제를 관리하는 시스템으로 봐야 오래 갑니다.

마무리

Prometheus 운영은 스크랩 대상을 늘리는 게임이 아닙니다. 시계열 수를 제어하고, 계산 비용을 recording rule로 낮추고, 저장 전략을 단계화하고, 운영 기준을 문서화하는 작업입니다.

특히 아래 네 가지는 초기에 잡아둘수록 좋습니다.

• high-cardinality label 금지 원칙
• recording rule 우선 설계
• alert rule의 for와 runbook 연결
• federation과 remote write의 역할 분리

잘 운영되는 Prometheus는 더 많은 메트릭을 모으는 시스템이 아니라, 더 나은 메트릭을 더 낮은 비용으로 유지하는 시스템입니다.

References

• Prometheus Storage
• Metric and Label Naming
• Instrumentation Best Practices
• Recording Rules
• Alerting Rules
• Federation
• Remote Write Tuning