Prometheus + Alertmanager + Dingtalk 实现钉钉群告警通知

一、项目背景

为了及时发现服务器运行异常，实现服务器 CPU、内存、磁盘等资源监控告警，并将告警信息及时推送到钉钉群，采用以下技术方案：

  • Prometheus：负责采集监控指标、执行告警规则。

  • Alertmanager：负责接收 Prometheus 告警、告警分组、告警抑制及通知管理。

  • prometheus-webhook-dingtalk：负责接收 Alertmanager 的 Webhook 请求，并转发至钉钉机器人。

  • 钉钉群机器人：接收告警触发和恢复通知。

整体架构：

服务器 / Node Exporter
        |
        v
   Prometheus
        |
        | 告警规则触发
        v
   Alertmanager
        |
        | Webhook
        v
 prometheus-webhook-dingtalk
        |
        | 钉钉机器人 API
        v
     钉钉告警群

二、部署环境及目录

服务器环境：CentOS 7

相关组件及路径：

组件版本/配置
Prometheus已部署
Alertmanager0.27.0
prometheus-webhook-dingtalk2.1.0
Node Exporter已部署
Alertmanager 端口9093
Dingtalk 端口8060

目录结构：

/usr/local/
├── prometheus/
│   ├── prometheus
│   ├── prometheus.yml
│   ├── rules/
│   └── file_sd_configs/
│
├── alertmanager/
│   ├── alertmanager
│   ├── amtool
│   ├── alertmanager.yml
│   └── data/
│
└── dingtalk/
    ├── prometheus-webhook-dingtalk
    ├── config.yml
    └── templates/
        └── custom.tmpl

三、Prometheus 配置 Alertmanager

编辑：

vi /usr/local/prometheus/prometheus.yml

配置告警管理地址：

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 127.0.0.1:9093

rule_files:
  - /usr/local/prometheus/rules/*.yml

说明：

  • alerting：指定 Prometheus 将告警发送到哪个 Alertmanager。

  • rule_files：指定告警规则文件目录。

  • 这里使用本机 9093 端口进行通信。

检查配置：

promtool check config /usr/local/prometheus/prometheus.yml

四、配置 Prometheus 告警规则

告警规则文件：

vi /usr/local/prometheus/rules/server_rules.yml

常见告警规则包括：

1. 服务器宕机告警

- alert: ServerDown
  expr: up{job="node"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "服务器无法连接"
    description: "服务器 {{ $labels.instance }} 已经无法采集指标超过2分钟。"

2. CPU 使用率告警

- alert: HighCPUUsage
  expr: 100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "服务器 CPU 使用率过高"
    description: "服务器 {{ $labels.instance }} CPU 使用率超过80%。"

3. 内存使用率告警

- alert: HighMemoryUsage
  expr: 100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "服务器内存使用率过高"
    description: "服务器 {{ $labels.instance }} 内存使用率超过85%。"

4. 磁盘使用率告警

- alert: HighDiskUsage
  expr: 100 * (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs",mountpoint!~"/run.*|/var/lib/docker.*"} / node_filesystem_size_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs",mountpoint!~"/run.*|/var/lib/docker.*"}) > 85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "服务器磁盘使用率过高"
    description: "服务器 {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} 磁盘使用率超过85%。"

检查规则：

promtool check rules /usr/local/prometheus/rules/server_rules.yml

五、配置 Alertmanager

配置文件：

vim /usr/local/alertmanager/alertmanager.yml

本次使用的配置：

global:
  resolve_timeout: 5m

route:
  receiver: 'web.hook'
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h

receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'http://127.0.0.1:8060/dingtalk/webhook1/send'
        send_resolved: true
        max_alerts: 20

inhibit_rules:
  - source_matchers:
      - 'severity="critical"'
    target_matchers:
      - 'severity="warning"'
    equal: ['alertname', 'dev', 'instance']

参数说明：

参数作用
resolve_timeout告警未收到更新时的恢复超时时间
group_by按告警名称分组
group_wait新告警组首次通知等待时间
group_interval同一告警组后续通知间隔
repeat_interval持续告警的重复通知间隔
send_resolved是否发送告警恢复通知
max_alerts单次 Webhook 通知最多携带的告警数量

告警抑制规则

inhibit_rules:
  - source_matchers:
      - 'severity="critical"'
    target_matchers:
      - 'severity="warning"'
    equal: ['alertname', 'dev', 'instance']

作用：

当同一台服务器的同一种告警同时存在 critical 和 warning 时，抑制 warning 通知，避免重复告警。

注意：告警抑制只影响通知，不会删除 Prometheus 中的告警规则或告警状态。

检查配置

/usr/local/alertmanager/amtool check-config \
/usr/local/alertmanager/alertmanager.yml

重新加载：

systemctl kill -s HUP alertmanager

查看服务：

systemctl status alertmanager

六、安装部署 prometheus-webhook-dingtalk

6.1 组件介绍

prometheus-webhook-dingtalk 是 Prometheus 官方生态中常用的钉钉告警转发组件。

它接收 Alertmanager 发送的 Webhook 请求，将告警信息转换为钉钉机器人支持的 Markdown 消息，再推送到指定钉钉群。

本次部署版本：

  • 软件名称：prometheus-webhook-dingtalk

  • 版本：2.1.0

  • 部署目录：/usr/local/dingtalk

  • 监听端口：8060

  • systemd 服务名称：dingtalk

6.2 创建部署目录

mkdir -p /usr/local/dingtalk
cd /usr/local/dingtalk

6.3 下载软件安装包

下载对应 Linux 架构的 2.1.0 版本安装包。

项目地址：

GitHub - timonwong/prometheus-webhook-dingtalk: DingTalk integration for Prometheus Alertmanager · GitHub

Release 页面：

Releases · timonwong/prometheus-webhook-dingtalk · GitHub

选择对应的 Linux AMD64 安装包。

可以先查看服务器架构：

uname -m

如果返回：

x86_64

则选择 Linux AMD64 版本。

下载后解压：

tar -zxvf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz

将解压后的程序放到统一部署目录：

cp prometheus-webhook-dingtalk-2.1.0.linux-amd64/prometheus-webhook-dingtalk \
/usr/local/dingtalk/

增加执行权限：

chmod +x /usr/local/dingtalk/prometheus-webhook-dingtalk

检查版本：

/usr/local/dingtalk/prometheus-webhook-dingtalk --version

注：以上是标准安装示例，具体安装包文件名以实际下载的 Release 资产为准。

6.4 创建配置文件

创建：

vim /usr/local/dingtalk/config.yml

配置内容：

timeout: 5s

templates:
  - /usr/local/dingtalk/templates/custom.tmpl

default_message:
  title: '{{ template "custom.title" . }}'
  text: '{{ template "custom.content" . }}'

targets:
  webhook1:
    url: https://oapi.dingtalk.com/robot/send?access_token=替换成实际Token
    secret: 替换成实际Secret

参数说明：

配置项说明
timeout请求超时时间
templates自定义模板文件路径
default_message默认告警标题和正文
targets钉钉机器人配置
webhook1机器人目标名称
url钉钉机器人 Webhook 地址
secret钉钉机器人加签密钥

注意：实际部署时需要替换 Token 和 Secret，不能使用示例占位内容。

6.5 创建模板目录

mkdir -p /usr/local/dingtalk/templates

创建模板文件：

vim /usr/local/dingtalk/templates/custom.tmpl

模板内容见后续章节「自定义钉钉告警模板」。

6.6 配置 systemd 服务

为了实现 Dingtalk 开机自启动、异常自动重启，使用 systemd 管理服务。

创建：

vim /etc/systemd/system/dingtalk.service

配置：

[Unit]
Description=Prometheus Webhook Dingtalk
Documentation=https://github.com/timonwong/prometheus-webhook-dingtalk
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
WorkingDirectory=/usr/local/dingtalk
ExecStart=/usr/local/dingtalk/prometheus-webhook-dingtalk \
  --config.file=/usr/local/dingtalk/config.yml \
  --web.listen-address=:8060
Restart=on-failure
RestartSec=5s
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

说明：

  • ExecStart：指定程序及配置文件。

  • --web.listen-address=:8060：监听 8060 端口。

  • Restart=on-failure：服务异常退出时自动重启。

  • RestartSec=5s：异常退出后等待 5 秒重启。

  • WorkingDirectory：指定程序工作目录。

注意：这里使用的是本次部署的 2.1.0 版本参数，实际启动参数应以该版本 --help 输出为准。

6.7 启动服务

重新加载 systemd：

systemctl daemon-reload

设置开机自启动：

systemctl enable dingtalk

启动服务：

systemctl start dingtalk

查看运行状态：

systemctl status dingtalk

查看监听端口：

ss -lntp | grep 8060

正常情况下可以看到 8060 端口处于 LISTEN 状态。

6.8 测试 Dingtalk 服务

先检查本地服务是否正常监听：

curl -i http://127.0.0.1:8060/

该请求主要用于确认 HTTP 服务可访问，根路径返回 404 不一定代表服务异常。

也可以检查服务日志：

journalctl -u dingtalk -n 50 --no-pager

实时查看日志：

journalctl -u dingtalk -f

6.9 防火墙及网络说明

本次 Alertmanager 与 Dingtalk 部署在同一台服务器，因此使用：

http://127.0.0.1:8060/dingtalk/webhook1/send

两者通过本地回环地址通信。

如果两者部署在不同服务器，需要：

  1. 将 Dingtalk 监听地址调整为可被 Alertmanager 访问的地址。

  2. 配置服务器防火墙和阿里云安全组，仅允许可信来源访问 8060。

  3. 修改 Alertmanager Webhook URL 为 Dingtalk 服务器的内网地址。

不建议将 8060 端口直接开放到公网。

6.10 Dingtalk 常用运维命令

# 启动
systemctl start dingtalk

# 停止
systemctl stop dingtalk

# 重启
systemctl restart dingtalk

# 查看状态
systemctl status dingtalk

# 开机自启动
systemctl enable dingtalk

# 取消开机自启动
systemctl disable dingtalk

# 查看最近50行日志
journalctl -u dingtalk -n 50 --no-pager

# 实时查看日志
journalctl -u dingtalk -f

七、配置 Dingtalk 转发服务

配置文件：

vim /usr/local/dingtalk/config.yml

主要配置：

timeout: 5s

templates:
  - /usr/local/dingtalk/templates/custom.tmpl

default_message:
  title: '{{ template "custom.title" . }}'
  text: '{{ template "custom.content" . }}'

targets:
  webhook1:
    url: https://oapi.dingtalk.com/robot/send?access_token=替换成实际Token
    secret: 替换成实际Secret

说明：

  • templates：指定自定义告警模板。

  • default_message：指定告警标题和正文使用的模板。

  • targets：配置钉钉机器人。

  • webhook1：机器人目标名称，对应 Alertmanager Webhook 地址中的名称。

注意：Token 和 Secret 属于敏感信息，不要上传到公开代码仓库或公开笔记。

八、自定义钉钉告警模板

模板文件：

vim /usr/local/dingtalk/templates/custom.tmpl

本次使用的模板：

{{- define "custom.title" -}}
{{- if eq .Status "firing" -}}
🚨 告警通知{{ with .CommonLabels.alertname }} · {{ . }}{{ end }}
{{- else -}}
✅ 告警恢复通知{{ with .CommonLabels.alertname }} · {{ . }}{{ end }}
{{- end -}}
{{- end -}}

{{- define "custom.content" -}}
{{- $status := .Status -}}
{{- $firingCount := len .Alerts.Firing -}}
{{- $resolvedCount := len .Alerts.Resolved -}}

# {{ if eq $status "firing" }}🚨 监控告警通知{{ else }}✅ 监控恢复通知{{ end }}

**当前状态：** {{ if eq $status "firing" }}🔴 存在触发{{ else }}🟢 已恢复{{ end }}

**触发数量：** {{ $firingCount }} 条

**恢复数量：** {{ $resolvedCount }} 条

---

{{ if gt $firingCount 0 }}
#### 🔴 正在触发的告警

{{ range .Alerts.Firing -}}
**{{ .Labels.alertname }}**
- **级别：** {{ if eq .Labels.severity "critical" }}🔴 严重{{ else if eq .Labels.severity "warning" }}🟠 警告{{ else if eq .Labels.severity "info" }}🔵 提示{{ else }}⚪ {{ .Labels.severity }}{{ end }}
- **实例：** {{ .Labels.instance }}
- **摘要：** {{ .Annotations.summary }}
- **详情：** {{ .Annotations.description }}
- **开始：** {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}

{{ end }}
{{ end }}

{{ if gt $resolvedCount 0 }}
#### 🟢 已经恢复的告警

{{ range .Alerts.Resolved -}}
**{{ .Labels.alertname }}**
- **级别：** {{ if eq .Labels.severity "critical" }}🔴 严重{{ else if eq .Labels.severity "warning" }}🟠 警告{{ else if eq .Labels.severity "info" }}🔵 提示{{ else }}⚪ {{ .Labels.severity }}{{ end }}
- **实例：** {{ .Labels.instance }}
- **摘要：** {{ .Annotations.summary }}
- **详情：** {{ .Annotations.description }}
- **开始：** {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}
- **恢复：** {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}

{{ end }}
{{ end }}

---
**监控平台：** Prometheus + Alertmanager
{{- end -}}

模板注意事项

  1. 使用 .Alerts.Firing 获取正在触发的告警。

  2. 使用 .Alerts.Resolved 获取已经恢复的告警。

  3. 不要在单条告警对象内部使用 .Status 判断恢复状态。

  4. 标题和正文分别通过 custom.title、custom.content 调用。

  5. 避免多个模板文件重复定义相同的模板名称。

本次为了避免模板名称冲突，原来的 alert.tmpl 已重命名为 alert.tmpl.bak，正式配置明确指定 custom.tmpl。

九、systemd 服务管理

Alertmanager 和 Dingtalk 分别使用 systemd 管理。

常用命令：

# 查看 Alertmanager 状态
systemctl status alertmanager

# 查看 Dingtalk 状态
systemctl status dingtalk

# 重启 Dingtalk
systemctl restart dingtalk

# 重新加载 Alertmanager 配置
systemctl kill -s HUP alertmanager

# 查看 Dingtalk 日志
journalctl -u dingtalk -n 50 --no-pager

# 实时查看 Dingtalk 日志
journalctl -u dingtalk -f

# 查看 Alertmanager 日志
journalctl -u alertmanager -f

十一、告警触发和恢复测试

为了验证整套告警链路是否正常，使用 Alertmanager HTTP API 模拟告警。

测试目标：

  • 模拟一条 warning 级别告警。

  • 检查钉钉群是否收到告警触发消息。

  • 再发送相同告警的恢复状态。

  • 检查钉钉群是否收到恢复通知。

1. 测试原理

向 Alertmanager 的 /api/v2/alerts 接口提交告警。

第一次提交时，将 endsAt 设置为未来时间，模拟 firing。

第二次提交时，保持 labels 和 startsAt 完全一致，将 endsAt 设置为当前时间，模拟 resolved。

2. 执行测试

这条命令用来测试你的模板中最复杂的逻辑（Alerts.Firing 和 Alerts.Resolved 同时存在），看看两个模块是否都能正确渲染出来。

curl -X POST -H "Content-Type: application/json" -d @- http://localhost:8060/dingtalk/webhook1/send <<'EOF'
{
  "version": "4",
  "status": "firing",
  "receiver": "webhook1",
  "groupLabels": {},
  "commonLabels": {},
  "commonAnnotations": {},
  "externalURL": "http://localhost:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "DiskFull",
        "severity": "critical",
        "instance": "10.0.0.5:9100"
      },
      "annotations": {
        "summary": "磁盘空间不足",
        "description": "挂载点 /data 剩余空间低于 5%。"
      },
      "startsAt": "2026-11-04T10:00:00Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "",
      "fingerprint": "test-f1"
    },
    {
      "status": "resolved",
      "labels": {
        "alertname": "NetworkLatency",
        "severity": "warning",
        "instance": "10.0.0.6:9100"
      },
      "annotations": {
        "summary": "网络延迟过高",
        "description": "Ping 延迟已恢复至正常范围。"
      },
      "startsAt": "2026-11-04T08:00:00Z",
      "endsAt": "2026-11-04T09:30:00Z",
      "generatorURL": "",
      "fingerprint": "test-r1"
    }
  ]
}
EOF

注意：恢复通知仍然受 Alertmanager 分组通知调度影响，测试时需要留出足够的等待时间。

十二、总结

本次完成了 Prometheus、Alertmanager 和 prometheus-webhook-dingtalk 的告警通知链路搭建，实现了服务器监控告警向钉钉群推送的能力。

通过自定义 Go Template，优化了告警消息展示，支持告警级别、服务器实例、告警摘要、详细描述、开始时间和恢复时间等信息。

后续可以继续扩展：

  1. 增加 HTTP 服务可用性监控。

  2. 增加 Redis、MySQL、Elasticsearch 等中间件告警。

  3. 增加网络流量、磁盘 IO、系统负载等监控。

  4. 根据不同业务系统设置不同钉钉群接收告警。

  5. 增加告警升级、值班通知和故障自动化处理机制。

# prometheus
Logo
DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

cover

AI 客服答到一半忘词：多轮对话断片的五步排查

avatar DAMO开发者矩阵
cover

机器人什么时候该认怂：转人工的四个触发信号设计

avatar DAMO开发者矩阵
cover

AgenticRoboRL：将“编程智能体”后训练引入智能体化机器人领域

avatar DAMO开发者矩阵