Jaeger 的构建目标是能够以弹性方式摄入海量数据。为了更好地利用可能导致延迟的资源（如存储或网络通信），Jaeger 会对数据进行缓冲和批处理。当生成的 Span 数量超过 Jaeger 能够安全处理的量时，Span 可能会被丢弃。然而，默认配置并不适合所有场景。
由于 Jaeger v2 基于 OpenTelemetry Collector，Collector 扩展文档中的大部分建议也适用于 Jaeger。
虽然对各个组件进行性能调优很重要，但 Jaeger 的部署方式对于获得最佳性能可能起着决定性作用。
对 Collector 进行纵向和横向扩展
利用你的平台的自动扩展功能：jaeger-collector 几乎可以水平扩展，因此可以按需添加和移除实例。
当你的平台提供自动扩展能力时，或者启动/停止 jaeger-collector 实例比更改现有运行中的实例更容易时，建议添加 jaeger-collector 实例。当需要将 CPU 使用分散到各节点时，也适合进行水平扩展。
确保存储能跟上
Danger
下面提到的指标
jaeger_collector_save_latency_bucket在 Jaeger v2 中尚不可用。
每个 Span 由 jaeger-collector 使用一个 worker 写入存储，在 Span 被存储之前会阻塞该 worker。当存储太慢时，被存储阻塞的 worker 数量可能过多，导致 Span 被丢弃。为了帮助诊断这种情况，可以分析直方图 jaeger_collector_save_latency_bucket。理想情况下，延迟应该随时间保持稳定。当直方图显示大多数 Span 的处理时间越来越长时，这是一个很好的信号，表明你的存储可能需要关注。
考虑使用 Kafka 作为中间缓冲
Jaeger 可以使用 Apache Kafka 作为 jaeger-collector 和实际后端存储（Elasticsearch、Apache Cassandra）之间的缓冲。这非常适用于流量高峰相对频繁（高峰时段流量）但存储最终可以在流量恢复正常后赶上的场景。有关配置此部署的详细信息，请参阅 Kafka 页面。
除了性能方面的优势外，将 Span 写入 Kafka 对于构建实时数据管道来进行链路追踪的聚合和特征提取也很有用。
jaeger-collector 仍然可以像直接写入存储时一样进行扩展。链路追踪 ID 用作 Kafka 分区的分片键，因此给定链路追踪的所有 Span 最终都会进入 Kafka 主题的同一分区。每个 jaeger-collector 都可以写入任何分区。
jaeger-ingester 也可以根据需要进行扩展以维持吞吐量。它们会自动在彼此之间协商和重新平衡 Kafka 分区。但是，运行比 Kafka 主题中的分区数更多的 jaeger-ingester 是没有意义的，因为在这种情况下，一些 jaeger-ingester 将处于空闲状态。