当前位置：首页 > 问答 > 正文

教你一步步弄懂Prometheus咋用企业微信发告警消息，简单实操不复杂

芮以莲
问答
2026-01-19 07:19:16
2

基于Prometheus官方文档、Alertmanager配置指南及企业微信机器人开放文档的整合与实践。

教你一步步弄懂Prometheus咋用企业微信发告警消息,简单实操不复杂

咱们得搞清楚这事儿是怎么一回事,Prometheus就像是个24小时不休息的保安，它不停地检查你的服务器、数据库这些应用是不是健康，当它发现某个指标不对劲，比如CPU使用率爆表或者网站打不开了，它自己不会直接跑去告诉你，它会把这个“警情”扔给另一个叫Alertmanager的“报警调度员”。

Alertmanager这个调度员的工作就是接收Prometheus发来的警报,然后决定怎么处理它：是静默掉重复的警报，还是分组把同类警报合并成一条，最关键的是，它要负责把最终的消息通过不同的渠道发出去，比如咱们今天要弄的企业微信。

整个流程就是：Prometheus发现故障 -> 告诉Alertmanager -> Alertmanager加工处理 -> 通过企业微信机器人发送到你的群里。

下面我们就来一步步实操。

第一步：在你企业的微信群里添个“机器人”

打开你的企业微信,找到一个你想接收报警消息的群聊。
点击右上角的群菜单,找到【添加群机器人】。
点击【新建一个机器人】，给它起个名字，服务器报警小助手”。
创建成功后,你会得到一个以 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key= 开头的一长串网址，这个网址超级重要，它就是机器人的“联系方式”，千万要复制保存好，待会儿Alertmanager就靠它来发送消息。

第二步：配置Alertmanager，让它认识这个机器人

Alertmanager通常用一个叫 alertmanager.yml 的配置文件来告诉它该怎么工作，我们需要修改这个文件。

找到你的Alertmanager的配置文件在哪,如果你是用Docker或者Kubernetes部署的，可能需要修改对应的ConfigMap或者挂载的文件。
用文本编辑器打开 alertmanager.yml 文件，我们需要重点关注两个部分：receivers 和 routes。

下面是一个最简化的配置示例,你完全可以照着改：

global:
  # 这里可以配置一些全局设置，比如解决超时时间，我们先不管它。
route:
  # 路由树的开头，所有警报默认都从这里进入
  group_by: ['alertname'] # 按警报名称分组，这样同一个问题的多个实例警报会合成一条消息
  group_wait: 10s # 分组等待时间，等10秒看有没有同组的其他警报，一起发
  group_interval: 10s # 同一组警报再次发送的间隔时间
  repeat_interval: 1h # 如果警报一直没解决，多久重复发送一次
  receiver: 'wechat-webhook' # 默认的接收器，就是我们下面要定义的企业微信机器人
receivers:
- name: 'wechat-webhook' # 接收器的名字，和上面route里的receiver对应
  webhook_configs:
  - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的机器人Webhook地址的KEY部分' # 把第一步里得到的完整URL贴在这里
    send_resolved: true # 这个很重要！意思是当警报恢复（问题解决了）时也发送一条消息通知你

简单解释一下：route 部分规定了警报的传递规则，这里我们用了最简单的，所有警报都默认发给名叫 wechat-webhook 的接收器，而 receivers 部分就定义了这个接收器，它其实就是一个webhook（网络钩子），指向了我们企业微信机器人的那个网址。

修改完配置文件后,保存退出，然后重启你的Alertmanager服务，让新的配置生效，重启的方法取决于你的部署方式，比如用Docker的话可能就是 docker restart alertmanager。

第三步：在Prometheus里设置报警规则

光有报警通道还不行,我们得告诉Prometheus保安，什么情况才需要报警，这个是通过Prometheus的“报警规则”文件来定义的。

找到Prometheus的配置文件 prometheus.yml。

在配置文件里,找到 rule_files 这个部分，它用来指定报警规则文件的位置。

rule_files:
  - "/etc/prometheus/rules/*.yml" # 假设你的规则文件都放在这个目录下

在那个指定的目录下（/etc/prometheus/rules/），创建一个新的规则文件，node_alerts.yml。

在这个文件里,我们可以写一些简单的规则，定义一个“实例下线”的警报：

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job="node-exporter"} == 0 # 这是PromQL表达式，意思是监控的node-exporter job如果状态为0（下线）就触发
    for: 1m # 持续1分钟都是这个状态才发警报，避免网络抖动误报
    labels:
      severity: critical # 给警报贴个标签，严重等级是“严重”
    annotations:
      summary: "实例下线：{{ $labels.instance }}"
      description: "{{ $labels.instance }} 上的 job {{ $labels.job }} 已经下线超过1分钟。" # 这些描述会出现在企业微信消息里

保存这个规则文件,然后重启Prometheus服务，或者让它重新加载配置（通常有 curl -X POST http://localhost:9090/-/reload 这样的方法）。

第四步：测试一下，看灵不灵

所有东西都配置好了,你可以故意制造一个故障来测试，比如把Prometheus监控的一个节点服务（比如node-exporter）关掉。

等上一两分钟,你应该就能在企业微信群里看到这样的消息了：

【Prometheus警报恢复】
状态：**firing**
警报：InstanceDown
级别：critical实例下线：192.168.1.100:9100
描述：192.168.1.100:9100 上的 job node-exporter 已经下线超过1分钟。
触发时间：2023-10-27 15:30:00

当你重新启动那个被关掉的服务,过一会儿还会收到一条状态是“resolved”的恢复消息，告诉你问题解决了。

这样一来,一个最简单的Prometheus通过企业微信发告警的流程就全部跑通了，之后你要做的就是根据你的实际需求，去增加更多的报警规则，比如磁盘快满了、内存不足了等等，配置的思路都是一模一样的。

教你一步步弄懂Prometheus咋用企业微信发告警消息，简单实操不复杂