Dapr是否真的无需修改应用代码即可实现分布式追踪？

针对两个核心疑问直接给出结论和实操说明：

1. Dapr是否仅能追踪经由sidecar处理的调用 #

结论是肯定的。
Dapr的分布式追踪能力完全构建在sidecar的流量处理逻辑之上：只有当请求的入站、出站路径经过Dapr sidecar时，sidecar才会自动完成W3C标准追踪上下文的注入、传播，生成对应调用链路的Span数据，最终上报到配置的追踪后端。它不会侵入应用进程内部做流量Hook，也不会捕获任何没有经过sidecar的直连流量，这是Dapr作为独立sidecar组件的核心设计逻辑，和常规服务网格的流量追踪实现逻辑一致。
官方示例里通过代码调用Dapr API实现追踪，只是触发sidecar流量处理的其中一种方式，并非唯一方式。

2. 存量直连应用接入可观测能力是否需要修改大量代码 #

绝大多数场景下不需要大量改代码，甚至可以做到完全零代码修改，可根据部署环境选择对应方案：

• 零代码接入：如果部署环境支持流量透明劫持（比如Linux环境用iptables、新版本Dapr支持eBPF劫持、Kubernetes集群下开启Dapr的流量自动注入配置），不需要修改任何应用代码，也不需要调整服务调用地址，所有进出应用的直连流量会被透明重定向到本地Dapr sidecar，sidecar会自动完成追踪上下文传播、链路数据生成，完全匹配官方文档描述的“无代码修改、无追踪厂商绑定”的效果。
• 低代码接入：如果环境因为安全、网络策略限制无法做透明流量劫持，需要的改动量也极小：不需要引入任何特定追踪系统的SDK，只需要保证服务调用时透传W3C标准的traceparent等追踪请求头即可。绝大多数主流的HTTP、gRPC框架都内置了W3C追踪头的自动传播能力，只需要打开对应配置项，不需要修改业务逻辑。只有当需要采集应用内部方法级别的自定义Span时，才需要补充少量埋点代码，这部分属于可选增强能力，不是跨服务链路追踪的必须项。

踩坑提示：测试时出现直连流量不进入追踪结果的情况，本质是没有配置透明流量劫持规则，不是Dapr能力与文档描述不符。默认部署下Dapr不会主动劫持应用的所有流量，只会处理显式发送到sidecar监听端口的请求。

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