Grafana 입문 5편 — Dashboard · Panel · Variable 깊이

이 글은 Grafana 입문에서 운영까지 시리즈 5편이에요. 4편 Tempo 까지가 데이터 인프라 였다면 5편은 데이터 시각화 의 자리.

이번 글의 범위

Dashboard 는 Grafana 의 얼굴 이라, 같은 데이터라도 디자인에 따라 사용성 · 신뢰도 가 크게 갈려요.

Panel 종류 — 15+ 종

시계열 시각화

1. Time Series (가장 흔함)
   - 선 차트
   - 여러 series 같은 시간축
   - threshold · area fill · gradient

2. Bar Chart
   - 카테고리 별 막대
   - 시계열 X (시간 무관 데이터)

3. Histogram
   - 분포 시각화
   - bucket 별 빈도

4. Heatmap
   - 시간 × 값 의 밀도
   - latency 분포 의 시계열 변화 최적

5. State Timeline
   - 시간 별 상태 (UP · DOWN · DEGRADED)
   - boolean · enum 시각화

6. Status History
   - 비슷 하지만 더 단순
   - 0/1 또는 상태 의 시간 변화

7. Candlestick
   - 금융 차트 (open · high · low · close)
   - trading dashboard 용

단일 값 시각화

8. Stat
   - 큰 숫자 한 개
   - sparkline (작은 trend)
   - 색상 threshold

9. Gauge
   - 게이지 (속도계 같은)
   - 0 ~ max 의 시각

10. Bar Gauge
   - 가로 막대 progress
   - 여러 metric 비교 (CPU · 메모리 · 디스크)

11. Pie Chart
   - 비율
   - 카테고리 별 share

표 · 텍스트

12. Table
   - 행/열 데이터
   - 셀 stylign · conditional formatting

13. Logs
   - Loki · Elasticsearch 의 로그 표시
   - tail · search · level filter

14. Text
   - Markdown · HTML
   - dashboard 의 설명 · 링크

15. News
   - RSS feed
   - Grafana Labs 의 announcements 자동

특수

16. Trace (Distributed Tracing)
   - Tempo · Jaeger 의 trace view
   - timeline · service graph

17. Geomap
   - 지도 위 데이터
   - region 별 KPI

18. Node Graph
   - 노드 + 엣지 (의존성 그림)
   - Tempo Service Graph 와 결합

19. Canvas
   - 자유 디자인
   - 도형 · 이미지 · 동적 텍스트
   - architecture diagram 의 live data

20. Annotations List
   - 모든 annotation 의 리스트
   - 최근 배포 · incident 추적

21. Alert List
   - 활성 alert 목록

22. Dashboard List
   - 다른 dashboard 의 링크
   - portal 페이지 용

Panel 선택 가이드

시계열 metric → Time Series
단일 KPI    → Stat
범위 의식     → Gauge · Bar Gauge
분포        → Histogram · Heatmap
상태        → State Timeline · Status History
로그        → Logs
표 데이터     → Table
지도        → Geomap
의존성       → Node Graph
설명/링크     → Text · Dashboard List

KPI(핵심 성과 지표) 는 여기서 처음 나오는데, 시험 함정도 같은 자리에 있어요. 모든 panel 을 다 쓰려고 덤비지 마세요. Time Series + Stat + Table 만으로 80% 의 사용 case 가 풀리고 나머지는 특수 case 일 뿐이에요.

Variable — Dynamic Dashboard

Variable 의 7 Type

1. Query
   - datasource 에서 자동 옵션
   - 예: label_values(up, instance) → 모든 instance

2. Custom
   - 직접 입력 (comma separated)
   - 예: dev, staging, prod

3. Constant
   - 고정값 (URL 에 안 노출)
   - 예: API_KEY 같은 secret

4. Data source
   - datasource 자체를 dropdown
   - 같은 dashboard 가 여러 env 의 datasource

5. Interval
   - 시간 간격 ($__interval)
   - 1m, 5m, 10m, 30m, 1h, 6h, 12h, 1d
   - rate · increase 의 window 동적

6. Ad hoc filter
   - dashboard 의 모든 panel 에 자동 filter 추가
   - 사용자가 dropdown 에 임시 filter

7. Text Box
   - 자유 입력
   - search · filter 의 임시 값

Cascading Dropdown (Chain)

Cascading dropdown 은 이전 variable 의 선택값이 다음 variable 의 query 에 들어가는 사슬 구조에요.

$environment → Custom: dev, staging, prod
$cluster     → Query: label_values(up{env="$environment"}, cluster)
$namespace   → Query: label_values(up{env="$environment", cluster="$cluster"}, namespace)
$pod         → Query: label_values(up{env="$environment", cluster="$cluster", namespace="$namespace"}, pod)

이렇게 environment → cluster → namespace → pod 순서로 좁혀가야 사용자가 의미 있는 범위만 골라볼 수 있어요.

Multi-Value · All

Variable 옵션:
  - Multi-value:    여러 값 선택 가능
  - Include All:    "전체" 옵션
  - Custom all value: "전체" 의 의미 (예: ".*" regex)

Panel 의 Query 안 변수

# Multi-value 처리 — regex 자동
rate(http_requests_total{
  env="$environment",
  service=~"$service",  ← 여러 값 선택 시 자동 regex
  cluster="$cluster"
}[$__interval])

# All 의 처리
rate(http_requests_total{
  service=~"${service:regex}"  ← regex format
}[$__interval])

Variable Format Modifier

${variable}              기본 — 값 그대로
${variable:regex}        regex format (multi-value 처리)
${variable:csv}          comma-separated
${variable:json}         JSON array
${variable:queryparam}   URL parameter format
${variable:text}         사용자 보이는 텍스트

Transformation — Panel Data 변형

Transformation 의 자리

Query 결과 → Transformation → Visualization

용도:
  - 여러 query 결과 결합
  - 값 계산 (rate · diff · percentage)
  - 컬럼 rename
  - filter · group · sort

26 종 Transformation

구조 변형:
  - Add field from calculation
  - Concatenate fields
  - Convert field type
  - Extract fields
  - Filter data by query
  - Filter data by values
  - Filter fields by name
  - Group by
  - Group to nested table
  - Heatmap
  - Histogram
  - Join by field
  - Join by labels
  - Labels to fields
  - Limit
  - Merge
  - Organize fields (rename · reorder · hide)
  - Outer join
  - Partition by values
  - Reduce
  - Rename by regex
  - Rows to fields
  - Series to rows
  - Sort by
  - Spatial operations
  - Time series to table

실전 예 1: Multiple datasource join

Query A: Prometheus 의 RPS by service
Query B: Loki 의 error rate by service

Transformation:
  - Join by field (service)
  - 결과: RPS + error_rate 같은 행

여기서 RPS(초당 요청 수) 가 첫 등장이라 풀어둬요.

실전 예 2: Add field from calculation

Query: http_requests (count) · http_errors (count)

Transformation: Add field from calculation
  Mode: Binary operation
  Field: error_rate
  Expression: http_errors / http_requests * 100

→ 차트 의 새 열 (계산된 error percentage)

실전 예 3: Organize fields

Query 결과:
  __name__: http_requests_total
  job: api
  instance: 10.0.0.1
  method: GET
  status: 200
  Value: 1234

Transformation: Organize fields
  - hide __name__
  - rename instance → server
  - reorder: job, server, method, status, Value

Annotation — Event 표시

Annotation 의 자리

Time Series chart 위 의 세로 선 + 라벨:
  - 배포 시각
  - Incident 시각
  - Feature flag 변경
  - 외부 event

→ "이 spike 가 일어난 시각 = 배포 직후" 즉시 인식

Annotation 의 종류

1. Built-in (시스템 표준)
   - Alert annotation (alert state change)
   - Annotations & Alerts datasource

2. Dashboard 의 Annotation Query
   - datasource 의 query
   - 예: Loki 의 deploy event
   - 예: Prometheus 의 alert state

3. 수동 입력
   - dashboard UI 의 "Add annotation"
   - 사용자가 클릭 + 메모

자동화 예 1: CI/CD 의 배포 annotation

CI/CD(지속 통합·지속 배포) 파이프라인이 배포 직후에 annotation 을 던지게 만들어두면 차트가 자동으로 표시해줘요.

# GitHub Actions 의 배포 직후
curl -X POST http://grafana:3000/api/annotations \
  -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tags": ["deploy", "production"],
    "text": "Deploy v1.2.3 by '"$USER"' — '"$COMMIT_MSG"'",
    "time": '"$(date +%s)"'000
  }'

자동화 예 2: Loki query annotation

Dashboard > Settings > Annotations:
  Name: Deploys
  Datasource: Loki
  Query: {app="ci-deploy"} | json | event="deploy_completed"
  Tags: $.tags
  Text: $.message

이렇게 걸어두면 모든 배포 event 가 모든 차트에 자동 표시 돼요.

자동화 예 3: GitHub Release annotation

# Grafana > Plugins > GitHub datasource
- Datasource: GitHub
- Query: releases of repo "company/app"
- Time field: published_at
- Text: "{{ name }} — {{ author }}"

Library Panel — 재사용

Library Panel 의 자리

표준 panel 을 *여러 dashboard 에서 재사용*:
  - 한 번 만들면 reuse
  - 한 곳 변경 = 모든 사용 dashboard 에 자동 반영

사용 case

- "Top 5 slow endpoints" panel
  → 여러 service 의 dashboard 에 동일 사용

- "Cluster health overview" panel
  → 모든 dashboard 의 head 에 동일

- "Recent deploys" panel
  → 모든 production dashboard

표준 dashboard 의 일관성 자동 + 유지보수 단순

변환

Panel 우상단 메뉴 > Library panels > Create library panel

이후:
  - 다른 dashboard 에서 "Add from library"
  - 같은 panel 즉시 추가

Dashboard JSON — Import · Export

JSON 구조

{
  "title": "Service Dashboard",
  "tags": ["api", "production"],
  "timezone": "browser",
  "panels": [
    {
      "id": 1,
      "type": "timeseries",
      "title": "RPS",
      "gridPos": {"x": 0, "y": 0, "w": 12, "h": 8},
      "datasource": "Prometheus",
      "targets": [
        {"expr": "rate(http_requests_total[5m])"}
      ]
    }
  ],
  "templating": {
    "list": [
      {"name": "service", "type": "query", "query": "label_values(service)"}
    ]
  }
}

Import 의 방법

1. UI Import:
   Dashboards > Import > JSON file 또는 ID

2. Grafana Marketplace:
   ID 입력 (예: 1860 = Node Exporter Full)
   → 자동 다운로드 + 등록

3. API:
   POST /api/dashboards/db
   - JSON payload
   - overwrite · folder 지정

Marketplace 의 활용

인기 dashboard ID:
  - 1860 — Node Exporter Full (Linux/Server)
  - 7587 — Spring Boot 2.1
  - 11378 — Argo CD
  - 13332 — Kubernetes / Views / Global
  - 17345 — Kafka Exporter Overview
  - 14584 — MySQL Database 의 detailed

설치:
  Dashboards > New > Import
  → ID 입력 (예: 1860)
  → Datasource 선택 → Import

Folder · Permission · Public Dashboard

Folder 의 조직

표준 folder 구조:
  /
  ├─ Infrastructure
  │   ├─ Kubernetes
  │   ├─ AWS
  │   └─ Network
  ├─ Applications
  │   ├─ API
  │   ├─ Frontend
  │   └─ Worker
  ├─ Business
  │   ├─ Revenue
  │   ├─ Marketing
  │   └─ Customer
  └─ Personal
      └─ <user>

Permission 의 layer

Permission 의 적용:
  1. Organization (전체)
  2. Folder (folder 안 모든 dashboard)
  3. Dashboard (개별)

Role:
  - Admin (모든 변경)
  - Editor (생성 · 수정)
  - Viewer (보기만)

Team 의 permission:
  - 팀 = 사용자 그룹
  - folder 에 team permission
  - 사용자 의 team 의 자동 권한

Public Dashboard (Public Sharing)

Dashboard > Share > Public dashboard:
  - 공개 URL 생성
  - 인증 없이 접근 가능
  - 일부 panel 만 공개 (filter)
  - Time range · Variable 의 lock

용도는 status page (uptime · incidents), 외부 stakeholder · customer, SLA(서비스 수준 협약) dashboard 같은 자리에 어울려요. 다만 PII(개인식별정보) · 내부 metric 이 새지 않도록 봐야 하고, 공개 URL = anyone with link 라는 점도 잊지 마세요.

Reporting — PDF Export

자동 Report

Grafana Enterprise · Cloud Pro:
  - Dashboard → PDF 자동 export
  - Schedule (매일 · 매주 · 매월)
  - Email 자동 발송

용도:
  - 주간 KPI 보고 (CFO · CEO)
  - 월간 review 자료
  - 회의 자료 자동 생성

Setup

Reporting > New report:
  - Dashboard 선택
  - Time range (last week · last month · 사용자 정의)
  - Schedule (cron)
  - Email recipients
  - PDF · CSV · panel image

Dashboard as Code

Grafonnet (Jsonnet)

// grafonnet 의 dashboard 정의
local g = import 'github.com/grafana/grafonnet/main.libsonnet';

g.dashboard.new('Service Dashboard')
+ g.dashboard.withVariables([
    g.dashboard.variable.query.new('service', 'label_values(service)')
    + g.dashboard.variable.query.withDatasource('Prometheus'),
  ])
+ g.dashboard.withPanels([
    g.panel.timeSeries.new('RPS by service')
    + g.panel.timeSeries.queryOptions.withTargets([
        g.query.prometheus.new(
          'Prometheus',
          'sum(rate(http_requests_total[5m])) by (service)'
        )
      ])
    + g.panel.timeSeries.gridPos.withW(12) + g.panel.timeSeries.gridPos.withH(8),
  ])

Terraform Grafana Provider

terraform {
  required_providers {
    grafana = {
      source = "grafana/grafana"
    }
  }
}

provider "grafana" {
  url  = "https://grafana.company.com"
  auth = var.grafana_token
}

resource "grafana_dashboard" "service_dashboard" {
  config_json = jsonencode({
    title = "Service Dashboard"
    panels = [
      # ...
    ]
  })
}

resource "grafana_alert_rule_group" "api_alerts" {
  name   = "API Alerts"
  folder_uid = grafana_folder.alerts.uid
  interval_seconds = 60

  rule {
    name = "HighErrorRate"
    # ...
  }
}

장점

- Git 의 dashboard 변경 history
- PR review 의 dashboard 변경
- staging · production 의 일관성
- 재해 복구 (재현 가능)
- 일괄 변경 (여러 dashboard 동시 update)

함정 정리

사고 1: 한 dashboard 에 panel 너무 많음

원인 — 30+ panel 한 페이지 → 가독성 0 + 로딩 느림.

해결 — 목적 별 분리 (Overview · Detailed · Debug). 한 dashboard = 한 stakeholder · 한 사용 case.

사고 2: Variable chain 없이 광범위 query

원인 — Variable 없이 모든 service 의 모든 instance query → slow + 정보 과부하.

해결 — cascading variable. 사용자가 좁혀서 의미 있는 panel.

사고 3: Transformation 너무 복잡

원인 — 10+ transformation 의 chain → 디버그 어렵 + 성능 저하.

해결 — query 의 datasource 단계 에서 (SQL · PromQL) 처리 가능 시 그렇게. Transformation = 마지막 단계.

사고 4: Annotation 의 noise

원인 — 너무 많은 annotation (모든 ci event · 모든 metric change) → 차트 의 세로 선 폭주.

해결 — 의미 있는 event 만 (production deploy · incident · feature release). filter 의식.

사고 5: Library Panel 안 사용 → drift

원인 — 같은 panel 의 dashboard 마다 copy-paste → 일관성 깨짐 → 한 곳 만 변경.

해결 — Library Panel 의식. 표준 panel = library.

사고 6: Public Dashboard 의 PII 누출

원인 — internal metric (user_id · 회사 secret) 의 panel 이 Public Dashboard 에 포함.

해결 — Public 전 의 review + Public 의 filter · lock + 내부 dashboard 와 분리.

사고 7: Folder · Permission 의 무관리

원인 — 모든 사용자 = Editor → 임의 dashboard 만들기 · 변경 → governance X.

해결 — Folder 별 permission + Team-based access + Personal folder 분리.

사고 8: Marketplace dashboard 의 무수정 사용

원인 — ID 1860 import → 우리 metric naming convention 과 다름 → panel 모두 빈값.

해결 — import 후 datasource · query 의 fix + 우리 환경에 맞춤.

사고 9: Dashboard JSON 의 hand editing

원인 — JSON 직접 편집 → syntax error → import 실패.

해결 — UI 사용 + export 후 git commit + Grafonnet · Terraform 의 IaC(Infrastructure as Code).

사고 10: Time range 너무 광범위

원인 — Default time range = "last 30 days" → 모든 panel 의 query 가 30일 scan → 매우 느림.

해결 — Default = "last 1 hour" + 필요 시 사용자가 확장. 명시 default.

운영 권장 패턴

Pattern 1: Production Dashboard 4 layer

1. Overview Dashboard
   - 전사 KPI (활성 사용자 · 매출 · SLO)
   - 가장 추상 · CEO 대상

2. Service Dashboard (per service)
   - 한 service 의 RED metric (Rate · Errors · Duration)
   - Tempo Service Graph
   - 최근 alert
   - Owner team 대상

3. Cluster Dashboard
   - Kubernetes overview
   - Node · Pod 의 resource
   - Infrastructure team 대상

4. Business Dashboard
   - Funnel · cohort · retention
   - 비즈니스 metric
   - Product · Marketing 대상

SLO(서비스 수준 목표) 가 여기서 처음 나와요. 6편에서 깊이 다룰 키워드.

Pattern 2: Variable 의 표준

모든 production dashboard 의 표준 variable:
  $environment  = prod / staging / dev  (Custom)
  $cluster      = us-east-1 / asia-northeast3 / eu-west-1  (Query)
  $namespace    = (dropdown based on environment + cluster)  (Query)
  $service      = (dropdown based on namespace)  (Query)
  $interval     = 1m / 5m / 10m / 30m / 1h  (Interval, 자동 $__interval)

이 cascading chain 으로 사용자가 의미 있게 좁혀가는 흐름 이 만들어져요.

Pattern 3: Annotation 의 표준 source

표준 annotation 3종:
  1. Production Deploys (CI/CD API call)
  2. Incidents (Loki query → severity=critical 의 incident)
  3. Feature Flags (Statsig · LaunchDarkly 의 webhook → Grafana API)

→ 모든 production dashboard 의 자동 표시

Pattern 4: Library Panel 의 표준 panel

표준 Library Panel:
  - "Service Health Overview" (RPS · Error rate · p99 latency 한 panel)
  - "Recent Deploys" (last 5 deploy 의 timestamp · author · commit)
  - "Active Alerts" (현재 fire 중인 alert 리스트)
  - "SLO Status" (error budget · burn rate)
  - "Cluster Resource" (CPU · 메모리 · 디스크)

→ 모든 service dashboard 가 위 5 panel 의 *동일 view*

Pattern 5: Folder 의 permission 자동

# Terraform
resource "grafana_folder" "backend_team" {
  title = "Backend Team"
}

resource "grafana_folder_permission" "backend_team_permission" {
  folder_uid = grafana_folder.backend_team.uid

  permissions {
    role       = "Viewer"
    permission = "View"
  }
  permissions {
    team_id    = grafana_team.backend.id
    permission = "Edit"
  }
}

Pattern 6: 자동 PDF Report

매주 월요일 09:00 KST:
  - "Overview Dashboard" 의 last week → PDF
  - CEO · CFO · Engineering Lead 의 이메일

매일 09:00 KST:
  - "Service Health" 의 last 24h → PDF
  - 모든 service Owner 의 이메일

매월 1일:
  - "Business Dashboard" 의 last month → PDF
  - Board · Investor 의 자료

시험 직전 한 번 더 — Dashboard 압축 노트

Panel 종류 (15+)

• 시계열 — Time Series · Bar Chart · Histogram · Heatmap · State Timeline · Status History · Candlestick
• 단일 값 — Stat · Gauge · Bar Gauge · Pie Chart
• 표 · 텍스트 — Table · Logs · Text · News
• 특수 — Trace · Geomap · Node Graph · Canvas · Annotations List · Alert List · Dashboard List
• 80% 사용 = Time Series + Stat + Table

Variable 7 Type

• Query · Custom · Constant · Datasource · Interval · Ad hoc filter · Text Box
• Cascading dropdown (chain)
• Multi-value · Include All
• Format modifier (${var:regex} · ${var:csv} · ${var:json})

Transformation (26종)

• Add field from calculation · Filter · Group by · Join · Organize fields · Rename · Sort · ...
• query 단계 처리 가능하면 그렇게 (transformation = 마지막)

Annotation

• Built-in (alert state · annotations datasource)
• Dashboard 의 annotation query (Loki 의 deploy event)
• 수동 입력
• 자동화 — CI/CD API call · Loki query · GitHub release

Library Panel

• 한 panel 재사용
• 한 곳 변경 = 모든 dashboard 반영
• 표준 panel (Service Health · Recent Deploys 등)

Dashboard JSON

• Import (UI · Marketplace ID · API)
• Marketplace (1860 = Node Exporter · 13332 = Kubernetes)
• import 후 datasource · query fix

Folder · Permission

• Organization · Folder · Dashboard 의 3 layer
• Role — Admin · Editor · Viewer
• Team-based access

Public Dashboard

• 공개 URL · 인증 없음
• PII · secret 누출 의식
• status page · 외부 customer

Reporting

• PDF · CSV · image
• Schedule (cron) · email 자동
• Enterprise · Cloud Pro

Dashboard as Code

• Grafonnet (Jsonnet)
• Terraform Grafana Provider
• Git history · PR review · staging/prod 일관성

사고

• Panel 너무 많음 (목적 분리)
• Variable chain 없음 (광범위 query)
• Transformation 너무 복잡
• Annotation noise (filter)
• Library Panel 안 사용 (drift)
• Public Dashboard PII 누출
• Folder permission 무관리
• Marketplace 무수정 (datasource mismatch)
• JSON 직접 편집 (syntax error)
• Time range 너무 광범위

패턴

• Production Dashboard 4 layer (Overview · Service · Cluster · Business)
• 표준 Variable (env · cluster · namespace · service · interval)
• 표준 Annotation 3종 (Deploy · Incident · FeatureFlag)
• 표준 Library Panel 5종
• Folder permission 자동 (Terraform)
• 자동 PDF Report (주간 · 일간 · 월간)

공식 문서: Grafana Dashboards · Variables 에서 더 깊은 spec 을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 1편 — Observability 3 pillar · LGTM stack 종합
• 2편 — Prometheus + PromQL 깊이 (Pull · Exporter · Alertmanager)
• 3편 — Loki + LogQL 깊이 (Label Index · 비용 효율)
• 4편 — Tempo + TraceQL · 분산 Trace 깊이

다음 글:

• 6편 — Alerting · Notification · SLO 깊이
• 7편 — Cloud · Enterprise · IaC 깊이
• 8편 — 운영 함정 + 사고 케이스 깊이
• 9편 — 시리즈 마무리 · 체크리스트 · 다음 학습