#observability

黃金路徑:由粗到細,一路「點」過去 ① Metric:有沒有 ↑ exemplar = trace_id 先看到「痛」 ② Trace:在哪一段 紅色那段 = 慢/error 縮到哪個服務、哪段 ③ Log:是什麼 info handling req error NPE at line 42 info retry ok 都帶同一個 trace_id 看到根因那一行 trace_id trace_id 三步都是「點」,不是「查」:看有沒有 → 看在哪 → 看是什麼

關聯:從一個尖峰,點到那一行 log

· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #8

整個系列從第一篇的黃金路徑就一直押著一句:metric 看有沒有、trace 看在哪、log 看是什麼,由粗到細。但我一直跳過最關鍵的一步——這三格之間,到底怎麼「跳」過去?Tempo 那篇說「找 t…

#observability#grafana#correlation

告警的狀態機:for 把短暫抖動吸收掉 查詢值 vs 門檻(每個 interval 評估一次) 門檻 短暫尖峰(< for) 持續超標(≥ for) Normal 超門檻 Pending在 for 期間持續觀察 撐過 for Firing 送通知 沒撐過 for → 回 Normal(不 page) for 是抗抖動閥:短暫尖峰在 Pending 就被吸收,只有真正持續的問題才會吵醒你

Grafana 告警:從看見到行動

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #7

這系列從第一篇就一直押著一句話——觀測的終點不是「看到」,是「行動」。前面六篇把「看到」講完了:三支柱怎麼存、怎麼查、怎麼進來。這篇補上最後那一哩、也是整個系列的 payoff——告警(Alertin…

#observability#grafana#alerting

✗ 直連:M × N 條耦合 app 1 app 2 app 3 Mimir Loki Tempo 每個 app 都要懂每個後端(位址/格式/重試) 換一個後端 → 改「所有」app ✓ 經過 collector:M + N 條 app 1 app 2 app 3 OTLP 一種協定 Collector(Alloy)批次・重試・脫敏・路由 Mimir Loki Tempo 換後端 → 只改 collector 設定,app 一行不動 M 個 app × N 個後端 → M + N:app 只認一種協定(OTLP),後端只面對 collector

採集層:資料怎麼進來——OpenTelemetry 與 Alloy

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #6

三支柱講完了,但有個前提一直被我跳過:訊號要先「進得來」,才有得看。第一篇資料流圖中間那格「採集層」,這篇把它拆開。兩個主角:OpenTelemetry(統一三種訊號的標準)與 Grafana All…

#observability#opentelemetry

一個請求的 trace:spans 排在時間軸上(waterfall) gateway auth checkout payment← 600ms 瓶頸 inventory db write 05001000 ms metric 只說「checkout 慢」;trace 指出是 payment 那 600ms —— 這是 metric/log 給不了的「在哪一段」

追蹤與 Tempo:一個請求走過的路

· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #5

三支柱最後一個:traces。它補的是 metric 和 log 之間那個最關鍵的洞——「在哪一段?」 Metric 告訴你「checkout 慢」,但一個請求橫跨了八個服務,到底卡在哪一 hop?L…

#observability#tracing

Loki 的兩步查詢 {service=checkout}|= "timeout" ① label 索引小而快 → 縮到幾個 chunk(只索引這個) ② grep 那小堆原始 chunk存 object storage・不索引全文暴力掃,但範圍已很小 ELK:索引全文每行都建全文索引 → 任意全文秒搜但索引巨大、RAM 貴 Loki:只索引 label先用 label 縮小、再 grep便宜到能存海量 log 賭注:你多半已知道要看哪個 service、哪段時間 → 先縮再 grep,夠用又便宜

日誌與 Loki:只索引 label,不索引全文

· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #4

三支柱第二個:logs。而 Loki 最該懂的一件事,是它一個很聰明、很省的設計選擇——它不像傳統 log 系統(ELK)那樣索引全文,而是「像 Prometheus 一樣只索引 label」。這個選…

#observability#logging

cardinality:series 數 = 每個 label 基數的乘積 http_requests_total{...} ✓ 低基數 labels service(3) × method(4) × status(5) = 60 條 series Prometheus 輕鬆扛 ✗ 多加一個高基數 label … × user_id(100 萬) = 6000 萬條 series 💥 記憶體被吃光,Prometheus 暴斃 label 只放低基數維度;高基數(user_id / request_id / email / URL)丟去 logs / traces

指標與 Prometheus:時序、pull、PromQL 與 cardinality 的坑

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #3

三大支柱進第一個,也是骨幹:metrics。它是你「有沒有問題」的第一道防線,也是後面告警和 SLO 的底層數字。而 metrics 世界的事實標準,是 Prometheus。這篇講它的資料模型、為什…

#observability#prometheus

Grafana 只查不存:資料在 data source Grafana(一塊玻璃)只存 dashboard / 設定,不存資料 panel:錯誤率 panel:延遲 p99 panel:錯誤 log 資料真正住這裡 ↓ Prometheus / Mimir Tempo Loki PromQL trace query LogQL 關掉 Grafana,資料一點不少(它在 data source);Grafana 只是「問」,不是「存」

Grafana:一塊玻璃,只查不存

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #2

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

#observability#grafana

三大支柱:各答一個問題 Metrics(指標)→ Prometheus / Mimir 有沒有問題?多嚴重? 數字時序・可聚合便宜・可長期存但沒有細節 Traces(追蹤)→ Tempo 在哪個服務?哪一段慢? 一個請求的完整路徑跨服務串起來 Logs(日誌)→ Loki 那裡到底發生什麼? 事件的完整細節量大・貴・難聚合 排障黃金路徑:由粗到細,逐步收斂 metric:有沒有→trace:在哪→log:是什麼

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

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #1

一個系統可不可靠,先看你看不看得見它在幹嘛。這系列講 Grafana 的 LGTM 這套可觀測性工具怎麼把「看見」做到位。第一篇立好整個系列的框架:monitoring 和 observability…

#observability#grafana