HTTP错误率告警应基于历史基线设定阈值，避免静态阈值误报；延迟类指标必须用histogram_quantile计算P95而非平均值；告警规则需包含service和instance等关键label以保障Alertmanager路由正确；for时长需按指标特性差异化设置，且须小于evaluation_interval。

HTTP 错误率告警怎么设才不误报

直接用 rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01 很容易误报——尤其当服务本身就有稳定低比例 5xx（比如支付回调常年 0.2%）。

• 先查基线：跑一次 rate(http_requests_total{code=~"5.."}[1h]) 看过去一小时真实 5xx 占比，再定阈值。若基线是 0.002，那阈值至少设成 0.01 以上，或改用绝对增量（如 rate(http_requests_total{code=~"5.."}[5m]) > 0.5）
• 避免短窗口抖动：不用 [1m] 这类极短区间，[5m] 是较稳妥起点；对核心路径（如下单、支付），可额外加一条 for: 1m 的瞬时毛刺告警
• 区分接口重要性：静态资源（/static/.*）建议关掉错误率告警，或把阈值提到 5% 以上

延迟类指标该用平均值还是分位数

用 avg(http_request_duration_seconds_sum / http_request_duration_seconds_count) 是典型陷阱——单个慢请求会拉高均值，掩盖多数请求其实很快的事实。

• 必须用 histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))，95 分位更能反映用户真实体感
• 别漏掉 sum by (le, service) 这步聚合，否则 quantile 计算会因 label 组合爆炸而失败
• 如果直方图没打点（比如只暴露了 Summary），就只能用 summary_quantile，但要注意 Summary 不支持多维 label 聚合，得提前在 Go 代码里按 service 和 path 分桶

告警规则里哪些 label 必须带

Alertmanager 路由依赖 label，缺关键字段会导致告警进错分组、甚至丢弃。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• service 和 instance 是硬性要求，否则 route 配置里的 match_re 或 group_by 全失效
• 业务上下文字段（如 trace_id、order_id）要提前塞进 alert rule 的 labels 块里：labels: { service: "payment", trace_id: "{{ $labels.trace_id }}" }
• 别在 alert rule 里写 annotations 依赖 $value —— Alertmanager 模板默认不渲染它，要用就得在 template 里显式写 {{ $value }}

for 字段设多长才合理

for: 2m 是常见默认值，但对不同指标意义差别很大。

• 错误率类：2m 合理，过滤瞬时网络抖动
• CPU/内存类：建议 5m～10m，避免容器启动时的短暂峰值触发
• 数据库连接池耗尽类：可设 30s，因为这种问题往往蔓延极快，等 2 分钟可能已雪崩
• 所有 for 值必须小于 Prometheus 的 evaluation_interval（默认 15s），否则规则压根不会触发

真正难的是把告警和业务 SLI 对齐——比如“支付成功率 99.9%”这个目标，对应到 Prometheus 规则里，不是简单套个 0.1% 阈值，而是得结合历史波动、降级策略、下游依赖状态一起建模。很多团队卡在这一步，不是不会写 PromQL，是没把监控指标和业务目标真正挂钩。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！