在高并发场景接入 OpenTelemetry 时，全量采集必定导致 Collector 频繁 OOM 与存储雪崩。本文的核心结论：必须采用 loadbalancing 结合双层采样（头部概率 + 尾部兜底）架构，配合基于内存限额的批处理机制。同时，利用 OTel Agent 的 MDC 自动注入，并修正自定义线程池的 Context 传递，才能实现 100% 异常 Trace 捕获及 Trace-Log 精准关联。
某次核心网关服务（约 50k QPS）接入 OpenTelemetry（下文简称 OTel）后，监控告警迅速亮起红灯。部署在集群内的 OTel Collector 容器频繁发生 OOMKilled，Load Average 飙升至 40 以上，导致大面积的 Span 丢失。
查看 Collector 容器的报错日志，满屏的内存申请失败和连接重置：
2023-10-18T10:23:45.102Z error receiver/otlp error reading from server: read tcp 10.244.2.10:4317->10.244.3.15:58392: read: connection reset by peer
2023-10-18T10:23:46.001Z warn memorylimiter Memory usage is strictly above the limit. Dropping data. {"kind": "processor", "name": "memory_limiter", "usage": 4096, "limit": 4096}
单纯增加 Collector 的内存只是延缓死亡时间。分布式追踪工程化落地的核心难点，不在于如何生成数据，而在于如何克制地丢弃数据。
为什么单节点尾部采样（Tail Sampling）注定会触发 OOM？
为了保留请求报错（HTTP 5xx）和慢请求（Latency > 1s）的完整调用链路，很多团队会直接开启 OTel 的 tail_sampling 处理器。但尾部采样的底层逻辑是：必须等待一个 Trace 的所有 Span 收集完毕（或达到超时时间），才能做出是否保留的采样决策。
假设当前系统的全局 QPS 为 50,000，每个请求平均产生 10 个 Span，每个 Span 大小约 1KB。
如果 tail_sampling 的决策等待时间（decision_wait）设置为默认的 10 秒。那么 Collector 在内存中至少需要维持 10 秒的在途数据：
50,000 * 10 * 1KB * 10s ≈ 5GB
这只是理论上的最小内存。遇到网络抖动、流量突增或者垃圾回收（GC）停顿，内存占用会轻易突破 10GB。如果你只部署了几个 OTel Collector 实例，OOM 是必然结果。
更致命的是，在 Kubernetes 部署架构下，网关的请求会通过 Service 负载均衡随机打到后端的 OTel Collector 实例上。同一个 Trace 的不同 Span，可能会落在不同的 Collector 节点上。 这导致单节点的 tail_sampling 永远无法拼凑出完整的 Trace，最终因为等不到数据而将关键 Trace 判定为不完整并丢弃（即产生大量的孤儿 Span）。
破局：两层架构与基于 TraceID 的路由分发
要解决这个问题，必须对 Collector 的架构进行解耦，分为 Gateway Collector 和 Processor Collector 两层（基于 OpenTelemetry Collector Contrib v0.87.0）。
-
第一层：Gateway Collector（轻量级，只做路由） 接收所有 Agent 发来的全量数据，使用
loadbalancingexporter 根据trace_id进行哈希一致性路由，确保同一个 Trace 的所有 Span 被精确转发到第二层的同一个实例。 -
第二层：Processor Collector（重负载，做尾部采样） 接收到完整的 Trace 数据后，在内存中进行聚合与尾部采样决策。
Gateway Collector 核心配置片段
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
memory_limiter:
check_interval: 1s
limit_mib: 2048
spike_limit_mib: 512
exporters:
# 关键配置：根据 trace_id 进行一致性哈希负载均衡
loadbalancing:
protocol:
otlp:
tls:
insecure: true
resolver:
dns:
hostname: otel-processor-headless.monitoring.svc.cluster.local
port: 4317
routing_key: "traceID"
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter]
exporters: [loadbalancing]
Processor Collector 核心配置片段
在第二层，我们通过 tail_sampling 组合多种策略：保留所有的 Error 链路，保留耗时超过 1000ms 的链路，其余正常链路按 1% 概率采样。
processors:
tail_sampling:
decision_wait: 10s # 等待 Trace 收集完整的时间
num_traces: 100000 # 内存中最大维持的 Trace 数量
expected_new_traces_per_sec: 10000 # 预估新 Trace 速率，用于预分配内存
policies:
[
{
name: retain-errors,
type: status_code,
status_code: {status_codes: [ERROR]}
},
{
name: retain-slow,
type: latency,
latency: {threshold_ms: 1000}
},
{
name: retain-probabilistic,
type: probabilistic,
probabilistic: {sampling_percentage: 1} # 正常流量保留 1%
}
]
batch:
send_batch_size: 8192
timeout: 1s
exporters:
otlp/storage:
endpoint: jaeger-collector:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
# 必须严格遵守 memory_limiter -> tail_sampling -> batch 的顺序
processors: [memory_limiter, tail_sampling, batch]
exporters: [otlp/storage]
注意：memory_limiter 必须放在第一位进行自我防御，防止突发流量直接打死进程。
补齐可观测的拼图：Trace 与 Log 的强关联
仅仅收集到 Trace 是不够的。在实战排查中，我们需要通过 TraceID 精准检索到那一刻的业务日志。
对于 Java 应用，OTel Java Agent（v1.30.0+）默认会自动将 trace_id 和 span_id 注入到 MDC（Mapped Diagnostic Context）中。但这里有两个常见的踩坑点：
1. 日志格式未配置占位符
如果在 logback-spring.xml 或 log4j2.xml 中没有修改 pattern，打印出来的日志依然是匿名的。必须在 Pattern 中显式提取 MDC 的值：
<!-- Logback 示例 -->
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<!-- %X{trace_id} 和 %X{span_id} 是 OTel 默认注入的 Key -->
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [traceId=%X{trace_id} spanId=%X{span_id}] %logger{36} - %msg%n</pattern>
</encoder>
</appender>
2. 异步线程池导致上下文丢失
这是业务开发最容易忽略的痛点。当业务代码使用 CompletableFuture 或自定义的 ThreadPoolExecutor 时，由于 MDC 底层依赖 ThreadLocal，不同线程间无法自然继承，导致日志中的 traceId 突然断代变为空白。
不要企图去魔改 ThreadPoolExecutor。标准的做法是利用 OTel API 提供的 Context 进行上下文传播包装：
import io.opentelemetry.context.Context;
// 错误写法：在新线程中丢失 Trace 上下文
executor.submit(() -> {
log.info("Processing async task"); // 这里的日志 traceId 会是空的
});
// 正确写法：使用当前 Context 包装 Runnable
Runnable wrappedRunnable = Context.current().wrap(() -> {
log.info("Processing async task"); // 这里能准确关联到父级 TraceId
});
executor.submit(wrappedRunnable);
对于 Spring 的 @Async 注解，可以通过实现 TaskDecorator 并在配置类中注入，实现自动的上下文转移，这里不再贴冗长的 Spring 模板代码。
常见问题 (FAQ)
Q1：使用 tail_sampling 后，在 Jaeger UI 上偶尔还是会看到一些断掉的“孤儿 Span”，为什么？
A： 通常是因为服务优雅下线或 Collector 重启期间，上游数据流被打断。另一个常见原因是 decision_wait 设得太短。如果业务逻辑中有一个长达 15 秒的外部调用，而等待时间只有 10 秒，那么 10 秒后的 Span 就会变成孤儿。可以根据 99 线延迟适当拉长 decision_wait，但要做好内存预估。
Q2：如果不想部署复杂的 Collector 集群，只在客户端做头部采样（Head Sampling），有办法保留错误日志吗？
A： 纯头部采样是确定性采样（在请求刚进入时就决定是否采样），此时并不知道后续是否会报错。一种妥协方案是：客户端不全量采样，但利用 OTel 的 Span.current().recordException(e) 和业务全局异常处理器联动。但这只能记录到报错那一刻的 Span，无法回溯完整的调用链，这是头部采样的硬伤。
Q3：底层存储用 ElasticSearch 还是 ClickHouse？
A： 坚决推荐 ClickHouse。Trace 数据的特点是：海量写入、弱更新、固定维度的分析。ES 的倒排索引在应对数万 TPS 的 Span 写入时会产生极大的 CPU 和 IO 损耗，且磁盘占用通常是 CH 的 3-5 倍。借助开源的 jaeger-clickhouse 插件或者直接用 SigNoz 等原生基于 CH 的可观测产品，能大幅降低存储成本。
Q4：为什么加入了 memory_limiter，Collector 还是会被 OOMKilled？
A： 检查你的 limit_mib 和容器的 Limit 配置。通常建议 limit_mib 设置为容器内存 Limit 的 70%-80%。因为 Golang 的 GC 是有延迟的，memory_limiter 触发 GC 和拦截请求的瞬间，系统底层的实际物理内存占用可能会有个短暂的尖峰。如果不留缓冲，就会被内核直接杀掉。