服务拓扑串联难？eBPF为滴滴可观测带来解题新思路

上篇文章我们讲到可观测性在滴滴的实践与落地，更多关注的是不同观测信号之间的关联关系。那服务与服务之间的关系又如何串联，业界当前爆火的 ebpf 又在滴滴有着怎样的应用，本文为你揭晓。

背景

业务介绍：业务接口调用观测

滴滴可观测平台除了负责滴滴 MTL 能力的建设，还涉及更偏向业务侧的数据及服务接口调用观测。

关于接口调用拓扑观测，这里先解释下以免引起歧义。如下图描述了一个调用关系：

一次请求、响应过程

这里用[caller=A, caller-func=/a, callee=B, callee-func=/b]，简写成[A, /a, B, /b]，以及 [A, /a, C, /c]来描述A服务的/a触发后调用B:/b以及C:/c的动作。在获取到足够多的接口调用数据时，通过给定某个业务的若干个调用入口（如上述示例中的[A, /a]），通过对接口调用链路的不断串联，可以梳理出该业务若干个重要的调用链路。

调用链路的构建对于服务稳定性保障有重要意义，无论是容灾放火、业务按需扩容、高峰期业务状态巡检护堤等均依赖于核心调用链路的构建。从经验上来看，在实际故障处理以及容量评估时，接口级的调用拓扑比服务级或者容器/物理机级的调用拓扑要有效很多。

一般来说，接口粒度的服务拓扑可以通过调用日志或者调用 metric 来进行串联。滴滴可观测早些时候采用调用日志+调用 metric 相结合的方式生成服务接口调用拓扑。后来随着统一服务治理的推进，业务上报 metric 完全可以覆盖调用日志里的调用关系，且生成接口拓扑的成本大幅降低，因此就接口拓扑生成这一场景而言，已经调整为基于服务调用的 metric 数据来生成。

通过metric串联接口拓扑的示意图

业务问题：服务接口拓扑的校验

看起来，通过接口调用 metric 来串联调用链路是一种通用的方式，但是其生成结果显然存在如下的问题：

• 已生成的数据缺少校验方式。由于数据是业务方代码上报的，即使引入了通用的SDK，caller-func 信息也只能依赖于代码调用时主动传入。从实践经验来看，caller-func 的漏传错传问题比较明显。

• 调用关系校验、生成成本高昂。依赖业务代码上报，意味着代码需要遵循相当的规范。较为核心的调用链路，推动代码的变更相对容易，业务配合度较高。但非核心的调用链路或已经稳定运行许久的遗留项目，代码的规范化变更是较难推动的。而手动添加则需要对项目进行人工梳理，对于存在近千个调用的链路而言，没有实际操作空间。

上述两个问题是使用 metric 串联业务接口拓扑时常见的问题。

以滴滴可观测的实践来看，当核心链路的复杂度达到以千计的量级，即使有专门的团队推动业务调用链路的 metric 接入治理，也会有相当比例的调用关系缺失或者错误。

    

  理想情况下的正常结果        

metric 信息错误时可能的结果

针对服务接口拓扑校验的问题，滴滴可观测通过探索，形成了基于eBPF（后文如无其他说明，简称BPF）技术进行服务接口拓扑无侵入采集的方案。通过 metric+BPF 采集相结合的方式，实现了接口拓扑数据的准确性验证、缺失数据补充。同时，进一步探索了可观测更深层次使用 BPF，如 MTL 的融合。

方案

BPF介绍

BPF 最早是伯克利包过滤器（Berkely Packet Filter）的简称，内核自3.15开始对 BPF 进行扩展，通过增加 BPF 程序寄存器个数、扩充 BPF 程序可使用内存以及增加多个BPF事件使得 BPF 具备高可定制性。为了和扩展前的 BPF进行区分，将3.15之前的BPF称为 cBPF（classic BPF），扩展后的 BPF 称为 eBPF ÿ