Grafana

Grafana는 Prometheus에 저장된 메트릭을 시각화 대시보드로 구성하고, Alertmanager와 역할을 분담하는 모니터링 스택의 시각화 계층이다.^[1] 이 페이지가 답하는 질문은 Prometheus 메트릭을 어떻게 대시보드로 구성하는지, Grafana와 Alertmanager의 역할이 어떻게 나뉘는지다.

데이터소스 → 패널 → 대시보드

Grafana는 데이터소스(이 강의에서는 Prometheus^[1:1]; 공식 문서는 Prometheus, Loki, SQL database 등 저장 backend 연결로 설명^[2])에서 데이터를 가져와 패널(그래프/게이지/표) 단위로 시각화하고, 여러 패널을 대시보드로 묶는다. 변수(Variable)로 서버를 동적으로 선택할 수 있고, 자동 프로비저닝으로 데이터소스·대시보드 JSON을 코드로 관리할 수 있다.^[1:2]

flowchart LR
  Prom["Prometheus
TSDB"]
  DS["Grafana
Data Source"]
  Panel["Panel
PromQL 쿼리"]
  Dash["Dashboard"]
  Prom --> DS --> Panel --> Dash

요소	설명
Data Source	Grafana가 query하는 저장 backend 연결 — 이 monitoring stack에서는 Prometheus^[1:3]
Panel	그래프/게이지/표 등 시각화 단위^[1:4]
Dashboard	여러 패널을 묶은 화면^[1:5]
Variable	대시보드 필터 (서버 선택 등)^[1:6]
Alerting	Grafana 자체 알림 기능 (단, 기본 알림은 Alertmanager 권장)^[1:7]

데이터소스 등록과 대시보드 구성

데이터소스 등록은 UI 수동 등록 또는 grafana/provisioning/datasources/prometheus.yml 자동 프로비저닝 방식으로 가능하다.^[3] 자동 프로비저닝 시 apiVersion: 1, name: Prometheus, type: prometheus, access: proxy, url: http://prometheus:9090, isDefault: true로 설정한다.^[3:1]
기본 대시보드 구조는 Row(Host Metrics, Containers, API/Services, DB/Redis) 아래 Panel(CPU, Memory, Disk, Probe Success, Latency P95 등)로 구성한다.^[4] 대시보드 "가져오기" 기능을 쓰면 Grafana.com ID로 Import할 수 있다: Node Exporter Full(1860), cAdvisor(14282/193), Blackbox(7587), MySQL(7362), Redis(763).^[4:1]
자동 배포용 대시보드 JSON은 grafana/provisioning/dashboards/dashboards.yml에 providers를 정의해 /etc/grafana/provisioning/dashboards 하위 JSON을 자동 로드하는 방식으로 저장한다.^[5]

자동 프로비저닝(datasources + dashboards)을 쓰면 UI 클릭 없이 코드로 데이터소스와 대시보드를 재현할 수 있어 마이그레이션과 GitOps 구성에 유리하다고 보인다.

자주 쓰는 패널 쿼리

# CPU (graph)
100 - (avg by (instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Memory (gauge)
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Disk % (bar gauge)
(1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
      / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100

# Container CPU Top 5
topk(5, sum by (container)(rate(container_cpu_usage_seconds_total{container!=""}[5m])) * 100)

# API Health (stat)
probe_success{instance="api"}

# API Latency P95 (graph)
histogram_quantile(0.95, sum by (le)(rate(http_request_duration_seconds_bucket[5m])))

변수(Variable) 패턴

대시보드 변수 설정은 instance 변수를 label_values(node_cpu_seconds_total, instance) 쿼리로 정의하고, 패널 쿼리에서 instance="$instance" 형태로 사용한다.^[6]

# 변수 정의
Name: instance
Type: Query
Query: label_values(node_cpu_seconds_total, instance)

패널 쿼리에서 사용:

100 - (avg by (instance)(rate(node_cpu_seconds_total{mode="idle", instance="$instance"}[5m])) * 100)

대시보드 상단 드롭다운으로 instance를 선택하면 패널이 동적으로 필터된다. Variable은 dashboard query만의 치환 변수가 아니다 — panel title·link 등 다른 dashboard element에도 사용할 수 있으며, 값이 바뀌면 이를 참조하는 element가 함께 갱신된다. 따라서 같은 구조의 dashboard를 환경·instance별로 복제하는 대신, source schema에 맞는 variable query를 둔다.

Grafana와 Alertmanager의 역할 분담

Grafana는 "데이터를 보여주는" 역할만 담당하고, "데이터를 수집/저장"하는 Prometheus와 "알림을 발송"하는 Alertmanager와 명확히 역할이 분리된다. 이 분리를 지키면 Grafana 장애가 모니터링 시스템 전체로 번지지 않는다고 볼 수 있다.

알림은 Alertmanager만 사용을 권장하고 Grafana Alert는 시각화용 대시보드 유지 보조로만 쓴다.^[7]
보안 옵션: GF_AUTH_ANONYMOUS_ENABLED=false로 로그인 요구, GF_SERVER_DOMAIN/GF_SERVER_ROOT_URL로 리버스프록시 뒤 환경 설정.^[8]

실행 체크리스트

Grafana 3000번 포트 접속 확인
Prometheus Data Source 정상 연결 (http://prometheus:9090)
대시보드 import 또는 JSON 프로비저닝
변수 $instance 정상 동작
Panel 쿼리가 0/NaN이 아닌 실제 값 반환
Alertmanager와 역할 구분 명확 (알림은 Alertmanager, 시각화는 Grafana)

흔한 실수

데이터소스 URL을 http://localhost:9090으로 설정하면 → Grafana 컨테이너 안에서만 reach되어 연결이 안 된다. 서비스명 기반 http://prometheus:9090을 써야 한다.
자동 프로비저닝 경로(GF_PATHS_PROVISIONING)와 마운트 경로가 불일치하면 → 데이터소스/대시보드가 안 잡힌다.
대시보드 import ID(1860/14282 등)를 안 쓰고 모든 패널을 수동으로 만들면 → 유지보수 비용이 커진다.
변수 쿼리(label_values(...))를 잘못 쓰면 → 드롭다운이 빈다.
Prometheus 전용 기능으로 생각해 datasource query editor·variable 문법을 다른 datasource에 그대로 적용하면 → 제대로 동작하지 않는다.
알림을 Grafana Alert로만 구성하면 → Alertmanager의 라우팅/inhibit 기능을 놓친다.
GF_AUTH_ANONYMOUS_ENABLED=true로 둔 채 공망에 노출하면 → 무제한 접근을 허용하게 된다.

datasource provisioning, dashboard JSON, panel query는 source의 Prometheus endpoint와 metric label을 전제로 한 운영 예시다. Grafana는 metric을 수집하거나 alert delivery를 담당하지 않는다 — 저장된 metric을 query·visualize하는 reader 역할이다.

출처

테스트 질문

Grafana 데이터소스를 localhost:9090 대신 서비스명 기반으로 설정해야 하는 이유는 무엇인가?
자동 프로비저닝(grafana/provisioning/)이 수동 UI 등록보다 나은 점은 무엇인가?
Grafana Alert와 Alertmanager의 역할 분담은 어떻게 이루어지는가?
대시보드 변수(Variable)가 label_values(node_cpu_seconds_total, instance) 형태로 정의되는 이유는 무엇인가?

Grafana.md — Grafana의 목적(메트릭 시각화·대시보드 생성·알림 설정)과 핵심 개념 요약 표 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
grafana-datasources.md — "A data source in Grafana is a connection to a storage backend that holds your data, such as a Prometheus server, a Loki instance, a SQL database, or a cloud monitoring service."(L5) ↩︎
Grafana.md — 데이터소스 등록(UI/자동 프로비저닝 yaml) ↩︎ ↩︎
Grafana.md — 기본 대시보드 템플릿 구조와 "대시보드 가져오기" ID 표 ↩︎ ↩︎
Grafana.md — 자동 배포용 대시보드 JSON 저장 방식 ↩︎
Grafana.md — 대시보드 변수(서버 선택 기능) 표 ↩︎
Grafana.md — Grafana Alert 사용 여부, "알림은 Alertmanager만 사용 — 추천 구조" ↩︎
Grafana.md — 인증/보안 표 ↩︎