可觀測性是什麼:三大支柱與 LGTM 全家桶

一個系統可不可靠,先看你看不看得見它在幹嘛。這系列講 Grafana 的 LGTM 這套可觀測性工具怎麼把「看見」做到位。第一篇立好整個系列的框架:monitoring 和 observability 差在哪、三大支柱各答什麼問題、LGTM 這四個字母怎麼對應。而貫穿全系列有一句話我會一直回扣——觀測的終點不是「看到」,是「行動」。

monitoring vs observability:從「已知的未知」到「未知的未知」

這兩個詞常被當同義詞,但差別很關鍵。Monitoring 是監看你預先知道要看的東西:CPU、錯誤率、佇列長度——你事先想好可能會壞的地方,擺個儀表板、設個告警。它回答的是「已知的未知」(known unknowns):我知道要問這題,只是不知道答案。

Observability 更進一步:系統把足夠的內部狀態往外吐,讓你能回答當初根本沒想到要問的問題——「未知的未知」(unknown unknowns)。而 Production 的事故,九成都是你沒預想到的那種。差別一句話:monitoring 是「我知道要問什麼」,observability 是「我能問出我當初沒想到的問題」。

三大支柱:各答一個問題

要做到後者,靠的是三種互補的訊號——metrics、logs、traces。它們各答一個不同的問題,而且合起來剛好是排障的黃金路徑:

三支柱不是三個工具,是三種問問題的粒度:Metrics 是聚合的數字,答「有沒有問題、多嚴重」,便宜、可長存、能告警,但沒有細節;Traces 把一個請求跨服務的路徑串起來,答「問題在哪一段」;Logs 是事件的完整記錄,答「那裡到底發生什麼」。合起來就是排障的黃金路徑——先用 metric 看有沒有、再用 trace 定位在哪、最後用 log 看是什麼,由粗到細。跟 K8s 排障的 get→describe→logs 漏斗是同一種收斂

關鍵是三個都要。只有 metrics,你知道「壞了」卻不知道哪裡;只有 logs,你在事件大海裡撈針、還貴到存不起;只有 traces,你看得到路徑卻抓不到整體趨勢。它們互補,不是三選一。

LGTM 全家桶:一塊玻璃,背後四個字母

那 Grafana 的 LGTM 怎麼對應這三支柱?這四個字母其實是四個元件(順帶一提,LGTM 也雙關 code review 那句 “Looks Good To Me”):

Loki —— 收 logs(下一批會講:它像 Prometheus 一樣只索引 label、不做全文索引,所以便宜)
Grafana —— 一塊玻璃:查詢 + 視覺化 + 告警的介面。注意它只查不存,資料在各支柱的儲存裡
Tempo —— 收 traces(只靠 object storage + trace-id)
Mimir —— 收 metrics,是可水平擴、可長期保留的 Prometheus 後端

再加上採集 metrics 的 Prometheus、以及把資料送進來的 agent(Grafana Alloy / OpenTelemetry),就是完整的一套:

整套的資料流是一條線:你的 app 產生訊號 → 採集層(Alloy / OpenTelemetry / Prometheus)把它們送進三個各自的儲存 → Mimir(metrics)、Loki(logs)、Tempo(traces)→ 最後全部被 Grafana 查詢。這裡最該記住的一點:Grafana 只是「一塊玻璃」,它只查、不存——真正的資料在後面那三個儲存裡。後面每一篇,就是把這條線上的每一格拆開講透

反思

三支柱是三種「問問題的粒度」,排障就是沿著它收斂

我剛開始用這套時,把 metrics/logs/traces 當成三個「要各自學的工具」,學得很散。後來想通:它們其實是同一件事的三種粒度——metric 是最粗的「有沒有」、trace 是中間的「在哪」、log 是最細的「是什麼」。而排障最有效的路徑,就是沿著這三個粒度由粗到細收斂:先看儀表板確認「真的有問題」,再用 trace 縮到「哪個服務、哪一段」,最後才鑽進那一小段的 log。這比一出事就跳進 log 大海撈針有效太多。這個「由粗到細」的收斂,跟我在 K8s 排障講的 get→describe→logs 漏斗是同一種思維——好的排障不是翻得快,是每一步都在縮小範圍。

observability 的真價值,是回答你「當初沒想到」的問題

monitoring 和 observability 的那條線,我越做越覺得重要。Monitoring 能告訴你「你當初設想的那些壞法,發生了沒」——但 Production 真正咬你的,幾乎都是你沒設想到的壞法。所以我現在評估一套觀測,不只看「儀表板漂不漂亮」,而是問一句更狠的:當一個我從沒預期的問題發生時,我手上的資料夠不夠讓我現場問出答案? 這就是為什麼三支柱的訊號要夠豐富、標籤要夠細(尤其 traces 和 high-cardinality 的資料)——不是為了平時好看,是為了那個你沒準備的半夜,還能靠它把真相問出來。能回答預料之外的問題,才叫可觀測。

「一塊玻璃」不是為了美觀,是為了在壓力下還能思考

Grafana 把三支柱收進「一塊玻璃」,這件事的價值,我是在一次事故當下才真的體會到的。事故現場,人腦的頻寬窄得可怕。如果 metrics 在一個系統、logs 在另一個後台、traces 又要開第三個工具,你會在最需要冷靜思考的時刻,把注意力耗在「切視窗、換 context、對時間戳」這些破碎的摩擦上。LGTM 把它們收進一個 Grafana、還能從一個指標尖峰直接跳到對應的 trace 和 log,價值不是「看起來整齊」,是事故當下少一層摩擦、讓有限的腦力用在判斷上。這也呼應了上一個系列的收尾——一塊玻璃,是小團隊能扛住大平台的關鍵。而這一切的終點,始終不是「看到」,是在對的時間、做對的事。下一篇,先把那塊玻璃 Grafana 本身講清楚。