EBPF 可观测性系列

eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。

bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层：

• 内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据
• 用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件

这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。

前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。

容器级 OOM 定位

在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。

前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。

• 概述：
• 如何分析一个协议(MongoDB)
  • 协议文档的分析思路
  • MongoDB协议操作码说明表
  • 对最常见的操作码OP_MSG分析
• 在DeepFlow Agent扩展一个协议解析采集
  • DeepFlow Agent的开发文档概要
  • 代码指引
    • 定义一个协议，并用一个常量标识。
    • 为新协议准备解析逻辑
      • 定义结构体
      • 实现 L7ProtocolParserInterface
• 利用Wasm插件扩展DeepFlow的协议采集
  • Kafka协议分析
    • Kafka的Header和Data概览
    • Kafka的Fetch API
    • Kafka的Produce API
  • Kafka协议DeepFlow Agent原生解码
  • DeepFlow Agent的 Wasm 插件
    • Wasm Go SDK 的框架
    • 插件代码指引
• 结语
  • 原生Rust扩展
  • Wasm插件扩展
• 附录

概述：

MongoDB 目前使用广泛，但是缺乏有效的可观测能力。 DeepFlow 在可观测能力上是很优秀的解决方案，但是却缺少了对 MongoDB 协议的支持。 该文是为 DeepFlow 扩展了 MongoDB 协议解析，增强 MongoDB 生态的可观测能力，简要描述了从协议文档分析到在 DeepFlow 内实现代码解析的过程拆解。

部署过程和指令参考：pixie install

Pixie平台主要由以下组件组成：

• Pixie Edge Module 边缘模块(PEM): Pixie’s agent, installed per node. PEMs use eBPF to collect data, which is stored locally on the node. Pixie的代理，安装在每个节点上。PEM使用eBPF收集数据，这些数据存储在节点本地。