Grafana 可觀測性實戰：Dashboard、PromQL、告警與程式碼化配置

Grafana 為什麼是可觀測性的中樞

Metrics、Logs、Traces 三足鼎立（可觀測性三大支柱），但真正把它們串起來的往往是 Grafana。它的價值不在「畫圖」，而在把分散的訊號聚合成一個能回答「現在系統怎麼了」的介面。

支柱	資料源	回答的問題
Metrics	Prometheus	系統整體上健康嗎？
Logs	Loki	出錯時具體發生了什麼？
Traces	Tempo	一次請求慢在哪個服務？

建構高效的 Dashboard

好 Dashboard 的原則：一張圖只講一件事，自上而下由粗到細。典型佈局：

頂部：全域 SLO（錯誤率、P99 延遲、QPS）。
中部：依服務/實例拆分的細分面板。
底部：原始日誌與單條 trace 連結。

{
  "panels": [
    {
      "title": "P99 延遲",
      "type": "timeseries",
      "targets": [
        { "expr": "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))" }
      ]
    }
  ]
}

Dashboard JSON 通常很大，編輯前先用 JSON 格式化工具展開，避免改錯巢狀層級。

寫好 PromQL：可觀測性的語言

率（rate）優於原始計數

# 錯誤率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)

分位數用 histogram_quantile

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

標籤對比

# 各實例 QPS
sum(rate(http_requests_total[5m])) by (instance)

變數與模板化：一個 Dashboard 看全部

用模板變數讓同一張圖依 service、env 動態切換，避免複製貼上幾十張面板。

{
  "templating": {
    "list": [
      {
        "name": "service",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(http_requests_total, service)"
      }
    ]
  }
}

面板裡引用：sum(rate(http_requests_total{service="$service"}[5m]))。

多資料源：Metrics + Logs + Traces

Grafana 的強項是關聯。例如從 Metrics 面板點開「Explore」，用同一 trace_id 跳到 Tempo，再用 service + 時間窗跳到 Loki 日誌。

# 在 Loki 中依標籤過濾
{service="checkout", level="error"} |= "timeout"

告警：從「看見」到「被通知」

告警規則建議基於「症狀」而非「原因」：

groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
              / sum(rate(http_requests_total[5m])) by (service) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "服務 {{ $labels.service }} 錯誤率超過 5%"

for: 10m 能過濾瞬時抖動，避免告警風暴。

排查告警觸發的介面回傳碼時，可用 HTTP 狀態碼工具快速對照 5xx 含義。

註解與程式碼化配置

註解（Annotation）

把部署、回滾等事件標到時間軸上，出問題一眼看出「是不是剛發版引起的」。

Provisioning：Dashboard 即程式碼

不要手動點出來的 Dashboard——用檔案宣告，隨 Git 管理：

apiVersion: 1
providers:
  - name: default
    folder: ""
    type: file
    options:
      path: /etc/grafana/provisioning/dashboards

這樣 Dashboard 可審查、可回滾、可複製，符合 GitOps 實踐。

常見問題 FAQ

Q1：P99 算出來是 NaN 怎麼辦？

多半是 histogram bucket 沒上報，或 rate 時間窗內無資料。先確認指標存在再用 histogram_quantile。

Q2：變數下拉為空？

檢查變數 query 的資料源是否正確，以及 label_values 的 metric 名是否真實存在。

Q3：告警老是誤報？

加 for 持續時間、提高閾值、或用 absent() 處理指標消失的情況。

Q4：Grafana 和 Prometheus 告警啥關係？

Prometheus 負責「算 + 觸發」，Grafana 負責「展示 + 路由通知」。也可直接用 Grafana 託管告警。

Q5：定時任務指標怎麼看？

配合 Cron 說明工具核對排程週期，再對照指標時間窗判斷是否按時跑。

工具推薦

在 Grafana / 可觀測性建設中，以下工具庫能幫上忙：

Cron 說明 — 核對定時任務的五段式排程
HTTP 狀態碼 — 對照 5xx/4xx 告警語意
JSON 格式化 — 展開 Dashboard / 告警規則 JSON
Base64 編碼 — 處理資料源憑據與權杖

Grafana 不是「畫圖工具」，而是把 Metrics/Logs/Traces 編織成「系統當下狀態」的敘事層。把 Dashboard 程式碼化、告警基於症狀、變數驅動複用，可觀測性才真正落地為生產力。