目录
一、eBPF 原理
二、eBPF 已可投入使用的场景
三、eBPF 与 Jaeger/Zipkin 的区别及先进性
四、使用 eBPF 的开源软件
五、开源软件的局限性或待实现功能
猫哥说
一、eBPF 原理
eBPF (extended Berkeley Packet Filter) 是一种内核技术,允许用户在内核空间安全、高效地运行自定义程序,而无需修改内核代码或加载内核模块。
核心概念:
- BPF 虚拟机:内核中的一个轻量级虚拟机,负责执行 eBPF 程序。
- eBPF 程序:用户编写的、经过编译的字节码程序,可以在内核事件(如系统调用、网络事件、内核探针)发生时被触发执行。
- Maps:eBPF 程序与用户空间程序之间共享数据的机制,类似于键值对存储。
- Helper Functions:内核提供的一组函数,eBPF 程序可以通过这些函数访问内核功能和数据。
- Verifier:内核中的一个安全验证器,确保 eBPF 程序不会导致内核崩溃或安全漏洞。
- JIT Compiler:将 eBPF 字节码编译为本地机器码,提高执行效率。
工作流程:
- 用户编写 eBPF 程序(通常使用 C 语言)。
- 使用 LLVM/Clang 编译器将 eBPF 程序编译为 BPF 字节码。
- 通过
bpf()
系统调用将字节码加载到内核。 - Verifier 验证程序的安全性。
- JIT Compiler 将字节码编译为本地机器码(可选)。
- 将 eBPF 程序附加到内核事件(如 kprobes、tracepoints、网络接口等)。
- 当事件发生时,eBPF 程序被触发执行。
- eBPF 程序可以通过 Maps 与用户空间程序交换数据。
eBPF 的优势:
- 安全:Verifier 确保 eBPF 程序不会破坏内核稳定性。
- 高效:JIT 编译和内核态执行带来高性能。
- 灵活:可以动态加载和卸载,无需重启内核或应用。
- 可编程:用户可以自定义 eBPF 程序,实现各种功能。
二、eBPF 已可投入使用的场景
eBPF 在可观测性领域有广泛的应用:
-
网络性能监控:
- 监控网络流量、延迟、丢包率等。
- 分析网络协议、识别性能瓶颈。
- 实现自定义的网络策略。
-
系统调用跟踪:
- 跟踪应用的系统调用,分析系统调用频率、耗时等。
- 识别系统调用相关的性能问题。
-
内核探针(kprobes/uprobes):
- 在内核函数或用户空间函数入口/出口处插入探针,收集函数参数、返回值、执行时间等信息。
- 用于性能分析、故障排查。
-
跟踪点(tracepoints):
- 利用内核中预定义的跟踪点,收集内核事件信息。
- 用于性能分析、故障排查。
-
安全监控:
- 监控系统调用、网络事件等,检测异常行为。
- 实现入侵检测、安全审计等功能。
-
容器监控:
- 监控容器的网络流量、资源使用情况等。
- 实现容器隔离和安全策略。
-
应用性能监控(APM):
- 通过 uprobes 跟踪用户空间函数,收集应用性能数据。
- 与传统的 APM 相比,eBPF 具有更低的开销和更高的灵活性。
三、eBPF 与 Jaeger/Zipkin 的区别及先进性
区别:
- Jaeger/Zipkin:是分布式追踪系统,主要关注服务间的调用关系和延迟,通过在应用中埋点(instrumentation)来收集数据。
- eBPF:是一种内核技术,可以在内核空间收集各种数据,包括网络、系统调用、内核事件等,也可以用于应用性能监控,但其应用范围更广。
先进性:
- 低开销:eBPF 在内核态执行,无需频繁的用户态/内核态切换,开销更低。
- 无需埋点:eBPF 可以通过 kprobes/uprobes 动态地收集数据,无需修改应用代码。
- 更全面的数据:eBPF 可以收集更底层的数据,如内核事件、系统调用等,而 Jaeger/Zipkin 主要关注服务间的调用。
- 安全性:eBPF 的 Verifier 机制确保了程序的安全性,不会影响内核稳定性。
- 动态性:eBPF 程序可以动态加载和卸载,无需重启应用或内核。
总结:eBPF 是一种更底层、更通用、更安全的技术,可以用于实现更广泛的可观测性场景,包括 Jaeger/Zipkin 所关注的分布式追踪。
四、使用 eBPF 的开源软件
-
BCC (BPF Compiler Collection)
- 官网:GitHub - iovisor/bcc: BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
- 解决的难题:提供了一组工具和库,简化 eBPF 程序的开发和部署。
- 局限性:需要一定的 C 和 Python 编程基础。
-
bpftrace
- 官网:GitHub - bpftrace/bpftrace: High-level tracing language for Linux
- 解决的难题:提供了一种高级的、声明式的语言,用于编写 eBPF 程序,简化了 eBPF 的使用。
- 局限性:表达能力不如 BCC 强大,不适合复杂的 eBPF 程序。
-
Cilium
- 官网:Cilium - Cloud Native, eBPF-based Networking, Observability, and Security
- 解决的难题:基于 eBPF 实现 Kubernetes 的网络、安全和可观测性。
- 局限性:主要面向 Kubernetes 环境。
-
Falco
- 官网:Falco
- 解决的难题:基于 eBPF 实现容器安全监控和威胁检测。
- 局限性:主要面向容器安全。
-
Katran
- 官网:GitHub - facebookincubator/katran: A high performance layer 4 load balancer
- 解决的难题:基于 eBPF 实现高性能的 L4 负载均衡器。
- 局限性:主要面向网络负载均衡。
-
Pixie
- 官网:Kubernetes Monitoring, Application Debug Platform | Pixie
- 解决的难题:基于 eBPF 实现 Kubernetes 应用的自动监控和调试。
- 局限性:主要面向 Kubernetes 环境。
-
Parca
- 官网:Parca - Open Source infrastructure-wide continuous profiling
- 解决的难题:基于 eBPF 实现持续性能分析(Continuous Profiling)。
- 局限性:主要面向性能分析。
五、开源软件的局限性或待实现功能
- eBPF 学习曲线陡峭:eBPF 技术本身有一定的学习门槛,需要掌握内核、C 语言、BPF 虚拟机等知识。
- eBPF 程序开发调试困难:eBPF 程序的开发和调试不如用户态程序方便。
- eBPF 安全性挑战:虽然 Verifier 机制可以防止大部分安全问题,但仍需谨慎编写 eBPF 程序,避免潜在的安全漏洞。
- eBPF 与应用集成的挑战:将 eBPF 收集的数据与应用层面的指标、日志、调用链关联起来,需要一定的集成工作。
- eBPF 标准化:eBPF 相关的工具和库仍在快速发展中,缺乏统一的标准。
待实现功能:
- 更友好的 eBPF 开发工具:提供更高级的语言、更强大的调试工具、更完善的文档,降低 eBPF 的使用门槛。
- 更丰富的 eBPF 程序库:提供更多预定义的 eBPF 程序,覆盖更多的可观测性场景。
- eBPF 与 OpenTelemetry 的集成:将 eBPF 收集的数据与 OpenTelemetry 标准集成,实现更全面的可观测性。
- eBPF 在安全领域的应用:进一步探索 eBPF 在安全领域的应用,如入侵检测、漏洞利用检测等。
- eBPF 在边缘计算的应用:将 eBPF 应用于边缘计算场景,实现边缘设备的监控和管理。
猫哥说
eBPF 是一项强大的内核技术,在可观测性领域具有广阔的应用前景。虽然 eBPF 仍存在一些挑战,但随着技术的不断发展和社区的不断壮大,eBPF 将在可观测性领域发挥越来越重要的作用。
其实eBPF本身没有那么难,但是如果总是让工程师人员复用,以做简单项目为主,以酒量作为考察标准,搞不出来eBPF,让单子飞了,是再正常不过的事情!