Grafana──洞察一切資訊的羅盤

Grafana 的定位#

在可觀測性的生態系中，Grafana 扮演的角色非常明確：它是一個視覺化與查詢平台，本身不儲存任何資料。

這個定位看似簡單，卻是 Grafana 最大的優勢。你的 Metrics 可能存在 Prometheus，Logs 存在 Loki，Traces 存在 Tempo，甚至還有一些資料在 Elasticsearch 或 InfluxDB 裡 ──Grafana 讓你在同一個介面中查詢和呈現所有這些來源的資料，而不需要在多個工具之間切換。

你可以把 Grafana 想像成一個「萬用遙控器」：它不是電視、也不是音響，但它能操控你家裡所有的設備。你需要的是設備本身（Backend），而 Grafana 提供的是統一的操作介面。

核心元件#

Data Source── 連接後端的橋樑#

Data Source 是 Grafana 與後端儲存之間的連接設定。每一種後端都有對應的 Data Source 外掛，告訴 Grafana 如何與該後端溝通。

設定一個 Data Source，本質上就是告訴 Grafana：這個後端的位址在哪裡、用什麼認證方式、預設的查詢參數是什麼
Grafana 內建支援數十種 Data Source，包括 Prometheus、Loki、Tempo、Elasticsearch、InfluxDB、MySQL、PostgreSQL 等
社群和第三方外掛提供了更多選擇，幾乎涵蓋所有主流的資料儲存系統

在規劃可觀測性架構時，選擇 Grafana 原生支援度高的 Backend（例如 Grafana 自家的 LGTM Stack：Loki、Grafana、Tempo、Mimir），可以獲得最佳的整合體驗，包括跨資料類型的關聯查詢。

Dashboard── 視覺化的核心#

Dashboard 是由多個面板（Panel）組成的頁面，每個面板顯示一個或多個查詢的視覺化結果。

Dashboard 是日常營運中最常使用的功能：

Panel 是最小的視覺化單位，支援折線圖、長條圖、儀表板、表格、熱力圖等多種呈現方式
Variable 讓 Dashboard 具備互動性 ── 你可以用下拉選單切換不同的服務、環境或時間範圍，而不需要為每種組合建立獨立的 Dashboard
Row 用來將相關的 Panel 分組，讓 Dashboard 在視覺上更有結構
Dashboard 可以匯出為 JSON，方便版本控制和跨環境部署

Explore── 臨時查詢的工作台#

Explore 是一個專為臨時查詢和除錯設計的介面，與 Dashboard 的差異在於它不需要預先設定面板。

當你在排查問題時，Explore 是你的起點 ── 直接選擇 Data Source、寫查詢、看結果
支援同時開啟多個查詢頁籤，方便比對不同來源的資料
Split View 功能讓你在同一個畫面左右並排兩個查詢，例如左邊看 Metrics 的異常時間點，右邊看同一時段的 Logs
當你在 Explore 中找到有價值的查詢，可以直接將它加入既有的 Dashboard

Dashboard 和 Explore 的使用時機不同：Dashboard 是給「已知要看什麼」的日常監控用的，Explore 是給「還不知道問題在哪裡」的臨時排查用的。兩者互補，不要試圖用 Dashboard 取代 Explore 的角色。

Alerting── 主動通知的機制#

Alerting 讓 Grafana 根據查詢結果自動觸發告警，而不需要有人一直盯著 Dashboard。

Alert Rule 定義告警條件：對哪個 Data Source 執行什麼查詢、當結果超過什麼閾值時觸發
Contact Point 定義通知管道：Email、Slack、PagerDuty、Webhook 等
Notification Policy 定義路由規則：哪些告警送到哪個 Contact Point、是否需要靜音（Silence）或分組
支援多層級告警（Warning / Critical），避免所有告警都用同樣的緊急程度

告警設計是一門學問。最常見的問題是告警疲勞（Alert Fatigue）── 當告警太多、太頻繁、且大多數是誤報時，團隊會開始忽略所有告警，包括真正重要的那些。設計告警時，每一條規則都應該對應一個需要人為介入的具體動作。

重要觀念#

查詢語言不是 Grafana 的#

一個常見的誤解是把查詢語言歸屬於 Grafana。事實上，Grafana 只是轉發查詢到後端，並呈現結果。你在 Grafana 中寫的 PromQL 是 Prometheus 的語言、LogQL 是 Loki 的語言、TraceQL 是 Tempo 的語言。

這意味著：

學習查詢語言，本質上是在學習對應的 Backend
同一個查詢在 Grafana 和直接對 Backend 執行，結果應該一致
換掉 Grafana 不影響你的查詢知識，換掉 Backend 才會

Provisioning 與 Infrastructure as Code#

Grafana 支援透過設定檔（YAML）或 API 來管理 Data Source、Dashboard 和 Alert Rule，而非只能透過 UI 手動操作。這在團隊協作和多環境部署時至關重要 ── 你的 Dashboard 定義可以跟應用程式碼一起進版本控制。

Dashboard 設計的最佳實踐#

一個好的 Dashboard 不只是「把圖表排上去」，它需要經過設計才能真正幫助團隊做出決策。

層次化設計#

建立 Dashboard 時，採用由上而下的層次結構：

Level 1 – Overview：全系統的健康狀態總覽，通常是一頁就能看完的高階指標（請求量、錯誤率、延遲分佈）。這是大多數人每天第一個打開的頁面
Level 2 – Service：單一服務的詳細資訊，包含該服務的 RED Metrics（Rate、Errors、Duration）和資源使用量
Level 3 – Debug：最詳細的排查用 Dashboard，可能包含個別 endpoint 的表現、資料庫查詢效能、快取命中率等

每一層的 Dashboard 都應該包含連結（Link），讓你能夠從 Overview 一鍵鑽探（Drill Down）到 Service，再鑽探到 Debug。

一致性原則#

命名規範：統一的 Dashboard 和 Panel 命名規則，例如 [Team] Service - Category
顏色語意：綠色代表正常、黃色代表警告、紅色代表異常 ── 在所有 Dashboard 中保持一致
時間範圍：相關的 Panel 使用相同的時間範圍，避免讓使用者誤解因果關係
單位標示：每個數值軸都要有明確的單位（ms、req/s、%、bytes），避免猜測

避免資訊過載#

一個 Dashboard 不要超過 15-20 個 Panel── 太多面板會讓人無法聚焦
使用 Row 摺疊次要資訊，讓使用者可以選擇性展開
不是所有 Metrics 都值得放上 Dashboard── 只放那些能驅動決策的指標
善用 Stat Panel（單一數字面板）來突顯最關鍵的數值，例如當前的錯誤率或 SLO 達成率

設計 Dashboard 時問自己：「看到這個面板之後，我會做什麼決定或採取什麼行動？」 如果答不出來，這個面板可能不需要存在。

什麼時候引入 Grafana#

Grafana 的引入時機取決於你的需求和現有架構：

適合引入的情境：

你的可觀測性資料分散在多個後端，需要一個統一的查看入口
團隊需要建立標準化的 Dashboard 和告警規則
你已經在使用或計畫使用 Prometheus、Loki、Tempo 等開源後端
你希望視覺化工具和儲存後端解耦，保留未來替換的彈性

可以暫緩的情境：

你使用的雲端服務已經提供了整合良好的原生監控介面（例如 AWS CloudWatch、GCP Cloud Monitoring）
團隊規模很小，且所有資料都在同一個後端中，不需要跨來源查詢
你的系統仍在非常早期的階段，基礎的 CLI 工具或簡單的日誌查看就足夠

即使在暫緩的情境下，理解 Grafana 的設計理念仍然有價值。它所強調的「資料源與視覺化分離」、「層次化 Dashboard」、「可程式化管理」等觀念，適用於任何視覺化工具的使用。

為什麼選擇 Grafana#

在眾多視覺化工具中，Grafana 脫穎而出的原因：

開源且活躍：Apache 2.0 授權，社群貢獻者眾多，更新頻率高
生態系完整：與 Prometheus、Loki、Tempo、Mimir、OpenTelemetry 等主流工具深度整合
Data Source 外掛豐富：幾乎支援所有主流的資料儲存系統
社群 Dashboard：Grafana.com 上有數千個社群分享的 Dashboard 模板，可以直接匯入使用
企業版與雲端版：如果需要更多功能（如 RBAC、SSO、SLA 保證），Grafana Cloud 和 Enterprise 版本提供商業支援

Grafana 不是唯一的選擇，但它是目前開源可觀測性生態系中整合度最高、社群最活躍的視覺化平台。理解了 Grafana，你就掌握了觀察和理解系統的核心工具。