系列文章
- Grafana 系列文章
概述
如前文 Grafana 系列 - 統一展示 -1- 開篇所述, Grafana 可以了解所有相關的資料--以及它們之間的關系--對于盡快根治事件和確定意外系統行為的真正來源非常重要，Grafana 允許團隊在一個地方對所有的資料進行無縫的可視化和跳轉，
最典型的就是 Grafana Labs 的 LGTM 技術堆疊，包括：
- Loki(Logging)
- Grafana（可視化）
- Tempo(Tracing)
- Mimir(Metrics)
通過如下的技術細節，可以實作 Logging、Tracing、Metrics 的無縫可視化和跳轉：
- Metrics -> Logs: 基于服務發現和統一 labels
- Logs -> Metrics: 基于 LogQL 提取 Metric 指標
- Logs -> Traces: 基于衍生欄位 (fields) 或自動化的日志
- Traces -> Logs: 基于 labels
- Traces -> Metrics: 基于來自 spans 的 Metric 指標
- Metrics -> Traces: 基于 Prometheus 的 Exemplars.
具體如下圖：
即使沒有采用 Grafana Labs 的解決方案，也仍然能實作一定程度的無縫跳轉，
如：
- Logging 使用 EFK
- Tracing 使用 Jaeger
如果日志中也包括 trace_id, Name 至少可以通過 trace_id, 實作 Logs -> Traces 的無縫跳轉，
??Notes:
前提是: 日志中包括
trace_id相關欄位.
當然, 日志中就包含trace_id欄位, 屬于開發對日志格式規劃地比較好了. 這使得運維側配置跳轉邏輯簡單了很多.
更多情況下, 是要結合clusternamespaceapppod等欄位/label 進行查詢. (而非直接通過trace_id直接定位.)
實戰 Logs(ElasticSearch) To Traces(Jaeger)
??Notes:
實戰場景: 針對報錯日志, 定位到出錯的 Trace.
首先, 更新 ES 資料源配置, 增加 Data links 相關配置:
- Field:
trace_id(根據實際情況配置, 也可能是traceId等) - Internal link: ??, 并選擇一個 Trace(Jaeger) 資料源
- Query:
${__value.raw}
之后, 可以通過ES 日志快速搜索儀表板, 篩選出ERROR 日志, 點擊展開 details, 會發現 trace_id 會帶一個跳轉鏈接, 如下圖:
點擊后, 會直接跳轉到 Explore -> Jaeger 頁面, 并帶有出錯的 trace_id, 同時顯示鏈路拓撲和 trace 瀑布圖, 如下圖:
??????
總結
至此, 我們完成了一個非常簡單的, 從 Logs(ElasticSearch) 到 Trace(Jaeger) 的單向跳轉. 但已經會為我們分析問題提供較大的便利了.
如果需要實作 Metrics, Logs, Traces 三者的雙向跳轉, 那么在這三者的解決方案需要是特定的方案， 另外這三者的資料源、Dashboard 和 Query 中都需要有更多精細的配置，包括不限于：
- 上文提到的三者之間的聯動配置
- 各個資料源上配置 Data link、Derived fields、Exemplars、Trace to logs、Trace to Metrics 等
- 在 Dashboard 上添加 Text 等 Panel，并結合 Variable 用于更友好地跳轉
- 在 Panel 配置 panel link 用于更友好地跳轉
- ...
以此拋磚引玉，希望讀者可以做出更精美、實用的監控統一展示和無縫跳轉方案，
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術博客 EWhisper.cn 撰寫.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552534.html
標籤：其他
上一篇：QueryFailedError: Connection Terminated
下一篇：返回列表