Prometheus 설계 문서

Prometheus 설계 문서 (Design doc)

이 문서는 Prometheus의 **원본 설계 문서(original design document)**예요. Prometheus가 왜 그렇게 설계되었는지, 푸시 대신 풀 방식을 택한 이유, 다차원 데이터 모델, 쿼리 언어, 알림 설계, 저장소 설계, 그리고 모니터링 시스템의 설계 원칙을 담고 있습니다.

2012년에 쓰여진 고전 문서로, Prometheus의 근본적인 설계 결정을 이해하는 데 가장 좋은 자료입니다. 운영 환경의 복잡성을 어떻게 데이터 모델과 쿼리 언어로 해결하려 했는지 보여줘요. (현대 Prometheus의 특정 구현 세부와는 다른 부분도 있으니 주의하세요.)

출처: 문서

본문

이 문서는 Prometheus의 원본 설계 문서입니다. 당시("Metric for monitoring systems"로 알려짐) 제시된 핵심 설계 목표와 지침을 요약합니다.

설계 목표 및 근본 질문

Prometheus는 "모니터링 시스템을 위한 메트릭"이라는 문제에서 출발했습니다. 설계 질문에는 다음이 포함됩니다:

  • 메트릭을 어떻게 저장하고 검색할까?
  • 푸시 방식과 풀 방식 중 어떤 것이 나을까?
  • 다차원(라벨) 데이터를 어떻게 모델링할까?
  • 알림과 계측을 어떻게 통합할까?

핵심 설계 결정

  • 풀(pull) 방식의 스크레이프 — 모니터링 시스템이 능동적으로 수집하면, 대상 추가가 쉬워지고 실패 감지가 자연스러워집니다.
  • 다차원 데이터 모델 — 메트릭 이름과 라벨로 시계열을 식별하며, 원하는 차원으로 집계·분해가 가능.
  • 강력한 쿼리 언어 — 시계열을 필터링·집계하고 수학 연산을 적용하는 쿼리 언어의 필요성.
  • 단순성 — 설정·운영이 단순하고, 대규모 시스템을 다룰 수 있어야 함.

메트릭과 라벨

  • 레이블이 차원(dimension)의 역할을 하여, 같은 메트릭을 여러 속성으로 분해할 수 있습니다.
  • 카운터·게이지·히스토그램(분포) 같은 메트릭 타입으로 의미를 부여합니다.

저장 및 성능

  • 로컬 디스크 기반의 시계열 저장, 지수 히스토그램 인코딩과 같은 효율적인 압축.
  • (현대 구현은 TSDB 블록 형식을 사용합니다 — 설계 문서는 초기 아이디어를 담고 있습니다.)

알림

  • 알림 규칙을 서버에서 평가해 Alertmanager로 전달하는 구조.

참고

이 문서는 역사적 설계 문서이므로, 정확한 현재 사양(메트릭 형식, 저장 인코딩, API 등)은 각각의 최신 문서를 참고하세요.

더 알아보기 (Learn more)