没有什么比你终于找到完美的轨迹却发现你错过了关键跨度更令人沮丧的了。其实，对于新用户和运营商来说，一个常见的问题Jaeger流行的分布式跟踪系统是:“我所有的跨度都去哪儿了?”
在这篇文章中，我们将讨论如何诊断和纠正积家跨度摄取管道中每个元素的丢失跨度。我还强烈建议您查看Jaeger的官方文档性能调优，因为它涵盖了部分相同的领域。
Jaeger架构
在设置Jaeger时，有很多配置选项可用。在这篇文章中，我们将特别解决以下设置:
In Process客户端->积家代理->积家收集器-> Kafka ->积家Ingester -> Cassandra
我们主要在Grafana实验室使用Go，所以我bob电竞频道们将具体讨论积家Go客户端．此外，所有的指标都将被抓取、聚合和查询普罗米修斯．有关Grafana实验室如何使用Jaeger的更bob电竞频道多细节，请查看这篇博文．
F5是魔法
但首先!在深入到基础设施中试图拼凑丢失的跨度之前，请先刷新。
Jaeger UI经常会在后端找到与搜索条件匹配的跟踪，但它们还没有被完全摄取。这在最近的痕迹中特别常见。
F5之前:
F5之后:
如果刷新失败，那么就应该开始查看span摄取的不同元素，并尝试找出删除span的位置。
进程内客户端
我们将从负责生成跨度的过程开始，然后转向我们的后端，在我们前进的过程中检查指标。对于过程内指标，我们希望查看jaeger_tracer_reporter_spans_total．这个特殊的度量是由积家Go客户端并且可以告诉我们什么时候span被删除，然后才离开进程:
我们可以看到这里有一个下降跨度的尖峰洛基导致中断跟踪的组件。
节俭客户也应该向代理报告下降跨度。这些下降的跨度被暴露为度规jaeger_agent_client_stats_spans_dropped_total是积家特工自己做的两种都试试，看看哪种更适合你!
修复!
Jaeger客户端在将跨距发送到Jaeger代理时在队列中进行内部缓冲。删除跨度仅仅意味着您的进程填充队列的速度快于卸载它们的速度。解决这个问题的两个选择是:
使用环境变量增加队列大小JAEGER_REPORTER_MAX_QUEUE_SIZE．将代理移到流程附近。例如，您可以在同一台机器上运行它或在一个挎斗中运行它。
其他的可能性
不幸的是，在这一点上还有另一种更难诊断的可能性。默认情况下，您的进程将通过UDP使用Thrift Compact与代理通信。UDP是一种尽力而为的协议，有可能在代理或进程不知情的情况下丢弃数据包。在这种情况下，我建议咨询由类似工具发布的网络指标节点出口国．
此外，如果您的客户端更新了Thrift协议的最新更改，代理将打印jaeger_agent_client_stats_batches_received_total而且jaeger_agent_client_stats_batches_sent_total．这些值可用于确定批次是否在客户端和代理之间被删除。然而，这并没有得到普遍的支持。
代理
关于代理，我建议注意jaeger_agent_thrift_udp_server_packets_dropped_total指标。该指标将指示代理在转发到积家收集器时是否不能足够快地清除其队列。
修复!
如果你看到这个指标出现峰值，可以考虑:
增加队列大小。注意，不同的协议有不同的开关。大多数人将使用积家-紧凑型。
——processor.jaeger-binary。server-queue-size UDP服务器的队列长度(默认为1000)。server-queue-size UDP服务器的队列长度(默认为1000)。server-queue-size UDP服务器的队列长度(默认为1000)添加更多积家代理人以更好地分散负载或添加更多积家收集器以更快地消耗它们。
也值得检查其他指标，如jaeger_agent_client_stats_batches_received_total以确定到代理的流量是否不平衡。
收集器
Jaeger Collector也有一个队列，但有点不同，因为它依赖于外部后端，如Kafka、Elasticsearch或Cassandra。在这种情况下，我们要观察的度规是jaeger_collector_spans_dropped_total．Kafka通常非常快速地消耗跨度，因此在我们的基础设施中，这是最不可能看到跨度下降的地方之一。
修复!
现在你大概能猜到规律了。配置该队列!
有两个主要选项可以调整收集器队列的性能。在Grafanabob电竞频道实验室，我们将队列大小设置为10000，并将工作人员的数量设置为100 (YMMV)。
——收集器。num-workers int从队列中提取项目的工人数量(默认为50)——collector。queue-size int收集器的队列大小(默认为2000)如果您想尝试一下，有一个新选项允许您配置收集器队列可用的最大内存量。此选项可能会导致CPU升高，但附带发布跨度大小指标的额外好处。
收集器。queue-size-memory uint (experimental) MiB中用于动态队列的最大内存大小。如果你在这里有持续的问题，我也会考虑检查jaeger_collector_save_latency柱状图和调整相应的后端。
摄取
摄取器是Jaeger基础设施的一部分，它没有内部队列，因为它依赖Kafka进行队列。摄取器中的错误和后端延迟通常只是减慢摄取，但不一定会导致跨度下降。对于摄取器，我主要观察错误和延迟，以确保跨度被及时插入到后端。在我们的例子中，这些是jaeger_cassandra_errors_total和jaeger_cassandra_latency_ok直方图。
另一个指标,jaeger_ingester_sarama_consumer_offset_lag，对于判断是否摄取器在Kafka队列上落后也很有用。
修复!
如果摄取器未能成功地将跨度卸载到后端，则需要研究后端指标和配置并进行相应调整。也许是时候扩大集群规模了?
总而言之:队列，队列，更多的队列
好吧，就是这样!如您所见，减少丢失的跨度通常是队列管理的问题。如果跨度被删除，您可以增加队列大小，减少管道中下一阶段的延迟，或增加下一阶段的容量。
这个指南绝对不是详尽的。Jaeger还提供了许多其他指标来帮助描述您的系统，并理解为什么跨度可能会下降。旋度的/指标端点，读取代码，并构建更好的仪表盘!
