乐趣区

关于运维:Grafana系列统一展示11Logs-Traces无缝跳转

系列文章

  • 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 字段, 属于开发对日志格局布局地比拟好了. 这使得运维侧配置跳转逻辑简略了很多.
更多状况下, 是要联合 cluster namespace app pod 等字段 /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 编写.

退出移动版