Jaeger 构建的目的是能够以弹性方式摄取海量数据。为了更好地利用可能导致延迟的资源，例如存储或网络通信，Jaeger 会对数据进行缓冲和批处理。当生成的 Span 数量超过 Jaeger 安全处理能力时，Span 可能会被丢弃。然而，默认设置可能并不适用于所有场景。

由于 Jaeger v2 基于 OpenTelemetry Collector，Collector 扩展文档 中的大部分建议也适用于 Jaeger。

虽然对单个组件进行性能调优很重要，但 Jaeger 的部署方式对于获得最佳性能可能起决定性作用。

伸缩 Collector

利用您平台的自动伸缩能力：jaeger-collector 几乎可以实现水平伸缩，以便按需添加和移除更多实例。

当您的平台提供自动伸缩能力时，建议添加 jaeger-collector 实例，或者当启动/停止 jaeger-collector 实例比更改现有运行实例更容易时。当需要将 CPU 使用率分散到多个节点时，也推荐水平伸缩。

确保存储能够跟上

每个 Span 由 jaeger-collector 使用一个工作进程写入存储，该工作进程会被阻塞直到 Span 存储完成。当存储速度过慢时，被存储阻塞的工作进程数量可能会过高，导致 Span 被丢弃。为了帮助诊断这种情况，可以分析直方图 jaeger_collector_save_latency_bucket。理想情况下，延迟应该随着时间保持不变。当直方图显示大多数 Span 的处理时间随着时间变得越来越长时，这很好地表明您的存储可能需要引起注意。

考虑使用 Kafka 作为中间缓冲区

Jaeger 可以使用 Apache Kafka 作为 jaeger-collector 与实际后端存储（Elasticsearch, Apache Cassandra）之间的缓冲区。这非常适合流量高峰相对频繁（例如高峰时段流量）但存储在流量恢复正常后最终能够跟上的情况。有关此部署的详细配置信息，请参阅Kafka 页面。

除了性能方面的好处外，将 Span 写入 Kafka 对于构建用于从跟踪数据进行聚合和特征提取的实时数据管道也非常有用。

jaeger-collectors 仍然可以像直接写入存储一样进行伸缩。跟踪 ID 被用作 Kafka 分区的分片键，这样给定跟踪的所有 Span 都会落入 Kafka 主题的同一个分区中。每个 jaeger-collector 可以写入任何分区。

jaeger-ingesters 也可以根据需要进行伸缩以维持吞吐量。它们会自动在彼此之间协商并重新平衡 Kafka 分区。然而，运行的 jaeger-ingesters 数量不应超过 Kafka 主题中的分区数量，因为在这种情况下，一些 jaeger-ingesters 将会处于空闲状态。