Golang代码埋点技术统计函数执行耗时指标-Golang-PHP中文网

最轻量无依赖的函数耗时埋点方式是入口调用start := time.now()，defer中用time.since(start)计算并记录耗时；需避免在defer闭包内重复调用time.now()，且不适用于非接口的纯函数全局自动埋点。

golang代码埋点技术统计函数执行耗时指标

如何用 defer + time.Now() 快速埋点函数耗时

最轻量、无依赖的埋点方式就是函数入口记录开始时间，defer 中计算差值。它不侵入业务逻辑，也不需要改调用链，适合临时排查或关键路径统计。

defer 保证即使函数 panic 也能执行耗时统计
注意避免在闭包中直接引用 time.Now() —— 应该在 defer 外先算好 start := time.Now()
不要用 time.Since() 在 defer 里反复调用，它内部会再调一次 time.Now()，引入微小但不必要的误差

示例：

func handleRequest() {
    start := time.Now()
    defer func() {
        log.Printf("handleRequest took %v", time.Since(start))
    }()
    // ...业务逻辑
}

为什么不用全局中间件统一埋点

Go 的函数不是一等公民，没有 Python 的装饰器或 Java 的 AOP，默认无法自动拦截任意函数调用。所谓“全局埋点”，本质是靠人肉加 defer 或重构为接口+包装器——后者成本高、改动大，且对非接口方法（如工具函数、私有方法）无效。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

HTTP handler 可以用中间件统一埋点，但仅限于 http.HandlerFunc 类型；普通函数不行
想对 CalculateScore() 这类纯函数埋点，必须显式修改调用方或被调用方
有些团队用代码生成（如 go:generate + AST 解析）自动注入，但维护成本高，且容易和 IDE、linter 冲突

使用 pprof 或 otel 埋点时要注意什么

如果项目已接入 OpenTelemetry（otel）或原生 pprof，优先复用其 trace 机制，而非另起一套日志打点——否则指标口径不一致，查问题时会串不住链路。

otel.Tracer.Start() 返回的 span 必须显式 End()，否则 span 泄漏，内存缓慢上涨
不要在 defer 里只调 span.End() 就完事：需提前把耗时、错误等属性写进 span，否则结束时拿不到上下文
pprof 的 StartCPUProfile 是进程级开关，不适合单函数粒度统计；它更适合性能瓶颈定位，而非 SLO 指标采集

示例：

ctx, span := tracer.Start(ctx, "CalculateScore")
defer span.End() // 注意：span.End() 本身不记录耗时，耗时由 Start/End 时间差自动算出

日志打点 vs. 指标上报：别把耗时写进文本日志

直接 log.Printf("took %v") 看似简单，但后续没法聚合分析。真实生产环境要求的是 P95、P99、错误率等可计算指标，不是一行行字符串。

文本日志里的耗时字段，得靠正则提取 + 外部系统清洗，延迟高、准确率低、查询慢
推荐用 prometheus.ClientGolang 的 histogramVec：按函数名、成功/失败状态打标签，直接暴露给 Prometheus 抓取
如果用 Loki 收日志，至少把耗时作为结构化字段（如 JSON 日志中的 "duration_ms": 12.3），并确保字段名统一、类型明确
特别注意单位：Go 的 time.Duration 默认是纳秒，转成毫秒要除以 time.Millisecond，别错写成 / 1e6（可能整数截断）