零侵入链路追踪的价值，不是简单地多画出一条调用链，而是在没有统一插装的复杂环境中，还原真实发生的业务调用。一次用户支付，可能从负载均衡进入API网关，随后经过订单、账户、风控和支付服务，最终访问Redis、消息队列和数据库。任何一跳出现延迟或错误，都可能在最上游表现为接口超时，而真正的异常位置却隐藏在多层服务和基础组件之后。

传统分布式追踪通常需要应用生成Trace ID、Span ID和父子关系，再通过HTTP Header或者RPC元数据，将追踪上下文传播给下一个服务。对于已经完成标准化插装的应用，这种方式能够提供丰富的代码级链路；但如果请求经过未插装应用、异构语言、传统中间件、数据库或第三方系统，链路便可能出现断点。零侵入链路追踪要解决的，就是在业务无法统一插装的情况下，从真实运行行为中识别一次次调用，并尽可能将它们还原为完整的跨服务请求路径。

01 自动发现：先识别究竟是谁在通信

构建链路的第一步，不是立即生成Span，而是先回答“当前节点上运行了哪些应用，它们分别属于哪个服务”。优云的预研方案是进程外自动观测思路，通过进程、可执行文件、监听端口、容器运行时和Kubernetes元数据，识别需要观测的应用，而不是要求每个业务团队逐一修改启动脚本和接入采集组件。

在Kubernetes环境中，采集到的进程和网络连接还需要与Pod、Deployment、Namespace、Node和Service建立关联。由于容器IP可能随着重建和调度不断变化，仅依赖IP无法形成稳定的服务身份，平台需要结合工作负载名称、容器ID、命名空间、集群和环境信息，判断一次通信究竟属于哪个业务服务。当一个新服务上线或者实例完成扩容，只要进入被观测的运行环境，平台便可以发现其通信行为，并自动补充相应的资源和服务属性。

这种节点级自动发现机制，将可观测接入从“一个应用一个应用地配置转变为一个运行环境统一感知”。它不仅降低了新应用的接入成本，也为后续协议识别、链路生成和动态拓扑构建提供了统一的身份基础。

02 协议重建：从内核事件还原一次调用

应用之间进行通信，最终都需要经过Socket和Linux内核网络栈。eBPF程序可以挂载在关键系统调用、内核事件和用户态函数边界上，观察连接建立、数据发送、数据接收和连接关闭等行为，并记录进程、线程、连接、时间戳和数据方向等信息。但捕获网络字节流，并不等于获得一条可以直接分析的业务调用。

平台还需要通过协议解析能力识别HTTP、HTTP/2、gRPC、数据库、缓存和消息等请求，提取方法、接口路径、响应状态、目标端点和调用方向。随后，系统要将同一连接上的请求与响应正确配对，形成一个完整调用单元，记录请求开始和结束时间、客户端与服务端身份、响应状态、错误类型以及请求耗时。围绕这些调用单元，平台可以进一步生成客户端Span和服务端Span，并计算请求量、错误率和响应时延等RED指标。

对于HTTPS等加密通信，仅在网卡侧读取数据通常只能看到密文。因此，零侵入观测还需要结合用户态探针，在数据进入TLS加密库之前或者完成解密之后，获取用于事务识别的必要信息。这里并不是绕过加密机制，而是在应用正常使用加密库的过程中观察请求和响应行为，尽可能获得接口、状态和耗时等可观测元数据。

03 从独立可用到深度增强：eBPF正在重构链路追踪

eBPF链路追踪首先解决的，不是“如何替代现有APM”，而是一个更基础的问题：如果企业没有部署任何APM，能不能在不修改业务代码的情况下，先把真实调用链看清楚？答案正在变得越来越明确。通过服务自动发现、协议识别、请求响应配对和运行时关联，eBPF已经可以在无需统一埋点的情况下，还原服务之间真实发生的调用关系，并形成Trace、RED指标和动态拓扑。对于企业日常最常见的接口超时、服务依赖异常、数据库慢调用、上下游影响分析等问题，这套零侵扰能力已经能够覆盖大部分运维场景。

当前eBPF真正的边界，更多在于代码内部语义。它能够知道“服务A调用了服务B的哪个接口、耗时多久、是否报错”，但并不天然知道某个业务方法内部执行了哪些函数，也无法自动理解订单号、客户等级等业务属性。因此，对于少量需要深入代码内部的关键应用，可以继续融合OpenTelemetry Agent、SDK等应用侧数据，对方法级调用和业务语义进行补充。但这不是eBPF能力的终点，随着协议解析、加密流量识别、线程与异步上下文关联、Trace Context传播等技术持续发展，越来越多过去必须依赖应用Agent完成的能力，正在向基础设施侧下沉。未来，服务发现、协议级链路追踪、RED指标、动态拓扑和大量基础故障定位能力，都有可能直接由eBPF完成，应用侧插装则更多聚焦真正需要代码级和业务级语义的少数场景。

因此，优云希望采用的路径很清晰：先用eBPF实现一套独立可用的零侵扰链路追踪，解决企业大部分“看不见、串不起来、定位难”的问题；再按需补充应用语义，让链路从“看得全”进一步走向“看得深”。

这也再次回到整个系列的核心观点：可观测能力不应依赖业务系统主动改造，而应逐步成为基础设施天然具备的能力。

结语：还原调用，是理解故障的第一步

零侵入链路追踪让我们在无需统一埋点的情况下，也能从真实运行行为中还原跨服务调用关系。但“看见链路”只是第一步，真正的可观测还需要进一步回答：哪里是根因、影响了谁、是否已经恢复？ 下一篇，我们将把Trace与RED指标、网络性能、资源状态和动态拓扑连接起来，看优云如何从“还原一次调用”走向“理解一次故障”。