go应用无需改代码即可被ebpf无侵入抓取慢sql，因其database/sql底层调用标准系统调用或go运行时函数（如mysql.(*conn).writepacket），ecapture等工具通过符号表hook实现捕获，但要求go二进制未strip、启用frame pointer，且内核支持ebpf。
直接上结论：Go 应用本身不需要改一行代码，只要它用 database/sql（或兼容驱动如 go-sql-driver/mysql）走标准系统调用，就能被 eBPF 工具无侵入抓取慢 SQL——但前提是工具能挂钩到 Go 的用户态函数入口，且内核和运行环境满足条件。
为什么 Go 的 MySQL 查询能被 eBPF 抓到？
eBPF 并不依赖 Go 的 /debug/pprof 或任何应用层埋点。真正起作用的是：Go 的 database/sql 底层最终会调用 write()、read() 等系统调用发包/收包；而像 eCapture 这类工具，专门针对 Go 二进制中 TLS/MySQL 协议的用户态函数（如 mysql.(*Conn).writePacket、mysql.(*Conn).readPacket）做符号级 hook——它靠解析 Go 二进制的符号表和函数偏移，动态注入 eBPF 探针。
这意味着：
- 你用 GORM、sqlx、还是原生
sql.DB都不影响，只要底层驱动没绕过 libc（比如用io_uring或自定义 socket） - Go 编译时不能 strip 符号表：
go build -ldflags="-s -w"会破坏函数名识别，导致探针挂载失败 - 必须启用 frame pointer（FP）：Go 1.17+ 默认关闭 FP，需显式加
-gcflags="-l -N -frames=true"编译，否则 eBPF 回溯栈可能截断
eCapture 的 MySQL 模块怎么启用？
eCapture 是目前对 Go MySQL 支持最成熟的开源 eBPF 工具之一，它的 mysql 模块专为 Go 驱动设计，不依赖 MySQL 服务端配置，也不需要开启慢日志。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操要点：
- 确认目标进程未被 strip：
readelf -s your_app | grep mysql能看到类似mysql.(*Conn).writePacket的符号 - 启动命令示例：
sudo ./eCapture -m mysql -p $(pgrep -f 'your_app')，其中-m mysql指定模块，-p指定 PID - 输出默认是 JSON 流，可管道进
jq实时过滤慢查询：... | jq 'select(.duration > 500000000)' # 单位纳秒，即 >500ms - 若报
"no symbol found"，大概率是 Go 二进制没符号或版本不匹配（eCapture 对 Go 1.20–1.23 支持较好，1.24+ 需查 release note）
和 MySQL 慢日志比，eBPF 方式有什么硬伤？
它快、实时、不依赖服务端，但也有明确边界：
- 抓不到纯服务端执行阶段的细节：比如 SQL 在 InnoDB 层锁等待、Buffer Pool 查找耗时，这些仍需
performance_schema或sys库配合 - 无法获取完整 query plan：EXPLAIN 结果得另外在数据库里跑，eBPF 只负责“哪条 SQL 执行了多久”
- 高并发下有采样丢失风险：eBPF ring buffer 容量有限，若每秒上千 query，建议加
--filter-sql或按库名过滤，避免日志洪泛 - 不支持加密连接（如
?tls=preferred）的明文解密：MySQL over TLS 的 payload 是加密的，eBPF 只能捕获加密前的原始字节，无法还原 SQL 文本
生产环境部署要注意什么？
别直接在 Pod 里跑 eCapture 二进制——它需要 CAP_SYS_ADMIN 和读写 /sys/fs/bpf，K8s 默认禁止。更稳妥的做法是：
- 用 DaemonSet 部署
eCaptureAgent，通过 hostPath 挂载/proc和/sys/fs/bpf，再用 namespace 或 label 过滤目标 Pod - 避免全局采集：务必加
--namespace-filter=default和--pid-filter（或通过 cgroupv2 path 匹配），否则可能把 kubelet、containerd 的网络调用也卷进来 - 输出别直写磁盘：建议 stdout → Fluent Bit → Loki，或对接 OpenTelemetry Collector 做采样/限速，防止日志服务被打爆
- Go 版本要对齐：eCapture 的 GoTLS 模块和 MySQL 模块共享符号解析逻辑，若混用 Go 1.19（无 FP）和 Go 1.22（默认 FP 关闭），需统一加编译参数
最易被忽略的一点：eBPF 抓到的“慢”，是客户端视角的端到端延迟（从 db.Query 调用开始，到 rows.Next() 返回为止），它包含网络 RTT、服务端排队、锁竞争等全部环节——但这恰恰是 SRE 最关心的真实用户体验，而不是 DBA 视角下的纯执行耗时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
