前言

Prometheus把异常检测出来，只解决了监控的一半。真正影响响应速度的，是告警能不能及时送到正在值班的人手里；如果还要主动打开Prometheus页面查看，很多故障依然会拖到用户反馈后才被发现。尤其当监控对象越来越多、告警规则越来越细以后，“告警有没有真正送达”本身也会变成监控体系里必须解决的一环。

这篇要解决的，就是把Prometheus告警真正送进钉钉。Alertmanager负责接收告警、分组、路由和恢复通知，prometheus-webhook-dingtalk负责把Alertmanager的Webhook转换成钉钉机器人能够接收的消息。

正文会先完成Prometheus与Alertmanager的连接，再创建钉钉机器人、部署prometheus-webhook-dingtalk，并配置Alertmanager把告警转发出去，实际验证钉钉能够正常收到消息。

在单群告警跑通以后，还会继续扩展到多个钉钉群，让不同团队接收各自需要关注的告警；后面再处理Prometheus与Alertmanager不在同一局域网时的通信问题。

所以整篇真正跑的是Prometheus触发告警 → Alertmanager分组与路由 → webhook-dingtalk转换消息 → 钉钉接收告警与恢复通知 → 多群分发 → 跨网络连接Alertmanager这条链。重点不是“发一条消息”，而是把告警真正变成可触达、可分流、可持续维护的通知流程。

1.为什么将Prometheus告警推送到钉钉？

把Prometheus告警推送到钉钉，核心价值是缩短“异常发生”和“责任人看到”之间的时间，同时把告警入口集中到团队日常使用的协作工具里。

1. 告警触达更及时，响应更迅速

钉钉作为国内企业广泛使用的即时通讯工具，几乎全员在线、消息必达。将告警直接推送至运维群或值班群，能确保问题在第一时间被看到，大幅缩短MTTR，避免小故障演变为大事故。

2. 统一告警入口，避免信息碎片化

传统方式可能依赖邮件、短信、Slack等多种渠道，容易造成告警分散、遗漏或重复处理。通过钉钉集中接收所有Prometheus告警，团队可在一个平台完成告警确认、讨论与协同处置，提升协作效率。

3. 支持富文本与结构化展示，信息更清晰

借助prometheus-webhook-dingtalk等中间件，告警消息可渲染为卡片式富文本，清晰展示：

• 告警名称（如HighCPUUsage）
• 严重等级（critical / warning）
• 故障实例（instance=192.168.1.10:9100）
• 触发时间与持续时长
• 快速跳转链接（直达 Grafana或Prometheus UI）

经过中间件转换后，告警名称、等级、实例、时间和跳转链接可以集中展示，处理时更容易快速定位重点。

4. 低成本、高可用的告警通道

相比短信或电话告警，钉钉推送零成本、无额度限制，且依托阿里云基础设施，服务稳定可靠。对于大多数非P0级别告警，钉钉是性价比极高的通知渠道。

2.前提条件

1. 本机已经部署prometheus和alertmanager

2. 具备一个可用的钉钉群，并拥有管理员权限

3. 可创建钉钉自定义机器人

4. 部署节点具备外网访问能力

5. Alertmanager与webhook服务网络互通

• Alertmanager所在主机必须能通过HTTP/HTTPS访问prometheus-webhook-dingtalk服务的地址
• 若两者部署在同一主机，注意Docker网络隔离问题（避免使用127.0.0.1，建议用宿主机IP或Docker自定义网络）。

6. 安装必要工具（用于部署与调试）

• Docker（推荐方式部署webhook服务）或systemd（二进制部署）

• curl / jq（用于测试API和解析JSON）

• 文本编辑器（如vim、nano）用于编写配置文件

  示例：检查Docker是否安装

docker--version

3.prometheus配置alertmanager

进入到prometheus配置文件，编辑配置文件，按照如图设置：

编辑后，重启prometheus：

systemctl restart prometheus

4.获取钉钉Webhook URL

打开钉钉群 → 点击右上角设置：

找到智能群助手 → 添加机器人：

添加自定义机器人：

点击添加：

给机器人起个名字，我这里是“prometheus告警”：

设置发消息关键词，因为现在钉钉对安全严格，所以需要设置限制，，也可以设置加签或者IP地址：

点击完成后，复制生成的Webhook，留着备用：

5.部署prometheus-webhook-dingtalk服务

创建配置文件dingtalk.yaml：

cat>dingtalk.yaml<<EOF targets: webhook1: url: https://oapi.dingtalk.com/robot/send?access_token=你的_access_token EOF

启动容器（假设配置文件在当前目录）:

dockerrun-d\--namedingtalk-webhook\-p8060:8060\-v$(pwd)/dingtalk.yaml:/etc/prometheus-webhook-dingtalk/config.yml\--restartalways\timonwong/prometheus-webhook-dingtalk:latest

6.配置Alertmanager告警

接下来配置Alertmanager的receiver和Webhook地址，让收到的告警继续转发到prometheus-webhook-dingtalk。

vialertmanager.yml

global: resolve_timeout: 2m route: group_by:['alertname']group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:'dingtalk-webhook'receivers: - name:'dingtalk-webhook'webhook_configs: - url:'http://<你的服务器IP> :8060/dingtalk/webhook1/send'send_resolved:true

systemctl restart alertmanager

替换 <你的服务器IP> 为运行prometheus-webhook-dingtalk的主机IP（如果是本机且Alertmanager也在本机，可用127.0.0.1，但注意Docker网络）

钉钉能够正常收到消息后，说明Prometheus → Alertmanager → webhook-dingtalk → 钉钉这条基础链路已经跑通。

7.告警多个钉钉群（拓展）

单个钉钉群已经能够接收告警以后，还可以继续扩展多个目标，让运维、开发或其他团队分别接收需要关注的消息，避免所有告警都堆在同一个群里。

获取另一个群的webhook（步骤和第4章节一致）。

配置文件dingtalk.yaml，添加两个钉钉群链接：

vidingtalk.yaml

targets: ops-team: url: https://oapi.dingtalk.com/robot/send?access_token=a391180a72b3c35f9308bbe1097dd5a29ca0cc440c6f1ee33601f8d5739ff6aa secret: secret1 dev-team: url: https://oapi.dingtalk.com/robot/send?access_token=3e373b6623264d1c71098acde924328d0e16753820a17475aa95bd6655111e04 secret: secret2

启动docker容器：

dockerrun-d\--namedingtalk-webhook\-p8060:8060\-v$(pwd)/dingtalk.yaml:/etc/prometheus-webhook-dingtalk/config.yml\--restartalways\timonwong/prometheus-webhook-dingtalk:latest

配置Alertmanager的alertmanager.yml：

vialertmanager.yml

global: resolve_timeout: 2m# 主路由：所有告警走这个路径route: group_by:['alertname']group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:'broadcast'# ← 指向一个组合 receiver# 定义 receiversreceivers: - name:'broadcast'webhook_configs:# 发给 ops 钉钉群- url:'http://<你的服务器IP>/dingtalk/ops-team/send'send_resolved:true# 发给 dev 钉钉群- url:'http://<你的服务器IP>/dingtalk/dev-team/send'send_resolved:true

配置完成后，重启alertmanager服务：

systemctl restart alertmanager

配置生效后，可以在两个钉钉群中分别看到对应的告警消息。

前面的告警链路是在Prometheus能够直接访问Alertmanager的前提下完成的。如果两者部署在不同局域网，Prometheus就无法直接把告警发送到Alertmanager的9093端口。

这里继续使用cpolar为Alertmanager提供一个外部TCP入口，让不同网络中的Prometheus也能把告警送到同一套Alertmanager。这个部分解决的是监控组件之间的网络连通，不改变前面Alertmanager到钉钉的通知链路。

8.使用cpolar打通跨网络Alertmanager

8.1 什么是cpolar？

cpolar是一款安全高效的内网穿透工具，无需公网IP或复杂配置，只需一条命令，即可将本地服务器、Web服务或任意端口映射到公网，让你随时随地远程访问内网应用，特别适合开发调试、远程运维和应急部署等场景。

8.2 部署cpolar

cpolar 可以将你本地电脑中的服务（如 SSH、Web、数据库）映射到公网。即使你在家里或外出时，也可以通过公网地址连接回本地运行的开发环境。

❤️以下是安装cpolar步骤：

使用一键脚本安装命令：

sudocurlhttps://get.cpolar.sh|sh

安装完成后，执行下方命令查看cpolar服务状态：（如图所示即为正常启动）

sudosystemctl status cpolar

Cpolar安装和成功启动服务后，在浏览器上输入虚拟机主机IP加9200端口即:【http://ip:9200】访问Cpolar管理界面，使用Cpolar官网注册的账号登录,登录后即可看到cpolar web 配置界面,接下来在web 界面配置即可：

打开浏览器访问本地9200端口，使用cpolar账户密码登录即可,登录后即可对隧道进行管理。

9.配置公网地址

这里为Alertmanager的9093端口创建TCP公网入口，后续Prometheus可以直接把这个公网地址作为Alertmanager目标。

• 隧道名称：可自定义，本例使用了:alertmanager，注意不要与已有的隧道名称重复
• 协议：tcp
• 本地地址：9093
• 端口类型：随机临时TCP端口
• 地区：China Top

创建成功后，打开左侧在线隧道列表,可以看到刚刚通过创建隧道生成了公网地址，接下来就可以在其他电脑或者移动端设备（异地）上，使用任意一个地址在终端中访问即可。

• tcp 表示使用的协议类型
• 2.tcp.cpolar.top是 Cpolar 提供的域名
• 10409是随机分配的公网端口号

在prometheus上使用不同局域网的alertmanager，修改prometheus的配置文件：

viprometheus.yml

alerting: alertmanagers: - static_configs: - targets:["2.tcp.cpolar.top:10409"]

重启服务：

systemctl restart alertmanager

修改目标并重启服务后，如果钉钉仍然能够正常收到告警，就说明跨网络链路已经接通。

10.保留固定TCP公网地址

使用cpolar为其配置TCP地址，该地址为固定地址，不会随机变化。

选择区域和描述：有一个下拉菜单，当前选择的是“China VIP”。
右侧输入框，用于填写描述信息。
保留按钮：在右侧有一个橙色的“保留”按钮，点击该按钮可以保留所选的TCP地址。
列表中显示了一条已保留的TCP地址记录。

• 地区：显示为“China Top”。

• 地址：显示为“3.tcp.cpolar.top:11755”。

登录cpolar web UI管理界面，点击左侧仪表盘的隧道管理——隧道列表，找到所要配置的隧道ssh，点击右侧的编辑。

修改隧道信息，将保留成功的TCP端口配置到隧道中。

• 端口类型：选择固定TCP端口
• 预留的TCP地址：填写保留成功的TCP地址

点击更新。

创建完成后，打开在线隧道列表，此时可以看到随机的公网地址已经发生变化，地址名称也变成了保留和固定的TCP地址。

固定TCP地址生效以后，Prometheus就可以长期使用同一组Alertmanager连接地址。

总结

这篇真正完成的，不只是把Prometheus告警“发到钉钉”，而是把告警从触发、路由、转换到最终通知完整串成了一条链。

Prometheus负责发现异常并触发规则，Alertmanager负责分组、路由、重复通知和恢复消息，prometheus-webhook-dingtalk负责把Webhook内容转换成钉钉机器人能够接收的格式。基础链路跑通以后，钉钉群就可以直接看到告警和恢复状态。

继续扩展多个钉钉群以后，不同团队还能按目标接收消息，避免所有告警都堆在一个群里；如果Prometheus和Alertmanager不在同一网络，后面的cpolar部分再负责把9093端口提供成可跨网络访问的固定TCP入口。

整条链最终解决的是“告警触发以后谁能及时看到、怎么分流、网络隔离时还能不能送达”这几个实际问题。Prometheus负责发现，Alertmanager负责调度，webhook-dingtalk负责适配钉钉，cpolar负责跨网络连通，最终让告警真正从监控系统走到责任人手里。