错误率监控应基于 HTTP 状态码打点而非 panic 捕获，用 CounterVec 按 status_code/path 统计，Grafana 中用 increase() 增量计算并过滤低流量场景。
如何用 Prometheus + Grafana 统计 http.Handler 的错误率
Go 服务的错误率监控，核心不是“捕获 panic”，而是对 HTTP 请求生命周期中可预期错误（如 4xx/5xx）做结构化打点。直接在 http.ServeHTTP 中埋点最轻量、最可靠。
常见错误是把日志行当指标——比如用 log.Printf("error: %v") 后再 grep 日志，这无法实时聚合、延迟高、且漏掉非日志路径的失败（如中间件提前 return）。正确做法是用 prometheus.CounterVec 按状态码和路由维度记录：
- 定义指标：
http_errors_total := prometheus.NewCounterVec(prometheus.CounterOpts{Name: "http_errors_total"}, []string{"status_code", "path"}) - 注册到默认注册器：
prometheus.MustRegister(http_errors_total) - 在自定义 handler 尾部判断：
if statusCode >= 400 { http_errors_total.WithLabelValues(strconv.Itoa(statusCode), r.URL.Path).Inc() }
注意：不要在 http.Error() 调用后立刻计数——它只是写响应头和 body，实际 writeHeader 可能被后续中间件覆盖。应在 ResponseWriter 的包装体（如 responseWriter.Status()）确认最终状态码后再打点。
为什么 recover() 不该用于错误率统计
recover() 只捕获 panic，而 panic 是异常中断，不是业务错误。把它当“错误”统计会导致两个严重偏差：
立即学习“go语言免费学习笔记（深入）”；
- 99% 的 HTTP 错误（如参数校验失败、DB 查询为空、第三方 API 返回 401）根本不会 panic，漏报率极高
- panic 往往是程序缺陷（空指针、切片越界），频次低但危害大；混入错误率指标后，会掩盖真实的服务可用性问题
- 在 HTTP handler 外层加
defer/recover会吞掉原始 panic 信息，不利于 debug（比如丢失调用栈）
如果真要监控 panic，应单独用 panics_total 计数器，并触发独立告警（如 5m 内 > 0），而不是塞进“错误率”这个语义明确的指标里。
net/http/pprof 不能替代错误率监控
有人误以为开启 pprof 就能看错误——其实 pprof 只暴露运行时 profile（goroutine、heap、block），不包含任何请求级业务指标。它的 /debug/pprof/trace 或 /debug/pprof/goroutine?debug=2 甚至可能因采样机制漏掉短时高频错误。
真正需要的是请求粒度的标签化计数，而非堆栈快照。如果你发现必须靠 pprof 才能定位错误，说明前置的日志结构化和指标埋点已经失效——这时候补监控不如先补 handler 的 error 返回路径和 context 超时控制。
Grafana 告警规则里别用平均值算错误率
错误率 = 错误请求数 / 总请求数，但直接用 rate(http_errors_total[5m]) / rate(http_requests_total[5m]) 在低流量时段会剧烈抖动（分母接近 0 导致结果失真）。更稳的做法是：
- 用
increase()算绝对增量，再做除法：increase(http_errors_total{job="myapp"}[5m]) / increase(http_requests_total{job="myapp"}[5m]) - 加兜底过滤：
AND http_requests_total > 10（避免请求量 - 错误率阈值别设死：对管理后台接口可设 1%，对支付回调接口建议 0.1%，不同 path 应分组配置
另外，rate() 基于采样窗口内斜率估算，当 scrape 间隔大于 15s 或存在丢包时，rate() 结果可能为负或突变。生产环境务必确保 Prometheus 抓取间隔 ≤ 10s，且网络稳定。
