三种追踪数据收集方式在侵入性与精确度之间的权衡

面对[[Dapper的Trace与Span概念及追踪系统面临的四项非功能挑战]]，三种数据 收集方式代表了侵入性与精确度之间不同的取舍点。基于日志的追踪（代表： Spring Cloud Sleuth）把Trace/Span信息直接输出到应用日志，随日志归集 过程汇聚、再反推出调用链拓扑——对网络消息零侵入、对应用极少侵入、性能 影响最低，但精度依赖日志归集本身（日志不追求绝对连续一致，见 [[日志收集从全能收集器退化为专用轻量客户端并只追求连续不追求完整]]）， 业务调用早已结束但日志可能延迟或缺失，导致追踪失真。基于服务的追踪 （代表：Zipkin、SkyWalking、Pinpoint）通过探针（Java应用常用Java Agent） 注入目标应用，探针本身就像一个寄生的小型微服务系统，有自己的注册、心跳， 通过独立的HTTP/RPC请求把调用信息发给追踪系统——消耗资源更多、侵入性 更强，换来的是不依赖日志归集、精确性和稳定性更有保证（如Pinpoint能做到 方法级、含参数返回值的详细追踪，但这种详细程度性能压力很大，一般只在 排错时开启，且Pinpoint本身运行还要维护一套HBase，比较重）。基于边车 代理的追踪是服务网格的专属方案，对应用完全透明（日志、服务本身都不用 改）、与编程语言无关（只要走网络就能被追踪）、有独立数据通道（追踪数据 通过控制平面上报，不干扰业务通信或日志），被认为是最理想的追踪模型， 局限是只能做到服务调用层面的追踪、做不到Pinpoint那种本地方法调用级别 的诊断，且服务网格本身还不够普及。

结构图：

flowchart LR
    A["基于日志<br/>Sleuth"] -->|零侵入网络/极少侵入应用/性能影响最低| A1[精度依赖日志归集, 易失真]
    B["基于服务探针<br/>Zipkin/SkyWalking/Pinpoint"] -->|注入探针, 消耗更多资源| B1[不依赖日志归集, 精确稳定]
    C["基于边车代理<br/>服务网格专属"] -->|对应用完全透明, 与语言无关| C1[只能服务调用级, 依赖服务网格普及]