在一个微服务分布式架构的系统中,可能存在复杂的、深层的层层服务调用关系,大致如下图
如果某个环节出问题,在海量的日志中定位问题是很痛苦的,于是就有了调用链追踪系统,比较有名的是:Jaeger和Zipkin。本篇文章主要介绍Jaeger
Jaeger的组成部分
Instrumentation SDKs: 集成到应用程序和框架中以捕获跟踪数据的库。 从历史上看,Jaeger 项目支持使用各种编程语言编写的自己的客户端库。 它们现在被弃用,取而代之的是 OpenTelemetry
Jaeger Agent: Jaeger 代理是一个网络守护程序,用于侦听通过 UDP 从 Jaeger 客户端接收到的 span。 它收集成批的它们,然后将它们一起发送给收集器。 如果 SDK 被配置为将 span 直接发送到收集器,则不需要代理
Jaeger Collector: Jaeger 收集器负责从 Jaeger 代理接收跟踪,执行验证和转换,并将它们保存到选定的存储后端
Storage Backends: Jaeger 支持各种存储后端来存储跨度。 支持的存储后端有 In-Memory、Cassandra、Elasticsearch 和 Badger(用于单实例收集器部署)
Jaeger Query: 这是一项服务,负责从 Jaeger 存储后端检索跟踪信息,并使其可供 Jaeger UI 访问。
Jaeger UI: 一个 React 应用程序,可让您可视化跟踪并分析它们。 对于调试系统问题很有用。
Ingester: 只有当我们使用 Kafka 作为收集器和存储后端之间的缓冲区时,ingester 才是相关的。 它负责从 Kafka 接收数据并将其摄取到存储后端。 更多信息可以在官方 Jaeger Tracing 文档中找到。
在go-zero中使用
在每个服务的配置文件中添加如下配置,其中article-rpc
是服务名称
Telemetry:
Name: article-rpc
Endpoint: http://localhost:14268/api/traces
Sampler: 1.0
Batcher: jaeger
访问 Jaeger UI
http://localhost:16686/
参考
https://blog.csdn.net/zuiyijiangnan/article/details/103836060