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-collector** 仍可以像直接写入存储时一样进行扩缩。跟踪 ID 用作 Kafka 分区的分片键，以便给定跟踪的所有 Span 都落在 Kafka 主题的同一分区中。每个 **jaeger-collector** 都可以写入任何分区。

**jaeger-ingester** 也可以根据需要进行扩缩以维持吞吐量。它们将自动协商并重新平衡它们之间的 Kafka 分区。然而，运行比 Kafka 主题分区数量更多的 **jaeger-ingester** 是没有意义的，因为在这种情况下，一些 **jaeger-ingester** 将会闲置。