HQY

×

Grafana Alerting 实战:主机异常自动通知到企微群

hqy hqy 发表于2026-10-23 16:34:57 浏览5 评论0

抢沙发发表评论

导读:前几篇我们把 Zabbix 的主机和 MySQL 指标搬进了 Grafana 大屏。但大屏再漂亮,也得有人"盯着"才算数——值班同学不可能 7×24 盯着墙。这篇补上闭环的关键一块:Grafana Alerting 告警链路。CPU 飙了、磁盘满了、MySQL 延迟超阈值,Grafana 自动把告警卡片推到企微群,30 秒内 @ 到人。全程 5 步配置,附每一步的高清截图。

1

为什么不用 Zabbix 自带告警?

Zabbix 的 Trigger + 动作体系很成熟,但当你已经把展示层统一到 Grafana之后,告警也放进 Grafana 有三个实打实的好处:

对比项
Zabbix Trigger
Grafana Alerting
与大盘的关系
两套体系,图表在 Grafana、告警在 Zabbix
同一个系统里,点告警直接跳大屏
告警条件表达力
函数语法门槛高
Reduce + Threshold 拼积木式配置
路由灵活度
动作条件里写逻辑
按 Label 树状路由,改群不改规则
消息内容定制
宏组合,调试繁琐
模板变量直取查询结果值

当然,Zabbix 侧的告警可以继续保留作为"老保底",两者并存互不影响。


2

先看全链路:一条告警是怎么流到企微群的

Zabbix 指标(API)
  ↓ Grafana 定时查询(每 30s 评估)
  ↓ Alert Rule:last() of CPU load IS ABOVE 阈值
  ↓ 打上 Label(severity=critical)
  ↓ Notification Policy 按 Label 匹配路由
  ↓ Contact Point:Webhook → 企微群机器人
  ↓ ✔ 运维告警群收到告警卡片

记住这条链路的四个关卡:规则(何时响)→ 标签(我是谁)→ 策略(发给谁)→ 渠道(怎么发)。下面逐步打通。

3

第一步:创建告警规则(Alert rules)

进入 Alerting → Alert rules → + New alert rule。核心是把"CPU 负载过高"翻译成三段式条件:

  • 查询 A

    :Zabbix 数据源,Group: Linux servers → Host: $host → Item: CPU load (1m);
  • 表达式 B

    :Reduce → last(),取最近一个采样点;
  • 表达式 C

    :Threshold → IS ABOVE 阈值。超过即 Firing。
Grafana 告警规则编辑
▲ 告警规则编辑:查询 A + Reduce(last)+ Threshold 三段拼装,Firing 状态一目了然

三处细节决定告警好不好用:

  • 评估间隔

    :Rule group 里设 30s,越短发现越快,但别低于采集周期;
  • Labels

    :打上 severity=critical、team=sre——这是后面路由的"钥匙";
  • Annotations

    :用 {{$host}} 1分钟负载={{$values.B}} 把具体数值写进消息,收到告警不用再翻系统。

踩坑提醒:新装的 Grafana 如果 Alerting 菜单里没有 unified alerting 相关页面,检查 ngalert 是否启用(Grafana 9+ 默认开启,7.0 升级上来的老实例需要手动开)。另外规则保存后默认暂停评估的实例极少见,但首次建议点 Preview 看一眼条件预览再保存。

4

第二步:配置企微群通知渠道(Contact points)

先在企微群里建机器人:群设置 → 群机器人 → 添加机器人,复制拿到的 Webhook 地址(形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx)。

然后进入 Alerting → Contact points → + Add contact point:

  • Integration

    :选 Webhook;
  • URL

    :填中继服务地址(直连企微群机器人的方案见下方提醒);
  • HTTP Method

    :POST,Content type 选 application/json;
  • 保存后点 Test,群里出现一条测试消息即为打通。
Grafana 通知渠道配置
▲ Contact points:企微运维告警群设为 Default 兜底渠道,Body 由中继转成企微 markdown 卡片

关键认知(少走 2 小时弯路):企微群机器人只认它自己的报文格式(msgtype: markdown),而 Grafana 的通用 Webhook 发的是自己的 payload,直连会 400。三个解法:
① 写一个 10 行的轻量中继(Nginx + Lua / 一个 Flask 脚本),把 Grafana payload 转成企微格式——常用;
② 用 Grafana OnCall,自带企微集成,还能做认领、升级;
③ 保留 Zabbix 侧企微告警媒介,Grafana 只做大屏——不推荐,链路分裂。

5

第三步:通知策略(Notification policies)— 谁的告警进谁的群

这是 Alerting 里非常关键的一层。进入 Alerting → Notification policies,树状结构一目了然:

  • Default policy

    :兜底渠道设为「企微运维告警群」,没匹配到规则的告警都发这里;
  • 子策略 1

    :Matcher severity = critical → 企微运维告警群,并设置 Group by: host(同一主机的多条告警合并,5 分钟内不重复轰炸);
  • 子策略 2

    :Matcher team = dba → 企微 DBA 群;
  • 子策略 3

    :Matcher severity = warning → 监控静默群(只在工作时间 @)。
Grafana 通知策略路由
▲ Notification policies 树:Label 是钥匙,换群、加群只动策略,一条规则都不用改

这样"值班"语义就出来了:critical 进值班群实时 @,warning 进静默群白天看,DBA 的数据库告警单独走自己的群,运维群里不再被 MySQL 告警刷屏。


6

实战效果:告警长什么样

压测把 web-prod-01 的 CPU 拉高,30 秒内告警进入 Firing。回到 Alerting → Alert list,触发中、待定、已恢复的状态和趋势尽收眼底:

Grafana 告警总览
▲ Alert list:3 条 critical 触发中,恢复时长(MTTR)也有了量化数据

与此同时,企微群里收到两张 markdown 卡片——标题红色、主机、级别、当前值、持续时长、直达 Grafana 的链接一应俱全:

企微群收到的告警消息
▲ 运维告警群实况:Grafana 机器人推送的告警卡片,点链接直接跳到对应大屏

指标回落并持续一段时间后,同一条消息会自动补充"Resolved 已恢复",告警有始有终,值班同学不用手工关单。

7

进阶技巧:让告警更"懂事"

  • Pending 缓冲,拒绝抖动

    :Condition 里的 for 2m(Alert Evaluation Behavior → Set alert state if error / pending)让条件持续 2 分钟才 Firing,瞬时毛刺不再半夜叫人;
  • 按主机合并轰炸

    :子策略里 Group by host,同一主机批量告警合并成一条 markdown,加上 Mute timings 设定免打扰时段;
  • 消息里带数值

    :Annotations 用 {{$values.B}}(人类可读)与 {{$value}}(原始值),配合 {{$labels.host}},卡片信息量拉满;
  • Keep Last State

    :数据源短暂断连时(评估失败)保持最后状态不发"Unknown 风暴",避免半夜被假告警吵醒;
  • Silence 静默窗口

    :变更窗口前在 Alerting → Silences 里按 host=xxx 静默 2 小时,发版不告警;
  • 告警即代码

    :规则支持导出 YAML(Alert rules → Export),放进 Git 走 CI 同步,多套环境一键复制。
8

常见问题(FAQ)

现象
排查方向
规则显示 Firing,企微群没消息
① Contact point 是否被策略引用(用了自定义策略但 Default 没兜住);② 中继服务日志有没有收到请求;③ 机器人 Webhook key 是否过期/被限流(每机器人 20 条/分钟)
Test 能发,真实告警不发
Test 不走 Notification policies,只测渠道本身;检查策略 Matcher 与规则 Label 是否拼写一致(区分大小写)
告警风暴,群被刷屏
开启 Group by host + group interval(默认 5m);检查是否有规则缺 for 持续条件
消息显示 No data / Unknown
查询返回空:确认 $host 变量取值、Zabbix 数据源账号 API 权限、Item 处于 Supported 状态
恢复通知不出现
Contact point / 策略里开启了 "Only send notifications when alert fires" 类选项的关掉;或策略层 resolve 被覆盖
9

写在最后

到这里,Zabbix × Grafana 系列的监控闭环就完整了:采集(Zabbix)→ 展示(Grafana 大屏)→ 告警(Alerting)→ 送达(企微群)。监控的价值不在图好看,而在"出事有人知道、多快知道、知道得够不够多"。一条带数值、带链接、自动恢复的企微卡片,往往比任何大屏都更能体现监控体系的成熟度。


打赏

本文链接:https://kinber.cn/post/6825.html 转载需授权!

分享到:


推荐本站淘宝优惠价购买喜欢的宝贝:

image.png

 您阅读本篇文章共花了: 

群贤毕至

访客