Prometheus와 Grafana는 어떤 역할로 함께 쓰나요?

Prometheus는 메트릭을 수집·저장하고 PromQL로 조회·알림 조건을 정의하는 백엔드에 가깝고, Grafana는 수집된 데이터를 대시보드·패널로 시각화하고 탐색하는 프론트엔드 역할에 가깝습니다. 둘을 연결해 수집·가시성·알림을 한 흐름으로 구성합니다.

스크랩(Scrape) 주기는 어떻게 정하는 것이 좋나요?

global의 scrape_interval은 서비스 부하, 메트릭 카디널리티(시계열 수), 그리고 알림이 필요한 최소 감지 지연에 맞춥니다. 너무 짧으면 부하·스토리지가 커지고, 너무 길면 장애·스파이크를 놓칠 수 있어, 보통 10~60초 범위에서 운영 환경에 맞게 조정합니다.

PromQL 쿼리는 어디에 쓰이나요?

Grafana의 패널, Prometheus의 콘솔, 알림 룰(Recording/Alerting rule)에서 동일한 언어로 쓰입니다. 복잡한 집계·윈도윙(rate, histogram_quantile 등)을 한곳에서 정의해 대시보드와 알림이 같은 정의를 공유하도록 맞출 수 있습니다.

알림은 Prometheus만으로 처리하나요, Alertmanager는 왜 따로 쓰나요?

Prometheus는 알람 조건(룰)을 평가하고, Alertmanager는 그룹핑, 중복 억제, 라우팅(이메일·Slack 등), 뮤트(silence)를 담당합니다. 별도 Alertmanager로 발송·운영 정책을 분리해 알림 스팸을 줄이고 장애 시 대응을 일관되게 합니다.

Prometheus & Grafana 완벽 가이드 | 모니터링·메트릭·알림·대시보드

2026년 4월 7일 · 4분 읽기 · 수정 2026년 4월 18일 고급

이 글의 핵심

Prometheus와 Grafana로 시스템 모니터링을 구축하는 완벽 가이드. 메트릭 수집, PromQL, 알림, 대시보드, 실전 예제까지 완벽 정리. Prometheus·Grafana·Monitoring 중심으로 설명합니다.

이 글의 핵심

Prometheus와 Grafana로 시스템 모니터링을 구축하는 완벽 가이드입니다. 메트릭 수집, PromQL, 알림, 대시보드, 실전 예제까지 완벽 정리했습니다.

실무 경험 공유: 마이크로서비스 모니터링을 Prometheus + Grafana로 구축하면서, 장애 감지 시간을 30분에서 1분으로 단축하고 시스템 가시성을 크게 향상시킨 경험을 공유합니다.

들어가며: “서버 상태를 모르겠어요”

실무 문제 시나리오

시나리오 1: 서버가 다운돼도 모르겠어요

장애를 사용자가 먼저 알립니다. Prometheus 알림으로 즉시 감지합니다. 시나리오 2: CPU, 메모리 사용량을 모르겠어요

로그로만 확인합니다. Grafana 대시보드로 실시간 확인합니다. 시나리오 3: 병목 지점을 찾기 어려워요

추측으로 최적화합니다. 메트릭으로 정확히 파악합니다.

1. Prometheus란?

핵심 특징

Prometheus는 오픈소스 모니터링 시스템입니다. 주요 기능:

메트릭 수집: Pull 방식
시계열 DB: 시간 기반 데이터
PromQL: 강력한 쿼리 언어
알림: Alertmanager 통합
서비스 디스커버리: 자동 타겟 발견

2. 설치

Docker Compose

# docker-compose.yml
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
volumes:
  prometheus-data:
  grafana-data:

3. Prometheus 설정

prometheus.yml

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'my-app'
    static_configs:
      - targets: ['localhost:8000']

4. Node.js 메트릭

설치

npm install prom-client

Express 통합

// server.ts
import express from 'express';
import client from 'prom-client';
const app = express();
// 기본 메트릭 수집
const register = new client.Registry();
client.collectDefaultMetrics({ register });
// 커스텀 메트릭
const httpRequestDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ['method', 'route', 'status'],
  registers: [register],
});
const httpRequestTotal = new client.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'status'],
  registers: [register],
});
// Middleware
app.use((req, res, next) => {
  const start = Date.now();
  res.on('finish', () => {
    const duration = (Date.now() - start) / 1000;
    
    httpRequestDuration.observe(
      { method: req.method, route: req.route?.path || req.path, status: res.statusCode },
      duration
    );
    httpRequestTotal.inc({
      method: req.method,
      route: req.route?.path || req.path,
      status: res.statusCode,
    });
  });
  next();
});
// 메트릭 엔드포인트
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType);
  res.end(await register.metrics());
});
app.listen(8000, () => console.log('Server running on :8000'));

5. PromQL

기본 쿼리

# 현재 값
http_requests_total
# 레이블 필터
http_requests_total{method="GET"}
http_requests_total{status="200"}
# 범위 쿼리
http_requests_total[5m]
# Rate (초당 증가율)
rate(http_requests_total[5m])
# Sum
sum(rate(http_requests_total[5m])) by (status)
# Avg
avg(http_request_duration_seconds)

복잡한 쿼리

# 5분간 평균 응답 시간
rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])
# 에러율 (5xx)
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
# CPU 사용률
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

6. Grafana 대시보드

Prometheus 데이터 소스 추가

Grafana 접속: http://localhost:3000 (admin/admin)
Configuration → Data Sources → Add data source
Prometheus 선택
URL: http://prometheus:9090
Save & Test

대시보드 생성

{
  "dashboard": {
    "title": "Application Metrics",
    "panels": [
      {
        "title": "Request Rate",
        "targets": [
          {
            "expr": "rate(http_requests_total[5m])"
          }
        ],
        "type": "graph"
      },
      {
        "title": "Error Rate",
        "targets": [
          {
            "expr": "sum(rate(http_requests_total{status=~\"5..\"}[5m])) / sum(rate(http_requests_total[5m]))"
          }
        ],
        "type": "graph"
      }
    ]
  }
}

7. 알림

Alertmanager 설정

# alertmanager.yml
global:
  resolve_timeout: 5m
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'email'
receivers:
  - name: 'email'
    email_configs:
      - to: '[email protected]'
        from: '[email protected]'
        smarthost: 'smtp.gmail.com:587'
        auth_username: '[email protected]'
        auth_password: 'password'

Alert Rules

# alerts.yml
groups:
  - name: example
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value | humanizePercentage }}"
      - alert: HighCPUUsage
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"

8. 실전 예제: 전체 스택

설정 파일 예시입니다.

# docker-compose.yml
version: '3.8'
services:
  # 애플리케이션
  app:
    build: .
    ports:
      - "8000:8000"
  # Node Exporter (시스템 메트릭)
  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
  # Prometheus
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./alerts.yml:/etc/prometheus/alerts.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
  # Alertmanager
  alertmanager:
    image: prom/alertmanager:latest
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
  # Grafana
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
volumes:
  grafana-data:

8.1 시계열 저장소(TSDB)와 샘플링

Prometheus는 수집된 샘플을 블록 단위로 로컬 디스크에 쌓고, 주기적으로 컴팩션합니다. 스크랩 간격(scrape_interval)이 짧을수록 해상도는 좋아지지만 디스크·CPU 부하가 커집니다. 알림 규칙의 for 지속 시간은 “짧은 스파이크 무시”에 쓰이므로, 스크랩 간격·evaluation_interval·for를 함께 설계해야 합니다.

카티널리티(cardinality) 는 시계열 수를 폭증시키는 주범입니다. user_id, request_id처럼 값의 종류가 무한에 가까운 레이블을 붙이면 메모리가 빠르게 고갈됩니다. 해결책은 레이블 설계 가이드를 팀에 공유하고, 필요 시 집계 레이어(recording rule) 로 상위 차원만 남기는 것입니다.

Recording rule 예시

groups:
  - name: api_recording
    interval: 30s
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job, status) (rate(http_requests_total[5m]))

대시보드와 알림은 가능하면 레코딩된 시계열을 조회해 PromQL 부하를 줄입니다.

8.2 Grafana·프로덕션 운영

데이터 소스 프로비저닝: 대시보드를 JSON으로 Git에 두고 환경별 변수만 바꿉니다.
알림 채널: Alertmanager가 1차이고, Grafana 알림은 UI 팀과 연동할 때 유용합니다. 이중화 시 같은 사건이 두 번 올 수 있으므로 라우팅을 분리합니다.
보안: Grafana는 관리자 계정·플러그인 공급망을 주기적으로 갱신합니다.

9. 트러블슈팅

증상	흔한 원인	점검
`query timed out`	카티널리티 과다, 긴 범위 쿼리	`topk`, `aggregate`, 레코딩 룰
타겟 DOWN	네트워크·TLS·스크랩 경로 변경	`/targets` UI, `up` 메트릭
알림이 안 울림	`for`가 김, 라벨 매칭 실패	Alertmanager 라우트 트리
디스크 풀	보관 기간·샘플 과다	Retention, `wal` 모니터링, Thanos/Cortex 검토

정리 및 체크리스트

핵심 요약

Prometheus: 메트릭 수집 및 저장
PromQL: 강력한 쿼리 언어
Grafana: 시각화 대시보드
Alertmanager: 알림 관리
Exporter: 다양한 시스템 메트릭
고가용성: 클러스터 지원

프로덕션 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

Prometheus, Grafana, Monitoring, Metrics, DevOps, Observability, Alert

자주 묻는 질문 (FAQ)

Q. Prometheus vs ELK Stack, 어떤 게 나은가요?

A. Prometheus는 메트릭에 특화되어 있습니다. ELK는 로그에 특화되어 있습니다. 둘 다 사용하는 것을 권장합니다.

Q. 데이터 보관 기간은?

A. 기본 15일입니다. 장기 저장은 Thanos나 Cortex를 사용하세요.

Q. Grafana는 무료인가요?

A. 네, 오픈소스이며 무료입니다. Grafana Cloud는 유료 관리형 서비스입니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, SoundCloud, DigitalOcean 등 많은 기업에서 사용합니다.

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Prometheus & Grafana 완벽 가이드 | 모니터링·메트릭·알림·대시보드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Prometheus & Grafana 완벽 가이드 | 모니터링·메트릭·알림·대시보드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “서버 상태를 모르겠어요”

실무 문제 시나리오

추측으로 최적화합니다. 메트릭으로 정확히 파악합니다.

1. Prometheus란?

핵심 특징

2. 설치

Docker Compose

3. Prometheus 설정

prometheus.yml

4. Node.js 메트릭

설치

Express 통합

5. PromQL

기본 쿼리

복잡한 쿼리

6. Grafana 대시보드

Prometheus 데이터 소스 추가

대시보드 생성

7. 알림

Alertmanager 설정

Alert Rules

8. 실전 예제: 전체 스택

8.1 시계열 저장소(TSDB)와 샘플링

Recording rule 예시

8.2 Grafana·프로덕션 운영

9. 트러블슈팅

정리 및 체크리스트

핵심 요약

프로덕션 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

자주 묻는 질문 (FAQ)

Q. Prometheus vs ELK Stack, 어떤 게 나은가요?

Q. 데이터 보관 기간은?

Q. Grafana는 무료인가요?

Q. 프로덕션에서 사용해도 되나요?

심화 부록: 구현·운영 관점

내부 동작과 핵심 메커니즘

프로덕션 운영 패턴

확장 예시: 엔드투엔드 미니 시나리오

문제 해결(Troubleshooting)

이 글이 도움이 되셨나요?