目录
Apache Zipkin 是一个分布式跟踪系统，可帮助收集微服务架构中故障排除延迟问题所需的计时数据。它管理此数据的收集和查找，并且基于 Google Dapper 论文。
Zipkin 用户界面表示依赖关系图，该图向您显示在什么时间有多少跟踪请求通过每个应用程序。这对于识别聚合行为非常有用，突出显示错误路径甚至对已弃用服务的调用等内容。其中一些数据将为您汇总，您还可以根据服务、操作名称、标签甚至您想要仔细查看的事件的持续时间等属性进行搜索。
为什么将 Telegraf 插件用于 Apache Zipkin？
Apache Zipkin Telegraf 插件收集跟踪和时间戳数据，这些数据对于解决微服务架构中的延迟问题至关重要。它以 Zipkin 数据格式定期收集跟踪客户端发送的 span，将其转换为 Telegraf 的内部数据格式，并将此数据写入 InfluxDB 实例。当然，可以在 InfluxDB 中查询此数据以了解微服务的行为。
如何使用 Apache Zipkin Telegraf 插件收集跟踪
Apache Zipkin Telegraf 插件具有简单的配置，用于定义 span 数据的路径，并且可以接受 JSON 或 thrift 格式的 span。该插件使用标签和字段来跟踪来自 span 的数据。
TRACE：是一组共享单个根 span 的 span。跟踪是通过收集共享traceId的所有 span 构建的。SPAN：是一组注释和二进制注释，对应于特定的 RPC。Annotations：对于 span 的每个注释和二进制注释，都会输出一个指标，并记录请求开始和结束时的时间发生。
注释可能具有以下值
CS（客户端启动）：span 的开始，即发出请求时。SR（服务器接收）：服务器接收请求并将开始处理网络延迟和时钟抖动，这些抖动与客户端启动 (CS) 不同。SS（服务器发送）：当服务器完成处理后，它会将请求发送回客户端；处理请求所花费的时间与服务器接收 (SR) 不同。CR（客户端接收）：span 的结束；客户端从服务器接收响应，并且此注释认为 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"：span 的 64 位 ID。"parent_id"：与特定子 span 关联的 ID。如果没有子 span，则父 ID 设置为 ID。"trace_id"：特定跟踪的 64 位或 128 位 ID。跟踪中的每个 span 共享此 ID。高位和低位串联并转换为十六进制。"name"：定义 span
注释具有这些附加标签
"service_name"：定义服务"annotation"：注释的值"endpoint_host"：监听端口与 IPV4 连接；如果端口不存在，则不会连接。
二进制注释具有这些附加标签
"service_name"：定义服务"annotation"：注释的值"endpoint_host"：监听端口与 IPV4 连接，如果端口不存在，则不会连接"annotation_key"：描述注释的标签
字段
"duration_ns"：span 的结束和开始之间的时间（以纳秒为单位）。
