前言很多团队刚开始搭建Prometheus监控体系的时候往往会把重点放在指标采集和监控面板上。CPU、内存、磁盘、服务状态、业务指标全部接入完成看着Grafana大屏不断刷新数据会有一种监控体系已经建设完成的感觉。但真正经历过线上故障之后才会发现一个监控系统是否有价值关键并不在于采集了多少指标而在于问题发生时能否第一时间通知到人。我见过不少环境都存在类似情况。Prometheus规则已经配置完成告警状态也确实被触发了但由于Alertmanager没有配置通知渠道或者通知方式过于原始最终导致告警信息安静地躺在后台系统里。等运维人员发现的时候故障已经持续了很长时间。有时候甚至Grafana大屏上满屏红色告警而值班人员却毫不知情。最开始很多人会选择邮件作为通知方式但实际使用下来并不理想。邮件容易被忽略移动端提醒不够及时深夜告警更难第一时间被发现。相比之下钉钉已经成为很多企业日常沟通的核心平台无论开发、运维还是测试团队基本都长期在线。把Prometheus告警直接推送到钉钉群后告警触达效率会有明显提升。不过真正配置的时候很多人又会遇到新的问题。Alertmanager本身并不直接支持钉钉Webhook需要借助中间服务实现转发机器人安全策略、Webhook地址、消息模板、恢复通知以及多群告警路由等配置环节也容易踩坑。看起来只是一个简单的告警推送实际涉及的组件和配置项并不少。因此本文将从实际部署角度出发带大家完成Prometheus、Alertmanager以及prometheus-webhook-dingtalk之间的联动配置并进一步实现多群告警推送和跨网络访问场景优化。如果你希望让监控系统真正发挥价值而不仅仅停留在数据展示层面那么这套方案值得了解一下。1.为什么将Prometheus告警推送到钉钉将Prometheus告警推送到钉钉不仅是技术集成的一步更是提升团队运维效率与系统可靠性的关键实践。以下是几个核心原因告警触达更及时响应更迅速钉钉作为国内企业广泛使用的即时通讯工具几乎全员在线、消息必达。将告警直接推送至运维群或值班群能确保问题在第一时间被看到大幅缩短MTTR避免小故障演变为大事故。统一告警入口避免信息碎片化传统方式可能依赖邮件、短信、Slack等多种渠道容易造成告警分散、遗漏或重复处理。通过钉钉集中接收所有Prometheus告警团队可在一个平台完成告警确认、讨论与协同处置提升协作效率。支持富文本与结构化展示信息更清晰借助prometheus-webhook-dingtalk等中间件告警消息可渲染为卡片式富文本清晰展示告警名称如HighCPUUsage严重等级critical / warning故障实例instance192.168.1.10:9100触发时间与持续时长快速跳转链接直达 Grafana或Prometheus UI相比纯文本邮件钉钉消息一目了然减少信息解读成本。低成本、高可用的告警通道相比短信或电话告警钉钉推送零成本、无额度限制且依托阿里云基础设施服务稳定可靠。对于大多数非P0级别告警钉钉是性价比极高的通知渠道。2.前提条件本机已经部署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--version3.prometheus配置alertmanager进入到prometheus配置文件编辑配置文件按照如图设置编辑后重启prometheussystemctl restart prometheus4.获取钉钉Webhook URL打开钉钉群 → 点击右上角设置找到智能群助手 → 添加机器人添加自定义机器人点击添加给机器人起个名字我这里是“prometheus告警”设置发消息关键词因为现在钉钉对安全严格所以需要设置限制也可以设置加签或者IP地址点击完成后复制生成的Webhook留着备用5.部署prometheus-webhook-dingtalk服务创建配置文件dingtalk.yamlcatdingtalk.yamlEOF 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:latest6.配置Alertmanager告警配置Alertmanager配置文件配置到告警自动发送到钉钉vialertmanager.ymlglobal: resolve_timeout: 2m route: group_by:[alertname]group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:dingtalk-webhookreceivers: - name:dingtalk-webhookwebhook_configs: - url:http://你的服务器IP :8060/dingtalk/webhook1/sendsend_resolved:truesystemctl restart alertmanager替换 你的服务器IP 为运行prometheus-webhook-dingtalk的主机IP如果是本机且Alertmanager也在本机可用127.0.0.1但注意Docker网络告警成功7.告警多个钉钉群拓展配置多个钉钉群告警是为了实现告警的精准投递与职责分离——让不同团队如运维、开发、安全只接收与其相关的告警避免信息过载提升响应效率并支持告警分级、环境隔离和故障升级等高级运维场景从而构建高效、可靠、可扩展的监控告警体系。获取另一个群的webhook步骤和第4章节一致。配置文件dingtalk.yaml添加两个钉钉群链接vidingtalk.yamltargets: ops-team: url: https://oapi.dingtalk.com/robot/send?access_tokena391180a72b3c35f9308bbe1097dd5a29ca0cc440c6f1ee33601f8d5739ff6aa secret: secret1 dev-team: url: https://oapi.dingtalk.com/robot/send?access_token3e373b6623264d1c71098acde924328d0e16753820a17475aa95bd6655111e04 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.ymlvialertmanager.ymlglobal: resolve_timeout: 2m# 主路由所有告警走这个路径route: group_by:[alertname]group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:broadcast# ← 指向一个组合 receiver# 定义 receiversreceivers: - name:broadcastwebhook_configs:# 发给 ops 钉钉群- url:http://你的服务器IP/dingtalk/ops-team/sendsend_resolved:true# 发给 dev 钉钉群- url:http://你的服务器IP/dingtalk/dev-team/sendsend_resolved:true配置完成后重启alertmanager服务systemctl restart alertmanager等响应一会就可以在两个群聊中都看见告警啦在典型的云原生监控架构中Prometheus负责采集指标并触发告警规则而Alertmanager则运行在独立节点上专职处理告警的去重、分组与通知。然而在实际部署中我们常常面临一个现实挑战Prometheus与Alertmanager并不在同一个局域网内——例如Prometheus部署在企业内网或私有云环境中而Alertmanager可能托管在另一台隔离的服务器、边缘节点甚至临时调试机上。由于内网环境通常无法被外部直接访问Prometheus默认通过HTTP向http://:9093/api/v1/alerts推送告警时会因网络不通而失败导致“告警静默”严重削弱监控系统的可靠性。此时我们需要一种安全、轻量且无需复杂网络配置如公网IP、端口映射、NAT穿透或 VPN的方式来打通内外网通信。内网穿透工具Cpolar正是为此而生——它能将Alertmanager所在内网的服务通过加密隧道暴露到公网生成一个临时或固定的公网地址让Prometheus无论身处何地都能稳定推送告警。接下来我们将演示如何借助Cpolar轻松实现跨网络的Prometheus-Alertmanager告警链路。8.安装cpolar实现随时随地开发8.1 什么是cpolarcpolar是一款安全高效的内网穿透工具无需公网IP或复杂配置只需一条命令即可将本地服务器、Web服务或任意端口映射到公网让你随时随地远程访问内网应用特别适合开发调试、远程运维和应急部署等场景。8.2 部署cpolarcpolar 可以将你本地电脑中的服务如 SSH、Web、数据库映射到公网。即使你在家里或外出时也可以通过公网地址连接回本地运行的开发环境。❤️以下是安装cpolar步骤使用一键脚本安装命令sudocurlhttps://get.cpolar.sh|sh安装完成后执行下方命令查看cpolar服务状态如图所示即为正常启动sudosystemctl status cpolarCpolar安装和成功启动服务后在浏览器上输入虚拟机主机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的配置文件viprometheus.ymlalerting: 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告警总是没人看？Alertmanager接入钉钉实战指南
前言很多团队刚开始搭建Prometheus监控体系的时候往往会把重点放在指标采集和监控面板上。CPU、内存、磁盘、服务状态、业务指标全部接入完成看着Grafana大屏不断刷新数据会有一种监控体系已经建设完成的感觉。但真正经历过线上故障之后才会发现一个监控系统是否有价值关键并不在于采集了多少指标而在于问题发生时能否第一时间通知到人。我见过不少环境都存在类似情况。Prometheus规则已经配置完成告警状态也确实被触发了但由于Alertmanager没有配置通知渠道或者通知方式过于原始最终导致告警信息安静地躺在后台系统里。等运维人员发现的时候故障已经持续了很长时间。有时候甚至Grafana大屏上满屏红色告警而值班人员却毫不知情。最开始很多人会选择邮件作为通知方式但实际使用下来并不理想。邮件容易被忽略移动端提醒不够及时深夜告警更难第一时间被发现。相比之下钉钉已经成为很多企业日常沟通的核心平台无论开发、运维还是测试团队基本都长期在线。把Prometheus告警直接推送到钉钉群后告警触达效率会有明显提升。不过真正配置的时候很多人又会遇到新的问题。Alertmanager本身并不直接支持钉钉Webhook需要借助中间服务实现转发机器人安全策略、Webhook地址、消息模板、恢复通知以及多群告警路由等配置环节也容易踩坑。看起来只是一个简单的告警推送实际涉及的组件和配置项并不少。因此本文将从实际部署角度出发带大家完成Prometheus、Alertmanager以及prometheus-webhook-dingtalk之间的联动配置并进一步实现多群告警推送和跨网络访问场景优化。如果你希望让监控系统真正发挥价值而不仅仅停留在数据展示层面那么这套方案值得了解一下。1.为什么将Prometheus告警推送到钉钉将Prometheus告警推送到钉钉不仅是技术集成的一步更是提升团队运维效率与系统可靠性的关键实践。以下是几个核心原因告警触达更及时响应更迅速钉钉作为国内企业广泛使用的即时通讯工具几乎全员在线、消息必达。将告警直接推送至运维群或值班群能确保问题在第一时间被看到大幅缩短MTTR避免小故障演变为大事故。统一告警入口避免信息碎片化传统方式可能依赖邮件、短信、Slack等多种渠道容易造成告警分散、遗漏或重复处理。通过钉钉集中接收所有Prometheus告警团队可在一个平台完成告警确认、讨论与协同处置提升协作效率。支持富文本与结构化展示信息更清晰借助prometheus-webhook-dingtalk等中间件告警消息可渲染为卡片式富文本清晰展示告警名称如HighCPUUsage严重等级critical / warning故障实例instance192.168.1.10:9100触发时间与持续时长快速跳转链接直达 Grafana或Prometheus UI相比纯文本邮件钉钉消息一目了然减少信息解读成本。低成本、高可用的告警通道相比短信或电话告警钉钉推送零成本、无额度限制且依托阿里云基础设施服务稳定可靠。对于大多数非P0级别告警钉钉是性价比极高的通知渠道。2.前提条件本机已经部署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--version3.prometheus配置alertmanager进入到prometheus配置文件编辑配置文件按照如图设置编辑后重启prometheussystemctl restart prometheus4.获取钉钉Webhook URL打开钉钉群 → 点击右上角设置找到智能群助手 → 添加机器人添加自定义机器人点击添加给机器人起个名字我这里是“prometheus告警”设置发消息关键词因为现在钉钉对安全严格所以需要设置限制也可以设置加签或者IP地址点击完成后复制生成的Webhook留着备用5.部署prometheus-webhook-dingtalk服务创建配置文件dingtalk.yamlcatdingtalk.yamlEOF 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:latest6.配置Alertmanager告警配置Alertmanager配置文件配置到告警自动发送到钉钉vialertmanager.ymlglobal: resolve_timeout: 2m route: group_by:[alertname]group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:dingtalk-webhookreceivers: - name:dingtalk-webhookwebhook_configs: - url:http://你的服务器IP :8060/dingtalk/webhook1/sendsend_resolved:truesystemctl restart alertmanager替换 你的服务器IP 为运行prometheus-webhook-dingtalk的主机IP如果是本机且Alertmanager也在本机可用127.0.0.1但注意Docker网络告警成功7.告警多个钉钉群拓展配置多个钉钉群告警是为了实现告警的精准投递与职责分离——让不同团队如运维、开发、安全只接收与其相关的告警避免信息过载提升响应效率并支持告警分级、环境隔离和故障升级等高级运维场景从而构建高效、可靠、可扩展的监控告警体系。获取另一个群的webhook步骤和第4章节一致。配置文件dingtalk.yaml添加两个钉钉群链接vidingtalk.yamltargets: ops-team: url: https://oapi.dingtalk.com/robot/send?access_tokena391180a72b3c35f9308bbe1097dd5a29ca0cc440c6f1ee33601f8d5739ff6aa secret: secret1 dev-team: url: https://oapi.dingtalk.com/robot/send?access_token3e373b6623264d1c71098acde924328d0e16753820a17475aa95bd6655111e04 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.ymlvialertmanager.ymlglobal: resolve_timeout: 2m# 主路由所有告警走这个路径route: group_by:[alertname]group_wait: 10s group_interval: 10s repeat_interval: 1h receiver:broadcast# ← 指向一个组合 receiver# 定义 receiversreceivers: - name:broadcastwebhook_configs:# 发给 ops 钉钉群- url:http://你的服务器IP/dingtalk/ops-team/sendsend_resolved:true# 发给 dev 钉钉群- url:http://你的服务器IP/dingtalk/dev-team/sendsend_resolved:true配置完成后重启alertmanager服务systemctl restart alertmanager等响应一会就可以在两个群聊中都看见告警啦在典型的云原生监控架构中Prometheus负责采集指标并触发告警规则而Alertmanager则运行在独立节点上专职处理告警的去重、分组与通知。然而在实际部署中我们常常面临一个现实挑战Prometheus与Alertmanager并不在同一个局域网内——例如Prometheus部署在企业内网或私有云环境中而Alertmanager可能托管在另一台隔离的服务器、边缘节点甚至临时调试机上。由于内网环境通常无法被外部直接访问Prometheus默认通过HTTP向http://:9093/api/v1/alerts推送告警时会因网络不通而失败导致“告警静默”严重削弱监控系统的可靠性。此时我们需要一种安全、轻量且无需复杂网络配置如公网IP、端口映射、NAT穿透或 VPN的方式来打通内外网通信。内网穿透工具Cpolar正是为此而生——它能将Alertmanager所在内网的服务通过加密隧道暴露到公网生成一个临时或固定的公网地址让Prometheus无论身处何地都能稳定推送告警。接下来我们将演示如何借助Cpolar轻松实现跨网络的Prometheus-Alertmanager告警链路。8.安装cpolar实现随时随地开发8.1 什么是cpolarcpolar是一款安全高效的内网穿透工具无需公网IP或复杂配置只需一条命令即可将本地服务器、Web服务或任意端口映射到公网让你随时随地远程访问内网应用特别适合开发调试、远程运维和应急部署等场景。8.2 部署cpolarcpolar 可以将你本地电脑中的服务如 SSH、Web、数据库映射到公网。即使你在家里或外出时也可以通过公网地址连接回本地运行的开发环境。❤️以下是安装cpolar步骤使用一键脚本安装命令sudocurlhttps://get.cpolar.sh|sh安装完成后执行下方命令查看cpolar服务状态如图所示即为正常启动sudosystemctl status cpolarCpolar安装和成功启动服务后在浏览器上输入虚拟机主机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的配置文件viprometheus.ymlalerting: 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与钉钉的集成让每一次告警都能够真正发挥作用而不是静静地停留在监控后台。
