Grafana 입문 1편 — Observability 3 pillar · LGTM stack 종합

이 글은 Grafana 입문에서 운영까지 시리즈 1편이에요. 8~9편 풀 시리즈의 시작이고, 첫 글은 큰 그림을 잡는 자리예요. 왜 Grafana 인가, Observability(시스템 가시성)의 3 pillar 가 무엇인지, LGTM stack 은 어떻게 묶이는지, Datasource 가 얼마나 풍부한지를 한 번에 정리해요.

왜 처음엔 어렵게 느껴질까

Grafana 를 처음 보면 막막한 이유가 두 가지예요.

첫째, Grafana 라는 이름이 너무 많은 것을 가리켜요. 시각화 도구로서의 Grafana 도 있고, Grafana Labs 라는 회사도 있고, LGTM 스택 전체를 가리키기도 해요. 거기에 Grafana Cloud, Grafana Enterprise 까지 합쳐지면 각각 다른 대상이에요.

둘째, observability(시스템 가시성) 라는 개념 자체가 추상적이에요. 모니터링이랑 뭐가 다른지, 왜 logs 만 봐서는 안 되고 metrics + logs + traces 를 다 갖춰야 하는지, 왜 한 도구로 안 되고 stack 이 필요한지, 이 첫 질문이 잘 풀리지 않아요.

해결은 한 줄씩 풀어보는 거예요. Grafana 는 시각화와 alerting 을 한자리에 모으는 도구고, observability 는 시스템이 자기 상태를 외부로 설명해주는 능력이고, 3 pillar 는 같은 사고를 세 각도에서 본다는 뜻이에요. 비유부터 잡으면 그 다음 깊이는 자연스럽게 따라와요.

Grafana 의 자리

회사 의 관점 비유

Grafana 의 자리를 회사로 비유하면 이래요.

회사:
  - 데이터 = 매출 · 비용 · 직원 · 고객 · ...
  - 각 데이터 = 별도 시스템 (회계 · HR · CRM · ERP)
  - CFO 의 dashboard = 모든 시스템 의 핵심 KPI 한 화면

Grafana = CFO 의 dashboard
  - 데이터 자체 X (그건 각 시스템)
  - 데이터 시각화 + 결정 자료 만들기
  - 알림 (KPI 한계 넘으면 알림)

여기서 첫 통찰은 Grafana 가 데이터를 저장하지 않는다 는 점이에요. Grafana 는 시각화만 담당해요. 데이터는 Datasource(데이터 출처) 쪽에 있어요. Prometheus, Loki, DB, CloudWatch 같은 시스템들이 그 자리를 맡아요.

Observability 의 의미

Monitoring 과 Observability 를 나란히 두면 차이가 뚜렷해져요.

Monitoring (전통):
  - 시스템의 *predefined metric* 만 본다
  - "CPU > 80%" 같은 threshold alert
  - "무엇이 잘못됨?" 답 가능 (이미 정의된 문제)

Observability (현대):
  - 시스템의 *내부 상태* 를 *외부 데이터로 추론* 가능
  - 새로운 문제도 *데이터 깊이로 발견* 가능
  - "왜 잘못됨?" · "어디서?" · "어떤 흐름?" 답 가능

여기서 시험 함정이 하나 있어요. Monitoring 과 Observability 는 같지 않아요. Observability 는 데이터로 시스템 내부를 어디까지 추론할 수 있느냐의 정도예요. metric 을 잔뜩 박는다고 observability 가 되는 게 아니에요. 데이터 사이의 상호 연결성, 질 좋은 context, drill-down(상세 파고들기) 가능 여부가 핵심이에요.

Observability 의 3 Pillar

Metrics · Logs · Traces

┌─────────────────────────────────────────┐
│ 1. Metrics (지금 상태)                    │
│    - 시계열 수치                          │
│    - CPU · 메모리 · 요청 수 · 지연 시간    │
│    - aggregated (이미 sum · avg)         │
│    - 저장 효율적                          │
├─────────────────────────────────────────┤
│ 2. Logs (발생한 일)                      │
│    - 시간 + 이벤트 텍스트                  │
│    - "user 12345 가 login 실패"           │
│    - 자유 형식                            │
│    - 저장 비용 높음                       │
├─────────────────────────────────────────┤
│ 3. Traces (요청의 여정)                  │
│    - 한 요청이 마이크로서비스 사이 의 흐름   │
│    - "frontend → auth → db → cache"     │
│    - span (각 service 의 시간)            │
│    - 분산 시스템 의식                     │
└─────────────────────────────────────────┘

각 pillar 의 사용 case

Metrics 의 자리:
  - 대시보드 KPI (현재 RPS · p99 latency)
  - Alert (CPU > 80% · error rate > 1%)
  - 트렌드 분석 (지난 24시간 vs 7일 평균)

Logs 의 자리:
  - 디버그 (error 의 context)
  - audit (누가 무엇 했나)
  - 사용자 행동 (한 사용자 의 모든 액션)

Traces 의 자리:
  - 분산 시스템 의 bottleneck (어느 service 가 느림?)
  - 한 요청 의 전체 path
  - 마이크로서비스 dependency 발견

여기서 RPS(초당 요청 수) 와 p99 latency(상위 1% 지연) 는 metrics 의 단골 지표예요.

함께 사용 — Correlate

시나리오: 사용자가 "사이트 느려" 신고 (오전 10:32)

Metrics:
  → 10:30~10:35 의 p99 latency = 정상 100ms → 5000ms 폭증
  → 한 service 의 RPS 정상 BUT latency 폭증

Logs:
  → 같은 시간대 의 error log 다수
  → "DB connection pool exhausted" 메시지

Traces:
  → 그 시간대 의 한 trace 의 span = DB query 가 4.8초

→ 결합: DB connection pool 부족 → 일부 query 대기 → latency 폭증

이렇게 한 도구 안에서 세 pillar 를 묶어 보는 자리가 Grafana 가 가장 큰 값을 내는 지점이에요.

LGTM Stack — Grafana Labs 의 통합 stack

LGTM 의 의미

L — Loki    (logs)
G — Grafana (시각화)
T — Tempo   (traces)
M — Mimir   (metrics, Prometheus 호환 long-term)

각 component 는 별도의 오픈소스 프로젝트로, 따로 운영해도 돌아가요. 하지만 함께 묶으면 완전한 observability stack 이 돼요.

Loki — Logs

Loki 의 특징:
  - "Prometheus for logs" 슬로건
  - Label 기반 indexing (full text X — 비용 절감)
  - Object storage (S3 · GCS) 사용 가능
  - LogQL — Loki 의 query language

대안으로 자주 비교되는 도구가 있어요.

Elasticsearch / OpenSearch:
  - full text search 강력
  - 비용 매우 높음 (RAM · 저장소)

Loki:
  - 비용 효율 (label index 만)
  - 검색 약간 느림
  - Kubernetes · cloud-native 환경 표준

Grafana — 시각화 + Alerting

Grafana 의 핵심:
  - Dashboard (Panel 모음)
  - Variable (dropdown 으로 동적 query)
  - Annotation (event 표시 — 배포 시각 등)
  - Alerting (rule + notification)
  - Datasource (수십 종)
  - Plugin (확장 panel · 데이터소스)
  - Folder · Permission (조직 관리)

Grafana 는 stack 의 UI 역할을 맡아요. metric, log, trace 를 공통의 view 에서 한꺼번에 보는 자리예요.

Tempo — Traces

Tempo:
  - 분산 trace 저장 (OpenTelemetry · Jaeger · Zipkin 호환)
  - Object storage (S3 · GCS)
  - TraceQL — Tempo 의 query language
  - Grafana Cloud 에서 자동 통합
  - Loki/Mimir 와 자동 correlation

대안도 살펴볼 만해요.

Jaeger:
  - 독립 오픈소스
  - UI 자체 있음 (Tempo 는 Grafana UI 사용)

Zipkin:
  - 더 오래된 분산 trace 시스템
  - Twitter 출신

OpenTelemetry:
  - protocol 표준 (Tempo · Jaeger · Zipkin 모두 OTel 호환)

OTel(OpenTelemetry 약자) 은 trace 데이터를 주고받는 공통 규약이에요.

Mimir — Long-term Prometheus

Mimir 의 자리:
  - Prometheus 의 한계 = single-node + limited retention
  - Mimir = horizontally scalable + long-term storage
  - Object storage (S3 · GCS)
  - PromQL 100% 호환
  - High availability (multiple replicas)

여기서 한 가지 중요한 게 Prometheus 와 Mimir 의 관계예요.

일반 사용 사례:
  1. 각 service 에 Prometheus exporter
  2. Prometheus 가 scrape (모든 service 의 metrics)
  3. Prometheus → Mimir 로 remote write
  4. Mimir = long-term storage (수 년 history)
  5. Grafana → Mimir query (PromQL)

Prometheus 만 쓰면 15일 정도 retention 이 권장 한도예요. Mimir 를 붙이면 수 년치 history 를 그대로 들고 갈 수 있어요.

추가 도구 — LGTM 외

Grafana Labs 가 만든 부가 OSS(오픈소스) 도구들이에요.

1. Pyroscope — Continuous profiling
   - CPU · Memory 의 *항상 profiling*
   - flame graph 자동
   - performance regression 자동 감지

2. Beyla — Auto-instrumentation
   - eBPF 기반 (code 수정 없이 자동 instrumentation)
   - HTTP · gRPC · DB 의 traces 자동

3. Alloy (구 Grafana Agent)
   - 통합 collector
   - metrics + logs + traces 한 agent 로 수집
   - OpenTelemetry · Prometheus · Loki 호환

4. k6 — Load testing
   - JavaScript 기반 load test
   - Grafana 와 결합 → test 결과 dashboard

5. OnCall — Incident management
   - PagerDuty 대안 (오픈소스)
   - alert routing · escalation · schedule

Beyla 가 쓰는 eBPF(리눅스 커널 내장 추적 기술) 는 애플리케이션 코드를 손대지 않고도 trace 를 잡아내는 게 강점이에요.

Datasource 의 풍부함

Built-in Datasource

┌──────────────────────────┬──────────────────────────────────┐
│ 카테고리                  │ Datasource                       │
├──────────────────────────┼──────────────────────────────────┤
│ Metrics (시계열)          │ Prometheus · Mimir · Graphite ·   │
│                          │ InfluxDB · OpenTSDB              │
├──────────────────────────┼──────────────────────────────────┤
│ Logs                     │ Loki · Elasticsearch · OpenSearch│
├──────────────────────────┼──────────────────────────────────┤
│ Traces                   │ Tempo · Jaeger · Zipkin          │
├──────────────────────────┼──────────────────────────────────┤
│ Profiles                 │ Pyroscope · Parca                │
├──────────────────────────┼──────────────────────────────────┤
│ Cloud Monitoring         │ AWS CloudWatch · Azure Monitor · │
│                          │ Google Cloud Monitoring          │
├──────────────────────────┼──────────────────────────────────┤
│ SQL Database             │ PostgreSQL · MySQL · MSSQL       │
├──────────────────────────┼──────────────────────────────────┤
│ Special                  │ Mixed · Dashboard · TestData ·    │
│                          │ Annotations & Alerts             │
└──────────────────────────┴──────────────────────────────────┘

Special Datasource

Mixed:
  - 한 panel 에서 *여러 datasource 동시 query*
  - 예: Prometheus 의 CPU + Loki 의 error log 한 차트

Dashboard:
  - 같은 dashboard 의 *다른 panel 의 결과* 를 input
  - panel 간 chain

TestData:
  - 가짜 데이터 생성기
  - panel 디자인 실험용

Plugin Marketplace

Grafana Plugin (공식 + 커뮤니티):
  - 100+ datasource
  - 200+ panel 종류
  - 신호 처리 의 거의 모든 시스템 통합

대표 plugin:
  - Snowflake · BigQuery · Databricks
  - Datadog · New Relic · Splunk
  - GitHub · GitLab · Jira
  - Salesforce · HubSpot
  - PostHog · Mixpanel · Amplitude

Dashboard · Panel · Variable

Dashboard 의 기본 구조

[Dashboard]
   ├─ Folder (조직)
   ├─ Tag (검색 라벨)
   ├─ Time Range (시각 범위)
   ├─ Refresh (자동 갱신 — 5s, 30s, 1m, ...)
   ├─ Variable (dropdown)
   ├─ Annotation (event 표시)
   └─ Panel 들
        ├─ Panel 1 (Graph)
        ├─ Panel 2 (Stat)
        ├─ Panel 3 (Table)
        └─ ...

Panel 종류

시각화 종류:
  - Graph (time series — 가장 흔함)
  - Stat (단일 값 큰 표시)
  - Gauge (게이지 차트)
  - Bar chart
  - Pie chart
  - Heatmap
  - Histogram
  - Table
  - Logs (텍스트 로그 보기)
  - Trace (분산 trace 보기)
  - Geomap (지도)
  - News (RSS feed)
  - Text (markdown)

Variable — 동적 query

Dashboard 의 dropdown:
  $environment = "prod" | "staging" | "dev"
  $service = "api" | "web" | "worker"
  $instance = (선택된 service 의 인스턴스 자동 로드)

Panel 의 query:
  rate(http_requests_total{
    env="$environment",
    service="$service",
    instance="$instance"
  }[5m])

→ dropdown 변경 = 모든 panel 자동 갱신

Variable 도 종류가 여러 가지예요.

- Query — datasource 에서 자동 옵션
- Custom — 직접 입력
- Constant — 고정값 (panel 마다 같음)
- Data source — datasource 자체를 dropdown
- Interval — 시간 간격 ($__interval)
- Ad hoc filter — 동적 filter 추가
- Text box — 자유 입력

Annotation — event 표시

시계열 chart 위의 세로 선:
  - 배포 시각
  - incident 시각
  - feature flag 변경

데이터 source:
  - 수동 입력
  - datasource query (예: Loki 의 deploy event)
  - 외부 API (GitHub release · Jira 등)

Alerting — Grafana 의 alert 시스템

Alert 의 구조

[Alert Rule]
   ├─ Query (어떤 metric/log)
   ├─ Condition (언제 trigger — 예: > 80%)
   ├─ Evaluation Interval (얼마나 자주 평가)
   ├─ For (얼마나 지속 조건 충족 시 fire)
   ├─ Labels (alert 의 메타데이터)
   ├─ Annotations (description · summary)
   └─ Contact Point
        ├─ Slack
        ├─ PagerDuty
        ├─ Email
        ├─ Webhook
        └─ ...

Contact Point 의 종류

- Slack (workspace · channel)
- PagerDuty (service key)
- Email (SMTP)
- Microsoft Teams
- OpsGenie
- Discord
- Telegram
- Webhook (custom)
- Pushover · Pushbullet
- VictorOps · Splunk
- 100+ 종 (plugin 포함)

Notification Policy — Routing

Alert 의 routing tree:
  ├─ severity = critical → PagerDuty (즉시)
  ├─ severity = warning  → Slack #alerts-prod
  ├─ team = backend     → Slack #team-backend
  ├─ team = frontend    → Slack #team-frontend
  └─ default            → Slack #general-alerts

라벨 기반으로 routing 을 짜면 각 팀이 자기에게 의미 있는 alert 만 받게 돼요.

Silence — alert 일시 mute

배포 중 / 점검 중 = 일부 alert 무시:
  - 라벨 기반 silence (예: deploy=true)
  - 기간 설정 (1시간 · 4시간 · 1일)
  - 자동 만료

Cloud vs OSS 선택

Grafana OSS (Open Source)

장점:
  - 무료 (self-host)
  - 완전 통제
  - on-premise 가능
  - 데이터 외부 X (privacy)

단점:
  - 운영 부담 (Grafana + Prometheus + Loki + ...)
  - 백업 · upgrade · 보안 직접
  - high availability 직접 구성

Grafana Cloud

Free Tier:
  - 10k metrics
  - 50GB logs
  - 50GB traces
  - 3명 사용자

Pro Tier (~$50/월~):
  - 더 큰 한도
  - SLA 보장
  - SSO · 권한 관리

Advanced (Enterprise):
  - 무제한 한도
  - Multi-tenancy
  - Dedicated support

Hybrid 패턴

가장 흔한 case:
  - Grafana Cloud (UI · dashboard · alerting)
  - 회사 의 Prometheus (metric scraping)
  - 회사 의 Loki (log aggregation)
  - 데이터 = on-prem, UI = Cloud

→ 운영 부담 절감 + 데이터 privacy

Grafana 의 첫 인상 (Hello World)

Docker 로 Grafana 띄우기

# Grafana 만
docker run -d \
  --name grafana \
  -p 3000:3000 \
  grafana/grafana-oss:latest

# 접속: http://localhost:3000
# 기본 로그인: admin / admin (첫 접속 시 변경 강제)

Datasource 추가

Grafana UI > Connections > Data sources > Add new data source

예: Prometheus 추가
  - URL: http://prometheus:9090
  - Save & test
  - 연결 확인 표시

첫 Dashboard

1. Dashboards > New dashboard
2. + Add visualization
3. Datasource 선택
4. Query 입력 (예 PromQL):
   rate(http_requests_total[5m])
5. Visualization 종류 선택 (Time series)
6. Save

첫 Alert

1. Alerting > Alert rules > New alert rule
2. Query: rate(http_requests_total[5m]) > 100
3. For: 5m
4. Contact point 선택
5. Save

여기까지 따라가면 Grafana 의 30분 hello world 는 끝나요.

함정 정리

사고 1: Grafana 가 데이터 저장 X 모름

원인 — Grafana 를 "metrics 를 저장하는 도구"로 오해해요. 실제로는 시각화만 담당해요.

해결 — Datasource 를 늘 의식해요. Grafana 의 모든 chart 는 외부 datasource 를 실시간 query 한 결과예요.

사고 2: Monitoring 만 박고 Observability 라 부름

원인 — 단순 metric 과 alert 만 깔아 놓고 "observability 잘 박혀 있다" 라고 자평하기 쉬워요.

해결 — 3 pillar(metrics + logs + traces) 를 모두 갖추고 correlation 과 drill-down 까지 돌아가야 진짜 observability 예요.

사고 3: Prometheus 만 + Mimir 없음 → retention 짧음

원인 — 단일 Prometheus 의 retention 이 기본 15일이라 1년 전 데이터를 못 찾는 일이 생겨요.

해결 — Mimir 나 Thanos, Cortex 같은 long-term storage 를 붙여요. Cloud-managed(Grafana Cloud, AWS AMP) 도 선택지예요. AMP 는 Amazon Managed Prometheus 의 약자예요.

사고 4: Cloud → 비용 폭탄

원인 — Grafana Cloud Free Tier 로 시작했는데 데이터가 늘면서 어느 순간 월 $1000 을 넘기는 경우가 있어요.

해결 — Free Tier 한도를 모니터하고, Pro 의 비용을 예측하고, self-host 와 비교한 분기점을 미리 정해 둬요.

사고 5: 모든 metric 박음 → cardinality 폭발

원인 — Prometheus 와 Mimir 에서 cardinality 폭발이 일어나요. 한 metric 에 너무 많은 label 조합이 붙는 경우예요.

해결 — label 을 의식해요. 동적 ID(request_id, user_id) 는 label 로 쓰면 안 되고, 미리 정의한 aggregation level 만 label 로 둬요.

사고 6: Variable 의 chain 무시

원인 — Variable A 와 B 를 독립으로 잡아요. A 가 prod 면 B 는 prod 의 service 만 보여야 하는데 전체가 다 노출돼요.

해결 — Variable B 의 query 안에 $A 를 참조해서 cascading dropdown 으로 만들어요.

사고 7: Alerting 의 너무 많은 alert

원인 — 100+ alert 에 매일 100+ Slack 알림이 쌓이면 alert fatigue(알림 피로) 가 와서 결국 무시하게 돼요.

해결 — SLO(서비스 수준 목표) 기반 alert 을 깔고, severity 를 나누고, grouping 과 silence routine 을 같이 굴려요.

사고 8: Annotation 자동화 안 됨

원인 — 배포와 incident 의 annotation 을 수동으로 입력하다 보면 잊고 안 박혀서 나중에 원인 분석이 어려워져요.

해결 — CI/CD 가 Grafana API 를 자동 호출하게 해서 모든 배포가 그대로 추적되게 해요.

사고 9: Dashboard 너무 많음 → "기억 안 남"

원인 — 분석가마다 dashboard 를 무한 생성해서 100+ dashboard 가 쌓이고, 어느 게 표준인지 아무도 몰라요.

해결 — Folder 로 분류하고 naming convention 을 정하고 Public / Personal 을 나누고 주기적으로 정리해요.

사고 10: Plugin 의 보안 위험

원인 — Community plugin 을 설치하다 보면 권한 누설이나 CVE(공개 보안 취약점) 위험이 따라와요.

해결 — 공식 plugin 을 우선 쓰고, plugin 의 review 와 audit 을 챙기고, production 환경은 따로 분리해요.

운영 권장 패턴

Pattern 1: 표준 stack 의 첫 시작

1주차:
  □ Docker Compose 로 Grafana + Prometheus + Loki + Tempo 띄우기
  □ Grafana 의 5개 datasource 추가
  □ Prometheus 의 첫 exporter (node_exporter) 박기
  □ Grafana Marketplace 의 표준 dashboard import

2주차:
  □ Loki 의 promtail · Alloy 로 첫 log 수집
  □ Tempo 의 OpenTelemetry instrumentation (한 service)
  □ Grafana 의 3 pillar correlation 첫 시도

3주차:
  □ Alerting rule 5개 (CPU · 메모리 · error rate · latency · disk)
  □ Slack contact point
  □ Notification policy (team 별 라우팅)

4주차:
  □ Mimir 또는 long-term storage 활성
  □ 첫 production 의 alert routine
  □ on-call 정착

Pattern 2: Production-ready stack

# docker-compose.yml (요약)
services:
  grafana:
    image: grafana/grafana-oss:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana

  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  loki:
    image: grafana/loki:latest
    command: -config.file=/etc/loki/local-config.yaml

  tempo:
    image: grafana/tempo:latest
    command: -config.file=/etc/tempo/tempo.yaml

  alloy:
    image: grafana/alloy:latest
    volumes:
      - ./alloy.config:/etc/alloy/config.alloy

Pattern 3: Dashboard as Code

# Grafonnet · Jsonnet 으로 dashboard 정의
local dashboard = import 'github.com/grafana/grafonnet/main.libsonnet';

dashboard.new('Web Service Overview')
+ dashboard.withVariables([
    dashboard.variable.new('service', 'web', 'api', 'worker')
  ])
+ dashboard.withPanels([
    # Panel definitions
  ])

Terraform Grafana Provider 를 써서 dashboard, datasource, alert 을 IaC(Infrastructure as Code, 코드형 인프라) 로 굴리는 방식도 흔해요.

Pattern 4: Alert 의 SLO 기반

SLO: 99.9% availability
SLI: success_rate = (200 OK) / (all requests)
Error budget: 0.1% (월 약 43분)

Alert:
  1. Page (Critical) — error budget 의 2% 소진 / 1시간
     → 매우 빠른 burn rate · 즉시 대응

  2. Ticket (Warning) — error budget 의 10% 소진 / 6시간
     → 점진 burn · 다음 영업일 대응

SLI(서비스 수준 지표) 는 SLO 를 측정하는 실제 수치예요. 단순히 "error rate > 1%" 로 끊는 대신 비즈니스 의미가 박힌 alert 을 만들 수 있어요.

Pattern 5: 다양한 stakeholder 의 dashboard

1. CEO/CFO Dashboard
   - 사용자 · 매출 · 핵심 KPI
   - 가장 추상

2. Engineering Manager Dashboard
   - 시스템 health (SLO · SLI · error budget)
   - 팀 별 service health

3. On-call Engineer Dashboard
   - 현재 alert · 진행중 incident
   - 즉시 행동 가능 한 정보

4. Service Owner Dashboard
   - 특정 service 의 깊은 metric
   - 디버그 도구

시험 직전 한 번 더 — Grafana 입문 압축 노트

Grafana 의 자리

• 데이터 저장 X (Datasource 가 저장)
• 시각화 + Alerting + 통합 UI
• 회사 의 CFO dashboard 비유

Observability vs Monitoring

• Monitoring = predefined metric (이미 정의된 문제 답)
• Observability = 시스템 내부 추론 (새 문제 발견)
• 3 pillar 만 박는다 ≠ observability
• correlation · drill-down 필수

3 Pillar

• Metrics — 지금 상태 (집계 수치, 저장 효율)
• Logs — 발생한 일 (자유 텍스트, 비용 높음)
• Traces — 요청의 여정 (분산 시스템 의식)

LGTM Stack

• L — Loki (logs, label index, S3)
• G — Grafana (시각화)
• T — Tempo (traces, OpenTelemetry · Jaeger · Zipkin)
• M — Mimir (long-term Prometheus, horizontal scale)

Datasource

• Metrics — Prometheus · Mimir · CloudWatch · Azure Monitor · GCM · InfluxDB · Graphite
• Logs — Loki · Elasticsearch · OpenSearch
• Traces — Tempo · Jaeger · Zipkin
• DB — Postgres · MySQL · MSSQL
• Special — Mixed (여러 datasource 한 panel) · Dashboard · TestData

Dashboard

• Folder · Tag · Time Range · Refresh
• Panel (Graph · Stat · Gauge · Table · Logs · Trace · Heatmap · ...)
• Variable (Query · Custom · Constant · Datasource · Interval · Ad hoc · Text)
• Annotation (배포 · incident 자동 표시)

Alerting

• Rule = Query + Condition + Evaluation Interval + For
• Contact Point — Slack · PagerDuty · Email · Webhook 등 100+
• Notification Policy = 라벨 기반 routing tree
• Silence = 일시 mute

Cloud vs OSS

• OSS — 무료 self-host, 운영 부담
• Cloud Free — 10k metrics · 50GB logs/traces · 3 user
• Cloud Pro — $50+/월, SLA · SSO
• Hybrid — Cloud UI + 회사 데이터

사고

• Grafana 가 데이터 저장 (오해)
• Monitoring 만 박고 observability 라 부름
• Prometheus 만 + retention 짧음
• Cloud 비용 폭탄
• Cardinality 폭발 (label 의식 X)
• Variable chain 무시
• Alert fatigue (너무 많은 alert)
• Annotation 수동 (CI/CD 자동화 X)
• Dashboard 너무 많음 (정리 정책 X)
• Plugin 보안 위험

패턴

• 표준 stack 4주차 도입 (Grafana + Prometheus + Loki + Tempo)
• Production-ready Docker Compose
• Dashboard as Code (Grafonnet · Terraform)
• SLO 기반 Alert (단순 metric threshold X)
• Stakeholder 별 dashboard (CEO · Manager · On-call · Owner)

공식 문서: Grafana introduction · Grafana datasources 에서 더 깊은 입문 자료를 확인할 수 있어요.

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

다음 글:

• 2편 — Prometheus + PromQL 깊이 (Pull · Exporter · Alertmanager)
• 3편 — Loki + LogQL 깊이 (Label Index · 비용 효율)
• 4편 — Tempo + TraceQL · 분산 Trace 깊이
• 5편 — Dashboard · Panel · Variable 깊이
• 6편 — Alerting · Notification · SLO 깊이