📚 课程目录第3章 Trace数据采集方案

Trace 数据采集方案：日志埋点、Agent 无侵入与采样策略

现象识别：为什么需要精确的 Trace 数据？

在线上故障排查中，第一道工序是现象识别。当报警或用户反馈出现高延迟、错误率飙升时，运维和研发必须尽快还原请求路径。然而，若缺乏完整的调用链数据，问题往往只能靠猜测。以下典型场景直接催生了 Trace 数据采集的需求：

慢调用根因未知：某接口 P99 延迟从 200ms 飙升至 2s，但无法判断是数据库慢查询、下游依赖超时还是自身业务逻辑问题。
异常传播链条断裂：收到异常堆栈时只知道最终失败节点，中间经过的网关、微服务节点全部丢失。
请求量突增下的资源竞争：并发数上升导致线程池耗尽，但缺乏每个请求的耗时构成，难以定位瓶颈。

这些现象倒逼我们建立一套能低成本、低侵入、高覆盖率的 Trace 数据采集方案。本章围绕三种核心采集手段展开，帮助你在“数据采集”环节做出正确选型。

数据采集：三种主流方案的对比与选型

  核心原则：采集方案必须在数据完整性、性能损耗和运维复杂度之间取得平衡。没有银弹，只有最适合业务场景的组合。

1. 日志埋点方式（侵入式）

通过在业务代码的关键路径（函数入口/出口、RPC 调用前后、数据库操作等）手动插入日志语句，携带 TraceId、SpanId、时间戳等上下文信息。这是最传统也是最灵活的方式。

优点：开发者可精确控制采集内容，信噪比高；与业务逻辑强绑定，易于附加自定义业务标签。
缺点：对代码有侵入性，需要修改已有代码；容易遗漏埋点或不一致；后期维护成本随系统规模线性增长。

典型日志埋点示例（Java SLF4J + MDC）：

// 在入口处生成 TraceId 并放入 MDC
MDC.put("traceId", TraceUtils.generateTraceId());
MDC.put("spanId", TraceUtils.generateSpanId());

// 业务逻辑执行后打印耗时
long start = System.nanoTime();
try {
    // 调用下游服务
    Order order = orderService.getOrder(orderId);
    logger.info("getOrder success, orderId={}, cost={}ns",
                orderId, System.nanoTime() - start);
} catch (Exception e) {
    logger.error("getOrder failed, orderId={}, cost={}ns",
                 orderId, System.nanoTime() - start, e);
} finally {
    MDC.clear();
}

2. Agent 无侵入采集（非侵入式）

利用 Java Agent + byte-buddy 或 eBPF 等技术，在运行时通过字节码织入或内核探针自动拦截指定类/方法，无需修改业务代码即可生成 Trace 数据。

优点：对业务完全透明，无需开发参与；可统一控制采集范围和开关；适合改造意愿弱或历史遗留系统。
缺点：字节码增强可能带来兼容性风险（如某些框架升级后织入点失效）；大量无差别采集会放大性能开销；无法获取纯业务层语义（如密码脱敏等）。

常见 Agent 配置（以 SkyWalking 为例，部分参数）：

agent.service_name=my-service
agent.instance_name=my-instance-001
collector.backend_service=127.0.0.1:11800

# 采样配置：单机 QPS 超过 1000 时按 10% 采样
agent.sample_rate=1000:10

3. 采样策略：平衡精度与开销

无论采用哪种采集方式，全量采集都会在高速流量下压垮存储和网络。必须引入采样策略。两种基础策略对比：

策略类型	工作原理	适用场景	风险
固定采样	以固定比率（如 1% 或 10%）随机丢弃/保留 Trace	流量平稳、资源预算固定的环境	低流量时可能漏掉“孤悬”的慢请求；统一比例无法自适应峰值
动态采样	根据延迟、错误率、QPS 等实时指标自动调整采样率，异常时提升采样，正常时降低	流量波动大、需要对异常场景高保真的系统	实现复杂度高；需要对自适应算法进行调参

常见陷阱：固定采样率过低（如 0.1%）时，故障链路被采到的概率极低，导致“明明系统出问题，Trace 却一个都没留下来”。建议在关键服务（支付、登录）上保底使用动态采样，并设置最低采样率（如 0.5%）。

三种方案在问题排查中的定位

上述方案并非互斥，实际生产环境通常组合使用：Agent 无侵入方案负责通用 RPC、HTTP、DB 调用等标准化链路的全量采集（配合动态采样降开销），日志埋点负责业务核心路径的精细化记录，采样策略作为全局调节阀。在问题排查流程中，数据采集阶段的目标是：在最短时间内，以最低影响，获取到足以支撑原因定位的 Trace 明细。

为了直观理解三种采集方案的关系与信息流，下图展示了从应用系统到 Trace 数据存储的采集链路：

原因定位与修复动作中的采集决策

当数据采集到位后，问题排查进入原因定位阶段。此时采集方案的选型直接影响定位效率：

日志埋点能提供业务层参数（如订单号、用户ID），帮助快速关联上下文，但若埋点遗漏则需回滚代码追加。
Agent 无侵入可自动捕获所有标准调用，适合跨服务链路还原，但在复杂异步场景（如消息队列）中可能丢失传递上下文。
采样策略决定了问题发生时是否留有数据：固定采样可能刚好漏掉故障，动态采样则会在错误率升高时自动“聚焦”异常样本，大大提高命中率。

实战建议：在排查线上问题前，先检查采样率及最近5分钟的采样记录数。若发现采样率过低或样本数量异常低，应优先调整采样策略至动态模式，再重新复现问题。

复测与预防：固化采集基线

修复补丁上线后，需要复测验证 Trace 数据是否如期生成且未引入额外性能开销。建议建立以下预防机制：

采样率监控告警：当固定采样率偏离设定值超过20%或动态采样率触发“全量采集”阈值时告警。
埋点覆盖率检查：每次代码变更后，通过自动化测试验证核心入口是否具备 Trace 埋点。
Agent 兼容性回归：中间件升级后，在预发环境跑全量用例，确保 Agent 织入不产生报错。

通过将采集方案纳入 CI/CD 流水线，可以提前发现因代码变更导致的采集断裂，避免问题再次出现时无数据可用。