185. 메트릭 (Metrics - Prometheus, Grafana)

핵심 인사이트 (3줄 요약)

본질: 메트릭 (Metrics)은 시스템 상태를 숫자 기반 시계열로 압축해 "얼마나 자주, 얼마나 느리게, 얼마나 많이"를 빠르게 답하게 만드는 관측 신호다.

가치: Prometheus의 풀 (Pull) 수집, 라벨 기반 데이터 모델, Grafana 대시보드는 클라우드 네이티브 환경에서 서비스 수준 지표 (Service Level Indicator, SLI)와 용량 추세를 표준 방식으로 운영하게 해 준다.

판단 포인트: 좋은 메트릭 설계의 성패는 수집량이 아니라 레이블 카디널리티 (Cardinality), 히스토그램 버킷, 스크레이프 주기, 보존 정책을 비용과 질문에 맞게 설계했는지에 달려 있다.

Ⅰ. 개요 및 필요성

메트릭은 시간의 흐름에 따라 계속 갱신되는 숫자 관측값이다. 중앙 처리 장치 (Central Processing Unit, CPU) 사용률, Hypertext Transfer Protocol (HTTP) 요청 수, 오류율, 지연시간 백분위수처럼 운영자가 가장 먼저 확인하는 값들이 여기에 속한다. 로그가 개별 사건의 문장을 남기고, 분산 추적 (Distributed Tracing)이 요청 경로를 이어 준다면, 메트릭은 전체 시스템이 정상 범위를 벗어났는지를 가장 빠르게 알려 주는 계기판 역할을 한다.

클라우드 네이티브 환경에서 메트릭이 더 중요해진 이유는 대상이 고정 서버에서 짧게 살아남는 컨테이너와 파드 (Pod)로 바뀌었기 때문이다. 인스턴스가 수시로 생기고 사라지는 환경에서는 개별 서버 이름보다 서비스 단위의 집계가 중요하다. 그래서 메트릭은 "한 대를 본다"가 아니라 "서비스 전체의 행동을 숫자로 본다"는 관점으로 설계해야 한다.

메트릭이 없으면 장애 감지는 대부분 사용자의 불만이나 로그 검색 이후로 늦어진다. 반대로 메트릭이 잘 잡혀 있으면 요청량 급증, 오류율 상승, 포화도 증가를 몇 초에서 수십 초 안에 감지하고, 서비스 수준 목표 (Service Level Objective, SLO) 위반 가능성까지 미리 볼 수 있다. 즉 메트릭의 본질은 단순 기록이 아니라 빠른 감지와 비교 가능한 운영 기준을 제공하는 데 있다.

┌────────────────────────────────────────────────────────────────────┐
│ Metrics answer the first operational question                     │
├────────────────────────────────────────────────────────────────────┤
│ Raw events -> aggregation by time window -> time-series numbers   │
│                                                                    │
│ request started                                                    │
│ request failed    ----> error_rate{service="checkout"}             │
│ latency observed  ----> latency_p95{service="checkout"}            │
│ cpu sampled       ----> cpu_usage{node="worker-a"}                 │
│                                                                    │
│ First question: "Is the system unhealthy right now?"              │
└────────────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 메트릭은 병원 응급실의 활력 징후 모니터와 같다. 환자의 모든 사연을 말해 주지는 않지만, 맥박과 산소포화도가 흔들리는 순간 위험을 가장 먼저 알려 준다.

Ⅱ. 아키텍처 및 핵심 원리

Prometheus는 계측된 애플리케이션이나 익스포터 (Exporter)에서 /metrics 엔드포인트를 주기적으로 읽어 오는 풀 기반 수집기를 중심으로 동작한다. 애플리케이션은 카운터 (Counter), 게이지 (Gauge), 히스토그램 (Histogram), 서머리 (Summary) 같은 유형으로 수치를 노출하고, Prometheus는 이를 시계열 데이터베이스 (Time Series Database, TSDB)에 저장한 뒤 Prometheus Query Language (PromQL)로 계산한다. Grafana는 그 결과를 대시보드와 경보 맥락으로 시각화하고, Alertmanager는 경보를 묶어 전달한다.

이 구조의 핵심은 "수집-저장-질의-시각화"가 느슨하게 분리된다는 점이다. 익스포터는 값을 노출하는 데만 집중하고, Prometheus는 스크레이프 주기와 라벨을 기준으로 저장하며, Grafana는 보기 좋은 그래프를 만드는 데 집중한다. 그래서 메트릭 설계는 도구 선택보다 먼저 무엇을 어떤 라벨로 얼마나 자주 수집할지를 정하는 일이다.

┌────────────────────────────────────────────────────────────────────┐
│ Prometheus metric pipeline                                        │
├────────────────────────────────────────────────────────────────────┤
│ App / Exporter                                                    │
│   └─ /metrics endpoint                                            │
│          ▲                                                        │
│          │ scrape every 15s / 30s                                 │
│          │                                                        │
│ Prometheus Server                                                 │
│   ├─ service discovery                                            │
│   ├─ TSDB                                                         │
│   ├─ recording rules                                              │
│   └─ alert rules                                                  │
│          │                           │                            │
│          ├──────────────┬────────────┘                            │
│          ▼              ▼                                         │
│      Grafana       Alertmanager                                   │
│   dashboards        route / group / page                          │
└────────────────────────────────────────────────────────────────────┘

메트릭 유형	의미	잘 맞는 예시	설계 시 주의점
카운터 (Counter)	단조 증가 누적값	총 요청 수, 총 오류 수	직접 값보다 `rate()`나 `increase()`로 해석
게이지 (Gauge)	현재 시점 값	CPU 사용률, 큐 길이, 메모리 사용량	순간 스파이크와 샘플 간격 왜곡에 주의
히스토그램 (Histogram)	버킷별 분포	지연시간, 응답 크기	버킷 경계를 업무 지연 구간에 맞춰 설계
서머리 (Summary)	클라이언트 측 요약값	라이브러리 내부 지연 통계	여러 인스턴스 합산 백분위수 계산이 어려움

지연시간 메트릭에서는 히스토그램 설계가 특히 중요하다. 평균값은 극단 지연을 숨기기 쉽지만, 히스토그램은 p95, p99 같은 백분위수와 서비스 수준 지표를 계산하는 데 유리하다. 예를 들어 http_request_duration_seconds_bucket에서 histogram_quantile()을 쓰면 느린 꼬리 구간을 볼 수 있다. 실무에서는 골든 시그널 (Golden Signals)의 지연시간, 트래픽, 오류, 포화도를 대부분 이런 메트릭 조합으로 계산한다.

rate(http_requests_total{job="api"}[5m])
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

📢 섹션 요약 비유: Prometheus와 Grafana는 공장 생산라인의 센서와 중앙 계기실 같다. 센서는 각 장비의 숫자를 보내고, 계기실은 그 숫자를 모아 어느 라인이 느려졌는지 한눈에 보여 준다.

Ⅲ. 비교 및 연결

메트릭의 경계는 로그, 분산 추적과 비교할 때 가장 잘 드러난다. 메트릭은 집계된 숫자라서 추세와 이상 탐지에 강하지만, 개별 오류의 문맥은 약하다. 로그는 예외 메시지와 입력 문맥에 강하지만, 규모가 커질수록 탐색 비용이 높다. 분산 추적은 서비스 간 인과관계에 강하지만, 장기 추세를 읽는 데는 메트릭만큼 효율적이지 않다.

비교 축	메트릭 (Metrics)	로그 (Logs)	분산 추적 (Distributed Tracing)
가장 잘 답하는 질문	얼마나 느린가, 얼마나 자주 깨지는가	무슨 예외가 났는가	어느 구간에서 막혔는가
데이터 형태	집계된 시계열 숫자	이벤트 문장 또는 구조화 레코드	요청 경로 그래프
경보 적합성	매우 높음	낮음	중간
장기 추세 분석	높음	낮음	중간
개별 원인 분석	낮음	매우 높음	높음

Prometheus의 풀 모델도 푸시 기반 메트릭 시스템과 비교해 봐야 한다. 풀 모델은 대상 상태를 Prometheus가 직접 확인하므로 생존 여부와 수집 실패를 함께 판단하기 쉽고, 쿠버네티스 서비스 디스커버리와 잘 맞는다. 반면 짧게 실행되는 배치 작업은 푸시게이트웨이 (Pushgateway)나 OpenTelemetry Collector 같은 중간 계층이 더 적합할 수 있다. 즉 "풀 vs 푸시"는 정답 경쟁이 아니라 대상 생명주기와 네트워크 구조의 문제다.

또한 메트릭 설계는 서비스 수준 지표, 서비스 수준 목표, 에러 버짓 (Error Budget)과 직접 연결된다. 요청 성공률, p95 지연시간, 작업 큐 지연은 단순 그래프가 아니라 운영 정책의 입력값이 된다. 그래서 메트릭은 관측성 도구이면서 동시에 품질 계약의 언어다.

📢 섹션 요약 비유: 메트릭은 도시 전체 교통량을 보는 항공 지도, 로그는 사고 접수 기록, 추적은 한 차량의 이동 경로와 같다. 길이 막혔는지부터 보려면 먼저 항공 지도가 필요하다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 가장 먼저 설계할 것은 대시보드가 아니라 메트릭 이름, 단위, 라벨 규칙이다. requests_total처럼 단위가 불명확한 이름보다 http_requests_total, queue_depth, cpu_usage_ratio처럼 대상과 단위가 드러나는 이름이 훨씬 낫다. 라벨도 service, region, status_code처럼 집계 가능한 차원만 남기고, user_id, order_id, session_id처럼 사실상 무한대에 가까운 값은 피해야 한다.

판단 항목	권장 접근	이유
스크레이프 주기	일반 인프라는 15~30초, 초고민감 지표만 더 짧게	해상도와 저장 비용의 균형
보존 기간	로컬 Prometheus는 단기, 장기는 Thanos·Mimir·VictoriaMetrics 검토	단일 노드 TSDB의 용량 한계
경보 기준	증상 기반 + 지속 시간 조건	순간 스파이크로 인한 오탐 감소
대시보드 구성	RED (Rate, Errors, Duration) + USE (Utilization, Saturation, Errors) 혼합	서비스와 인프라를 함께 해석 가능
라벨 정책	저카디널리티 유지, 공통 라벨 표준화	쿼리 성능과 비용 보호

특히 히스토그램 버킷은 실제 의사결정 구간에 맞춰야 한다. 응답시간 목표가 100ms, 300ms, 1s라면 버킷도 그 지점 주변에서 촘촘해야 한다. 버킷이 너무 거칠면 백분위수가 무의미해지고, 너무 촘촘하면 시계열 수가 과도하게 늘어난다. 메트릭 설계는 정확도 경쟁이 아니라 운영 질문에 필요한 해상도만 남기는 절제다.

경보는 원인보다 사용자 증상에 가까워야 한다. 예를 들어 CPU 사용률 90퍼센트만으로 바로 호출하기보다, 오류율 상승 또는 지연시간 악화와 함께 볼 때 더 실행 가능한 경보가 된다. 서비스 수준 목표를 운영하는 팀이라면 멀티 윈도·멀티 번 레이트 (Multi-window Multi-burn-rate) 방식으로 에러 버짓 소진 속도를 경보에 반영하는 것이 좋다.

대표 안티패턴도 분명하다. 첫째, 모든 값을 메트릭 라벨로 밀어 넣는 카디널리티 폭발이다. 둘째, Recording Rule이 없어 매 쿼리마다 무거운 계산을 반복하는 구조다. 셋째, 메트릭만 믿고 로그·추적 연계를 하지 않아 "이상은 보이는데 이유는 모르는" 상태에 빠지는 것이다.

📢 섹션 요약 비유: 메트릭 운영은 가계부 작성과 같다. 항목을 너무 잘게 쪼개면 적는 비용이 더 커지고, 너무 뭉뚱그리면 어디서 새는지 모른다. 필요한 수준까지만 분류해야 진짜 도움이 된다.

Ⅴ. 기대효과 및 결론

메트릭이 잘 설계되면 장애를 빨리 감지하고, 용량 계획을 수치로 설명하며, 배포 전후 품질 변화를 같은 기준으로 비교할 수 있다. Prometheus와 Grafana 조합은 특히 쿠버네티스, 마이크로서비스, 플랫폼 운영처럼 대상이 자주 바뀌는 환경에서 서비스 단위의 공통 숫자 언어를 제공한다. 이는 운영자가 서버 이름보다 서비스 건강도와 사용자 경험에 집중하게 만든다.

다만 메트릭은 만능이 아니다. 메트릭은 집계 데이터이므로 개별 오류의 서사를 직접 주지 못하고, 장기 보존이나 멀티클러스터 집계는 별도 아키텍처가 필요하다. 또한 수집 대상을 늘릴수록 스토리지, 쿼리, 대시보드 관리 비용도 함께 증가한다. 따라서 메트릭의 핵심 가치는 많이 모으는 것이 아니라 같은 질문을 반복 가능하게 만드는 표준 숫자 체계를 만드는 데 있다.

결론적으로 메트릭은 관측성의 출발점이다. 먼저 메트릭으로 이상을 찾고, 그 다음 로그와 추적으로 이유를 좁히는 운영 루프가 가장 현실적이다. 기억할 핵심은 단순하다. Prometheus와 Grafana는 숫자를 예쁘게 보여 주는 도구가 아니라, 서비스 건강을 계산 가능하게 만드는 운영 계약의 기반이다.

📢 섹션 요약 비유: 메트릭은 비행기 조종석 계기판과 같다. 창밖 풍경만 보고 날 수는 없고, 고도·속도·연료가 숫자로 보여야 안전하게 방향을 잡을 수 있다.

📌 관련 개념 맵

개념	연결 포인트
시계열 데이터베이스 (Time Series Database, TSDB)	시간 축으로 누적되는 메트릭 저장의 핵심 기반
PromQL	메트릭을 비율, 백분위수, 에러 버짓 지표로 계산하는 질의 언어
서비스 수준 지표 (Service Level Indicator, SLI)	메트릭을 품질 측정값으로 해석하는 운영 기준
서비스 수준 목표 (Service Level Objective, SLO)	메트릭 임계값을 정책과 약속으로 바꾸는 목표
Alertmanager	메트릭 경보를 묶고 라우팅하는 전달 계층
히스토그램 (Histogram)	지연시간 분포와 백분위수 계산에 핵심인 메트릭 유형
Thanos / Mimir / VictoriaMetrics	멀티클러스터 집계와 장기 보존을 위한 확장 계층

📈 관련 키워드 및 발전 흐름도

호스트 자원 모니터링
    │
    ▼
애플리케이션 메트릭 계측
    │
    ▼
Prometheus 수집 · TSDB 저장
    │
    ▼
Grafana 시각화 · Alertmanager 경보
    │
    ▼
SLI / SLO · Error Budget 운영
    │
    ▼
Thanos · Mimir 기반 장기 보존 · 멀티클러스터 확장

👶 어린이를 위한 3줄 비유 설명

메트릭은 컴퓨터가 지금 얼마나 바쁘고 아픈지를 숫자로 알려 주는 건강 체크표예요.
Prometheus는 여러 기계에게 정기적으로 "지금 상태 어때?" 하고 묻는 선생님이에요.
Grafana는 그 답을 그래프로 그려서 누가 힘들어하는지 바로 보이게 해 주는 칠판이에요.