无侵入式监控在 go 微服务中仅能通过 ebpf（内核层劫持）或编译期注入（ast 修改）实现；prometheus 和 opentelemetry 等 sdk 均需手动埋点，属侵入式；ebpf 是当前唯一生产可用方案，无需改代码、不重启进程、不依赖 sdk，但要求 linux 内核 ≥5.4 且启用 bpf 支持。
无侵入式监控在 Go 微服务中无法靠纯 Go 模块实现——prometheus/client_golang、go.opentelemetry.io/otel 等 SDK 全部需要手动埋点，本质是“侵入式”。真正能做到无侵入的，只有两类技术：eBPF（运行时内核层劫持）和编译期注入（AST 修改）。别被“Go 模块”误导，模块本身不解决侵入性问题。
eBPF 是当前唯一生产可用的无侵入方案
eBPF 不修改应用代码、不重启进程、不依赖 SDK，直接在内核中挂钩 Go 运行时关键函数（如 net/http.serverHandler.ServeHTTP、runtime.nanotime、GC 事件等），提取 HTTP 方法、路径、状态码、延迟、goroutine 数、堆分配量等指标。
- 必须运行在支持 eBPF 的 Linux 内核（≥5.4，推荐 ≥5.10）
- 需启用
CONFIG_BPF_SYSCALL=y和CONFIG_BPF_JIT=y - 主流工具链：Beyla（CNCF 毕业项目）、ARMS 应用监控 eBPF 版、Pixie
- Beyla 启动示例：
./beyla -instrumentation-type=go -go-probe-libs="/path/to/libgo.so"，它会自动发现并 hook 同主机上的 Go 进程 - 注意：Beyla 依赖 Go 编译时保留调试符号（禁用
-ldflags="-s -w"），否则无法解析函数签名
编译期注入（AST 修改）能绕过 runtime 限制但有构建耦合
当 eBPF 不可用（如 Windows/macOS 开发机、老内核、容器无 CAP_BPF）时，可采用编译期注入。原理是用 -toolexec 接管 go build，用 dst 库解析 AST，在函数入口/出口/HTTP handler 中自动插入 OTel 或 Prometheus 打点代码。
- 不会污染源码，生成的二进制自带监控逻辑
- 需确保所有构建环境安装同一版 agent 工具，CI/CD 流水线必须统一配置
- 不支持动态加载的插件式 HTTP handler（如通过反射注册的路由），因为 AST 分析无法预知运行时行为
- 典型失败场景：Gin 的
router.Any("/*path", handler)路由无法被静态分析识别路径标签，导致 HTTP 指标丢失 method/path 维度
为什么 promauto + otelhttp 这类“模块组合”不算无侵入
它们看起来只需 import 几个包，但实际仍要求你显式包装 handler、transport、client，并在关键路径调用 otelhttp.NewHandler() 或 otelhttp.NewTransport()。漏一处，整条链路就断。
-
otelhttp.NewHandler()必须替换原始http.Handler，否则 inbound 请求无 span -
http.DefaultClient不会被自动增强，必须显式构造带 interceptor 的 client - gRPC 场景下，
otelgrpc.UnaryClientInterceptor()必须传入每个grpc.Dial()调用，无法全局生效 - 自定义业务指标（如订单创建成功数）仍需手写
counter.Inc()，SDK 不可能猜到你的业务语义
真正无侵入的边界很清晰：如果你没改一行业务代码、没重写任何 handler、没调整 client 构造方式，且监控数据仍能按 method/path/status 下钻、能串联跨服务 trace、能捕获 goroutine 泄漏，那才是无侵入。其余都是“低侵入”或“开发友好型侵入”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
