Go云原生监控需分层设计：日志用Zap+Lumberjack结构化输出并注入trace_id；指标用Prometheus client暴露规范化的业务与运行时指标；追踪、日志、指标通过OpenTelemetry统一上下文；采集由sidecar或agent完成，应用仅负责暴露。
在 Go 语言开发的云原生应用中，监控不是“加个库就完事”，而是需要分层设计：日志采集要结构化、低侵入；指标暴露要符合 Prometheus 规范；两者还要能关联定位问题。核心是用对工具、写好接口、留出扩展点。
用 Zap + Lumberjack 做结构化日志输出
Zap 是 Go 生态最主流的高性能结构化日志库，比标准 log 快数倍，且天然支持 JSON 输出，便于 ELK 或 Loki 摄入。Lumberjack 可无缝接入做日志轮转，避免磁盘打满。
- 初始化时配置 JSON 编码器、添加 service name 和 env 字段，方便后续按服务过滤
- 用 zap.String("trace_id", ctx.Value("trace_id").(string)) 注入链路 ID，打通日志与分布式追踪
- 禁止在日志中拼接字符串（如 fmt.Sprintf），全部走 zap.String("key", value) 结构化字段
- 错误日志必须带 stacktrace：用 zap.Error(err) 而非 zap.String("error", err.Error())
用 Prometheus Client Go 暴露标准指标
云原生监控默认对接 Prometheus，Go 应用需通过 prometheus/client_golang 暴露 /metrics HTTP 端点。重点不是“埋多少点”，而是暴露有意义的业务和运行时指标。
- 定义指标时带上 namespace 和 subsystem，例如：prometheus.NewCounterVec(prometheus.CounterOpts{Namespace: "myapp", Subsystem: "http", Name: "requests_total", Help: "Total HTTP requests"})
- HTTP 请求延迟用 HistogramVec，按 path 和 status 分桶；连接池使用率用 Gauge 实时反映
- 在 HTTP handler 中用 middleware 自动记录请求量、延迟、状态码，避免每个 handler 重复写
- 运行时指标（goroutines、gc pause）可直接复用 prometheus.DefaultRegisterer.Collector 中的 runtime.NewGoCollector()
用 OpenTelemetry 统一追踪、日志、指标三者上下文
单看日志或指标很难定位根因。OpenTelemetry 提供统一的 context 传播机制，让 trace_id 在日志、指标、HTTP header、消息队列中自动透传。
立即学习“go语言免费学习笔记（深入）”；
- 初始化 OTel SDK 时启用 trace、metric、log bridge（需搭配 go.opentelemetry.io/otel/log 或 zap-otel 集成）
- HTTP middleware 中从 request context 提取 trace_id，并注入到 zap logger 的 With() 中
- 指标收集器（如 http duration histogram）可绑定当前 span，自动打上 service.name、http.route 等标签
- 避免手动传 trace_id 字符串，始终用 otel.GetTextMapPropagator().Inject() 和 Extract()
部署时通过 sidecar 或 agent 集中采集，不依赖应用内推送
云原生场景下，采集逻辑应与业务解耦。应用只负责“暴露”，采集由 infra 层完成。
- 日志：应用 stdout 输出 JSON 日志，由 Fluent Bit / Vector sidecar 收集并转发至 Loki 或 ES
- 指标：Prometheus 通过 Kubernetes ServiceMonitor 或 PodMonitor 主动抓取 /metrics 端点，无需应用主动上报
- 追踪：OTel Collector 以 DaemonSet 方式部署，接收应用通过 OTLP 协议上报的 span，再导出到 Jaeger / Tempo
- 健康检查端点（如 /healthz）也建议返回结构化 JSON，供巡检系统解析，而非仅返回 200
不复杂但容易忽略的是上下文一致性——同一请求的日志行、指标样本、trace span 必须能靠 trace_id 对齐。只要在初始化 logger、HTTP handler、OTel tracer 时共享 context 并正确注入字段，后续排查效率会大幅提升。
