Go程序需组合标准库工具实现实时监控:用net/http/pprof查运行时指标(如CPU、内存、goroutine、GC),用expvar暴露自定义变量,用prometheus/client_golang对接Prometheus+Grafana实现可视化,三者用途不同不可混用。
Go 程序本身不内置环境监控界面,要实时查看系统状态(CPU、内存、goroutine 数、GC 情况等),得靠组合标准库 + 外部工具,而不是“配置一个监控工具”就完事。
net/http/pprof 查看运行时指标这是最轻量、最常用的方式,无需第三方依赖,Go 标准库自带。它暴露的不是图形界面,而是可被 go tool pprof 解析的原始数据端点。
import _ "net/http/pprof"
// 然后启动 HTTP 服务(哪怕只监听 localhost)
go http.ListenAndServe("localhost:6060", nil)/debug/pprof/:索引页,列出所有可用 profile 类型/debug/pprof/goroutine?debug=1:当前 goroutine 堆栈(文本)/debug/pprof/heap?debug=1:堆内存摘要(含 topN 分配者)/debug/pprof/gc:最近 GC 的时间戳和暂停时间?debug=1 返回纯文本;不带参数则返回二进制 profile 数据(供 go tool pprof 使用)localhost:6060 到公网——它没有认证机制expvar 暴露自定义变量与运行时统计expvar 提供了简单的键值式指标导出,适合暴露应用层计数器(如请求总数、错误数)、内存缓存大小等,它默认挂载在 /debug/vars。
cmdline、memstats(来自 runtime.ReadMemStats)、num_goroutine
import "expvar"
var reqCount = expvar.NewInt("http_requests_total")
// 每次请求递增
reqCount.Add(1)expvar_exporter 抓取,也方便 curl 调试:curl http://localhost:6060/debug/vars | jq '.num_goroutine'
myapp_http_requests_total)单独用 pprof 或 expvar 只能查快照,要“实时查看”,必须引入指标采集与展示链路。
prometheus/client_golang 替代 expvar:支持 Counter/Gauge/Histogram,有标签(label)能力,更适配 Prometheus 模型/metrics):
import (
"github.com/prometheus/client_golang/prometheus/promhttp"
)
http.Handle("/metrics", promhttp.Handler())/debug/pprof 和 /metrics 混用——前者是诊断用的 pr
ofiling 数据,后者是聚合指标,用途和采样频率都不同很多人以为加个包就能“开箱即用”,结果卡在权限、路径或语义误解上。
localhost 不等于宿主机可访问 —— 启动服务需绑定 :6060 或 0.0.0.0:6060,并检查容器端口是否映射runtime.NumGoroutine() 返回的是瞬时数量,不是峰值;pprof/goroutine?debug=1 里的 “running” 状态 goroutine 才代表真正在执行,其余多为阻塞或休眠go tool pprof http://localhost:6060/debug/pprof/heap 时,若提示 “no samples”,说明程序还没触发 GC 或分配足够内存——可手动调用 runtime.GC() 触发一次runtime.ReadMemStats —— 它会 STW(stop-the-world),影响延迟真正难的不是加几行代码,而是区分清楚:哪些数据用于故障定位(pprof),哪些用于趋势观测(Prometheus),哪些只是调试快照(expvar)。混用它们,反而会让监控变成噪音源。