目录
三、eBPF 与 Jaeger/Zipkin 的区别及先进性
一、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，让单子飞了，是再正常不过的事情！