聊聊如何构建一套基于 Prometheus、Alertmanager 和钉钉的自动化告警系统
一，项目概
为提升系统运维的自动化和响应效率，我成功构建了一套基于 Prometheus、Alertmanager 和钉钉的自动化告警系统。该系统能够实时监控线上 Linux 服务器的根目录磁盘使用率，并在超出预设阈值时，通过钉钉机器人即时发送告警信息给相关运维团队，实现了从监控、告警到通知的闭环管理。
最终实现效果： 监控 -> 分析 -> 告警 -> 推送 -> 解决 -> 恢复通知的全流程自动化。
技术栈核心组件:
Node Exporter (数据采集): 部署在被监控服务器上（如 10.1.12.15, 10.1.12.3, 10.1.12.4），负责采集包括磁盘使用率在内的系统指标。
Prometheus (监控与告警触发): 在服务器 prometheus-server31 上运行，负责从各个 Node Exporter 拉取指标数据，并根据预设的告警规则 (disk_alert.rules.yml) 判断是否触发告警。
Alertmanager (告警路由与分发): 在服务器 node-exporter43 上运行，负责接收来自 Prometheus 的告警，并根据其路由规则，将告警信息发送给下一级处理器。
prometheus-webhook-dingtalk (告警适配器/插件): 在服务器 node-exporter42 上运行，作为 Alertmanager 与钉钉之间的桥梁，它接收 Alertmanager 发送的 Webhook 请求，并将其转换成钉钉机器人能够识别的格式后发送。
钉钉群 (告警接收端): 最终用户界面，运维人员在此接收并处理告警。
二、 准备工作：配置钉钉机器人
这是所有通知的入口，是连接 Alertmanager 和运维人员的桥梁。
创建钉钉群: 在钉钉中创建一个专门用于接收告警的群组。
添加机器人:
进入群设置 -> 智能群助手 -> 添加机器人。
选择 “自定义” 机器人。
安全设置: 为了安全，务必选择 “加签” 方式。系统会自动生成一个 Secret 密钥。
复制并妥善保管生成的 Webhook 地址 和 Secret 密钥。这两项是后续配置的关键。
Webhook 地址格式: https://xxxxxxxxxx
Secret 密钥格式: SECxxxxxxxx
三、 详细实施步骤
该插件作为中间件，负责接收 Alertmanager 发送的告警数据，并将其转换为钉钉机器人要求的格式后发送出去。
1.1 下载并解压插件
部署位置: 在一台独立的服务器（或与 Alertmanager/Prometheus 共用）上部署。本文档中，我们将其部署在 10.1.12.3（即 node-exporter42）
# 下载插件包 (建议使用官方源或经过验证的内部源)
[root@node-exporter42 ~]# wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz
# 解压到指定目录
[root@node-exporter42 ~]# tar xf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz -C /usr/local/
# 确认解压后的文件结构
[root@node-exporter42 ~]# ll /usr/local/prometheus-webhook-dingtalk-2.1.0.linux-amd64/
total 18752
-rw-r--r-- 1 3434 3434 1299 Apr 21 2022 config.example.yml
-rwxr-xr-x 1 3434 3434 19172733 Apr 21 2022 prometheus-webhook-dingtalk1.2 配置插件
插件的配置文件决定了告警要发往哪个钉钉机器人。
# 进入插件目录
[root@node-exporter42 ~]# cd /usr/local/prometheus-webhook-dingtalk-2.1.0.linux-amd64/
# 基于模板创建配置文件
[root@node-exporter42 prometheus-webhook-dingtalk-2.1.0.linux-amd64]# cp config.example.yml config.yml
# 编辑并填入钉钉机器人的信息
[root@node-exporter42 prometheus-webhook-dingtalk-2.1.0.linux-amd64]# vim config.yml
config.yml 内容如下：
targets:
# 此处的 "linux98" 是一个自定义标识符，将用于 Alertmanager 回调 URL 的一部分
linux98:
# 对应的是钉钉机器人的 Webhook 地址
url: https://oapi.dingtalk.com/robot/send?access_token=08462ff18a9c5e739b98a5d7a716408b4ccd8255d19a3b26ae6b8dcb90c73384
# 对应的是钉钉机器人的 "加签" Secret
secret: "SECf5414b69dd0f8a3a72b0bb929cf9271ef061aaea4c60e270cb15deb127339e4b"1.3 启动插件服务
# 在前台启动服务，并指定监听地址和端口
[root@node-exporter42 prometheus-webhook-dingtalk-2.1.0.linux-amd64]# ./prometheus-webhook-dingtalk --web.listen-address="10.1.12.3:8060"
# 观察启动日志，确认 Alertmanager 需要使用的回调 URL
...
ts=2025-08-07T07:58:59.946Z caller=main.go:113 component=configuration msg="Webhook urls for prometheus alertmanager" urls=http://10.1.12.3:8060/dingtalk/最佳实践: 在生产环境中，应使用 systemd 或 supervisor 将其作为后台服务长期运行。
2.1 创建告警规则文件 (disk_alert.rules.yml)
在 Prometheus 服务器上创建规则文件。
# file: /softwares/prometheus-2.53.4.linux-amd64/disk_alert.rules.yml
groups:
- name: LinuxNodeRules
rules:
- alert: LinuxRootFilesystemUsageHigh
# PromQL 表达式：计算根目录磁盘使用率，当 > 80% 时满足条件
expr: |
(
node_filesystem_size_bytes{mountpoint="/"}
-
node_filesystem_free_bytes{mountpoint="/"}
) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 80 # 阈值设为 80% 用于测试
# 持续 1 分钟才触发，防止瞬间抖动导致误报
for: 1m
labels:
severity: critical # 告警级别标签
# 告警的详细信息，这些内容会发送到钉钉
annotations:
summary: "服务器根目录空间使用率过高"
description: |
- **告警级别**: {{ $labels.severity }}
- **主机IP**: {{ $labels.instance }}
- **挂载点**: {{ $labels.mountpoint }}
- **当前使用率**: {{ $value | printf "%.2f" }}%
- **详细信息**: 服务器 {{ $labels.instance }} 的根目录 (/) 空间使用率已超过阈值，请立即处理！2.2 更新主配置文件 prometheus.yml
编辑 Prometheus 主配置文件，加载告警规则文件、指定 Alertmanager 地址，并确保已配置对 Node Exporter 的数据抓取
# 在 prometheus-server31 服务器上操作
# file: /softwares/prometheus-2.53.4.linux-amd64/prometheus.yml
# ... (global settings) ...
# 加载告警规则文件
rule_files:
- "disk_alert.rules.yml"
# 配置 Alertmanager 地址
alerting:
alertmanagers:
- static_configs:
# 指向 Alertmanager 服务的地址
- targets: ['10.1.12.4:9093'] # node-exporter43 的 IP 是 10.1.12.4
# 数据抓取配置
scrape_configs:
# ... (other jobs like prometheus self-scrape) ...
# 抓取 Node Exporter 指标，这是告警的数据来源
- job_name: "old-node-exporter"
static_configs:
- targets:
- 10.1.12.15:9100 # 抓取这三台服务器
- 10.1.12.3:9100
- 10.1.12.4:9100【排错点】: 确保每个 target 没有在多个 job 中重复出现，否则会导致指标重复，可能引发告警计算错误。
Alertmanager 负责接收、分组、并路由告警到正确的渠道。
3.1 修改 alertmanager.yml
# 登录到服务器 node-exporter43
[root@node-exporter43 alertmanager-0.28.1.linux-amd64]#
# 查看并编辑配置文件
[root@node-exporter43 alertmanager-0.28.1.linux-amd64]# cat alertmanager.yml
# 通用配置 (此处保留了邮件配置，但本次重点是webhook)
global:
resolve_timeout: 5m
smtp_from: '13949913771@163.com'
smtp_smarthost: 'smtp.163.com:465'
smtp_auth_username: '13949913771@163.com'
smtp_auth_password: 'UGTMVNtb2Xup2St4'
smtp_require_tls: false
smtp_hello: '163.com'
# 定义路由信息
route:
group_by: ['alertname']
group_wait: 5s
group_interval: 5s
repeat_interval: 5m
# 默认接收者是 sre_system，所有不匹配子路由的告警都会发给它
receiver: 'sre_system'
# 配置子路由
routes:
- receiver: 'sre_dba'
match_re:
job: yinzhengjie_dba_exporter
continue: true # 匹配后继续向下匹配，确保系统组也能收到
- receiver: 'sre_k8s'
match_re:
job: yinzhengjie_k8s_exporter
continue: true
# 这是一个总括规则，确保所有告警都经过 sre_system 处理
- receiver: 'sre_system'
match_re:
job: .*
continue: false # 在这里停止，因为它是最终目的地
# 定义接收者
receivers:
- name: 'sre_dba'
email_configs:
- to: '18295829783@163.com'
# ... (email details)
- name: 'sre_k8s'
email_configs:
- to: '2996358563@qq.com'
# ... (email details)
# 【本次集成的核心配置】
- name: 'sre_system'
webhook_configs:
# 指向我们在 node-exporter42 上部署的钉钉插件地址
- url: 'http://10.1.12.3:8060/dingtalk/linux98/send'
send_resolved: true # 告警恢复时发送通知
# 加载模板（用于邮件格式化，对钉钉通知无直接影响）
templates:
- '/oldboyedu/softwares/alertmanager/tmpl/*.tmpl'3.2 检查配置并启动 Alertmanager
# 检查配置文件语法
[root@node-exporter43 alertmanager-0.28.1.linux-amd64]# ./amtool check-config alertmanager.yml
Checking 'alertmanager.yml' SUCCESS
# 启动 Alertmanager 服务
[root@node-exporter43 alertmanager-0.28.1.linux-amd64]# ./alertmanager --config.file=alertmanager.yml五、 系统联调与端到端验证
确认所有服务已启动:
钉钉插件 (node-exporter42): ps aux | grep prometheus-webhook-dingtalk
[root@node-exporter42 prometheus-webhook-dingtalk-2.1.0.linux-amd64]# ./prometheus-webhook-dingtalk --web.listen-address="10.1.12.3:8060"
ts=2025-08-07T10:06:16.846Z caller=main.go:59 level=info msg="Starting prometheus-webhook-dingtalk" version="(version=2.1.0, branch=HEAD, revision=8580d1395f59490682fb2798136266bdb3005ab4)"
ts=2025-08-07T10:06:16.846Z caller=main.go:60 level=info msg="Build context" (gogo1.18.1,userroot@177bd003ba4d,date20220421-08:19:05)=(MISSING)
ts=2025-08-07T10:06:16.846Z caller=coordinator.go:83 level=info component=configuration file=config.yml msg="Loading configuration file"
...Alertmanager (node-exporter43): ps aux | grep alertmanager
[root@node-exporter43 alertmanager-0.28.1.linux-amd64]# ./alertmanager
time=2025-08-07T11:54:04.659Z level=INFO source=main.go:191 msg="Starting Alertmanager" version="(version=0.28.1, branch=HEAD, revision=b2099eaa2c9ebc25edb26517cb9c732738e93910)"
time=2025-08-07T11:54:04.659Z level=INFO source=main.go:192 msg="Build context" build_context="(go=go1.23.7, platform=linux/amd64, user=root@fa3ca569dfe4, date=20250307-15:05:18, tags=netgo)"
time=2025-08-07T11:54:04.663Z level=INFO source=cluster.go:185 msg="setting advertise address explicitly" component=cluster addr=10.1.12.4 port=9094
time=2025-08-07T11:54:04.665Z level=INFO source=cluster.go:674 msg="Waiting for gossip to settle..." component=cluster interval=2s
...Prometheus (prometheus-server31): ps aux | grep prometheus
热加载 Prometheus 配置
[root@prometheus-server31 ~]# curl -X POST http://10.1.24.13:9090/-/reload模拟告警
登录到一台被监控的服务器，例如 10.1.12.4。
# 先查看
# 先查看
http://106.55.44.37:9090/alerts?search=
检查当前磁盘使用率 df -h
使用 dd 命令创建大文件，使根目录使用率超过90%：
[root@node-exporter43 ~]# dd if=/dev/zero of=/test_large_file.img bs=1G count=40观察 Prometheus UI:
打开 Prometheus 的 Alerts 页面。
预期流程：告警状态首先变为 Pending (黄色)，并在 for 设定的时间（5分钟）后，变为 Firing (红色)
http://106.55.44.37:9090/alerts?search=
等待片刻（Prometheus 的抓取间隔 + 告警规则的 for 时间），成功在钉钉群里收到告警消息
恢复告警
# 清理测试文件,观察恢复
rm -f /big_test_file
六、Grafana展示
第一步：登录 Grafana 并创建新的仪表盘
打开您的 Grafana 网站并登录。
点击左侧菜单栏的 + (Create) 图标，然后选择 Dashboard。
在新创建的空白仪表盘中，点击 Add panel -> Add new panel。
第二步：配置图表面板 (Panel)
进入面板编辑页面后，我们需要配置几个关键部分：
数据源 (Data source)、查询 (Query)、图表类型 (Visualization) 和 面板选项 (Panel options)。
1. 选择数据源 (Data source)
在面板编辑页面的下方，找到 "Query" 选项卡。确保 Data source 下拉菜单中选择了您的 Prometheus 数据源。
2. 输入 PromQL 查询语句
3. 配置图例 (Legend)
默认情况下，Grafana 会显示非常长的图例信息，我们可以把它格式化得更清晰。在查询编辑器的 Legend 字段中，输入以下格式化字符串：
4. 选择图表类型 (Visualization)
在右侧的面板设置区域，找到 Visualization (可视化类型)。
选择 Time series (时间序列图) 是最常见的选择，可以展示使用率随时间变化的趋势。
您也可以选择 Gauge (仪表盘) 或者 Stat (统计值)，这两种类型更适合展示当前的数值。我们以 Time series 为例。
5. 配置坐标轴和单位 (Axes and Unit)
为了让图表更具可读性，我们需要设置单位。
在右侧面板设置中，滚动到 Standard options (标准选项) 部分。
找到 Unit (单位) 字段。
在下拉菜单中搜索并选择 Percent (0-100)。
恢复告警后效果：
七、 总结
本项目通过整合 Prometheus 生态的核心组件及第三方钉钉插件，成功构建了一套稳定、高效、自动化的 Linux 服务器磁盘监控告警系统。所有操作均严格按照预定方案执行，配置细节精确到每一行命令和每一个参数，最终实现了从数据采集到告警通知的完整闭环，显著提升了运维团队对潜在风险的预警和处理能力。
