核心是统一注入并跨编排节点传播标准Trace Context，覆盖HTTP、消息队列、定时任务等全路径，在异步无状态组件中显式提取重建上下文，并按编排特征定制采样策略。
多服务编排场景下实现分布式链路追踪采集，核心是让整个调用链路中的每个环节——无论是服务网关、工作流引擎（如temporal、cadence）、函数计算（如openfaas、aws lambda），还是自定义编排逻辑——都能生成、传递并上报标准的追踪上下文。不能只依赖“服务间http调用”这一种路径，必须覆盖异步消息、定时任务、状态机跳转等编排特有模式。
统一注入 Trace Context 到编排起点
所有外部请求进入编排系统时（如API网关调用Workflow API、MQ消息触发编排任务），必须生成初始 Trace ID 和 Span ID，并写入可透传的上下文载体中：
- HTTP 请求：通过 traceparent（W3C 标准）头注入，例如
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 - 消息队列（Kafka/RabbitMQ）：将 traceparent 封装为消息头（headers）或嵌入 payload 的 metadata 字段，避免污染业务数据
- 定时调度器（如Quartz、Airflow DAG）：在触发任务前主动创建根 Span，并把 Context 注入到任务执行参数中
跨编排节点传播 Span 上下文
编排引擎本身不是“透明管道”，它需要主动参与追踪链路构建：
- 对每个子任务（如调用微服务A、执行SQL、触发Lambda）创建独立 Span，设置正确的 parent span ID 指向上游编排节点
- 若编排逻辑含条件分支（if/else）、并行分支（fork/join）、重试循环，需为每条路径生成带唯一 Span ID 的子 Span，避免 ID 冲突或丢失
- 使用 OpenTelemetry SDK 的 Context propagation 工具（如
otelcontext.ContextWithSpan）显式携带上下文，不依赖自动注入（自动注入在非HTTP场景常失效）
适配异步与无状态组件
Serverless 函数、事件驱动服务等无长连接组件，需在冷启动时从输入中提取 traceparent 并重建 Context：
- AWS Lambda：从
event.headers或event["headers"]中解析 traceparent，用otel.TraceContextPropagator.Extract()恢复 Context - Cloud Functions / Knative：检查 HTTP 触发的 request headers，或 Pub/Sub 消息的 attributes 字段
- 数据库操作（如编排中直接查MySQL）：使用支持 OpenTelemetry 的驱动（如 pgx/v5 + otel plugin），自动为 query 创建 Span 并关联父 Context
采样与数据导出策略要匹配编排特征
编排任务通常耗时长、步骤多、失败率波动大，通用采样策略容易漏掉关键链路：
- 对失败任务（status=error）、超时任务（duration > P99）、关键业务流程（如支付成功回调）启用 Always On 采样
- 对高频低价值任务（如心跳检测、日志归档）采用 TraceID Ratio 采样，降低数据量
- 所有 Span 必须导出到同一后端（如 Jaeger 或 OTLP Collector），确保跨编排/服务/函数的数据可关联查询
