擎创技术流 | 深入浅出运维可观测工具（二）：eBPF应用中常见问题

上期跟大家聊了下eBPF的发展历史还有特性，点击这里↓↓↓擎创技术流 | 深入浅出运维可观测工具（一）：聊聊eBPF的前世今生，一键回看上期精彩内容。

这期主要跟大家分享下eBPF在应用过程中可能出现的问题，希望能帮到遇到类似问题的朋友，话不多说，我们进入正题。

一、内核适应性，老版本的某些功能不可用

eBPF 最低要求版本为LInux 4.1，eBPF的最低内核版本要求是 Linux 4.1，这是在 2015 年发布的内核版本。在这个版本之前的内核不支持 eBPF。

1.对于Linux4.1版本之前的监控

擎创对于Linux 4.1.0 之前的版本采用BPF采集HTTP 1数据以及DNS解析请求，进行可观测统计。

2.对于Linux4.1版本之后的监控

为了保证eBPF程序在各个linux内核版本之间的可移植性，我们编写eBPF程序的时候采用了CORE技术,CORE技术目前只有在 Linux 4.9.0 之后才会支持。

如果用户内核版本低于4.9.0或者内核未开启CO-RE, 我们能够提供linux内核升级包。

BCC总结了kernel版本与eBPF功能的关系：https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

二、权限安全要求

1.eBPF权限

需要具备root权限或CAP_SYS_ADMIN能力，这意味着只有能够加载内核模块的用户才能加载eBPF程序。

2.eBPF执行安全

在执行安全方面，eBPF 在加载之前会通过eBPF验证器对要执行的字节码文件进行校验，包括但不限于以下方面：

程序不包含控制循环
程序不会执行超过内核允许的最大指令数
程序不包含任何无法到达的指令
程序不会跳转到程序界限之外

三、uprobe 和 kprobe 差异

1.kprobe的优劣分析

优势：

更简单实现和更易维护。
不依赖于其他库的具体实现细节

劣势：

用户程序可能会将单个请求分割成多个系统调用，重新组装这些请求会带来一些复杂性
与TLS不兼容, 无法解包TLS

2.uprobe的优劣分析

优势：

我们可以访问和捕获应用程序上下文，如堆栈跟踪
我们可以构建uprobes以在解析完成后捕获数据，避免在跟踪器中重复工作
可以比较容易捕获https 请求,对TLS兼容性较好

劣势：

（1）对于使用的底层库版本敏感。无法在剥离了符号的二进制文件上运行

（2）需要为每个库实现不同的探针（每种编程语言可能都有自己的一组库）

（3）会导致额外的调用性能开销

四、性能消耗

虽然内核社区已经对 eBPF 做了很多的性能调优，跟踪用户态函数（特别是锁争用、内存分配之类的高频函数）还是有可能带来很大的性能开销。因此，我们在使用 uprobe,kprobe 时，应该尽量避免长时间跟踪高频函数。

我们以监控一个Golang 程序HTTP 1通信过程为例子,在分别开启uprobe和kprobe时候对该程序进行压力测试：

从结果可以看出，如果HTTP延迟大于1毫秒，引入的开销可以忽略不计，在大多数情况下只是噪音。这对于kprobes和uprobes都是类似的，尽管我们重新解析了所有数据，但kprobes的性能稍微好一些。请注意，开销有时是负值，这很可能只是测量中的噪音。在这里的关键要点是，如果您的HTTP处理程序正在进行任何实际的工作（大约1毫秒计算时间），引入的开销基本上可以忽略不计。