eBPF可通过挂载内核tracepoint（如tcp:tcp_connect）或USDT探针（如nginx:request_start）在内核态直接采集Nginx连接与请求指标，无需修改源码或解析access_log，实现高精度、低开销、实时的无侵入监控。
直接在内核态采集 Nginx 的连接、请求、响应等指标，能绕过用户态日志解析与 HTTP 解包开销，显著提升监控精度和实时性。eBPF 是实现这一目标的关键技术，但需注意其与 Nginx 的协同方式——Nginx 本身不原生暴露 eBPF 接口，必须借助内核网络事件（如 socket、tcp_connect、tcp_sendmsg）或 uprobes/usdt 探针间接捕获行为。
基于 socket 和 TCP 事件的无侵入采集
eBPF 程序可挂载到内核的 tracepoint（如 tcp:tcp_connect、tcp:tcp_receive_skb、sock:inet_sock_set_state）上，精准跟踪每个 TCP 连接的建立、数据收发、关闭全过程。结合套接字地址信息（源/目的 IP+端口），可自动识别出哪条流属于 Nginx worker 进程（通过 pid/tgid 过滤或 comm == "nginx" 匹配进程名）。
- 无需修改 Nginx 源码或配置，也不依赖 access_log 解析
- 可统计每秒新建连接数、活跃连接数、连接持续时间、异常断连（RST/FIN 不对称）等底层指标
- 注意：需开启 CONFIG_BPF_KPROBE_OVERRIDE 和 CONFIG_NET_CLS_BPF 等内核配置，推荐使用 5.4+ 内核
利用 USDT 探针捕获 HTTP 语义级事件
Nginx 官方编译版本（含 --with-debug）或从源码启用 --with-http_stub_status_module 并开启 debug 日志时，会内置少量 USDT（User Statically Defined Tracing）探针，例如 nginx:upstream_connect、nginx:request_start、nginx:request_done。eBPF 程序可通过 bpf_usdt_read() 读取探针参数（如 URI、status、upstream_addr）。
- 比纯 socket 层更贴近业务：可区分 /api/v1/users 和 /healthz 的响应延迟
- 需确认 Nginx 构建时启用了 USDT 支持（检查 readelf -n $(which nginx) | grep -i usdt）
- 推荐搭配 BCC 或 libbpf + CO-RE 工具链开发，避免硬编码 probe 地址
构建低开销指标聚合与导出管道
eBPF 程序不宜直接写文件或调用用户态网络栈。应将原始事件写入 perf event array 或 ring buffer，由用户态守护进程（如用 Rust/Go 编写的 exporter）持续消费并聚合为 Prometheus 格式指标（如 nginx_conn_active_total、nginx_request_duration_seconds_bucket）。
- 聚合逻辑建议放在用户态：eBPF 中仅做轻量过滤与打标（如标记是否 HTTPS、是否命中缓存）
- 用 bpf_map_lookup_elem() + bpf_map_update_elem() 维护连接生命周期状态机，避免重复计数
- 设置合理 ring buffer 大小（如 4MB）与批处理间隔（100ms），平衡延迟与吞吐
调试与可观测性注意事项
eBPF 程序加载失败、事件丢失或指标偏差常见于权限、资源限制或逻辑竞态。建议：
- 用 bpftool prog list 和 bpftool map dump 实时查看程序状态与 map 内容
- 通过 tc exec bpf show 验证是否已正确挂载到 ingress/egress qdisc
- 对关键路径添加 bpf_printk()（仅限调试，上线前移除），配合 /sys/kernel/debug/tracing/trace_pipe 查看
- 对比 eBPF 指标与 stub_status 输出，验证连接数、请求数一致性
