Go云原生监控需日志、指标、追踪三者对齐同一请求，否则排查失效；/metrics须正确注册、早于Serve启动并启用GoCollector；Zap日志需中间件解析traceparent并注入子logger；HTTP延迟应优先用预设Buckets的Histogram而非Summary；OTel日志桥接不可跳过，需统一字段名并贯穿上下文。
Go 云原生应用的监控不是加个库就能跑通的事，真正落地时，日志、指标、追踪三者必须能对得上同一个请求——否则查问题时你看到的延迟高、错误多、日志里却找不到 trace_id，等于白搭。
怎么暴露/metrics端点才不会被Prometheus漏采
Prometheus 是 pull 模型，它只认标准格式的文本输出，且依赖 HTTP 状态码和响应头。很多服务启动后/metrics 能访问，但 Prometheus 抓不到数据，常见原因有：
-
http.Handle("/metrics", promhttp.Handler())没注册在正确的http.ServeMux上（比如用了 Gin，却没用gin.WrapH(promhttp.Handler())） - 启动了多个 HTTP server，但
/metrics只挂在一个未被 Prometheus 配置为 target 的端口上 - 指标注册太晚：在
http.ListenAndServe之后才调用prometheus.MustRegister(...)，导致首次抓取时指标为空 - 没启用默认运行时指标：漏掉
prometheus.MustRegister(prometheus.NewGoCollector())，Goroutine、GC 等关键指标就没了
建议统一在 main() 开头注册所有指标，并显式创建 prometheus.Registry 控制生命周期。
结构化日志里 trace_id 怎么注入才不丢
Zap 本身不感知 OpenTelemetry 上下文，trace_id 必须手动从 context.Context 中提取并传入 logger。常见错误包括：
- 在中间件外直接用全局
zap.L()，没有绑定 request context - 用
ctx.Value("trace_id")但没做类型断言或空值判断，panic 后日志全断 - HTTP header 中是
traceparent（W3C 标准），但代码里硬写成X-Trace-ID，上下游对不上
正确做法是：在 Gin 或 net/http middleware 中解析 otel.GetTextMapPropagator().Extract()，拿到 spanContext.TraceID().String()，再用 logger.With(zap.String("trace_id", tid)) 创建子 logger。后续所有日志都基于这个子 logger 输出。
为什么直方图比 Summary 更适合 HTTP 延迟统计
两者都能算 P95/P99，但HistogramVec 是服务端聚合，SummaryVec 是客户端聚合，这在云原生场景下差异巨大：
-
Summary每个实例独立计算分位数，K8s 里 Pod 重启、扩缩容后统计口径不一致，PromQL 查出来的 P99 是“拼凑结果”，不可信 -
Histogram只上报桶计数（_bucket）和总数（_sum/_count），Prometheus 在服务端用histogram_quantile()统一计算，结果稳定可复现 - 直方图需预设
Buckets，别用默认的 [0.005, 0.01, …] —— 对 HTTP 接口，建议按业务 SLA 设：[0.1, 0.3, 0.5, 1.0, 3.0, 10.0]
示例：
立即学习“go语言免费学习笔记（深入）”；
histogram := prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "HTTP request latency in seconds",
Buckets: []float64{0.1, 0.3, 0.5, 1.0, 3.0, 10.0},
},
[]string{"method", "path", "status"},
)OpenTelemetry 的 log bridge 为什么常被跳过
很多人集成 OTel 只做 trace 和 metrics，却忽略 log bridge，结果是：链路里能看到 span，日志里也有 trace_id，但 Grafana 中点击 trace 跳不过去对应日志。这是因为：-
go.opentelemetry.io/otel/log还在实验阶段，Zap 用户更倾向用uber-go/zap-otel（需手动桥接） - 日志字段名不统一：
trace_id、traceId、traceID混用，Loki 查询时得写正则匹配 - 没在 logger 初始化时注入
otel.LogRecord的 context 传播逻辑，导致异步 goroutine 中的日志丢失 trace_id
真正打通三者的最小闭环是：HTTP middleware 提取 trace_id → 注入 Zap logger → 指标 histogram 绑定当前 span → 所有日志和指标打上相同 service.name 和 trace_id 标签。
指标暴露容易，上下文贯穿最难；别让 trace_id 只活在第一个 handler 里。
