Apache Zipkin 监控

免费使用此 InfluxDB 集成

Apache Zipkin 是一个分布式跟踪系统，它帮助收集微服务架构中解决延迟问题所需的时间数据。它负责收集和查找这些数据，并基于 Google Dapper 论文。

Zipkin 用户界面表示一个依赖图，展示了在什么时间有多少跟踪请求通过了每个应用程序。这可以帮助您识别聚合行为，突出显示错误路径或对已弃用服务的调用等。部分数据将为您汇总，您还可以根据服务、操作名称、标签等属性进行搜索，甚至可以查看您想深入了解的事件持续时间。

为什么使用 Apache Zipkin 的 Telegraf 插件？

Apache Zipkin Telegraf 插件收集微服务架构中解决延迟问题所需的重要跟踪和时标数据。它以固定时间间隔收集 Zipkin 数据格式发送的跟踪客户端的跨度，将它们转换为 Telegraf 的内部数据格式，并将这些数据写入 InfluxDB 实例。当然，您可以在 InfluxDB 中查询这些数据以了解您的微服务的行为。

如何使用 Apache Zipkin Telegraf 插件收集您的跟踪

Apache Zipkin Telegraf 插件具有简单的配置，用于定义跟踪数据的路径，并可以接受 JSON 或 thrift 格式的跟踪数据。该插件使用标签和字段来跟踪跟踪数据。

• TRACE：是一组共享单个根跟踪的跟踪。通过收集共享相同 traceId 的所有跟踪来构建跟踪。
• SPAN：是一组对应特定远程过程调用的注解和二进制注解。
• Annotations：对于每个跟踪的注解和二进制注解，都会输出一个度量并记录请求开始和结束的时间点。

注解可能具有以下值

• CS（客户端开始）：跟踪的开始，当发出请求时。
• SR（服务器接收）：服务器接收请求并开始处理网络延迟和与客户端开始（CS）不同的时钟抖动。
• SS（服务器发送）：服务器完成处理，将请求发送回客户端；处理请求所需的时间与服务器接收（SR）不同。
• CR（客户端接收）：跟踪的结束；客户端从服务器接收响应，该注解标志着 RPC 完成。

需要注意的是，截至 2020 年，Apache Zipkin Telegraf 插件仍被视为实验性的。这意味着其数据模式（更不用说其他属性）可能会根据其实际应用场景和 OpenTracing 标准的发展在未来发生变化。

话虽如此，Apache Zipkin Telegraf 插件的配置过程非常简单。只需将以下命令中的默认值替换为您部署的相关值。注意，如果未设置“Content-Type”，则插件将假设其为 JSON 格式。

[[inputs.zipkin]]
    path = "/api/v1/spans" # URL path for span data
    port = 9411 # Port on which Telegraf listens

使用 Apache Zipkin Telegraf 插件收集的跟踪看起来像什么？

以下显示了您在 InfluxDB 数据格式中跟踪的结构

标签

• "id"：跟踪的 64 位 ID。
• "parent_id"：与特定子跟踪相关联的 ID。如果没有子跟踪，则父 ID 设置为 ID。
• "trace_id"：特定跟踪的 64 或 128 位 ID。跟踪中的每个跟踪都共享此 ID。将高和低部分连接起来并转换为十六进制。
• "name"：定义一个跟踪

注解具有以下附加标签

• "service_name"：定义一个服务
• "annotation"：注解的值
• "endpoint_host"：监听端口与 IPV4 连接；如果不存在端口，则不会连接。

二进制注解具有以下附加标签

• "service_name"：定义一个服务
• "annotation"：注解的值
• "endpoint_host"：监听端口与 IPV4 连接，如果不存在端口，则不会连接
• "annotation_key"：描述注解的标签

字段

• "duration_ns"：跟踪开始和结束之间的时间，以纳秒为单位。

项目 URL   文档