Observability

Prometheus 는 2016 년 CNCF 에 가입한 후, CNCF 역사상 두 번째로 Graduated 단계에 오른 프로젝트다. 첫 번째 Graduated 프로젝트는 쿠버네티스였고, Prometheus 는 메트릭 수집과 모니터링이라는 단일 목적에 특화된 도구로 성장했다. Prometheus 가 태어난 배경인 클라우드 네이티브의 철학을 이해하면, 클라우드 네이티브란 무엇인가 에서 설명하는 컨테이너 오케스트레이션과 DevOps 파이프라인의 관계가 더 명확해진다.

Prometheus 의 핵심 기능 세 가지를 먼저 짚자.

첫째, 시간 경과에 따른 숫자 데이터를 수집한다. CPU 사용률, 요청 수, 지연 시간 — 이런 지표는 시계열 데이터다. Prometheus 는 이 데이터를 시간 축에 정렬해 저장하고, PromQL 로 자유롭게 추출할 수 있게 한다.

둘째, pull 기반 수집을 기본으로 한다. 에이전트가 서버로 데이터를 보내는 push 가 아니라, Prometheus 가 대상 서버의 /metrics 엔드포인트로 직접 접속해 데이터를 가져온다.

셋째, 단일 바이너리로 동작한다. 외부 데이터베이스나 메시징 시스템을 설치하지 않아도 된다. Prometheus 가 자체적으로 시계열 데이터를 디스크에 저장하고, 쿼리하고, 알람을 보낸다. 장기 저장을 위해서는 Thanos 나 Mimir 같은 확장 도구가 필요하지만, 기본 기능만으로도 충분히 작동한다.

Prometheus 가 메트릭 전용 도구라는 점은 의도적인 설계 선택이다. 로그는 Fluentd 나 Loki 가, 트레이스는 Jaeger 나 Tempo 가 각각 담당한다. Prometheus 는 메트릭에 집중함으로써 다른 도구보다 훨씬 깊이 있는 시계열 쿼리와 알람 기능을 제공한다.

메트릭 수집 방식에는 pull 과 push 가 있다. push 는 에이전트가 메트릭을 중앙 서버로 밀어 넣는 방식이고, pull 은 중앙 서버가 에이전트의 /metrics 엔드포인트로 직접 접속해 데이터를 가져간다. Prometheus 는 pull 을 선택했다. 이 결정이 왜 중요한지 세 가지 관점에서 본다.

서비스 디스커버리와 헬스체크의 동시 수행

쿠버네티스 환경에서는 파드가 끊임없이 생성되고 사라진다. push 모델에서는 파드가 살아있는 동안에만 메트릭을 보내고, 갑자기 사라지면 중앙 서버가 그 사실을 모른 채 오래된 데이터를 보유하게 된다. 반면 pull 모델에서는 Prometheus 가 정기적으로 타깃을 스캔하는데, /metrics 에 응답하지 않는 파드는 자동으로 unhealthy 로 표시된다. 타깃 상태를 확인하는 행위 자체가 헬스체크가 되는 구조다.

이 동작은 ServiceMonitor 나 PodMonitor 같은 쿠버네티스 커스텀 리소스로 자동화된다. Prometheus 는 Endpoints 정보를 바탕으로 scraping 대상 목록을 동적으로 구성하고, 응답이 끊긴 타깃은 scrape pool 에서 자동으로 제거한다. 파드의 생명주기를 더 깊이 이해하려면 쿠버네티스 Pod 완벽 가이드 를 참고하면, Pod 재시작 시 Counter 의 리셋과 관련된 현상을 자연스럽게 해석할 수 있다.

과부하 방지

push 모델에서 수많은 파드가 동시에 메트릭을 보내면 중앙 서버가 과부하에 빠질 수 있다. pull 모델에서는 Prometheus 가 scrape interval(기본 15초) 을 기준으로 자신의 부담을 통제할 수 있다. 타깃 수가 늘어나면 scrape concurrency 를 조정하거나 우선순위가 낮은 타깃의 주기를 늘리는 것이 가능하다.

내구성

push 모델에서 네트워크 장애가 발생하면 메트릭이 유실된다. pull 모델에서는 Prometheus 가 다음 scrape 에서 누락된 데이터를 보정할 수 있다. Prometheus 는 실패한 scrape 를 retry 하지 않고 다음 주기까지 기다리는데, 이는 단기 지표의 경우 데이터 gaps 가 큰 영향을 미치지 않기 때문이다.

Prometheus 의 데이터 모델은 SQL 의 테이블이나 MongoDB 의 문서와 완전히 다르다. metric name + label 조합이 하나의 시계열을 정의한다. 이 모델이 Prometheus 를 다른 시계열 데이터베이스와 구분하는 가장 큰 특징이다.

metric name 의 규칙

metric name 은 영문자와 밑줄, 콜론만으로 구성된다. http_requests_total 같은 이름은 "HTTP 요청의 총 횟수"를 의미한다. Prometheus 는 metric name 의 접미사를 통해 메트릭의 종류를 암시적으로 나타내는 관례를 사용한다. _total 은 Counter, _duration_seconds 는 시간 기반 측정임을 알려준다.

label 이 만드는 카디널리티

label 은 metric 에 태그를 붙이는 방식이다. http_requests_total 에서 method 와 handler 가 label 키고, "GET" 과 "/api" 가 label 값이다.

여기서 중요한 개념이 카디널리티다. 카디널리티란 metric name 과 label 의 고유 조합 수를 말한다. http_requests_total 에 user_id label 이 붙고, 각 user_id 가 고유한 값을 가진다면 — 예를 들어 10 만 명의 사용자가 있다면 — 이 metric 은 10 만 개의 시계열로 분화된다. Prometheus 는 메모리 상에서 각 시계열을 인덱싱하는데, 카디널리티가 너무 높아지면 메모리 사용량이 급증하고 쿼리 성능이 저하된다.

이것이 Prometheus 의 가장 흔한 운영 함정이다. label 값에 UUID, 요청 ID, 사용자 이메일 같은 고 유니크 값을 넣지 않아야 하는 이유다. label 은 분류 목적으로만 사용하고, 상세한 식별자는 annotation 에 맡기는 것이 원칙이다. APM 핵심 지표 읽는 법 에서 설명하는 Golden Signals(지연 시간, 트래픽, 오류, 포만도) 를 Prometheus 메트릭으로 매핑할 때도, label 카디널리티를 염두에 두지 않으면 대시보드 설계 시 성능 문제가 발생할 수 있다.

Prometheus 는 네 가지 기본 메트릭 타입을 제공한다. 각각 다른 측정 대상에 맞춰져 있고, 잘못 사용하면 쿼리 결과가 완전히 달라진다.

Counter — 누적값

Counter 는 한 방향으로만 증가하는 값이다. 요청 수, 처리된 바이트 수, 오류 발생 횟수 — 이 값들은 절대 줄어들지 않는다. Counter 는 절대값보다 증가율(rate) 이 중요하다. http_requests_total 이 1000 에서 1200 으로 늘었다면, 그 사이 200 개의 요청이 처리된 것이다. 파드가 재시작되면 값이 0 으로 리셋되므로, 반드시 rate() 함수로 단위 시간당 증가율을 계산해야 한다.

Gauge — 오가는 값

Gauge 는 오르내리는 값이다. CPU 사용률, 메모리 사용량, 현재 연결 수 — 이 값들은 언제든 증가하기도 하고 감소하기도 한다. Gauge 는 현재 시점의 값을 읽는 것이 주목적이며, rate() 대신 avg() 나 max() 같은 집계 함수를 주로 사용한다. node_memory_MemAvailable_bytes 는 사용 가능한 메모리 양을 나타내는 Gauge 로, 이 값이 갑자기 0 에 가까워지면 메모리 부족을 의미한다.

Histogram — 분포를 쪼개기

Histogram 은 값의 분포를 구간(bucket) 으로 나누어 저장한다. HTTP 응답 시간을 0.01 초, 0.05 초, 0.1 초, 0.5 초, 1 초 미만으로 구간을 나누면, 각 구간에 몇 개의 요청이 빠졌는지 알 수 있다. Histogram 은 bucket 샘플 수, 샘플 합계, 샘플 개수 세 가지 데이터를 저장하며, 이를 조합해 다양한 percentiles 를 계산할 수 있다.

Summary — 클라이언트 측 percentiles

Summary 도 Histogram 과 비슷하게 percentiles 를 제공하지만, 계산 주체가 다르다. Histogram 은 서버가 bucket 에 빠진 값을 집계하고, Summary 는 클라이언트(sidecar 에이전트) 가 percentiles 를 미리 계산해 저장한다. Prometheus 의 histogram_quantile() 함수는 Histogram 의 bucket 데이터를 기반으로 percentiles 를 근사 계산하며, SLA 검증에 자주 쓰인다. 실무에서는 Histogram 이 더 널리 쓰인다. percentiles 를 쿼리 시 결정할 수 있는 유연성이 운영에서 훨씬 유용하기 때문이다.

Prometheus Query Language(PromQL) 는 시계열 데이터를 다루기 위한 전용 언어다. 수십 개의 함수가 있지만, 실제로 매일 쓰는 함수는 세 개다.

rate() — 단위 시간당 증가율

rate(http_requests_total[5m]) — 이 쿼리는 "api-server 의 http_requests_total 메트릭에서, 최근 5 분간의 단위 시간당 증가율"을 계산한다. rate 함수는 Counter 메트릭에 반드시 필요하다. Counter 의 절대값은 파드 재시작으로 리셋되므로, 증가율을 계산하지 않으면 데이터가 갑자기 뚝 떨어진 것처럼 보인다. rate 는 이 리셋을 자동으로 보정한다. [5m] 은 범위 시간 범위(range vector) 라 부르고, 1~5 분이 적당하다.

sum by() — 라벨로 그룹화해 합산

sum by (pod) (rate(container_cpu_usage_seconds_total[5m])) — 이 쿼리는 파드별로 CPU 사용률을 합산한다. sum by (pod) 의 pod 부분은 group by 절이다. 다중 파드 환경에서 전체 리소스 사용량을 파악할 때 필수적이다.

histogram_quantile() — percentiles 추출

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) — 이 쿼리는 "최근 5 분간 HTTP 요청의 95 퍼센타일 응답 시간"을 계산한다. SLA 검증에 자주 쓰이며, "95% 의 요청이 200ms 이내에 응답해야 한다"는 SLA 가 있다면 이 쿼리의 결과가 200ms 를 초과하는지 모니터링하면 된다.

Prometheus 가 쿠버네티스와 자연스럽게 동작하는 이유는 쿠버네티스 네이티브의 서비스 디스커버리 메커니즘 덕분이다. Prometheus 는 Kubernetes API 에 직접 접속해 파드, 서비스, 엔드포인트 정보를 가져오고, 이를 바탕으로 scraping 대상을 자동 구성한다. 쿠버네티스 아키텍처 완전 정복 에서 컨트롤 플레인과 데이터 플레인의 구조를 이해하면, kube-state-metrics 가 어떤 정보를 가져오는지, node-exporter 가 어디에 위치하는지 명확해진다.

kube-state-metrics — 쿠버네티스 객체의 상태 메트릭

kube-state-metrics 는 쿠버네티스 API 서버의 데이터를 읽어와 메트릭으로 변환하는 추가 컴포넌트다. 파드가 Running 인지 Pending 인지, 디플로이먼트의 리플리카 수는 몇 개인지 — 이런 정보는 /metrics 엔드포인트에서 노출되지 않으며, kube-state-metrics 가 별도의 메트릭으로 제공한다. kube_pod_status_phase 은 현재 Running 상태인 파드의 수를, kube_deployment_spec_replicas 는 설정된 리플리카 수를 나타낸다. kube-state-metrics 는 push 가 아니라 pull 방식으로 동작하며, 외부 데이터베이스나 브로커가 필요 없는 Stateless 컴포넌트다.

node-exporter — 노드 레벨의 하드웨어 메트릭

node-exporter 는 각 쿠버네티스 노드에서 동작하는 exporter 다. CPU, 메모리, 디스크 I/O, 네트워크 트래픽 같은 하드웨어 및 OS 레벨의 메트릭을 Prometheus 형식으로 노출한다. Prometheus 가 직접 하드웨어 메트릭을 수집할 수 없으므로, 각 노드에 exporter 를 배포하고 Prometheus 가 이를 scrape 한다.

ServiceMonitor — 쿠버네티스 네이티브 서비스 디스커버리

ServiceMonitor 는 Prometheus Operator 가 제공하는 커스텀 리소스로, 특정 서비스의 엔드포인트를 자동으로 scrape 대상으로 등록한다. app=api-server 라벨을 가진 서비스의 metrics 포트를 15 초마다 scrape 하라는 의미다. 파드가 새로 생성되거나 사라져도 ServiceMonitor 는 자동으로 대응한다. 쿠버네티스에서 Prometheus 를 운영하려면 Prometheus Operator 와 CRD 가 필수적이다.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-server
  namespace: default
spec:
  selector:
    matchLabels:
      app: api-server
  endpoints:
  - port: metrics
    interval: 15s

Prometheus 는 메트릭 수집에 탁월하지만, 모든 옵저버빌리티 문제를 해결하는 만능 도구는 아니다.

그림 1. Prometheus 는 메트릭 전용이다 — 로그·트레이스까지 한 백엔드로 묶으려면 다른 선택지를 본다.

장기 저장 — Thanos 와 Mimir

Prometheus 는 로컬 디스크에 데이터를 저장하므로, 노드가 재시작되면 과거 데이터가 사라진다. 또한 단일 Prometheus 인스턴스가 처리할 수 있는 메트릭 양에 한계가 있다. 일반적으로 단일 인스턴스가 100 만 개 이하의 시계열을 처리하는 것이 권장된다.

Thanos 는 Prometheus 의 기존 아키텍처를 최대한 활용하면서 장기 저장과 글로벌 쿼리 능력을 추가한다. Thanos Sidecar 는 Prometheus 와 함께 동작하며 데이터를 객체 스토리지(S3, GCS 등) 에 백업하고, Thanos Query 는 여러 Prometheus 인스턴스의 데이터를 통합해 단일 쿼리로 처리한다.

Mimir(구 Cortex) 는 Prometheus 와 호환되는 분산 아키텍처로, 처음부터 대규모 관측 가능성을 위해 설계되었다. Mimir 는 메트릭 수집, 저장, 쿼리를 각각 독립적으로 스케일링할 수 있으며, 수억 개의 시계열을 처리할 수 있다. 기존 Prometheus 인스턴스를 유지하면서 장기 저장만 추가하려면 Thanos 가 적합하고, 처음부터 대규모 분산 아키텍처를 구축하려면 Mimir 가 더 적합하다.

로그와 트레이스 — OpenTelemetry 와의 관계

Prometheus 는 메트릭만 다룬다. 로그를 수집하려면 Fluentd 나 Loki 를, 분산 트레이스를 위해서는 Jaeger 나 Tempo 를 사용해야 한다. 이 세 가지(메트릭, 로그, 트레이스) 를 통합하는 접근 방식으로 OpenTelemetry 가 부상하고 있다. OpenTelemetry 는 메트릭, 로그, 트레이스를 모두 수집하는 표준 프레임워크로, Prometheus 는 메트릭 수집 부분에서 OpenTelemetry 와 자연스럽게 통합된다. OpenTelemetry Collector 가 수집한 메트릭을 Prometheus 형식으로 변환해 내보내면, Prometheus 가 이를 scrape 할 수 있다.

Prometheus 가 로그나 트레이스를 직접 다루지 않는 것은 결함이 아니라 설계 선택이며, 이 선택 덕분에 Prometheus 는 메트릭 분야에서 다른 도구보다 훨씬 깊이 있는 기능을 제공한다.

Prometheus 와 Grafana 는 같은 도구인가?

아니다. Prometheus 는 메트릭을 수집하고 저장하는 데이터베이스이고, Grafana 는 그 데이터를 시각화하는 대시보드 도구다. Prometheus 는 Grafana 없이도 단독으로 동작하지만, PromQL 콘솔을 통해 직접 쿼리를 확인해야 하므로 운영이 불편하다. Grafana 는 Prometheus 를 포함한 다양한 데이터 소스를 연결해 대시보드를 구성하고 알람을 설정할 수 있다. 보통 Prometheus + Grafana 조합으로 관측성 스택을 구성한다.

Prometheus 의 scrape interval 을 너무 짧게 설정하면 안 되는 이유는?

scrape interval 이 짧을수록 Prometheus 가 부담하는 scrape 작업량이 기하급수적으로 늘어난다. 각 타깃에 대해 HTTP 연결을 열고, /metrics 를 요청하고, 응답을 파싱하고, 메모리에 저장하는 전 과정이 매 scrape 마다 반복되기 때문이다. 또한 메트릭 카디널리티가 높은 환경에서 scrape interval 을 5 초처럼 짧게 설정하면 메모리 사용량이 급증하고 GC 부하가 커져 Prometheus 자체가 불안정해질 수 있다. 일반적으로 15~30 초가 적당하며, 중요한 메트릭만 더 짧은 주기로 수집하는 것이 좋다.

Prometheus 가 다루지 않는 것은 무엇인가?

Prometheus 는 메트릭만 다룬다. 로그 파일 분석, 분산 트레이스 추적, 이벤트 기반 알림 등은 Prometheus 의 범위가 아니다. 이러한 작업에는 각각 전용 도구가 필요하다. 로그에는 Fluentd 나 Loki, 트레이스에는 Jaeger 나 Tempo, 이벤트에는 Elasticsearch 를 사용한다. Prometheus 는 OpenTelemetry 를 통해 메트릭·로그·트레이스를 수집하는 통합 파이프라인에서 메트릭 수집 담당자로 참여한다.

Prometheus 공식 문서

• Prometheus 개요 — 아키텍처, 메트릭 모델, PromQL 입문.
• Prometheus Operators — 쿠버네티스 서비스 디스커버리 설정.
• PromQL Documentation — PromQL 기본 문법과 함수.
• Prometheus Storage Overview — 저장소 구조와 장기 저장 옵션.
• Prometheus Best Practices — 메트릭 네이밍, 라벨 관리, 카디널리티 팁.

함께 읽으면 좋은 글

• 쿠버네티스란 무엇인가 — Prometheus 가 동작하는 쿠버네티스 기본 개념. 파드·서비스·네임스페이스 관계가 서비스 디스커버리 이해의 첫걸음.
• 쿠버네티스 아키텍처 완전 정복 — 컨트롤 플레인과 데이터 플레인 구조. kube-state-metrics 와 node-exporter 위치 파악.
• 쿠버네티스 Pod 완벽 가이드 — 파드 생명주기. scrape 대상 사라짐 현상과 Counter 리셋 사례.
• 클라우드 네이티브란? — 클라우드 네이티브 철학. 메트릭·로그·트레이스 분리 배경.
• APM vs 옵저버빌리티 차이 — 옵저버빌리티 생태계에서 Prometheus 의 역할.
• APM 핵심 지표 읽는 법 — Golden Signals 와 Prometheus 메트릭 매핑. 대시보드 설계 참고.
• 클라우드 네이티브 4대 요소 — 마이크로서비스, 컨테이너, DevOps 에서 Prometheus 의 위치.