Grafana接入Alertmanager时收不到告警？

Question

在Grafana接入Alertmanager后收不到告警，常见原因之一是告警规则触发但通知渠道配置错误。例如，Grafana内置的Alertmanager与外部Prometheus Alertmanager实例混淆，导致告警虽触发却未发送至正确接收器。此外，notification_interval设置过长、静默规则（silence）误配或webhook地址填写错误，也会导致告警“看似未送达”。需检查Grafana告警频道（Alert Channels）配置、确保Alertmanager集群状态正常，并通过日志确认通知是否实际发出。

Answer 1

一、问题现象与初步排查

在Grafana中配置告警并接入Alertmanager后，用户反馈无法收到告警通知。尽管告警规则已触发并在UI上显示为“firing”，但通知未到达邮件、钉钉或企业微信等接收端。

• 确认Grafana的告警引擎是否启用（feature_toggles = enable alerting）
• 检查Grafana是否使用内置Alertmanager还是外部Prometheus Alertmanager实例
• 查看Grafana日志：grep -i alert /var/log/grafana/grafana.log
• 通过Grafana UI进入“Alerting” → “Instances and history”验证告警是否真正触发

二、告警路由机制解析

理解从Grafana到通知接收者的完整链路至关重要：

1. 数据源查询结果满足告警条件
2. Grafana评估器判定状态变更（OK → Alerting）
3. 事件发送至其管理的Alertmanager（内置或外部）
4. Alertmanager根据route树匹配receiver
5. receiver执行具体通知方式（如email、webhook）
6. 若notification_interval设置为1小时，则重复通知间隔过长，易被误判为“未送达”
7. 静默规则（silence）可能屏蔽了本应发出的通知
8. Webhook地址拼写错误或目标服务不可达导致投递失败
9. 防火墙/Nginx反向代理阻断了出站请求
10. 接收系统无响应或返回非2xx状态码

三、核心配置项审查表

配置项	位置	常见错误示例	建议值
alertmanager_url	grafana.ini 或 provisioning/yaml	指向了测试环境AM	http://alertmanager-prod:9093
notification_interval	Alertmanager config receiver level	设置为6h	2m~5m（生产推荐）
webhook_configs.url	receiver 配置块	https://oapi.dingtalk.com/robot/send?accesstoken=错位复制	使用Secrets管理敏感信息
group_wait	route 配置	设为5min 导致延迟感知	30s
resolve_timeout	AM 全局配置	超过Grafana默认值引发不一致	5m

四、诊断流程图：告警丢失路径分析

graph TD
    A[告警未收到] --> B{Grafana内置AM?}
    B -- 是 --> C[检查Grafana Alert Channels]
    B -- 否 --> D[确认external AM URL可达]
    C --> E[测试通知渠道连通性]
    D --> F[curl http://am-host:9093/api/v2/alerts]
    F --> G{返回告警列表?}
    G -- 否 --> H[检查rule_evaluations & alerts_sent指标]
    G -- 是 --> I[查看AM logs: 'NotifySuccess' or 'NotifyFailed']
    I --> J{Webhook返回200?}
    J -- 否 --> K[排查接收端服务状态]
    J -- 是 --> L[确认消息是否被过滤/丢弃]
    

五、深入日志与指标分析

高级运维需结合多维度信号交叉验证：

# 查询Alertmanager自身运行状态
curl -s http://alertmanager:9093/metrics | grep -E "alertmanager_notifications_failed_total|alertmanager_silences"

# 查看Grafana内部告警调度器状态
SELECT * FROM alert WHERE state = 'alerting'; -- via SQL backend

# Prometheus抓取Grafana暴露的指标
grafana_alerting_execution_time_seconds_count{result="success"}
grafana_alert_rule_group_iterations_missed

重点关注alertmanager_notifications_failed_total计数增长情况，结合level=error的日志条目定位根因。

六、典型误配置场景复现与修复

案例1：混合使用Grafana内置Alertmanager与外部Prometheus Alertmanager

• 现象：规则触发，但通知未发出
• 原因：conf/provisioning/alerting/ntwrkrules.yaml中指定的contact_point指向外部AM，而Grafana仍将告警推送给本地实例
• 解决方案：统一告警出口，关闭内置AM（disable_builtin_alertmanager=true），并通过provisioning配置全局notifier

案例2：静默规则覆盖范围过大

{
  "id": "abcd-1234",
  "createdBy": "admin",
  "comment": "维护期间屏蔽所有主机down告警",
  "startsAt": "2025-04-01T00:00:00Z",
  "endsAt": "2025-04-07T00:00:00Z",
  "matchers": [
    {
      "name": "alertname",
      "value": "HostDown",
      "isRegex": false
    },
    {
      "name": "severity",
      "value": "critical",
      "isRegex": true
    }
  ]
}
    

上述静默规则因isRegex=true且value为critical，实际会匹配所有包含critical字样的标签，造成过度抑制。

七、自动化检测脚本建议

构建CI/CD流水线中的告警健康检查环节：

#!/bin/bash
# check-alertmanager-connectivity.sh
AM_URL="http://$ALERTMANAGER_HOST:9093"
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" "$AM_URL/api/v2/status")
if [ "$HTTP_CODE" != "200" ]; then
echo "FATAL: Cannot reach Alertmanager"
exit 1
fi
echo "OK: Alertmanager is reachable"
# 进一步可集成对接收器做dry-run测试 此类脚本可用于Kubernetes Pod启动探针或GitOps部署前验证。