Prometheus + Grafana: 오픈소스 모니터링의 표준 조합 완전 정복

들어가며: "서버가 죽기 5분 전에 알 수 있다면"

새벽 3시, 슬랙 채널에 메시지가 올라온다.

"사이트 접속이 안 됩니다." "결제가 안 돼요."

고객이 먼저 알았다. 팀은 30분 뒤에야 확인했고, 원인 파악에 2시간이 걸렸다. 서버 한 대의 메모리가 가득 차 OOM(Out of Memory)으로 죽은 것이었다. 메모리 사용률이 90%를 넘은 건 서버가 죽기 15분 전 — 그때 알았다면 트래픽을 돌리고 재시작하면 끝이었을 것이다.

모니터링의 핵심은 단순하다: 사람보다 기계가 먼저 알아채는 것. 그리고 이 역할을 하는 오픈소스 표준이 바로 Prometheus(메트릭 수집)와 Grafana(시각화)다. 유료 서비스도 아니고, 특정 클라우드에 묶이지도 않는다.

1. 모니터링 지형도: 유료 vs 오픈소스

모니터링 도구는 크게 클라우드 네이티브, SaaS, 오픈소스 세 진영으로 나뉜다.

Datadog은 뛰어난 제품이지만, 스케일이 커지면 비용이 급증한다. 호스트당 월 $15~$23, 커스텀 메트릭 100개당 $5 — 서버 수십 대에 메트릭 수천 개면 **월 수백만 원**이 기본이다. Prometheus + Grafana가 사실상 표준이 된 핵심 이유는 소프트웨어 비용 **$0**, 벤더 독립, 그리고 Kubernetes와의 완벽한 궁합이다.

2. Prometheus: CNCF가 인정한 메트릭의 표준

탄생: SoundCloud의 절박함 (2012)

2012년, 베를린의 음악 스트리밍 회사 SoundCloud는 수백 개의 마이크로서비스를 운영하고 있었다. 기존 도구(StatsD + Graphite)로는 다차원 데이터 모델도, 서비스 디스커버리도, 강력한 쿼리 언어도 없었다.

SoundCloud의 엔지니어 Matt T. Proud와 Julius Volz — Google 출신이었다. Google 내부 모니터링 시스템 Borgmon의 아이디어를 가져와 Prometheus를 시작했다.

Pull 모델: Prometheus의 핵심 설계

대부분의 모니터링(Datadog, StatsD)은 Push 모델 — 서버가 메트릭을 모니터링 시스템으로 밀어 넣는다. Prometheus는 반대다. Prometheus가 각 타겟에 HTTP GET을 보내 메트릭을 당겨온다(Pull).

Pull의 장점: 스크래핑 실패 자체가 "타겟이 죽었다"는 시그널이고, 브라우저에서 http://target:9090/metrics에 접속하면 어떤 메트릭이 노출되는지 바로 확인할 수 있다.

3. 데이터 모델: 메트릭, 레이블, 시계열

Prometheus의 모든 데이터는 시계열(Time Series) — 타임스탬프가 찍힌 숫자 값의 연속이다. 하나의 시계열은 메트릭 이름 + 레이블 집합으로 식별된다:

같은 http_requests_total이라도 레이블 조합이 다르면 별개의 시계열이다. 이것이 Prometheus의 다차원 데이터 모델이다.

4가지 메트릭 타입

Counter는 "지금까지 총 몇 번?" — 요청 수, 에러 수처럼 계속 증가하는 값. rate()로 "초당 변화율"로 변환해서 쓴다. Gauge는 "지금 얼마?" — CPU, 메모리처럼 현재 값 자체가 의미 있는 값. Histogram은 응답 시간의 분포를 버킷으로 나눠 p99(상위 1% 지연)를 계산할 수 있게 한다.

4. PromQL: 시계열 데이터의 SQL

핵심 함수 4가지

이 4개만 익히면 실무 쿼리의 80%를 작성할 수 있다.

rate() — Counter의 초당 변화율. Counter 메트릭은 반드시 rate()로 변환해야 의미가 생긴다.

# 지난 5분간 초당 HTTP 요청 수
rate(http_requests_total[5m])

# 5xx 에러만 필터
rate(http_requests_total{status=~"5.."}[5m])

sum() — 여러 시계열의 합계. by 절로 그룹핑한다.

# 서비스별 초당 요청 수
sum by (service)(rate(http_requests_total[5m]))

avg() — 평균값.

# 전체 인스턴스의 평균 CPU 사용률
avg(node_cpu_usage_percent)

histogram_quantile() — Histogram에서 백분위수를 계산. 응답 시간 모니터링의 핵심.

# 응답 시간 p99 (상위 1%가 경험하는 지연)
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

실전 PromQL 레시피

5. Alertmanager: 알림의 두뇌

Prometheus가 이상을 감지하면, 알림 전송은 별도 컴포넌트인 Alertmanager가 담당한다.

알림 규칙 예시:

groups:
  - name: service-alerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by (instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m          # 5분 지속 시에만 발동 (순간 스파이크 무시)
        labels:
          severity: warning
        annotations:
          summary: "CPU 사용률 {{ $value }}% ({{ $labels.instance }})"

Alertmanager의 3대 기능

6. Grafana: 데이터를 눈에 보이게 만드는 도구

탄생: 한 명의 개발자에서 시작 (2014)

2014년, 스웨덴의 개발자 Torkel Odegaard가 Kibana의 포크로 Grafana를 시작했다. 이름은 Graphite + Kibana의 합성어. 처음에는 Graphite 전용이었지만, 데이터 소스 플러그인 아키텍처를 도입하면서 어떤 데이터 소스든 연결할 수 있게 되었다.

현재 Grafana Labs는 기업 가치 $6B 이상의 유니콘, GitHub 스타 65,000개 이상으로 가장 많이 사용되는 관측성 대시보드다.

핵심 개념

킬러 기능은 템플릿 변수다. 대시보드 상단 드롭다운에서 production, staging을 선택하면 전체 패널이 해당 환경의 메트릭으로 전환된다. 환경별 대시보드를 따로 만들 필요가 없다.

7. Grafana 데이터 소스: LGTM 스택

Grafana가 단순한 그래프 도구가 아닌 통합 관측성 플랫폼이 된 이유는 Grafana Labs가 만든 오픈소스 생태계 때문이다.

Loki는 전통적 로그 시스템(ELK)과 달리 로그 내용을 인덱싱하지 않고 레이블만 인덱싱한다. 비용이 ELK 대비 극적으로 낮으면서도, "이 서비스의 최근 에러 로그" 같은 실무 조사에는 충분하다.

Tempo는 마이크로서비스에서 요청이 서비스 A → B → C를 거치는 경로를 추적하는 분산 추적 시스템이다. 백엔드를 S3/GCS에 직접 저장하여 운영 비용이 낮다.

8. 실전 구축: Kubernetes 클러스터 모니터링

Kubernetes와 Prometheus는 둘 다 CNCF 프로젝트이며, Kubernetes가 자체적으로 /metrics 엔드포인트를 노출하고, Prometheus의 서비스 디스커버리가 K8s API와 연동되어 새 Pod이 뜨면 자동으로 스크래핑 대상에 추가된다.

9. kube-prometheus-stack: 원클릭 설치

Kubernetes에서 Prometheus + Grafana를 처음부터 설정하는 것은 번거롭다. kube-prometheus-stack Helm 차트 하나로 Prometheus, Grafana, Alertmanager, node-exporter, kube-state-metrics가 모두 설치된다.

# Helm 리포지토리 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 설치
helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword='YourSecurePassword' \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

설치 후 Grafana에는 20개 이상의 사전 구성된 대시보드가 포함된다 — Kubernetes Cluster Overview, Node Exporter, Pod Resources 등을 바로 볼 수 있다.

# Grafana 접속
kubectl port-forward -n monitoring svc/kube-prometheus-grafana 3000:80
# http://localhost:3000 → admin / YourSecurePassword

커뮤니티 대시보드도 활용하자:

10. Prometheus vs CloudWatch vs Datadog

비용 비교

기능 비교

어떤 상황에 어떤 도구를?

마치며: 모니터링은 "보험"이 아니라 "눈"이다

많은 팀이 모니터링을 보험으로 생각한다. "장애 대비용이니 나중에 하자." 하지만 모니터링은 보험이 아니라 눈이다. 눈이 없으면 서비스가 지금 어떤 상태인지 알 수 없다.

시작은 간단하다. kube-prometheus-stack을 설치하고, 기본 대시보드로 클러스터 상태를 확인하고, 앱에 /metrics를 추가하고, Slack 알림을 연결하면 된다.

코어닷투데이의 AI 서비스에서도 Prometheus + Grafana는 핵심 인프라다. AI 모델 서빙의 응답 시간, GPU 사용률, 추론 요청 처리량 — 이 모든 메트릭이 Grafana 대시보드에서 실시간으로 확인되고, 이상이 감지되면 Alertmanager가 즉시 알려준다. 서버가 죽기 5분 전에 아는 것과 5시간 뒤에 아는 것 — 그 차이는 모니터링 하나에 달려 있다.