OpenTelemetry Java Agent采集追踪时关键指标下降15%的问题排查

问题描述 #

我们在评估OpenTelemetry Java Agent采集追踪数据时，通过JMeter对仅含一个模拟API的简单Dropwizard REST应用做了性能测试，结果显示：

• 延迟、每秒请求数（QPS）、堆内存利用率均出现约15%的下降
• CPU占用基本保持不变

当前启动配置 #

java -Xms3g -Xmx4g -javaagent:./opentelemetry-javaagent.jar 
-Dotel.instrumentation.common.default-enabled=false 
-Dotel.instrumentation.experimental.span-suppression-strategy=span-kind 
-Dotel.traces.sampler=traceidratio 
-Dotel.traces.sampler.arg=0.01 
-Dotel.bsp.max.export.size=1024 
-Dotel.bsp.max.queue.size=4096 
-Dotel.bsp.schedule.delay=30000ms 
-Dotel.logs.exporter=none 
-Dotel.metrics.exporter=none 
-Dotel.instrumentation.jetty.enabled=true 
-Dotel.instrumentation.apache-httpclient.enabled=true 
-Dotel.service.name=root-service 
-Dotel.exporter.otlp.endpoint=http://<ip>:4317 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=40002 
-Dcom.sun.management.jmxremote.local.only=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false 
-jar root-service-1.0-SNAPSHOT.jar server /home/user/apps/config/config.yml

注：仅启用了Jetty和Apache HTTP Client的instrumentation。

问题解答 #

1. 是否存在配置错误？ #

当前配置没有明显的语法或逻辑错误，但部分参数设置有优化空间，并非错误，调整后可进一步降低性能影响。

2. 为何延迟会受影响？ #

延迟上升主要来自以下同步开销：

• 字节码增强的拦截逻辑：Agent通过字节码注入对Jetty和Apache HTTP Client的关键方法做拦截，每个请求都会执行上下文创建、采样判断、ThreadLocal存取等操作，直接增加请求处理时间。
• 采样判断的固定开销：即使设置0.01的低采样率，每个请求仍需执行traceId比率采样的判断逻辑，这部分同步操作会累积延迟。
• 上下文存储的开销：Agent用ThreadLocal存储追踪上下文，高并发场景下ThreadLocal的存取会带来上下文切换和内存开销，间接拉长延迟。
• 队列累积的间接影响：BSP导出器的30秒调度延迟可能导致Span队列（最大4096）在高并发下被占满，触发临时阻塞逻辑影响请求处理。

3. Agent是否执行了高开销操作？ #

Agent没有明显的高CPU开销操作（与你观察到的CPU占用不变一致），但存在同步的内存与延迟开销：

• Span与上下文对象的创建：即使采样率低，仍会有部分Span被创建，加上上下文对象分配，会增加堆内存消耗，导致GC频率上升，间接影响延迟。
• 方法拦截的固定开销：对Jetty请求处理链的关键方法拦截，会增加方法调用层数和执行时间，累积到每个请求上就体现为延迟上升。

4. 如何将性能影响降至最低？ #

可从以下维度优化：

• 优化采样策略：
  • 用parentbased_traceidratio替代traceidratio采样器，避免对无父Span的请求重复执行采样判断，降低同步开销。
  • 若业务允许，可进一步降低采样率（如0.005），减少Span创建量。
• 调整Span抑制策略：
  • 尝试使用otel.instrumentation.experimental.span-suppression-strategy=none，配合otel.instrumentation.jetty.excluded-methods排除不必要的Jetty内部方法拦截，减少无用Span生成。
• 优化导出配置：
  • 缩短otel.bsp.schedule.delay至5000ms左右，避免队列长时间累积Span导致内存占用过高，降低GC压力。
  • 若导出链路稳定，可适当调小otel.bsp.max.queue.size至2048，减少内存占用。
• 精简instrumentation：
  • 通过otel.instrumentation.common.enabled-instrumentations确认仅启用Jetty和Apache HTTP Client相关的instrumentation，排除隐含启用的其他组件。
• 调整Agent性能参数：
  • 增大otel.instrumentation.common.cache.max.size（默认1000），缓存常用Span元数据，减少重复计算。
  • 启用otel.context.propagation.cache.enabled=true，缓存上下文传播数据，降低ThreadLocal存取开销。
• JVM与GC优化：
  • 切换到ZGC或Shenandoah GC，降低GC停顿时间，缓解堆内存下降带来的影响。
  • 适当增大堆内存（如Xmx5g），减少GC频率。
• 升级Agent版本：
  • 升级到最新版OpenTelemetry Java Agent，新版本通常会修复性能瓶颈，优化字节码增强逻辑。

内容的提问来源于stack exchange，提问作者Avinash Vundyala