#链路追踪性能开销

链路追踪为故障排查提供了巨大价值，但它不是免费的午餐。Trace 数据的采集、序列化和传输都会消耗 CPU 和内存资源；在高 QPS 系统下，这些开销可能成为性能瓶颈。

理解链路追踪的开销来源，是做出正确配置决策的前提。关键问题是：在什么量级下，追踪开销变得不可忽略？如何通过配置优化将开销降到最低？

#开销来源分析

链路追踪的开销分为四个层面：

Span 创建与销毁：每次调用自动埋点或手动埋点都会创建 Span 对象，涉及内存分配。频繁创建小对象会产生 GC 压力。对于 Java 应用，Span 创建的开销在纳秒到微秒级别，通常可忽略。

属性设置：为 Span 添加 Attributes、Events 会产生对象分配和字符串处理开销。每次 setAttribute() 都会涉及键值对的序列化和存储。优化建议是：避免在高频调用路径（如每请求处理器）中添加过多属性；使用预定义的 AttributeKey 避免重复创建。

Context 传播：在服务间传递 Trace Context 需要序列化 TraceID 和 SpanID，通过 HTTP Header 或消息属性传输。对于 HTTP 调用，这个开销通常小于 1ms；对于高并发小请求场景，Context 传播可能成为瓶颈。

数据导出：Span 数据需要序列化（JSON 或二进制）后发送到 Collector。序列化开销与 Span 大小（属性数量、事件数量）正相关；网络开销与 Span 数据量和发送频率正相关。

#开销量化

根据社区测试数据和公开基准测试（来源：OpenTelemetry 官方性能报告）：

数据说明：低 QPS 场景下（\<100 QPS），追踪开销几乎不可感知；中等 QPS 场景（1000 QPS），开销需要关注但通常可接受；高 QPS 场景（\>5000 QPS），开销会成为主要瓶颈，需要优化采样策略。

#优化策略

采样策略优化：这是降低开销最有效的手段。头部采样的开销最低（数据产生时即决定是否采样），尾部采样可以保留关键数据但实现复杂。对于大多数场景，1-5% 的采样率已经足够覆盖异常场景。

批量发送：Span 数据先缓存在内存中，达到一定数量或时间阈值后再批量发送到 Collector。批量发送减少网络往返次数，提高吞吐量。OpenTelemetry SDK 默认使用 BatchSpanProcessor。

压缩传输：Span 数据使用 Protobuf 序列化（相比 JSON 减少 50%+ 数据量），并启用 gzip 压缩传输（额外减少 30%+ 数据量）。

异步处理：Agent 接收应用数据后，通过异步队列发送给 Collector，应用代码无需等待网络 I/O。OpenTelemetry SDK 的 SpanProcessor 默认是异步的。