go微服务监控告警需暴露真实可用指标、设置合理告警规则并确保告警触达：在init()注册多维业务指标（如http延迟、db操作），用rate和delta计算避免误报，/healthz轻量探测加超时保护，所有告警配for:3m，指标须对应可执行运维动作。
Go 微服务的监控报警不是配个 Prometheus 就完事——漏掉 http.Server 的超时指标、没暴露 runtime.NumGoroutine()、或者把 prometheus.MustRegister() 放在 goroutine 里，都会让告警变成“事后诸葛亮”。
怎么暴露真实可用的指标？
很多团队用 promhttp.Handler() 暴露 metrics，但只挂了默认指标（go_gc_duration_seconds 等），却忽略了业务关键路径。比如 HTTP 请求延迟、数据库连接池等待时间、gRPC 方法成功率这些不主动打点，Prometheus 就永远看不到瓶颈在哪。
- 用
prometheus.NewHistogramVec()按 path + status 分桶记录 HTTP 延迟，别只用一个全局prometheus.NewHistogram() - 数据库操作必须包裹
prometheus.NewCounterVec()和prometheus.NewHistogramVec()，字段包含db、operation（query/update）、error（true/false） - 避免在 handler 里直接调
prometheus.MustRegister()—— 它 panic 且不可重复注册，应在init()或 main 启动时一次性注册
为什么告警规则总不准？
告警不准，90% 是因为用了静态阈值（比如 CPU > 80%）或没对齐数据采集周期。Go 服务常因 GC 暂停导致短时 runtime.GCStats().NumGC 突增，如果告警规则写成 rate(go_gc_duration_seconds_sum[1m]) > 0.1，就会误报。
- HTTP 错误率用
rate(http_request_duration_seconds_count{status=~"5.."}[5m]) / rate(http_request_duration_seconds_count[5m])，窗口至少 5 分钟，避开毛刺 - Goroutine 泄漏看
delta(runtime_num_goroutine[1h]) > 100，而不是绝对值 > 5000 —— 不同服务 baseline 差异太大 - 所有告警规则加
for: 3m，防止瞬时抖动触发
怎么让报警真正触达人？
Alertmanager 配了 email、Webhook，但 Go 服务本身没做健康检查探针，Kubernetes 就可能把流量导给一个卡在 GC 中的 Pod；或者 http.ListenAndServe() 没设 ReadTimeout，导致 /healthz 一直 hang 住。
- 实现
/healthz必须轻量：只检查本地 listener 是否可 bind、DB 连接池db.Ping()（带 context.WithTimeout），别查 Redis 或下游服务 - 在
http.Server上显式设置ReadTimeout、WriteTimeout、IdleTimeout，否则 /metrics 也可能阻塞，导致 Prometheus 抓取失败 - Alertmanager 的 Webhook 接收端要校验
X-Hub-Signature-256，不然恶意请求能伪造告警
最难的不是写 exporter，而是让每个指标都对应一个可执行的运维动作——看到 grpc_server_handled_total{service="user",code="Unknown"} 暴涨，得立刻知道该查 client 的 context deadline 还是 server 的 handler panic 日志。指标和代码必须一对一绑定，否则监控就只是仪表盘上跳动的数字。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
