프로메테우스 그라파나 실전 가이드: 기본 대시보드가 안 알려주는 꿀팁

모니터링 시스템을 설계할 때 가장 먼저 마주하는 거대한 갈림길이 바로 데이터를 보내는 주체가 누구인가입니다.

“Prometheus가 가서 가져온다”는 말은, 데이터를 가진 애플리케이션(Ex. 가상화 서버, GPU 익스포터, 웹 서비스 등)이 프로메테우스에게 데이터를 던져주는 게 아니라, 프로메테우스가 정해진 시간마다 각 서비스의 문을 두드려 “지금 상태가 어때?” 하고 받아오는 구조(Scraping)를 뜻합니다.

🛒 배달(Push)과 장보기(Pull)의 차이

기존의 전통적인 모니터링 시스템(구형 시스템이나 일부 APM)이 ‘배달’이라면, 프로메테우스는 ‘장보기’에 가깝습니다.

• Push 방식 (배달): 애플리케이션들이 각자 타이머를 재고 있다가, “저 지금 CPU 80%예요!”, “저 지금 메모리 꽉 찼어요!”라며 중앙 모니터링 서버로 데이터를 계속 배달(Push)합니다.
• Pull 방식 (장보기): 애플리케이션들은 그저 자기 집 앞마당(/metrics라는 웹 페이지)에 현재 상태를 적은 메모만 슥 올려둡니다. 그러면 Prometheus가 카트를 끌고 돌아다니며 그 메모를 수집(Pull)해 갑니다.

🧠 프로메테우스가 “가서 가져올 때” 생기는 3가지 강력한 이점

홈랩이나 AI 인프라 환경에서 이 Pull 방식은 단순한 ‘취향 차이’를 넘어 시스템의 생존을 결정하는 중요한 무기가 됩니다.

1. 중앙 서버의 과부하 방지 (주도권은 나에게)
Push 방식의 치명적인 약점은 트래픽이 몰릴 때 발생합니다. 만약 디도스(DDoS) 공격을 받거나 AI 추론 요청이 폭주하면, 수많은 컨테이너가 동시에 모니터링 서버로 데이터를 push하려 들 것입니다. 모니터링 서버가 먼저 뻗어버리는 불상사가 생기죠. 반면 Pull 방식은 프로메테우스가 자신의 체력(자원 상태)에 맞춰 5초든, 30초든 원하는 주기로 요청을 조절하기 때문에 모니터링 인프라 자체가 마비되는 일이 거의 없습니다.

2. “살아는 있니?” — 자연스러운 생사 확인 (Health Check)
Push 방식에서는 어떤 컨테이너가 조용할 때, ‘일이 없어서 조용한 건지’, ‘서버가 죽어서 말을 못 하는 건지’ 알기 어렵습니다. 하지만 Pull 방식은 프로메테우스가 직접 찌르는 구조이기 때문에, 요청을 보냈는데 찔리지 않거나(Connection Refused) 404 에러가 뜨면 그 즉시 “이 녀석 죽었구나!” 하고 감지할 수 있습니다. 프로메테우스 기본 메트릭인 up 메트릭이 바로 이 원리로 작동합니다.

3. 애플리케이션의 극단적인 단순화
모니터링 대상이 되는 서비스(ComfyUI, Dify, Node Exporter 등)는 프로메테우스 서버가 어디에 있는지, IP가 뭔지 알 필요가 없습니다. 그저 자기 포트(Ex. 9100)에 프로메테우스가 읽을 수 있는 형식의 텍스트만 띄워두면 끝입니다. 모니터링 서버의 IP가 바뀌더라도 개별 애플리케이션의 설정을 바꿀 필요 없이, 프로메테우스의 설정 파일(prometheus.yml)만 수정하면 됩니다.

혹시 현재 구축 중이거나 구상하고 계신 홈랩 환경에서, 프로메테우스가 데이터를 ‘가져가기’ 까다로운 환경(예: IP가 계속 바뀌는 가변 컨테이너나 외부 방화벽 뒤에 숨은 서비스)이 존재하나요?

🏷️ 메트릭의 구조 — 이름 + 라벨(Label)

모든 메트릭은 메트릭이름{라벨="값"} 숫자값 형태입니다. 라벨이 핵심입니다 — 같은 메트릭이라도 라벨로 잘게 쪼개서 구분할 수 있습니다.

node_cpu_seconds_total{cpu="0",mode="idle"}  48291.2
node_cpu_seconds_total{cpu="1",mode="idle"}  47733.8
node_cpu_seconds_total{cpu="0",mode="user"}  1820.4
container_memory_usage_bytes{name="n8n"}     184320000
container_memory_usage_bytes{name="comfyui"} 2147483648

위처럼 CPU 코어별로, 컨테이너 이름별로 라벨이 자동으로 붙어서 나뉩니다. 이 라벨을 PromQL에서 필터링·집계하는 게 실력의 거의 전부입니다.

📐 4가지 메트릭 타입

① scrape_interval — Job마다 다르게 줄 수 있습니다

전역(global) 설정을 모든 job이 따르지만, 특정 job만 더 자주/덜 자주 수집하도록 개별 오버라이드가 가능합니다. GPU처럼 빠르게 바뀌는 값은 짧게, 디스크 용량처럼 느리게 바뀌는 값은 길게 주면 저장 공간을 아낍니다.

scrape_configs:
  - job_name: 'nvidia-gpu'
    scrape_interval: 5s        # GPU는 빠르게 변하니 5초마다
    static_configs:
      - targets: ['nvidia-exporter:9835']

  - job_name: 'node'
    scrape_interval: 30s       # CPU/RAM은 30초면 충분
    static_configs:
      - targets: ['host.docker.internal:9100']

② 라벨 직접 붙이기 — labels: 옵션

여러 서버를 모니터링할 때 “어느 서버 데이터인지” 구분하려면 라벨을 직접 추가합니다. 지금은 R730 한 대뿐이지만, 나중에 NAS나 다른 서버도 모니터링하게 되면 이게 필수입니다.

  - job_name: 'node'
    static_configs:
      - targets: ['host.docker.internal:9100']
        labels:
          server: 'r730'
          role: 'ai-main'

③ external_labels — Prometheus 인스턴스 자체에 라벨 달기

나중에 Prometheus를 여러 대 운영하거나, Grafana에서 여러 환경(운영/테스트)을 구분하고 싶을 때 유용합니다.

global:
  scrape_interval: 15s
  external_labels:
    environment: 'homelab'
    server_name: 'R730'

④ Recording Rules — 무거운 쿼리를 미리 계산해두기

대시보드에서 매번 무거운 PromQL을 실행하면 느려집니다. 자주 쓰는 복잡한 쿼리를 미리 계산해서 새로운 메트릭으로 저장해두면, 대시보드는 그 결과만 가볍게 조회합니다.

groups:
  - name: precomputed_metrics
    interval: 30s
    rules:
      # CPU 사용률(%) — 매번 계산하지 않고 미리 저장
      - record: instance:cpu_usage:rate5m
        expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

      # 컨테이너별 메모리 사용량(MB)
      - record: container:memory_usage:mb
        expr: container_memory_usage_bytes{name!=""} / 1024 / 1024

만든 다음 rule_files:에 alert_rules.yml과 같이 한 줄 추가하면 됩니다. 대시보드에서는 instance:cpu_usage:rate5m처럼 미리 계산된 이름으로 바로 조회합니다.

⑤ 데이터 보존 기간/용량 제한 (docker-compose.yml command 항목에 추가)

curl -X POST http://localhost:9090/-/reload

PromQL은 처음엔 어려워 보이지만, 패턴 몇 개만 외우면 거의 모든 상황에 응용할 수 있습니다.

📈 비율(rate) 계열 — Counter를 다룰 때 필수

🖥️ 실전 쿼리 — CPU·RAM·디스크

# CPU 사용률(%) — 코어 평균
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# CPU 사용률(%) — 코어별로 따로 보기
100 - (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

# RAM 사용률(%)
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# 디스크 여유공간(GB)
node_filesystem_avail_bytes{mountpoint="/"} / 1024^3

# 디스크 I/O (초당 읽기 MB)
rate(node_disk_read_bytes_total[5m]) / 1024^2

🎮 실전 쿼리 — GPU (nvidia_gpu_exporter 기준)

# GPU 사용률(%)
nvidia_smi_utilization_gpu_ratio * 100

# VRAM 사용량(GB)
nvidia_smi_memory_used_bytes / 1024^3

# VRAM 사용률(%)
(nvidia_smi_memory_used_bytes / nvidia_smi_memory_total_bytes) * 100

# GPU 온도
nvidia_smi_temperature_gpu

# GPU 전력 소비(W)
nvidia_smi_power_draw_watts

# 지난 1시간 GPU 온도 최고값 (스파이크 확인용)
max_over_time(nvidia_smi_temperature_gpu[1h])

🐳 실전 쿼리 — 컨테이너 (cAdvisor 기준)

# 컨테이너별 메모리 사용량 순위 (높은 순)
topk(5, container_memory_usage_bytes{name!=""})

# 컨테이너별 CPU 사용률(%)
rate(container_cpu_usage_seconds_total{name!=""}[5m]) * 100

# 특정 컨테이너만 (n8n)
container_memory_usage_bytes{name="n8n"} / 1024^2

# 컨테이너 재시작 횟수 (지난 1시간)
increase(container_last_seen{name!=""}[1h])

🔧 집계 연산자 — sum, avg, max, topk, bottomk

# 컨테이너 이름별로 CPU 합산 (코어 여러 개일 때 합치기)
sum(rate(container_cpu_usage_seconds_total[5m])) by (name)

# 현재 떠있는 컨테이너 개수
count(container_last_seen{name!=""})

🔍 필터링 연산자 정리

⚠️ Alert Rule만으로는 “알림”이 안 갑니다

Alert Rule 문법 완전 분해

- alert: GPUTemperatureHigh        # ① 알림 이름
  expr: nvidia_smi_temperature_gpu > 85   # ② 조건 (PromQL)
  for: 2m                          # ③ 이 시간 동안 계속 참이어야 발동 (스파이크 무시)
  labels:
    severity: warning              # ④ 심각도 (나중에 라우팅에 사용)
  annotations:
    summary: "GPU 온도 위험"        # ⑤ 알림 제목
    description: "{{ $value }}도"  # ⑥ 알림 본문, $value로 실제 측정값 삽입

Alertmanager 최소 구성 — 텔레그램으로 알림 받기

이 시리즈에서 이미 n8n에 텔레그램 봇을 연결해두셨다면, Alertmanager의 Webhook 기능으로 그 봇을 재활용할 수 있습니다.

  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    restart: unless-stopped
    ports:
      - "9093:9093"
    volumes:
      - /mnt/data/00_infra/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    networks:
      - ai-common-net

route:
  receiver: 'telegram'
  group_wait: 30s
  repeat_interval: 1h

receivers:
  - name: 'telegram'
    telegram_configs:
      - bot_token: 'YOUR_BOT_TOKEN'
        chat_id: YOUR_CHAT_ID
        message: '{{ .CommonAnnotations.summary }}: {{ .CommonAnnotations.description }}'

등록 후 prometheus.yml에 아래처럼 alertmanager 위치를 알려줘야 합니다.

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

Grafana로 넘어가기 전에, Prometheus 자체 웹 화면(:9090)을 제대로 쓰는 법부터 익히면 문제 진단이 훨씬 빨라집니다.

기본 연결(URL 입력 후 Save & Test)만 하고 끝내는 분들이 많은데, 아래 추가 옵션들을 켜두면 훨씬 안정적이고 빠른 대시보드가 됩니다.

Connections → Data sources → Prometheus → 설정 화면에서

여러 데이터소스 운영 시 — 폴더로 정리

나중에 Loki(로그)나 다른 Prometheus 인스턴스를 추가하게 되면, Connections → Data sources 목록이 길어집니다. 데이터소스 자체엔 폴더 기능이 없지만, 대시보드 쪽(Dashboards)에는 폴더 기능이 있으니 “AI서버”, “네트워크” 처럼 폴더로 미리 나눠두는 걸 권장합니다.

대시보드를 만들 때 “Add panel” 누르고 패널 타입을 고르는 순간 많이들 막힙니다. 용도별로 정리했습니다.

Gauge/Stat에서 임계값(Threshold) 색상 설정하는 법

자주 쓰는 Unit 설정 모음

Transform 기능 — 쿼리 결과를 가공하기

패널 편집 화면 상단 “Transform” 탭에서, PromQL을 다시 안 짜고도 결과를 가공할 수 있습니다.

컨테이너마다, GPU마다 똑같은 대시보드를 복제하지 마세요. 변수(Variable) 하나로 드롭다운 선택만 바꿔서 같은 패널을 재사용할 수 있습니다.

실전 예시 — “컨테이너 선택” 드롭다운 만들기

Multi-value — 여러 개 동시 선택도 가능

Variable 설정에서 “Multi-value” 옵션을 켜면 체크박스 형태로 여러 컨테이너를 동시에 선택해서 비교할 수 있습니다. “Include All option”을 같이 켜면 “전체 선택”도 가능합니다.

Part 4에서 다룬 Prometheus+Alertmanager 조합 대신, Grafana 자체 알림 기능(Unified Alerting)을 쓰면 별도 컨테이너 없이도 텔레그램·Discord·Slack 알림이 가능합니다. 홈랩 규모에서는 이 방법이 훨씬 간단합니다.

① Contact point 만들기 — 텔레그램

② Alert rule 만들기 — Prometheus 쪽 yml 안 만지고 UI에서

GPU 사용률이 갑자기 튄 시점에 “이때 ComfyUI로 영상 생성을 돌렸다” 같은 메모를 그래프 위에 직접 남길 수 있습니다. 배포 시점, 재시작 시점을 표시해두면 나중에 원인 추적이 훨씬 쉬워집니다.

자동 Annotation — Alert 발동 시점 자동 표시

대시보드 설정 → Annotations에서 “Alert state changes” 옵션을 켜두면, 알림이 발동/해제된 시점이 그래프에 자동으로 표시됩니다. 수동으로 기록할 필요가 없어집니다.

Row로 패널 그룹 접기/펼치기

패널이 10개 넘어가면 한 화면에 다 보기 힘듭니다. “Row”를 추가하면 “GPU”, “CPU/RAM”, “컨테이너” 같은 섹션으로 나눠서 접고 펼칠 수 있습니다. Add panel → Row 선택 → 패널들을 그 Row 안으로 드래그.

대시보드를 폴더로 정리

Dashboards → New folder로 “AI서버 모니터링” 폴더를 만들고, GPU 대시보드·시스템 대시보드·컨테이너 대시보드를 그 안에 모아두면 나중에 대시보드가 늘어나도 안 헤맵니다.

대시보드 JSON으로 백업/공유

대시보드 설정(⚙️) → JSON Model에서 전체 구성을 JSON으로 복사할 수 있습니다. 직접 만든 대시보드는 이 JSON을 따로 백업해두세요 — Grafana 컨테이너 데이터가 날아가도 이 JSON으로 즉시 복원 가능합니다.

Playlist — 여러 대시보드를 자동 순환 표시

거실 모니터나 별도 화면에 여러 대시보드를 자동으로 돌려가며 보여주고 싶을 때, Dashboards → Playlists에서 “어떤 대시보드들을, 몇 초마다 순환”할지 정하면 자동 슬라이드쇼처럼 작동합니다.

지금까지 배운 걸 실제로 이 홈랩 환경에 적용한다면, 아래 구성을 추천합니다.

📋 추천 대시보드 구조 (Row 4개)

🎯 임계값 추천표 (Gauge 색상 기준)

🔔 알림 추천 — 텔레그램으로 받을 것만 추려보기

모든 변화에 알림을 받으면 금방 무시하게 됩니다. 아래 3개 정도만 우선 연결하는 걸 추천합니다.

• !GPU 온도 85도 이상 2분 지속 — 하드웨어 보호 최우선
• !VRAM 95% 이상 5분 지속 — OOM 직전 경고
• !디스크 85% 이상 — 백업 실패나 로그 폭증 조기 발견

🎨 ① ComfyUI — GPU 점유 시점과 컨테이너 리소스를 같이 본다

ComfyUI 자체엔 메트릭 엔드포인트가 없지만, “ComfyUI가 돌 때 GPU가 얼마나 쓰이는지”는 cAdvisor + nvidia-exporter 조합으로 충분히 보입니다. 생성 작업 중 VRAM이 얼마나 차오르는지, 컨테이너 자체의 CPU/RAM은 정상인지를 같은 화면에 겹쳐 보면 충분합니다.

# ComfyUI 컨테이너 메모리(시스템 RAM, VRAM 아님)
container_memory_usage_bytes{name="comfyui"} / 1024^3

# ComfyUI 컨테이너 CPU 사용률(%)
rate(container_cpu_usage_seconds_total{name="comfyui"}[2m]) * 100

# ComfyUI 네트워크 I/O (모델 다운로드·이미지 입출력 확인용)
rate(container_network_transmit_bytes_total{name="comfyui"}[5m]) / 1024^2

🎮 ② RTX 3060 OC 12GB — 이 카드 스펙에 맞춘 정밀 임계값

RTX 3060의 정격 TGP는 170W이고, 8핀 커넥터+PCIe 슬롯 조합상 최대 225W까지 헤드룸이 있습니다(OC 모델들이 보통 이 여유를 씁니다). 범용 임계값 대신 이 카드에 맞춘 값을 쓰세요.

# 전력 소비를 OC 헤드룸(225W) 대비 비율로 — 임계값 색상 설정에 직접 활용
(nvidia_smi_power_draw_watts / 225) * 100

# 팬 속도(%) — 지속적으로 높으면 발열/먼지 점검 신호
nvidia_smi_fan_speed_ratio * 100

# GPU 코어 클럭 (OC가 실제로 유지되는지 확인)
nvidia_smi_clocks_current_graphics_clock

# 메모리 클럭 (12GB GDDR6 OC 유지 확인)
nvidia_smi_clocks_current_memory_clock

🤖 ③ Dify — 컨테이너 6개 중 어디가 문제인지 구분해서 본다

Dify는 컨테이너 하나가 아니라 dify-api·dify-worker·dify-web·dify-plugin-daemon·dify-sandbox·dify-nginx 6개로 구성됩니다. 정규식으로 한 번에 모아보면서, 특히 plugin_daemon은 따로 떼서 보는 걸 추천합니다 (Ollama 연동 문제가 실제로 가장 많이 나는 지점).

# Dify 컨테이너 전체 메모리 합산
sum(container_memory_usage_bytes{name=~"dify-.*"}) / 1024^3

# Dify 컨테이너별로 나눠서 (Table 패널 추천)
container_memory_usage_bytes{name=~"dify-.*"} / 1024^2

# plugin_daemon만 따로 — Ollama 연동 이슈 시 여기부터 확인
rate(container_cpu_usage_seconds_total{name="dify-plugin-daemon"}[2m]) * 100

# dify-api 재시작 감지 (API 장애 조기 발견)
changes(container_last_seen{name="dify-api"}[10m])

🔥 ④ Firecrawl — Playwright 컨테이너가 제일 무겁습니다

Firecrawl도 firecrawl-api·firecrawl-playwright·firecrawl-redis-db·firecrawl-pg-db·firecrawl-rabbitmq 등 여러 컨테이너입니다. 실제 브라우저를 띄워서 크롤링하는 firecrawl-playwright가 메모리를 가장 많이 먹는 지점이라 별도 패널로 감시할 가치가 있습니다.

# Firecrawl 전체 컨테이너 메모리
sum(container_memory_usage_bytes{name=~"firecrawl-.*"}) / 1024^3

# Playwright만 따로 — 크롤링 중 메모리 누수 감시
container_memory_usage_bytes{name="firecrawl-playwright"} / 1024^2

# Firecrawl API CPU — 크롤 요청이 몰릴 때 확인
rate(container_cpu_usage_seconds_total{name="firecrawl-api"}[2m]) * 100

📰 ⑤ WordPress(agibop.com) — 이건 컨테이너가 아니라 외부 사이트입니다

두 가지 방법이 있습니다. 이미 이 시리즈에 있는 Uptime Kuma가 압도적으로 더 간단합니다.

💬 ⑥ Open WebUI — 메모리 증가 추세를 지켜보세요

Open WebUI도 자체 메트릭은 없지만, 대화 기록이 쌓이면서 메모리가 천천히 늘어나는 패턴이 있을 수 있어 장기 추세를 보는 게 의미 있습니다.

# Open WebUI 메모리 — Time series로 길게(7일) 보면서 추세 확인
container_memory_usage_bytes{name="open-webui"} / 1024^2

# 컨테이너 재시작 여부 (멈춤·크래시 조기 발견)
changes(container_last_seen{name="open-webui"}[1h])

🗂️ 이 6개 통합 Row 하나로 만들기

지금까지 만든 대시보드에 “내 서비스” Row를 새로 추가하고, 위 쿼리들을 한 곳에 모아두면 매일 확인할 화면이 완성됩니다.

• ✓prometheus.yml에 job별 scrape_interval 적절히 분리했는가
• ✓retention.time/size 디스크 용량 고려해서 설정했는가
• ✓Grafana 데이터소스에 timeout·HTTP Method(POST) 설정했는가
• ✓최소 1개 이상 대시보드에 Variable(변수)로 컨테이너 선택 가능하게 만들었는가
• ✓GPU 온도·VRAM·디스크 최소 3개는 텔레그램 알림 연결했는가
• ✓직접 만든 대시보드 JSON을 백업해뒀는가
• ✓RTX 3060 OC 전력을 헤드룸(225W) 대비 비율로 설정했는가
• ✓WordPress(agibop.com)는 Uptime Kuma로 별도 등록했는가