Grafana:一塊玻璃,只查不存

第一篇那張資料流圖,最右邊那格是 Grafana。這篇把它拆開——而理解 Grafana,其實只要抓住一句反直覺的話:它不存任何觀測資料,它只是一塊拿來「問」的玻璃。 想通這句,它的所有特性就都通了。

Grafana 只查不存:資料在 data source

很多人第一個誤會,是以為指標和日誌「存在 Grafana 裡」。不是。 Grafana 手上沒有任何時序資料——它是一層查詢 + 視覺化 + 告警的介面。真正的資料,住在它連過去的 data source(Prometheus/Mimir、Loki、Tempo,甚至 PostgreSQL、CloudWatch)裡。你在儀表板上看到的每一條線,都是 Grafana 當下去 data source 問來的:

Grafana 手上只有 dashboard 定義與一些設定(存在它自己一個小 DB 裡),沒有任何時序資料。每個 panel 都是「一個查詢 + 一種視覺化」,查詢當下打到對應的 data source——用 PromQL 問 Prometheus/Mimir、用 LogQL 問 Loki、用 trace 查詢問 Tempo。這個「只查不存」的定位,正是它能同時接一堆異質來源、又好部署好備份的原因——因為它沒有寶貴資料要顧,truth 全在後面的 data source

這個定位帶來三個好處:Grafana 自己近乎無狀態(掛了重開、換一台都不痛,因為資料不在它身上);能統一異質來源(不管後面是 Prometheus 還是雲商的監控,對它都只是「一個可以問的地方」);而「一塊玻璃」的價值也就在這——把散在各處的資料,收進一個地方問。分清「呈現層(Grafana)」和「儲存層(data source)」,是用好它的第一步。

dashboard 與 panel:一個 panel 回答一個問題

Grafana 的組成很單純:一個 dashboard = 一組 panel;一個 panel = 一個查詢 + 一種視覺化(折線、單一數字、表格、熱圖…)。心法就一句——一個 panel 只回答一個問題。別把十個指標塞進一張圖,那樣事故當下沒人讀得懂;讓每個 panel 清楚地回答「錯誤率多少」「p99 延遲多少」,一眼就能掃。(什麼圖配什麼問題,系列後面的儀表板設計那篇會專門講。)

template variable:一張儀表板,服務一百個目標

如果每個服務都手刻一張儀表板,五十個服務就是五十張、改一個共同欄位要改五十次——這跟 Kustomize 要解的跨環境重複是同一個病。Grafana 的解法是 template variable:把會變的部分(namespace、service…)抽成一個下拉選單,查詢裡用 $service 代入,一張模板就能套遍所有目標:

Template variable 把「會變的目標」抽成一個下拉選單,查詢裡用 $service 代入。於是一張模板儀表板,就能套遍所有服務——選 checkout 看 checkout、切 payment 看 payment,同一張圖、不同目標。少了它,你得為每個服務手刻一張、共同欄位改一次要改五十次。好的觀測平台不是儀表板多,是「一張能套很多目標」——變數是規模化的關鍵武器

dashboard as code:別用滑鼠拖出你的可靠性

最後一個工程紀律:Grafana 的 dashboard 本質是一份 JSON。你可以把它存進 git、用 provisioning 或 Terraform 部署,而不是靠某個人在 UI 上手動拖出來。手拖的儀表板,是拖的人腦裡的知識——他離職就沒了、無法 review、無法一鍵重建。存成程式碼,它才變成團隊資產。這跟我一路講的宣告式 + 版控是同一條紀律:把重要又會變的東西,從人的臨時操作,搬進可追蹤的宣告。

反思

分清「呈現層」和「儲存層」,是用好任何工具的基本功

「Grafana 只查不存」這句話,想通之後,我發現它是一把能套很多地方的尺。Grafana 是呈現層、data source 是儲存層——搞混這兩層,你會做出蠢事:以為刪了 Grafana 資料就沒了(其實資料在 data source)、或想在 Grafana 裡「存」什麼(它不是那種東西)。這個「呈現 vs 儲存」的分層,到處都是——三支柱的儲存 vs Grafana 的玻璃、MVC 的 view vs model、甚至 Airflow 的 UI vs metadata DB。我看任何一個系統,都會先問一句:它是在『呈現』還是在『儲存』? 分清楚了,你就知道哪個掛了會痛、哪個換掉不痛、備份該備哪個。

規模化一個觀測平台,靠的是「一張套很多」,不是「圖很多」

template variable 這個小功能,背後是一個大道理。新手容易覺得「儀表板越多越專業」,結果做出一百張沒人維護、彼此重複的圖。真正能規模化的做法恰恰相反——是把重複的部分抽成變數,讓一張模板服務一百個目標。這跟我在 Kustomize、在 Airflow 那條「一份來源 + 每環境差異」是同一種思維:規模化靠的是消除重複,不是堆數量。 一個團隊的觀測成不成熟,我現在不看它有幾張儀表板,而看它「加一個新服務,要不要重刻一張圖」——答案是「不用、下拉多一個選項就好」的,才是做對了。

可版控的玻璃,才是可靠的玻璃

第一篇我說「一塊玻璃的價值,是事故當下少一層摩擦」。這篇要補一句:那塊玻璃本身,也得是可靠的。 一個靠某人手動點出來、沒進版控的儀表板,是脆弱的資產——它會在你最需要的時候,因為某次誤刪、某個人離職而消失。把 dashboard 存成 JSON、進 git、宣告式部署,它就從「某個人的手藝」變成「團隊能重建的資產」。這也收束回這系列的主軸:觀測的終點是行動,而你要在事故當下靠它行動的東西,自己絕不能是不可靠的。玻璃要透、要統一,但更根本的——它得在你需要它的那一刻,還在那裡。