2、eBPF基础概念：eBPF程序类型、Map、验证器与内核交互模型
在深入eBPF网络观测之前，必须理解eBPF的核心基础概念。本章将系统梳理eBPF程序类型、eBPF Map、验证器以及eBPF与内核的交互模型，为后续的Prometheus指标接入与定制打下坚实的理论基础。
2.1 eBPF程序类型
eBPF程序必须挂载到内核的特定事件或钩子上才能执行。不同的程序类型决定了程序可以访问的数据、可以调用的辅助函数以及最终的用途。以下是eBPF网络观测中最核心的几种程序类型：
| 程序类型 | 挂载点 | 触发时机 | 主要用途 |
|---|---|---|---|
| XDP (eXpress Data Path) | 网络驱动层（网卡驱动） | 网卡收到数据包后，在SKB分配前 | 高性能包过滤、DDoS防护、负载均衡、早期丢弃 |
| TC (Traffic Control) | 内核网络协议栈（ingress/egress） | 数据包进入/离开协议栈时 | 流量整形、QoS、包修改、隧道封装 |
| kprobe / kretprobe | 内核函数入口/返回点 | 内核函数被调用/返回时 | 动态追踪内核函数、性能分析、故障定位 |
| tracepoint | 内核静态跟踪点 | 内核预定义事件发生时 | 稳定的内核事件追踪（如系统调用、网络事件） |
| perf_event | 性能监控单元（PMU） | 硬件/软件性能事件发生时 | CPU周期、缓存命中率、指令计数等硬件级观测 |
观测选型建议： 在eBPF网络观测制品库中，XDP 和 TC 是数据包捕获与处理的主力，适合构建高性能的流量指标；kprobe 和 tracepoint 则用于追踪内核网络栈的函数调用与事件，适合诊断连接建立、内存分配等细粒度问题。
下图展示了XDP与TC在Linux内核网络栈中的挂载位置差异：
2.2 eBPF Map
eBPF Map是eBPF程序与用户态程序之间、以及不同eBPF程序之间进行数据交换的核心数据结构。Map以键值对的形式存储数据，支持多种类型，是构建观测指标的基础。
2.2.1 常用Map类型
| Map类型 | 描述 | 典型用途 |
|---|---|---|
| BPF_MAP_TYPE_HASH | 哈希表，基于键的快速查找 | 存储连接跟踪表（五元组 -> 统计信息） |
| BPF_MAP_TYPE_ARRAY | 数组，索引访问，预分配固定大小 | CPU核心统计、per-CPU计数器 |
| BPF_MAP_TYPE_PERCPU_HASH | per-CPU哈希表，每个CPU独立副本 | 高性能计数器，避免锁竞争 |
| BPF_MAP_TYPE_PERCPU_ARRAY | per-CPU数组，每个CPU独立副本 | 包长度分布统计、延迟直方图 |
| BPF_MAP_TYPE_RINGBUF | 环形缓冲区，高效传递事件数据 | 将网络事件（如连接建立、丢包）推送到用户态 |
| BPF_MAP_TYPE_STACK_TRACE | 存储内核栈跟踪信息 | 与perf_event配合，记录函数调用栈 |
2.2.2 Map操作与观测指标
在eBPF网络观测中，Map通常用于：
- 计数器：使用
BPF_MAP_TYPE_PERCPU_ARRAY统计每秒收发包数、字节数。 - 直方图：使用
BPF_MAP_TYPE_ARRAY记录不同包长区间的包数量。 - 连接跟踪：使用
BPF_MAP_TYPE_HASH存储源IP、目的IP、端口等五元组信息及对应统计。 - 事件推送：使用
BPF_MAP_TYPE_RINGBUF将异常事件（如TCP重传）实时推送到用户态。
Prometheus接入关键点： 用户态程序通过
bpf_map_lookup_elem / bpf_map_get_next_key 等系统调用定期读取Map中的数据，然后转换为Prometheus指标格式（Gauge、Counter、Histogram），通过HTTP端点暴露给Prometheus Server。
2.3 eBPF验证器
eBPF验证器是内核中一个关键的安全组件，负责在eBPF程序加载到内核之前对其进行静态分析和安全校验。验证器确保程序不会导致内核崩溃、死锁或信息泄露。
2.3.1 验证器核心检查项
- 控制流完整性：确保程序有向无环图（DAG），不存在循环或不可达代码。
- 指令数限制：早期eBPF程序最大指令数为4096，5.x内核后扩展到100万条（允许复杂程序）。
- 栈大小限制：eBPF程序栈空间固定为512字节，禁止栈溢出。
- 指针检查：禁止解引用未经验证的指针，禁止将指针泄露到用户态。
- 辅助函数白名单：程序只能调用当前程序类型允许的辅助函数（如
bpf_get_current_pid_tgid、bpf_map_lookup_elem）。
观测开发注意事项： 验证器对程序大小和复杂度有限制。在开发网络观测程序时，应尽量精简逻辑，将复杂计算（如聚合、排序）放在用户态完成，eBPF内核态只做数据采集和初步过滤。
2.4 eBPF与内核交互模型
eBPF程序并非独立运行，而是通过一套精心设计的机制与内核及用户态程序交互。理解这个模型对于正确设计观测制品库至关重要。
下图展示了eBPF程序从加载到数据采集的完整交互流程：
2.4.1 交互步骤详解
- 编写与编译：开发者使用C语言编写eBPF程序，通过LLVM/Clang编译为eBPF字节码。
- 加载与验证：用户态加载器（如libbpf）通过
bpf()系统调用将字节码传入内核。内核验证器对字节码进行安全校验。 - JIT编译：验证通过后，JIT编译器将eBPF字节码转换为本地机器指令，提升执行效率。
- 挂载与执行：程序被挂载到指定的内核钩子（如XDP、TC、kprobe）。当对应事件触发时，eBPF程序在内核态执行。
- 数据交互：eBPF程序通过Map与用户态程序交换数据。用户态程序定期读取Map，将数据转换为Prometheus指标。
观测制品库架构启示： 在eBPF网络观测制品库中，eBPF程序负责在内核态高效采集网络数据（包计数、延迟、连接状态），用户态程序负责读取Map、聚合计算、格式化为Prometheus指标。这种分工既保证了采集性能，又降低了内核态程序的复杂度，使其更容易通过验证器检查。