可觀測性架構 — Grafana LGTM Stack
內部工程文件
flow:apps(OTel SDK / exporters)→ Alloy → { Mimir · Tempo · Loki } → Grafana · tenancy:每次寫入/讀取都帶 X-Scope-OrgID · 互動原版 ↗
0 · 全貌 — 誰做什麼
Grafana Alloy — 收集器
第一線的 agent。一個二進位檔即可抓取、接收、處理並轉送 metrics、logs 與 traces — 取代 Prometheus agent + Promtail + OTel Collector。
- 在所有遙測產生處執行(DaemonSet / systemd)
- 在此做過濾與 relabel,直接控制後端成本
- 以 WAL 緩衝,後端中斷不會丟資料
- 在所有資料上蓋 tenant 身分(X-Scope-OrgID)
| protocol | in: OTLP, scrape, file/journald · out: remote_write, OTLP, Loki push |
Grafana Mimir — metrics
可水平擴展、多租戶的 metrics 儲存,同時是 PromQL 查詢引擎。Grafana 送 PromQL,Mimir 執行 — 用於 TPS、延遲、CPU/記憶體、SLO。
- Prometheus 相容:可直接作為 remote_write 目標
- 長期保留在物件儲存(以年計,而非週)
- 同時執行 recording/alerting rules(ruler)+ Alertmanager
- 跨 tenant 可擴展到 10 億以上活躍 series
| protocol | query: PromQL · ingest: remote_write |
Grafana Tempo — traces
分散式追蹤後端,同時是 TraceQL 查詢引擎。把每個 span 便宜地存進物件儲存 — 支撐請求瀑布圖與瓶頸分析。
- 後端不需取樣:物件儲存便宜到可以保留 100%
- TraceQL:依 duration、屬性、結構搜尋 spans
- metrics-generator 從 traces 導出 RED metrics 與 service graphs 到 Mimir
- Trace ID 是三種訊號之間的關聯鍵
| protocol | query: TraceQL · ingest: OTLP |
Grafana Loki — logs
日誌聚合儲存,同時是 LogQL 查詢引擎。只索引 labels(不做全文),所以便宜;查詢時平行 grep chunks — 關鍵字與錯誤碼搜尋。
- 「像 Prometheus,但用於 logs」— 同一套 label 模型
- 極小的 index → 比全文日誌儲存便宜 10–100 倍
- LogQL 也能從 logs 算出 metrics(例如錯誤率)
- Log 行帶 trace ID → 一鍵跳到 Tempo
| protocol | query: LogQL · ingest: /loki/api/v1/push |
Grafana — UI
統一的視覺化層。自身不存遙測 — 把 PromQL/TraceQL/LogQL 送到三個後端,渲染儀表板、Explore 與告警。
- 一個 UI 涵蓋三種訊號並做它們之間的關聯
- Exemplars:圖上的延遲尖峰 → 背後那條 trace
- Derived fields:log 行中的 trace ID → Tempo 瀑布圖
- 全組織的儀表板、值班視圖、SLO 報表
| protocol | speaks PromQL · TraceQL · LogQL over HTTP |