eBPF：解锁 Linux 内核的可观测性与编程新范式

很早前就想写一篇关于 eBPF 的文章，但迟迟没有动手。最近有了些时间，于是决定动笔。这篇文章主要还是简单介绍 eBPF 是用来干什么的，并通过几个示例来阐述它如何工作。

什么是 eBPF？

eBPF（extended Berkeley Packet Filter）是一项革命性的技术，它允许我们在 Linux 内核中运行自定义的、沙箱化的程序，而无需修改内核源码或加载内核模块。你可以把它理解为一个高度优化、高度安全的虚拟机，运行在内核空间。

想象一下，你可以在内核的关键路径（例如网络数据包处理、系统调用跟踪、文件系统操作等）上插入自己的代码逻辑，而且完全不会影响内核的稳定性。这就是 eBPF 的魔力。

eBPF 能做什么？

eBPF 的应用场景非常广泛，几乎渗透到了系统性能和安全的方方面面：

高性能网络：实现自定义的包过滤、负载均衡，甚至是用户态的 TCP/IP 协议栈（如 Cilium 项目）。这比传统的 iptables 性能更高、更灵活。
安全监控与策略执行：实时监控系统调用、文件访问、进程创建等行为，实现细粒度的安全策略和容器运行时安全检测。
深度性能剖析与调试：无需侵入式地修改应用，即可追踪 CPU 调度、内存分配、锁竞争、I/O 延迟等内核与应用行为，是排查性能瓶颈的利器。这与 Text2SQL 关注的上层数据交互不同，eBPF 深入到了系统运行的底层逻辑。
内核与应用可观测性：构建强大的监控和追踪基础设施，为微服务、云原生环境提供前所未有的洞察力。

eBPF 的工作原理（简化版）

一个典型的 eBPF 工作流程如下：

编写程序：使用 eBPF 特定的指令集（或通过 C 语言编译）编写一段程序，明确它要挂载到哪个内核钩子点（hook point）。
验证与加载：用户态工具将这段程序提交给内核。内核的 验证器 会严格检查程序，确保它不会导致内核崩溃、死锁或安全漏洞。只有通过验证的程序才能被加载。
JIT 编译：通过验证的 eBPF 字节码会被 JIT（即时）编译器 转换为本地机器码，以接近原生的性能执行。
挂载与执行：程序被挂载到指定的内核钩子点。当内核执行到该点时，eBPF 程序就会被触发执行。
数据共享：eBPF 程序可以通过 eBPF Map（一种高效的键值存储）与用户态程序通信，输出监控数据或接收配置信息。

这套机制确保了 eBPF 程序的安全性、性能和灵活性。

实例：一个简单的跟踪程序

虽然这里无法直接运行代码，但我们可以想象一个最简单的 eBPF 程序：跟踪系统调用 execve（用于创建新进程）。

我们编写一个 eBPF 程序，将其挂载到 tracepoint/syscalls/sys_enter_execve 内核跟踪点。
当任何进程调用 execve 时，我们的程序就会被执行。它可以从寄存器中读取传递给系统调用的参数（比如要执行的命令）。
程序将这条信息（“进程A执行了命令B”）通过一个 eBPF Map 发送到用户态。
用户态的监控程序从 Map 中读取这些信息并打印出来。

这样，我们就实现了一个实时监控系统中所有新进程创建的工具。这比传统的 strace 工具效率高得多，且对系统性能影响极小。

总结

eBPF 正在彻底改变我们与 Linux 内核交互的方式。它将内核从一个静态的黑盒，变成了一个可编程、可观测的平台。对于开发者、SRE 和安全工程师而言，eBPF 提供了前所未有的能力来理解、优化和保护复杂的分布式系统。它的生态系统（如 BCC, bpftrace, Cilium, Falco）正在飞速发展，学习和掌握 eBPF 将成为一项极具价值的技能。

想更直观地了解现代系统监控的复杂性，可以参考深入解析 React Server Components 的渲染机制，虽然领域不同，但都体现了对复杂系统内部状态观测的深入探索。

本文最初发布于酷壳 - CoolShell，经翻译与润色。