国产 CPU 上跑 eBPF 采集：ARM 与 LoongArch 的适配要点

eBPF 无侵入采集（进程、网络、性能数据）在 x86 上已经相当成熟，但迁移到国产 ARM（鲲鹏、飞腾）和 LoongArch（龙芯）之后，很多团队的采集方案会卡在内核、编译和权限三个坎上。这篇文章把这几个问题一次讲清楚，并给出验收方法。

先确认内核版本与 BTF

eBPF 的 CO-RE 机制依赖内核开启 CONFIG_DEBUG_INFO_BTF，它让 eBPF 程序在不同内核版本之间可移植。国产发行版（麒麟 V10、统信 UOS）默认内核不一定开这个选项。先用下面两条命令确认：

cat /proc/config.gz | gunzip | grep CONFIG_DEBUG_INFO_BTF
bpftool btf dump file /sys/kernel/btf/vmlinux format c > /dev/null && echo OK

没有 BTF，就只能退回对内核版本敏感的旧式预编译，几乎不可维护。若内核版本低于 5.4（LoongArch 早期内核），建议先升级内核再上 eBPF，而不是硬啃兼容问题。

采集器的编译与部署

国产平台大多没有现成的 eBPF 采集器二进制，需要在目标架构上重新编译。以 Go 编写的采集器为例：

CGO_ENABLED=0 GOARCH=arm64 go build -o jj-ebpf-agent ./cmd/agent

龙芯 LoongArch 需要 GOARCH=loong64，且依赖的 libbpf 要用支持 LoongArch 的版本，否则 eBPF 对象加载会直接失败。编译产物务必在目标 CPU 上做一次 readelf -h 确认架构，避免把 amd64 二进制错发上去。

权限与安全上下文

加载 eBPF 程序需要 CAP_BPF、CAP_PERFMON 等能力。容器里跑采集器时，挂载 /sys/kernel/btf 并显式声明 capabilities，不要图省事用 privileged 全开：

securityContext:
  capabilities:
    add: ["CAP_BPF", "CAP_PERFMON", "CAP_SYS_RESOURCE"]
volumeMounts:
  - name: btf
    mountPath: /sys/kernel/btf
    readOnly: true

信创场景对安全要求更严，采集器最小权限化是审计时绕不开的一环。

压测与验收

先挑一台 ARM 节点做 24 小时压测，重点看三项：采集器自身 CPU 占用（通常应低于 5%）、内核日志有无 verifier 报错、以及采集到的数据在控制台是否连续无缺口。最后给一句实用建议：信创环境下 eBPF 是加分项而不是必选项，如果内核或 CPU 不支持，退回用 OpenTelemetry SDK 埋点或 agent 侧采集，指标一样能拿到，不必为了 eBPF 卡住整个迁移进度。