Go服务的告警不会自动触发——必须在Prometheus服务端显式配置 alert_rules.yml，且规则中引用的指标需已在Go程序中注册并暴露。
Go代码里要先暴露可被PromQL查询的指标
没有暴露指标，Prometheus连数据都抓不到，更谈不上触发告警。常见错误是只调用了 prometheus.MustRegister()，但没在HTTP handler中实际写入值；或者注册了指标却忘了加 gin.WrapH(promhttp.Handler()) 暴露 /metrics 端点。
- 直方图延迟指标（用于P95/P99告警）必须用
prometheus.NewHistogramVec()定义，并在请求中间件中调用.Observe() - 计数器如
http_requests_total需带状态码、方法等标签，否则无法写出rate(http_requests_total{status=~"5.."}[5m])这类表达式 - 暴露端点路径默认是
/metrics，若自定义了路径（如/monitor/metrics），Prometheus的scrape_configs也得同步改metrics_path
Prometheus rules.yml 中的 expr 必须能实际查到数据
写完规则后访问 http://<prometheus-url>/graph</prometheus-url> 手动执行 expr，确认返回非空结果。很多告警长期不触发，根本原因是表达式语法对但无数据匹配——比如指标名拼错、标签值不一致、或采样窗口太短导致 rate() 计算失败。
- 检查指标是否存在：
curl http://localhost:9090/metrics | grep http_request_duration_seconds - 验证 PromQL 表达式：
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))要求原始指标是带_bucket后缀的直方图，且le标签存在 -
for: 2m不代表“2分钟后发告警”，而是要求该条件连续两个采集周期（默认15s）都为真；若scrape_interval是30s，则实际需持续至少60s
Alertmanager 配置决定告警是否真正发出
Prometheus只负责“生成告警事件”，真正发邮件、钉钉、短信的是 Alertmanager。常见问题是 Prometheus 显示 FIRING，但收不到通知——大概率是 Alertmanager 的 route 配置没匹配上告警的 labels，或接收器（receiver）未正确定义。
- 确保 Alertmanager 的
global.smtp_from和邮箱配置正确，否则邮件静默失败 - Go服务告警规则里写的
labels: {severity: "critical"}，必须和 Alertmanager 的route.matchers对得上，例如：matchers: ['severity="critical"'] - 使用
amtool alert list可实时查看 Alertmanager 收到哪些告警，比翻日志快得多
最容易被忽略的一点：Go进程重启后，所有计数器（counter）会重置为0，但直方图（histogram）的 _sum 和 _count 也会重置——这会导致 rate() 在重启后头几个周期计算异常，可能误触发延迟告警。生产环境建议搭配 prometheus/client_golang 的 process_start_time_seconds 辅助判断是否刚重启。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
