必须用 Prometheus HistogramVec 暴露接口耗时并设合理 buckets 和标签，告警规则须在 Prometheus 中基于 histogram_quantile 计算 P99 且带 for: 2m，通知需含 service_name、env、instance、method、endpoint 等关键字段。
慢接口告警不能只靠日志里 grep “latency > 2000”，必须把响应时间指标暴露给 Prometheus，并在服务端完成阈值判定与事件生成——否则无法做到准确、去抖、可抑制。
怎么用 prometheus/client_golang 暴露接口耗时指标
核心是采集每个请求的处理时长，聚合为直方图（prometheus.HistogramVec），而不是简单记录最大值或平均值。直方图支持 rate() 和 histogram_quantile() 计算 P95/P99，这才是判断“慢”的合理依据。
- 不要用
Gauge或Counter存单次耗时——丢失分布信息，无法做分位数告警 - 必须设置合理的
Buckets，例如[]float64{0.1, 0.2, 0.5, 1, 2, 5, 10}（单位：秒），覆盖业务真实延迟范围 - 标签要包含
method和endpoint，否则告警无法定位具体接口；避免加高基数标签（如user_id）导致指标爆炸
示例注册逻辑：
var httpDuration = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "HTTP request duration in seconds.",
Buckets: []float64{0.1, 0.2, 0.5, 1, 2, 5, 10},
},
[]string{"method", "endpoint", "status"},
)
func init() {
prometheus.MustRegister(httpDuration)
}
为什么告警规则必须写在 Prometheus 里，而不是 Go 代码里
在 Go 中写 if latency > 2000 { sendAlert() } 看似直接，但会立刻掉进三个坑：无法去抖、无法跨实例聚合、无法自动恢复通知。
立即学习“go语言免费学习笔记（深入）”；
- 单机判定 → 同一接口在多个实例上反复触发告警，形成风暴
- 无状态重试 → 进程重启后计数清零，漏告；网络抖动时误告
- 无法做 P99 计算 → 你真正该关心的是“99% 的请求都卡在哪儿”，不是某一次超时
正确做法是让 Prometheus 拉取所有实例的 http_request_duration_seconds_bucket，用 histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, method, endpoint)) 算出各接口 P99 延迟，再由 Alertmanager 统一管理静默、抑制和通知。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何防止“慢接口告警”变成噪音
关键不是调低阈值，而是加两层过滤：时间窗口收敛 + 状态机兜底。
- 告警规则中必须带
for: 2m，避免瞬时毛刺触发；P99 超过 2s 持续 2 分钟才告，比单次超时靠谱得多 - 在 Go 服务内维护一个轻量级状态映射：
map[string]time.Time（key 是"POST:/api/order"），每次触发告警前检查是否在冷却期内（比如 10 分钟），避免重复推送 - 收到“已恢复”事件时，主动清空该 key —— 不依赖 Alertmanager 的 resolved 通知，因为网络可能丢包
这个 map 不需要持久化，也不用加锁到每个请求；用 sync.Map + 定期清理 goroutine 即可平衡性能与准确性。
通知内容里必须带什么字段才能快速止损
光说“/api/pay 响应慢”没用。一线同学打开告警第一眼要能判断：是不是我的接口？最近有没有发版？负载高不高？
- 必须带
label：service_name、env、instance（IP:port）、method、endpoint - 必须带
annotation：当前 P99 值（{{ $value }}s）、过去 5 分钟错误率（rate(http_requests_total{status=~"5.."}[5m])）、同实例 goroutine 数（go_goroutines） - 避免在通知模板里拼接冗余信息，比如“请立即处理”，运维同学早看腻了
这些字段全靠 Prometheus rule 中的 labels 和 annotations 表达式填入，不是 Go 代码里硬编码的字符串。
最难的不是把延迟打点上报，而是让告警从“我知道它慢了”变成“我知道它为什么慢、影响哪些用户、要不要回滚”。这要求指标、日志、链路三者标签对齐，而慢接口告警只是那个最先敲响的钟——钟声本身不解决问题，但得让人听得清、找得准。
