前言
在云原生时代，可观测性已成为保障系统稳定性的核心支柱，而Prometheus作为CNCF毕业的主流监控解决方案，其强大的告警能力更是运维工程师不可或缺的“哨兵”。
然而，再精准的告警若不能及时触达责任人，也形同虚设。如何将Prometheus的告警高效、可靠地推送到团队日常使用的协作平台——钉钉，成为许多DevOps团队亟需解决的关键一环。
尽管Alertmanager提供了灵活的通知路由机制，但它并不原生支持钉钉Webhook。这使得不少用户在集成过程中踩坑不断：消息格式混乱、告警无法发送、恢复通知缺失，甚至因安全配置不当导致机器人被滥用。
为此，社区涌现出如prometheus-webhook-dingtalk等成熟中间件，为打通Prometheus与钉钉之间“最后一公里”提供了优雅解法。本文将手把手带你从零开始，完整配置Alertmanager向钉钉推送告警，涵盖钉钉机器人创建、中间服务部署、Alertmanager路由策略设计、消息模板优化等关键环节。
无论你是初次尝试集成，还是希望优化现有告警体验，这篇文章都将为你提供一套生产可用、高可靠、易维护的最佳实践方案。让每一次告警，都真正“响”在该响的地方。
1.为什么将Prometheus告警推送到钉钉？
将Prometheus告警推送到钉钉，不仅是技术集成的一步，更是提升团队运维效率与系统可靠性的关键实践。以下是几个核心原因：
- 告警触达更及时，响应更迅速
钉钉作为国内企业广泛使用的即时通讯工具，几乎全员在线、消息必达。将告警直接推送至运维群或值班群，能确保问题在第一时间被看到，大幅缩短MTTR，避免小故障演变为大事故。
- 统一告警入口，避免信息碎片化
传统方式可能依赖邮件、短信、Slack等多种渠道，容易造成告警分散、遗漏或重复处理。通过钉钉集中接收所有Prometheus告警，团队可在一个平台完成告警确认、讨论与协同处置，提升协作效率。
- 支持富文本与结构化展示，信息更清晰
借助prometheus-webhook-dingtalk等中间件，告警消息可渲染为卡片式富文本，清晰展示：
- 告警名称（如HighCPUUsage）
- 严重等级（critical / warning）
- 故障实例（instance=192.168.1.10:9100）
- 触发时间与持续时长
- 快速跳转链接（直达 Grafana或Prometheus UI）
相比纯文本邮件，钉钉消息一目了然，减少信息解读成本。
- 低成本、高可用的告警通道
相比短信或电话告警，钉钉推送零成本、无额度限制，且依托阿里云基础设施，服务稳定可靠。对于大多数非P0级别告警，钉钉是性价比极高的通知渠道。
2.前提条件
- 本机已经部署prometheus和alertmanager:再也不怕半夜被叫醒：用 Prometheus+Alertmanager实现智能告警
-
具备一个可用的钉钉群，并拥有管理员权限
-
可创建钉钉自定义机器人
-
部署节点具备外网访问能力
- Alertmanager与webhook服务网络互通
- Alertmanager所在主机必须能通过HTTP/HTTPS访问prometheus-webhook-dingtalk服务的地址
- 若两者部署在同一主机，注意Docker网络隔离问题（避免使用127.0.0.1，建议用宿主机IP或Docker自定义网络）。
- 安装必要工具（用于部署与调试）
- 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
启动容器（假设配置文件在当前目录）:
docker run -d \
--name dingtalk-webhook \
-p 8060:8060 \
-v $(pwd)/dingtalk.yaml:/etc/prometheus-webhook-dingtalk/config.yml \
--restart always \
timonwong/prometheus-webhook-dingtalk:latest
6.配置Alertmanager告警
配置Alertmanager配置文件，配置到告警自动发送到钉钉：
vi alertmanager.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网络）
告警成功！
7.告警多个钉钉群（拓展）
配置多个钉钉群告警，是为了实现告警的精准投递与职责分离——让不同团队（如运维、开发、安全）只接收与其相关的告警，避免信息过载，提升响应效率，并支持告警分级、环境隔离和故障升级等高级运维场景，从而构建高效、可靠、可扩展的监控告警体系。
获取另一个群的webhook（步骤和第4章节一致）。
配置文件dingtalk.yaml，添加两个钉钉群链接：
vi dingtalk.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容器：
docker run -d \
--name dingtalk-webhook \
-p 8060:8060 \
-v $(pwd)/dingtalk.yaml:/etc/prometheus-webhook-dingtalk/config.yml \
--restart always \
timonwong/prometheus-webhook-dingtalk:latest
配置Alertmanager的alertmanager.yml：
vi alertmanager.yml
global:
resolve_timeout: 2m
# 主路由：所有告警走这个路径
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'broadcast' # ← 指向一个组合 receiver
# 定义 receivers
receivers:
- 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并不在同一个局域网内——例如，Prometheus部署在企业内网或私有云环境中，而Alertmanager可能托管在另一台隔离的服务器、边缘节点，甚至临时调试机上。
由于内网环境通常无法被外部直接访问，Prometheus默认通过HTTP向 http://
8.安装cpolar实现随时随地开发
8.1 什么是cpolar？
cpolar是一款安全高效的内网穿透工具，无需公网IP或复杂配置，只需一条命令，即可将本地服务器、Web服务或任意端口映射到公网，让你随时随地远程访问内网应用，特别适合开发调试、远程运维和应急部署等场景。
8.2 部署cpolar
cpolar 可以将你本地电脑中的服务（如 SSH、Web、数据库）映射到公网。即使你在家里或外出时，也可以通过公网地址连接回本地运行的开发环境。
❤️以下是安装cpolar步骤：
使用一键脚本安装命令：
sudo curl https://get.cpolar.sh | sh
安装完成后，执行下方命令查看cpolar服务状态：（如图所示即为正常启动）
sudo systemctl status cpolar
Cpolar安装和成功启动服务后，在浏览器上输入虚拟机主机IP加9200端口即:【http://ip:9200】访问Cpolar管理界面，使用Cpolar官网注册的账号登录,登录后即可看到cpolar web 配置界面,接下来在web 界面配置即可：
打开浏览器访问本地9200端口，使用cpolar账户密码登录即可,登录后即可对隧道进行管理。
9.配置公网地址
通过配置，你可以在本地WSL或Linux系统上运行SSH服务，并通过Cpolar将其映射到公网，从而实现从任意设备远程连接开发环境的目的。
- 隧道名称：可自定义，本例使用了:alertmanager，注意不要与已有的隧道名称重复
- 协议：tcp
- 本地地址：9093
- 端口类型：随机临时TCP端口
- 地区：China Top
创建成功后，打开左侧在线隧道列表,可以看到刚刚通过创建隧道生成了公网地址，接下来就可以在其他电脑或者移动端设备（异地）上，使用任意一个地址在终端中访问即可。
- tcp 表示使用的协议类型
- 2.tcp.cpolar.top是 Cpolar 提供的域名
- 10409是随机分配的公网端口号
在prometheus上使用不同局域网的alertmanager，修改prometheus的配置文件：
vi prometheus.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告警推送到钉钉，不仅是技术集成，更是运维理念的升级——从“看得见”走向“管得住”，从“被动响应”迈向“主动治理”。通过本文提供的端到端方案，无论你是单机测试还是生产集群，都能快速构建一套可靠、智能、可扩展的告警通知体系，让每一次异常都真正“响”在该响的地方。
告警的价值，不在于它被触发，而在于它被行动。
愿你的系统永远平静，但你的告警始终锋利。
感谢您对本篇文章的喜爱，有任何问题欢迎留言交流。cpolar官网-安全的内网穿透工具 | 无需公网ip | 远程访问 | 搭建网站
