生产环境CPU性能追踪必须用libbpf-go：它通过内核BTF自动解析tracepoint参数布局，避免cilium/ebpf硬编码字段偏移导致的读错问题；高频调度事件应使用perf_event_array而非ringbuf；暴露指标首选ebpf_exporter；uprobe追踪Go函数时需谨慎验证寄存器有效性。
直接用 libbpf-go 加载 tracepoint 程序，别碰 cilium/ebpf
Go 本身不能编译或运行 eBPF，所有监控都依赖用户态加载已编译的 .o 字节码。生产环境 CPU 性能追踪必须用 libbpf-go：它读取内核 BTF 信息自动解析 tracepoint/syscalls/sys_enter_sched_yield 或 tracepoint/sched/sched_switch 的参数布局；而 cilium/ebpf 硬编码字段偏移，在 5.15+ 内核上极易读错 ctx->prev_state 或 ctx->next_pid，导致指标全为空或乱码。
常见错误现象：
-
failed to load object: invalid argument→ 多半是内核没开CONFIG_DEBUG_INFO_BTF=y，libbpf-go找不到 BTF 无法推导结构体 - 日志里看到
ctx->next_comm是空字符串 →cilium/ebpf按旧版字段名硬读next_comm，但新内核已改名为next_comm[16]，地址算错 - 程序跑起来没数据 → tracepoint 子系统未启用，检查
/sys/kernel/debug/tracing/events/sched/sched_switch/enable是否可写
用 perf_event_array 收集调度事件，别用 ringbuf 做高频采样
CPU 调度类 tracepoint（如 sched:sched_switch）每毫秒可能触发数百次，ringbuf 在高负载下容易丢事件，且 Go 侧需手动解析变长 ring buffer 结构；perf_event_array 更稳，内核自动做 per-CPU 缓冲、批量提交，Go 侧只需调用 PerfEventArray.Read() 循环读取即可。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 内核侧 eBPF C 代码中，用
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &data, sizeof(data))提交结构化数据 - Go 侧定义结构体时，字段顺序、对齐、大小必须和内核侧完全一致；推荐用
btfgen自动生成，而非手写 - 避免在
Read()循环里做 JSON 序列化或深拷贝；高频场景下，用unsafe.Slice直接解析原始字节更可靠 - 每次
Read()后必须调用PerfEventArray.Consume()清空已处理事件，否则缓冲区会满并静默丢弃新事件
ebpf_exporter 是最快暴露 Prometheus 指标的路径
自己写 HTTP handler 暴露指标既重复又易出错。直接用 ebpf_exporter：它内置 YAML 配置驱动，把 eBPF map 中的计数器、直方图自动转成 Prometheus 格式，监听 :9436/metrics 即可被 Prometheus 抓取。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型配置片段（config.yaml）：
collectors:
- name: cpu_sched_latency
program: sched_latency.o
maps:
- name: latency_hist
type: hist
help: "CPU scheduling latency (ns)"
buckets: [1000, 10000, 100000, 1000000]
注意点：
-
latency_hist必须和 eBPF 程序里定义的 map 名完全一致，大小写敏感 - 如果 map 类型是
percpu_hash或percpu_array，ebpf_exporter会自动聚合所有 CPU 数据，无需 Go 侧干预 - 不支持自定义 label，所有指标都是无标签的 raw value；如需按
comm或pid维度切分，得在 eBPF 侧用复合 key（如struct { pid_t pid; char comm[16]; }）写入 map
uprobe 追踪 Go runtime 函数时，%ax 不一定可靠
想监控 Go goroutine 切换延迟？别只 hook runtime.schedule 并读 %ax——Go 1.17+ 启用寄存器 ABI 后，%ax 可能在 uprobe 触发前就被中间指令覆盖。真实可用的寄存器状态取决于 probe 插入点是否在函数入口、以及编译时是否禁用了内联（-gcflags="all=-l"）。
更稳妥的做法：
- 优先用 tracepoint
sched:sched_switch获取进程/线程级调度行为，它稳定、低开销、参数语义明确 - 若必须 uprobe Go 函数，用
go tool objdump -s "runtime\.schedule" ./myapp查看汇编，确认%ax在 probe 点是否仍存有效值 - 避免在 hot path 上做复杂计算；eBPF 栈空间仅 512 字节，
bpf_probe_read_user_str读长字符串易触发 verifier 拒绝
真正难的是让指标有意义：sched_switch 事件本身不带时间戳，你得在 eBPF 侧用 bpf_ktime_get_ns() 手动打点，再在用户态做差值计算延迟分布——这一步稍有不慎，就变成统计噪声。
