基于ebpf的可观测方案

插桩

应用程序可观测性的一个重要方向是通过代码插桩的方式来实现。利用插桩，应用程序可以暴露非常丰富的观测信号，包括指标、追踪、日志、函数性能剖析等。插桩是一种软件开发技术，它的主要目的是在不修改源代码的情况下，对程序进行测试、监控和分析。有两种常见的插桩方案：

1. 无侵入的Agent方式：这个主要跟语言强相关，每种语言都需要自己实现一套独立的agent方案

• Python猴子补丁：对于python语言来说，因为是解释性语言，所以这个很好实现，也有很多现成的开源方案。

• Java 探针（Java Agent）：Java 探针是一种可以加载到 Java 应用程序中的小型程序，它可以监视和控制应用程序的行为。通过在应用程序中嵌入 Java 探针，开发人员可以实时了解应用程序的运行时状态，例如方法调用、对象创建等方面。此外，Java 探针还可以用于性能分析和调试，从而提高软件质量和可靠性。

• Go语言：因为是编译型语言，非常复杂也不容易理解，这里主要有几个开源库可以支持编译阶段注入：可以扩展编译器，修改编译过程中的ast语法树代表库为：go/ast——https://github.com/dave/dst启动阶段注入：修改编译后的机器码，插入跟踪代码。代表库有：Monkey、 gohook，其中gohook更好用。https://github.com/kmalloc/gohookhttps://github.com/bouk/monkey

1. 嵌入式 SDK（Software Development Kit）：嵌入式 SDK 是一种专门为某一软件开发工具包设计的插桩工具，例如 Prometheus SDK 或 Open Telemetry 的 SDK。通过将 SDK 嵌入到应用程序中，开发人员可以轻松地收集和传输应用程序的性能数据，从而帮助开发人员更好地了解应用程序的性能和行为。

我们来看下上面两种方式，会发现还是有很多的局限性和不够灵活：

• agent方式：局限性很大，只适用于特定语言

• sdk方式虽然支持各种语言，但是需要侵入到业务程序，需要在业务代码中主动调用，这是缺点也是优点，优点就是可以实现很多跟业务相关的细粒度观测上报。

Ebpf

上面两种方式都是应用层面的观测，对于一个大型系统来说，端到端的链路涉及到上上下下非常多的系统，以及操作系统、网络层面的观测等等，这些都需要一个额外的观测方式来实现，那就是基于ebpf的完全无侵入观测方案。

eBPF（Extended Berkeley Packet Filter）是一种在Linux内核中运行的轻量级虚拟机，可以用于执行用户定义的程序。

eBPF 程序是事件驱动的，当内核或用户程序经过一个 eBPF Hook 时，对应 Hook 点上加载的 eBPF 程序就会被执行。Linux 内核中预定义了一系列常用的 Hook 点，你也可以利用 kprobe 和 uprobe 技术动态增加内核和应用程序的自定义 Hook 点。得益于 Just-in-Time (JIT) 技术，eBPF 代码的运行效率可媲美内核原生代码和内核模块。得益于 Verification 机制，eBPF 代码将会安全的运行，不会导致内核崩溃或进入死循环。

这催生了很多基于 eBPF 的项目，涵盖了广泛用例，包括云原生网络、安全和可观测性。例如：当下正流行的 Cilium ，是基于eBPF 实现数据转发的 CNI 网络插件；Falco 是 CNCF 开源孵化的运行时安全工具，专门为 Kubernetes 、Linux 和云原生构建；Pixie 使用 eBPF 自动收集遥测数据，也已开源应用，并进入了 CNCF 沙箱的可观测项目；同时一些服务网格产品也在探索使用 eBPF。

Ebpf的可观测方案有pixie-ebpf、clinum、DeepFlow。pixie-ebpf、clinum是不能支持分布式追踪的，DeepFlow可以支持。成熟度最高的是clinum ，功能最强大的是DeepFlow。