应使用 pprof、Prometheus 和 OpenTelemetry 构建分层可观测体系：pprof 暴露运行时诊断指标，需正确启动 HTTP 服务并限制访问；Prometheus 上报业务指标，须全局注册、避免重复；OpenTelemetry 统一追踪与指标，确保 context 透传；禁用无上下文的 os.Getpid() 或 runtime.NumGoroutine() 健康检查。
用 net/http/pprof 暴露基础运行时指标
Go 标准库自带的 pprof 是最轻量、最可靠的运行时状态采集入口，它默认提供 goroutine 数量、heap 分配、CPU 采样等关键指标，无需额外依赖。
常见错误是只注册了 /debug/pprof/ 路由但没启动 HTTP 服务，或监听在 127.0.0.1:6060 导致外部监控系统无法访问。
- 必须显式调用
http.ListenAndServe(":6060", nil)启动服务（端口可自定义） - 生产环境建议绑定到
0.0.0.0:6060并通过防火墙或反向代理限制访问来源 -
/debug/pprof/goroutine?debug=1返回所有 goroutine 堆栈，?debug=2返回简化摘要，后者更适合 Prometheus 抓取 - 避免长期开启
/debug/pprof/profile（CPU profile），它会阻塞应用并消耗可观 CPU
package main
import (
"log"
"net/http"
_ "net/http/pprof"
)
func main() {
go func() {
log.Println("pprof server listening on :6060")
log.Fatal(http.ListenAndServe(":6060", nil))
}()
// your service logic here
select {}
}
用 prometheus/client_golang 上报自定义业务指标
pprof 提供的是运行时“诊断性”数据，而业务级健康状态（如请求成功率、处理延迟、队列积压）必须靠主动上报。Prometheus 生态是 Go 微服务事实标准，prometheus/client_golang 库封装简洁、性能好、兼容性强。
容易踩的坑是把指标注册逻辑放在 handler 内部，导致每次请求都重复注册，引发 panic；或使用 promauto.NewCounter 时未传入全局注册器，导致指标不被暴露。
- 所有指标应在
init()或main()开头一次性注册，不要在 handler 中 new - 使用
prometheus.MustRegister()替代promauto可明确控制注册时机 - HTTP handler 中直接调用
counter.Inc()或histogram.Observe(latency.Seconds())，不要在 goroutine 中异步调用（除非你确保 metric 实例是并发安全的） - 暴露路径推荐
/metrics，与 Prometheus 默认抓取路径一致
package main
import (
"net/http"
"time"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)
var (
httpRequestsTotal = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests.",
},
[]string{"method", "status_code"},
)
httpRequestDuration = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "Latency distribution of HTTP requests.",
Buckets: prometheus.DefBuckets,
},
[]string{"method"},
)
)
func init() {
prometheus.MustRegister(httpRequestsTotal)
prometheus.MustRegister(httpRequestDuration)
}
func exampleHandler(w http.ResponseWriter, r *http.Request) {
start := time.Now()
defer func() {
status := "200"
if w.Header().Get("Content-Type") == "" {
status = "500"
}
httpRequestsTotal.WithLabelValues(r.Method, status).Inc()
httpRequestDuration.WithLabelValues(r.Method).Observe(time.Since(start).Seconds())
}()
w.WriteHeader(200)
w.Write([]byte("OK"))
}
func main() {
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("healthy"))
})
http.Handle("/metrics", promhttp.Handler())
log.Fatal(http.ListenAndServe(":8080", nil))
}
用 go.opentelemetry.io/otel 统一追踪 + 指标 + 日志上下文
当服务间调用变多、链路变深，单靠 pprof 和 Prometheus 指标不足以定位跨服务延迟瓶颈。OpenTelemetry 是当前唯一被 CNCF 毕业的可观测性标准，Go SDK 支持同时导出 trace、metric、log，并保证 context 透传。
典型问题是 tracer 和 meter 初始化顺序错乱，或忘记在 HTTP handler 中注入 context，导致 span 断裂、指标丢失标签。
- 必须先初始化
TracerProvider和MeterProvider，再创建Tracer和Meter - HTTP handler 必须用
r = r.WithContext(ctx)注入 span context，否则下游服务无法延续 trace - metric 的
label建议复用 trace 的span.SpanContext().TraceID()，便于关联分析 - 本地开发可导出到
stdout或jaeger，生产环境建议用 OTLP 协议推送到 Grafana Tempo / Prometheus / Loki
为什么不能只靠 os.Getpid() 或 runtime.NumGoroutine() 做健康检查
很多团队早期用简单函数拼凑健康端点，比如返回 PID、goroutine 数、内存 RSS —— 这类数据既无业务语义，又缺乏时间维度，更无法触发告警阈值判断。
真实故障场景中，goroutine 数突增可能是死锁前兆，也可能是合法的批量任务；RSS 高可能源于缓存，未必代表泄漏。没有上下文的原始数字等于无效信号。
-
runtime.NumGoroutine()是瞬时快照，需配合历史趋势（如 Prometheus 的rate()或deriv()）才有意义 -
os.Getpid()对容器化部署几乎无用：K8s liveness probe 不关心进程 ID，只关心 HTTP 状态码和响应时间 - 真正可用的健康检查必须包含：依赖服务连通性（DB、Redis、下游 HTTP）、核心业务逻辑可达性（如能生成 token）、资源水位（如磁盘剩余
- 推荐实现为
/healthz（轻量）和/readyz（含依赖检查）两个端点，由 K8s 分别配置 livenessProbe 和 readinessProbe
pprof 和 Prometheus 解决“发生了什么”，OpenTelemetry 解决“发生在哪条链路上”，而健康端点解决“还能不能收请求”。三者缺一不可，但最容易被跳过的，是把健康检查真正和业务 SLA 对齐——比如支付服务的 /readyz 必须验证支付网关连接，而不仅仅是 ping 通 DB。
