Go微服务监控必须体系化接入指标采集、链路追踪和健康检查三类能力；需用prometheus/client_golang暴露/metrics端点，OTel实现跨服务追踪，/healthz与/readyz区分语义，并补充运行时指标。
Go 微服务监控不能只靠 log.Printf 打点或手动查 pprof，必须体系化接入指标采集、链路追踪和健康检查三类能力，否则线上问题响应慢、定位难、扩缩容无依据。
用 prometheus/client_golang 暴露标准指标端点
Prometheus 是 Go 微服务监控的事实标准，所有指标必须通过 /metrics 端点以文本格式暴露。不支持 JSON 或自定义格式，否则 prometheus 抓取失败。
关键实操点：
- 初始化时注册全局
prometheus.Registry，避免多个http.Handler冲突 - 使用
prometheus.NewCounterVec而非NewCounter，按status_code、method等维度打标，否则聚合查询无法下钻 - 在 HTTP 中间件里调用
counter.WithLabelValues(r.Method, strconv.Itoa(statusCode)).Inc()，不要在 handler 末尾硬编码 - 务必调用
promhttp.HandlerFor(registry, promhttp.HandlerOpts{})，而非直接http.Handle("/metrics", promhttp.Handler())，后者用的是默认 registry，你自定义的指标不会被采集
func initMetrics() {
reg := prometheus.NewRegistry()
httpRequestsTotal := prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests",
},
[]string{"method", "status_code"},
)
reg.MustRegister(httpRequestsTotal)
http.Handle("/metrics", promhttp.HandlerFor(reg, promhttp.HandlerOpts{}))
}
集成 go.opentelemetry.io/otel 实现跨服务链路追踪
OpenTelemetry 是当前唯一被 CNCF 毕业的可观测性标准，opentracing 已归档，jaeger-client-go 不再维护。新项目必须用 OTel。
立即学习“go语言免费学习笔记（深入）”；
常见踩坑点：
- HTTP transport 层必须用
otelhttp.NewTransport()包装，否则 outbound 请求无 span - gRPC 客户端需用
otelgrpc.UnaryClientInterceptor()，服务端用otelgrpc.UnaryServerInterceptor()，缺一不可 - context 传递不能漏：handler 入口用
otel.TraceIDFromContext(r.Context())验证是否已注入 trace，下游调用必须传r.Context()，不是context.Background() - 采样率别设成
AlwaysSample()，生产环境建议ParentBased(TraceIDRatioBased(0.01))（1%）
实现 /healthz 和 /readyz 双端点做 Kubernetes 探针
Kubernetes 的 livenessProbe 和 readinessProbe 必须对应不同语义：前者判断进程是否卡死，后者判断是否能正常提供服务。混用会导致滚动更新失败或流量打入未就绪实例。
实操要点：
-
/healthz只检查本地进程状态（如 goroutine 数是否爆炸、内存是否超阈值），不依赖外部服务 -
/readyz必须检查数据库连接、Redis 连通性、配置中心拉取状态等依赖项，任一失败返回 503 - 两个端点都应返回结构化 JSON，含
status、checks字段，方便日志解析和告警提取 - 避免在
/readyz中执行耗时操作（如全表 count），超时时间设为 1s，K8s 默认 probe timeout 是 1s
func readyzHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
status := map[string]interface{}{
"status": "ok",
"checks": map[string]string{},
}
if err := db.Ping(); err != nil {
status["status"] = "failure"
status["checks"].(map[string]string)["db"] = err.Error()
http.Error(w, "DB unreachable", http.StatusServiceUnavailable)
return
}
json.NewEncoder(w).Encode(status)
}
用 runtime.ReadMemStats + debug.ReadGCStats 补充运行时指标
Prometheus 标准指标不包含 Go 运行时细节，但 GC 频率、堆分配速率、goroutine 泄漏是微服务性能退化的最常见原因。这些数据必须主动采集并暴露。
注意事项：
-
runtime.ReadMemStats是 cheap 操作，可每 10s 调用一次；但debug.ReadGCStats有锁，建议每 30s 一次 - 将
MemStats.Alloc、MemStats.TotalAlloc、MemStats.NumGC注册为Gauge，而非Counter，因为它们是瞬时值 - 注意
GOGC环境变量影响：默认 100 表示当新分配内存达到上次 GC 后存活内存的 100% 时触发 GC，若服务长期低负载，可能 GC 频率过低导致突发流量时 STW 时间飙升 - 不要只看
NumGC，要结合PauseTotalNs / NumGC算平均 STW 时间，超过 5ms 就需排查
真正难的不是埋点，而是指标命名一致性、标签粒度取舍、以及把 tracing 数据和 metrics 关联起来做根因分析——比如某接口 P99 升高时，自动捞出该时间段内 span duration > 2s 的所有下游调用，再比对对应 service 的 CPU 和 GC 指标。这需要在采集层就对 trace_id、service_name、host 做统一打标，而不是等数据进 Grafana 再拼接。