实战目标
在前一篇笔记中，我们了解了 eBPF 的基本原理和工具生态。本篇将通过具体工具和实践案例，展示如何利用 eBPF 实现零侵入的系统、网络和容器可观测性，并将采集到的数据用于 AIOps 分析。
工具选择
| 工具 | 定位 | 适用场景 |
|---|---|---|
| BCC | Python/C 框架 | 开发复杂 eBPF 程序 |
| bpftrace | 类 awk 脚本语言 | 快速编写一次性追踪脚本 |
| libbpf | C/C++ 库 | 生产级独立 eBPF 程序 |
| Cilium | K8s CNI | 网络可观测与安全策略 |
| Pixie | 完整可观测平台 | 快速落地 K8s 全栈观测 |
bpftrace 快速入门
bpftrace 非常适合快速验证想法。例如，统计每个进程的 TCP 连接建立耗时：
sudo bpftrace -e '
kprobe:tcp_v4_connect {
@start[tid] = nsecs;
}
kretprobe:tcp_v4_connect /@start[tid]/ {
@us[comm] = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}
'
输出是一个直方图，展示不同进程建立 TCP 连接的微秒级延迟分布。
BCC 开发示例：跟踪文件打开
BCC 工具集提供了大量现成脚本，也可以自行开发。下面是一个跟踪文件打开操作的简单示例：
#!/usr/bin/env python3
from bcc import BPF
prog = """
#include <uapi/linux/ptrace.h>
BPF_HASH(counts, u32, u64);
int trace_open(struct pt_regs *ctx) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
u64 *val, zero = 0;
val = counts.lookup_or_try_init(&pid, &zero);
if (val) {
(*val)++;
}
return 0;
}
"""
b = BPF(text=prog)
b.attach_kprobe(event="do_filp_open", fn_name="trace_open")
print("Tracing file opens... Ctrl-C to exit.")
try:
while True:
sleep(1)
for k, v in b["counts"].items():
print(f"PID {k.value}: {v.value} opens")
except KeyboardInterrupt:
pass
Cilium 网络可观测性
Cilium 是基于 eBPF 的 Kubernetes CNI，除了网络策略和负载均衡，还提供强大的可观测能力：
- Hubble：Cilium 的可观测组件，提供服务和网络流的可见性。
- L7 协议感知：支持 HTTP、Kafka、gRPC 等协议的流量观测。
- 网络策略可视化：直观展示哪些流量被允许或拒绝。
启用 Hubble 后，可以通过 CLI 查看实时流量：
cilium hubble port-forward &
hubble observe --namespace prod --protocol http
容器级系统调用观测
在 Kubernetes 环境中，可以针对特定 Pod 或容器进行系统调用追踪。使用 BCC 的 funcslower 或 syscount 工具：
# 统计每个容器的系统调用次数
sudo /usr/share/bcc/tools/syscount -c -P
# 跟踪特定进程的慢函数调用
sudo /usr/share/bcc/tools/funcslower do_sys_open -p $(pgrep -n myapp)
这些工具不需要修改容器镜像，也无需重启应用，真正做到零侵入。
eBPF 数据与 AIOps 联动
将 eBPF 采集的数据与 Metrics、Traces、Logs 整合，可以大幅提升 AIOps 的分析能力。例如：
- 网络延迟基线学习：使用 eBPF 采集每个服务间调用的 TCP 握手延迟，建立正常基线。
- 异常检测：当延迟超过基线 3 个标准差时触发告警。
- 根因定位：自动采集相关 Pod 的系统调用和调度数据，交给 LLM 分析。
数据流转架构示例：
eBPF Agent (DaemonSet)
-> Local Aggregator
-> OTLP Collector
-> Prometheus / Jaeger / Loki
-> AIOps Analysis Engine
-> LLM Root Cause Analysis
实战注意事项
- 内核版本要求：部分 eBPF 特性需要较新的内核版本（如 5.x 以上）。
- 权限控制：加载 eBPF 程序通常需要 CAP_BPF 权限或 root 用户。
- 性能影响：虽然 eBPF 开销低，但在高频事件场景下仍需注意采样和过滤。
- 验证器限制：eBPF 程序需要符合内核验证器的要求，如循环必须有限、不能解引用空指针等。
总结
eBPF 为云原生可观测性提供了强大的零侵入能力。通过 BCC、bpftrace、Cilium 等工具，开发和运维人员可以快速获取系统调用、网络、容器等多维度的底层数据。将这些数据与 OpenTelemetry、AIOps 结合，可以构建更智能、更全面的运维观测体系。