Go微服务不可直接加载eBPF程序，须由Cilium-agent统一管理；监控应使用Hubble而非tcpdump；指标暴露必须用promhttp.Handler()并按path/method/status打标，延迟用HistogramVec而非Summary。
Go 微服务本身不加载、不运行 eBPF 程序；想用 eBPF 监控 Go 应用，必须把监控逻辑从应用进程里彻底剥离——否则 cilium/ebpf 会报 permission denied 或 invalid argument，这不是权限没开够，是架构层级错了。
别在 Go 代码里 LoadProgram
你在 main.go 里 import cilium/ebpf 并调用 LoadProgram，必然失败。原因很直接：eBPF 程序必须由具备 CAP_SYS_ADMIN 权限的进程加载到内核，且需匹配当前内核的 BTF 类型信息。Go 微服务作为普通用户态进程，既无权限，也无 BTF 上下文。
- 真正该做的，是让 Go 服务跑在已启用 Cilium 的 Kubernetes 集群中，靠
cilium-agent统一加载和管理 eBPF 程序 - 若需自定义追踪（比如抓取
http.ServeHTTP延迟），不要用cilium/ebpf，改用libbpf-go——它支持 BTF 自动推导，适配新内核特性更稳 - Pod 必须加注解
io.cilium.monitoring: "true"（部分 Cilium 版本需显式开启），否则 Hubble 不采集该 Pod 流量
用 Hubble 查真实网络行为，别信 tcpdump
当你怀疑 Go 服务有 TCP 重传，tcpdump -i eth0 抓到的很可能是加密后流量（WireGuard）或封装包（VXLAN），根本不是内核实际发出的原始包。而 cilium hubble observe --pod my-go-app --type l3 --follow 直接读取 TC 层原始流，显示未加密、未封装的 L3/L4 事件。
-
tcpdump显示大量重传但hubble observe无TCP Retransmit→ 实际是网卡丢包或宿主机路由问题，非 Go 应用层问题 -
netstat -s | grep -i retransmit和hubble metrics中的tcp_retransmits_total数值不一致是正常的：前者统计 socket 层重传，后者是 IP 层实际发出的重传包，Cilium eBPF 在中间做了短路优化 - 看到 SYN 重发但无 ACK → 运行
cilium monitor --type trace，检查输出中是否含drop: No route to host，这说明策略规则误拦截了初始连接
Go 服务暴露指标必须用 promhttp.Handler()
/metrics 端点不能用 http.HandleFunc 手写实现，否则 Prometheus 抓不到数据或超时。根本原因是缺失标准 HTTP 头、不支持 HEAD 健康探测、也不做 gzip 压缩。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
promhttp.Handler()：它自动设Content-Type: text/plain; version=0.0.4、Cache-Control: no-cache，并正确响应 HEAD 请求 - 大指标集（如带多 label 的
HistogramVec）经promhttp.Handler()压缩后体积可减少 70%+；手写 handler 几乎都不处理压缩 - 打点时状态码必须从
ResponseWriter捕获，不能读r.Context().Value()—— 否则中间件未重写WriteHeader()会导致所有错误请求记成 200
延迟监控必须用 HistogramVec，别用 Summary
Summary 在客户端算分位数，无法跨实例聚合；Prometheus 查询时会严重卡顿，且结果不准。而 HistogramVec 把原始 bucket 暴露出去，用 histogram_quantile() 才能反映全量数据的真实延迟。
- 必须按
path、method、status打标，否则查“下单接口 P99”会混入健康检查或静态资源请求 - 电商类服务建议 buckets 设为
[]float64{0.05, 0.1, 0.2, 0.5, 1.0, 3.0, 5.0}（单位秒），别抄默认DefBuckets（从 10ms 开始，对后端 API 意义不大） - 中间件里打点前务必用
time.Since(start)，别用time.Now().Sub(start)—— 系统时间跳变时后者可能返回负值，导致 Prometheus 拒绝该样本
eBPF 监控真正的复杂点不在 Go 代码怎么写，而在于它要求你同时理解内核路径（TC 层 vs socket 层）、可观测工具链边界（Hubble vs tcpdump）、以及指标语义差异（client-side quantile vs server-side histogram）。这些地方一旦混淆，排查方向就全错了。
