prometheus + fiber 通过 fiber/prometheus 中间件暴露标准指标，需在路由前注册 prom.handler() 并确保 /metrics 路径不被拦截；自定义指标须预创建、避免高基数标签；超时与错误率需手动补全监控。
怎么用 Prometheus + Fiber 内置中间件暴露指标
Fiber 本身不内置指标收集，但官方推荐搭配 fiber/prometheus 中间件快速暴露标准 Prometheus 格式指标。它默认采集请求计数、延迟直方图、状态码分布三类基础指标，无需额外埋点。
关键点是：必须在路由注册前挂载，且不能被其他中间件（比如权限校验）拦截或提前写响应——否则指标采集会漏掉。
- 安装依赖：
go get github.com/gofiber/contrib/prometheus - 初始化时注册：
prom := prometheus.New()，然后app.Use(prom.Handler()) - 暴露指标端点：
app.Get("/metrics", prom.Handler())（注意路径必须是/metrics才能被 Prometheus 默认抓取） - 别把
prom.Handler()放在app.Static()或app.Get("/*")后面——静态资源和兜底路由会吞掉指标请求
为什么 /metrics 返回 404 或空响应
最常见原因是中间件顺序错乱或路径注册冲突。Fiber 的中间件执行顺序严格按 Use() 和 Get() 调用顺序，prom.Handler() 必须在所有业务路由之前注册，否则可能被前置中间件的 ctx.Status(401).Send() 或 return 提前终止。
另一个隐蔽坑：如果你用了 app.All("/*", someMiddleware) 这类通配路由，它会匹配 /metrics 并跳过后续 Get("/metrics")，导致 404。
- 检查
app.Use(prom.Handler())是否在app.Get("/metrics")之前 - 确认没有
app.All("/*", ...)或app.Use(...)中调用了ctx.SendStatus(404)或return - 用
curl -v http://localhost:3000/metrics看响应头是否为200 OK且 Content-Type 是text/plain; version=0.0.4
如何加自定义业务指标（比如 DB 查询耗时）
原生 fiber/prometheus 只覆盖 HTTP 层，DB、缓存、外部 API 等耗时需手动打点。推荐用 promauto.With(reg).NewHistogram() 创建带标签的直方图，避免重复注册同名指标。
重点：不要在每个请求里 NewHistogram()，而是在应用启动时一次性创建；标签值（如 db_name）应来自配置或常量，不能动态拼接用户输入——防止指标爆炸（cardinality explosion）。
- 示例：
dbLatency := promauto.With(reg).NewHistogram(prometheus.HistogramOpts{Name: "db_query_duration_seconds", Labels: map[string]string{"db": "primary"}}) - 在 DAO 方法中记录：
defer dbLatency.WithLabelValues("users").Observe(time.Since(start).Seconds()) - 避免用
c.Params("id")作为 label 值——每个用户 ID 都会生成新指标，内存和 Prometheus 存储扛不住
监控告警容易忽略的两个硬伤
一是超时指标缺失。Fiber 默认不暴露协程阻塞或 handler 超时事件，你得自己在关键路径加 time.AfterFunc() 或结合 context.WithTimeout() 打点；二是错误率计算偏差——fiber/prometheus 把所有非 2xx/3xx 都算作 error，但 400、401 这类客户端错误不该触发 P99 告警，得用 prometheus.NewCounterVec 单独统计服务端异常（5xx）。
真正上线后，第一个要看的不是 QPS，而是 http_request_duration_seconds_count{code=~"5.."} / http_request_duration_seconds_count 这个错误率比率，它比单看 5xx 计数更能反映服务健康度。
