Grafana 대시보드 구성과 시각화

Grafana가 담당하는 역할

Prometheus는 메트릭을 수집하고 저장하며 PromQL로 쿼리를 처리한다. 그러나 Prometheus의 기본 UI는 쿼리 탐색 도구에 가깝다. 실제 운영 현장에서는 수십 개의 메트릭을 한 화면에 배치하고, 시간 범위를 대화식으로 바꾸고, 배포 이벤트를 그래프 위에 오버레이하고, 팀 전체가 동일한 뷰를 공유해야 한다. 이 시각화 레이어를 담당하는 것이 Grafana다.

Grafana는 데이터를 저장하지 않는다. Grafana는 데이터 소스(Prometheus, Loki, MySQL 등)에 쿼리를 보내고 그 결과를 패널로 렌더링한다. 이 설계 덕분에 이기종 데이터 소스를 단일 대시보드에서 조합할 수 있다. 왼쪽 그래프는 Prometheus에서, 오른쪽 로그 패널은 Loki에서, 아래 테이블은 MySQL에서 가져올 수 있다.

데이터 소스 연결

데이터 소스는 Grafana가 쿼리를 보낼 외부 시스템을 지정하는 설정이다. Grafana는 핵심 데이터 소스 외에도 커뮤니티 플러그인을 통해 수백 가지를 지원한다.

UI에서 Administration → Data sources → Add data source로 추가하거나, YAML 프로비저닝 파일로 코드화할 수 있다.

# /etc/grafana/provisioning/datasources/all.yaml
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus:9090
    isDefault: true
    jsonData:
      scrapeInterval: "15s"
      httpMethod: POST
  - name: Loki
    type: loki
    url: http://loki:3100
    jsonData:
      maxLines: 1000

isDefault: true로 지정된 데이터 소스는 새 패널을 만들 때 기본으로 선택된다. 프로비저닝 파일은 Git에 커밋해 팀이 공유하고, Grafana 재시작 시 자동 적용된다. editable: false를 추가하면 UI에서 수정할 수 없게 보호된다.

데이터 소스를 추가한 후 Explore 탭에서 바로 쿼리를 실행해 연결 상태를 확인하는 것이 좋다.

패널과 시각화 타입

대시보드는 하나 이상의 패널(Panel)로 구성된다. 패널은 "이 데이터 소스에서 이 쿼리를 실행해 이 방식으로 보여줘"라는 단위다. 하나의 패널에 여러 쿼리를 올려 멀티 시리즈를 만들 수 있다.

모든 패널에 공통으로 설정할 수 있는 것들이 있다.

• Thresholds: 값이 임계값을 넘으면 색상이 바뀐다.
• Overrides: 특정 시리즈에만 다른 색상·두께·표시 방식을 적용한다.
• Data links: 패널의 특정 값을 클릭했을 때 다른 대시보드나 외부 URL로 이동한다.
• Transformations: 쿼리 결과를 패널에 표시하기 전에 필터링·정렬·합산한다.

Stat 패널과 임계값

Stat 패널은 현재 단일 값에 임계값 색상을 적용하기 좋다.

"thresholds": {
  "mode": "absolute",
  "steps": [
    { "color": "green", "value": null },
    { "color": "orange", "value": 70 },
    { "color": "red", "value": 90 }
  ]
}

CPU 사용률이 70% 미만이면 초록, 70~90%이면 주황, 90% 이상이면 빨강으로 자동 변경된다.

변수와 템플릿

변수는 대시보드 상단에 드롭다운으로 표시된다. 사용자가 값을 선택하면 그 값이 패널 쿼리에 자동으로 대입돼 모든 패널이 갱신된다. 변수 없이 환경별·인스턴스별 대시보드를 만들면 거의 동일한 대시보드가 수십 개로 늘어난다. 변수 하나로 하나의 대시보드가 모든 경우를 처리한다.

변수 타입

Query 타입이 가장 많이 쓰인다. Prometheus에서 label_values(메트릭명, 레이블명) 형식으로 레이블 값 목록을 가져온다.

변수를 쿼리에 사용

변수 이름은 $변수이름 또는 ${변수이름}으로 쿼리에 삽입한다.

rate(http_requests_total{job="$job", instance="$instance"}[5m])

$job과 $instance는 드롭다운에서 선택한 값으로 치환된다. 멀티 값(Multi-value)을 허용하면 Prometheus에서는 선택된 값들이 자동으로 정규식으로 변환된다.

-- $job에 "api-server"와 "payment-service"가 동시 선택된 경우 자동 변환:
rate(http_requests_total{job=~"api-server|payment-service"}[5m])

변수 연쇄(Cascading)

변수 간 의존 관계를 설정하면 상위 변수 선택에 따라 하위 변수 목록이 자동으로 바뀐다.

$namespace → $pod → $container

하위 변수의 Query에 상위 변수를 참조하면 된다.

label_values(kube_pod_info{namespace="$namespace"}, pod)

$namespace를 "default"로 선택하면 $pod 목록은 default 네임스페이스의 Pod들만 표시된다.

All 옵션

변수 설정에서 Include All option을 켜면 "전체 선택" 옵션이 생긴다. All 선택 시 Prometheus 쿼리에서 해당 레이블이 정규식 .+로 처리돼 모든 인스턴스를 집계한다. 팀 공용 Overview 대시보드라면 기본값을 All로 두는 것이 자연스럽다.

RED·USE 메서드로 대시보드 설계하기

패널을 어떻게 배치할지 기준이 없으면 의미 없는 패널이 쌓인다. 두 가지 메서드가 대시보드 구성의 기준으로 널리 쓰인다.

RED 메서드 (서비스 관점, Tom Wilkie 제안):

• Rate — 서비스가 처리하는 초당 요청 수
• Errors — 초당 에러 수 또는 에러율
• Duration — 요청 처리 지연 시간(p50, p95, p99)

API 서버, 마이크로서비스, 외부 엔드포인트를 모니터링할 때 적합하다.

USE 메서드 (자원 관점, Brendan Gregg 제안):

• Utilization — 자원 사용률(CPU %, 메모리 %)
• Saturation — 자원 포화도(큐 길이, 대기 요청 수)
• Errors — 자원 수준 에러(디스크 I/O 오류, 패킷 드롭)

서버, 데이터베이스, 네트워크 장비 같은 인프라 자원 모니터링에 적합하다.

상단 Overview 대시보드는 전체 상황을 한눈에 본다. 이상이 발견되면 변수를 좁혀 서비스·인스턴스 단계로 드릴다운한다. 이 계층으로 분리하면 모든 정보를 한 화면에 욱여넣지 않아도 된다.

Provisioning: 코드로 관리하는 대시보드

Grafana UI에서 수동으로 만든 대시보드는 Grafana 컨테이너를 재생성하면 사라진다. Provisioning을 사용하면 데이터 소스와 대시보드를 파일로 선언해 Grafana 시작 시 자동 적용된다.

대시보드 프로비저닝

먼저 대시보드를 JSON으로 내보낸다(Dashboard → Share → Export).

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: default
    folder: ""
    type: file
    options:
      path: /etc/grafana/dashboards
      foldersFromFilesStructure: true

이 설정이 있으면 Grafana가 /etc/grafana/dashboards/ 디렉터리의 JSON 파일을 자동으로 가져온다.

grafana-config/
├── provisioning/
│   ├── datasources/
│   │   └── all.yaml
│   └── dashboards/
│       └── default.yaml
└── dashboards/
    ├── kubernetes-overview.json
    ├── api-service.json
    └── database.json

이 디렉터리를 Git 저장소로 관리하면 대시보드 변경 이력이 코드로 남는다. 팀원이 PR을 올리면 코드 리뷰를 거쳐 대시보드가 변경된다.

한 가지 제약이 있다. 프로비저닝된 대시보드는 Grafana UI에서 수정 후 "Save"가 비활성화된다. 변경 사항을 반영하려면 JSON을 내보내 파일을 업데이트해야 한다. 이 제약은 의도치 않은 대시보드 변경을 막아주는 역할도 한다.

Grafana Alerting

Grafana 9부터 자체 알림 엔진(Unified Alerting)이 강화됐다. Prometheus의 Alerting rule 외에 Grafana 레벨에서 직접 알림을 정의할 수 있고, MySQL·Loki 같은 비 Prometheus 데이터 소스도 동일한 인터페이스로 알림을 설정한다.

핵심 구조는 Prometheus Alertmanager와 유사하다.

이미 Prometheus Alertmanager를 쓰고 있다면 Grafana에서 Alertmanager를 외부 Contact point로 등록해 두 시스템을 통합할 수 있다.

실무 체크리스트

한 줄 정리

Grafana는 데이터 소스에서 쿼리한 결과를 패널로 렌더링하는 시각화 레이어다. 변수로 하나의 대시보드를 여러 환경·서비스에서 재사용하고, 프로비저닝으로 대시보드를 코드로 관리한다.

References

• https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/
• https://grafana.com/docs/grafana/latest/visualizations/dashboards/variables/
• https://grafana.com/docs/grafana/latest/administration/provisioning/
• https://grafana.com/docs/grafana/latest/alerting/
• https://grafana.com/docs/grafana/latest/fundamentals/intro-histograms/
• https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/
• https://www.brendangregg.com/usemethod.html
• https://oneuptime.com/blog/post/2026-02-20-grafana-variables-templating/view
• https://oneuptime.com/blog/post/2026-01-20-grafana-dashboards-as-code/view