在这篇文章中，我想简单介绍一下 Elastic 的Universal Profiler和安全解决方案都使用的一项非常有趣的技术，称为 eBPF，并解释为什么它是现代可观测性中至关重要的一项技术。
我将稍微谈谈它的工作原理以及如何使用它来创建强大的监控解决方案——并设想 eBPF 在未来用于可观测性用例的方式。
什么是 eBPF？
eBPF 或 Extended Berkeley Packer Filter 是一个非常有趣的名称，但它没有帮助用户以概念化的功能描述来理解该技术（也就是你不能将其简单的理解为一个包过滤器）。之所以取这个名字，是因为该技术的最初用途是在网络中，用于动态地实现极其复杂的防火墙规则。
如今，该技术可用于许多其他事情，并且在安全和可观测性领域具有广泛的适用性。
eBPF 的核心是这样一种技术：它可以在操作系统的内核空间中运行程序，而无需更改内核源代码或编译其他模块。
[相关文章：从客户到内核的云原生可观测性]
为什么 eBPF 在可观测性方面如此重要
我在 APM 领域工作多年，无论是作为客户还是作为厂商，我们传统上进行埋点监测的方式非常具有侵入性。如果您没有手动添加埋点，APM 会将自身插入到代码中并重新编译。这种类型的部署可能会导致各种问题，从而导致生产环境瘫痪。
现在我是 APM 的坚定拥护者，导致问题的可能性远远低于它可以带来的价值，但 eBPF 可以为我们提供更好的前进方式。eBPF 可以提供一种无需埋点即可获取所需可观测性数据的方法，因此安全性要高得多。
当您编写要在内核中运行的 BPF 代码时，首先使用 Clang 将其编译为 BPF“字节码”，然后对字节码进行测试，以确保它可以安全执行。这些严格的验证保证机器代码不会有意或无意地破坏 Linux 内核，并且 BPF 探测器每次被触发时都会执行有限数量的指令。
传统埋点监测的另一个问题是，由于您需要频繁地获取数据然后处理该数据，这通常会消耗资源，因此它可能会导致大量开销。由于eBPF可以直接在内核内运行，它可以被用来对数据进行聚合，并且只将摘要传递给用户级，从而大量减少用户空间解决方案所产生的开销。
使用 BPF Compiler Collection (BCC) 深入了解其工作原理
要深入剖析，我们可以从此处列出的 BCC 工具开始。我喜欢这些工具的地方在于，它们抽象出了大量将 eBPF 程序引导到内核所需的代码，并使它们可以通过 Python 代码轻松访问，如下所示。
首先，让我们看一下这个——这是 eBPF 的 hello world：
代码语言：javascript复制from bcc import BPF
prog = ‘int kprobe__sys_clone(void *ctx) {
bpf_trace_printk("Hello, World!\n");
return 0;
};’
BPF(text=prog).trace_print()这个程序将为每个从终端创建的新的子进程打印 "hello world!"，因为它有一个 "sys_clone "的钩子，如手册页中所述。
如果你把这段代码塞进一个python文件，你应该能够运行它（假设你已安装了BCC工具），然后在另一个终端开始写一些命令，在你启动一个进程时，将会看到 "Hello World''出现。它真的就这么简单。
这个程序有四个有趣的地方：
text='...'：这定义了一个使用简单文本的 BPF 程序。这个程序是用C写的。kprobe__sys_clone()**：**这是通过 kprobes 进行内核动态跟踪的快捷方式。如果 C 函数以kprobe__ 开头，则其余部分将被视为要挂钩的内核函数名称，在本例中为sys_clone() 。bpf_trace_printk()**：**一个简单内核工具。 可将printf()输出到到通用 trace_pipe (/sys/kernel/debug/tracing/trace_pipe) 中。trace_print()**：**读取 trace_pipe 并打印输出的 bcc 例程。
让我们看一下另一个示例（在此处），该示例对于可观测性目的稍微有用一些，跟踪 http 服务器调用。
正如您所看到的，这并没有太多内容，而且它非常强大。它允许您从本质上拦截 Node JS http 请求并查看传递到请求方法中的特定参数。
值得查看该存储库中的其他 BCC 工具（如下所示），以查看所有帮助解决您遇到的棘手问题的方法，尤其是传统工具无法为您解决的问题。我毫不怀疑，我们很快就会看到将这些工具集成到我们最喜欢的可观测性解决方案中。
blog-elastic-ebpf-2.png以下是我们在 Elastic 能够使用 BCC 工具通过 eBPF 解决的问题列表：
- 分析磁盘 IO 延迟
- 跟踪缓慢的 xfs 文件操作
- 总结 XFS 操作延迟
- 跟踪内核函数调用以查找 md_flush_request 问题并减少磁盘写入速度减慢
eBPF 技术走向何方？
如您所见，我们很容易将钩子插入内核并开始查看系统上发生的事情，从网络和low level子系统到运行在顶层的应用程序。
现在 eBPF 确实有一些限制。它不能安全地修改数据——运行 eBPF 代码的虚拟机对代码中的变量具有只读访问权限，这非常重要，否则可能会导致各种意外问题。您不能像使用 APM 那样使用 eBPF 以实用的方式真正添加标签或跟踪 ID 以动态编码。虽然从技术上讲这是可能的，但它涉及内存修改，这是不安全的并且可能具有更高的开销。因此，直到这些问题得到解决，
APM 代理和 OpenTelemetry 在当今世界仍然占有一席之地，因为我们需要将跟踪信息、日志和指标数据添加到我们的代码中。
我认为这里可能发生的是，传统APM的一些责任，特别是收集部分，将转移到基于eBPF的代理。我们读取跟踪ID或指标，以便我们能够生成上下文并将所有的数据联系在一起，这部分可以转移到基于eBPF的代理，因为它的性能优势，总结的速度，以及因为它可以访问更多的底层系统。
同时，eBPF 可用于收集更深入、更有趣的信息：网络数据、安全数据、有关 kubernetes 的数据以及传统上 APM 无法提供的其他系统服务。
期待在未来听到更多关于 eBPF 的信息。像 Elastic 这样的大部分可观测性解决方案将越来越多地在幕后使用更多这种技术。也许我们甚至可能会看到嵌入机器学习模型的 eBPF 程序可以识别最重要的数据和问题，从而比以往更快地提醒我们注意问题。eBPF 在现代可观测性和未来几年的新兴用例方面具有重要的未来。
