很多团队搭建完 Prometheus + Grafana 监控后，只实现了数据可视化，却缺失了最核心的主动告警能力。监控的终极价值不是“看数据”，而是“发现问题、及时通知、快速止损”。

本文带你从零完成 Prometheus 告警全链路实战，涵盖告警原理、规则编写、Alertmanager 部署配置、钉钉/企业微信消息推送、告警降噪、测试验证与生产最佳实践，全程可直接复刻，适配服务器、业务接口、服务可用性等主流监控场景。

一、核心架构：搞懂Prometheus告警流程

完整的 Prometheus 告警体系由两大核心组件组成，分工清晰、解耦设计：

1. Prometheus Server：负责规则计算，定期执行告警规则表达式，判断指标是否触发阈值，生成告警状态（Pending/Firing）。

2. Alertmanager：负责告警分发与治理，接收Prometheus推送的告警，实现去重、分组、降噪、静默、路由分发，最终推送至钉钉、企业微信、邮件等渠道。

完整链路：采集指标 → 匹配告警规则 → 触发告警 → Alertmanager处理 → 渠道推送 → 运维响应

二、前置环境准备

本文基于 Linux 环境实战，需提前部署基础环境，版本无强制要求，主流稳定版均可：

• Prometheus 2.30+

• Alertmanager 0.24+

• node-exporter（服务器指标采集）

• 可正常通信的钉钉/企业微信机器人（用于消息推送）

默认组件安装目录：/usr/local/prometheus、/usr/local/alertmanager

三、第一步：编写生产级告警规则

告警规则是告警的核心，决定监控什么、阈值多少、持续多久告警。我们单独创建规则文件统一管理，避免和主配置混淆，方便维护。

3.1 创建告警规则文件

在Prometheus配置目录新建规则文件，统一存放服务器监控告警规则：

mkdir -p /usr/local/prometheus/rules vi /usr/local/prometheus/rules/node-rules.yml

3.2 核心实战告警规则（可直接复用）

包含服务宕机、CPU过载、内存溢出、磁盘满四大核心服务器告警，适配生产环境，包含阈值、持续时间、告警级别、详细描述：

groups: - name: node_server_alerts interval: 15s # 规则检测执行频率 rules: # 1. 实例宕机告警（严重级别） - alert: NodeInstanceDown expr: up == 0 for: 1m labels: severity: critical module: server annotations: summary: "服务器实例 {{ $labels.instance }} 宕机" description: "实例 {{ $labels.instance }} 服务失联，持续1分钟未采集到指标，请立即排查服务器状态、进程与网络！" # 2. CPU使用率过高告警 - alert: NodeHighCPUUsage expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85 for: 5m labels: severity: warning module: server annotations: summary: "服务器 {{ $labels.instance }} CPU使用率过高" description: "CPU近5分钟平均使用率超过85%，当前值：{{ $value }}%，存在性能瓶颈，建议排查进程负载！" # 3. 内存使用率过高告警 - alert: NodeHighMemoryUsage expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90 for: 5m labels: severity: warning module: server annotations: summary: "服务器 {{ $labels.instance }} 内存使用率过高" description: "内存近5分钟使用率超过90%，当前值：{{ $value }}%，存在OOM风险，建议清理内存或扩容！" # 4. 磁盘使用率过高告警 - alert: NodeHighDiskUsage expr: 100 - (avg by(instance,device) (node_filesystem_avail_bytes / node_filesystem_size_bytes * 100)) > 90 for: 5m labels: severity: warning module: server annotations: summary: "服务器 {{ $labels.instance }} 磁盘使用率过高" description: "磁盘 {{ $labels.device }} 使用率超过90%，当前值：{{ $value }}%，即将写满，请及时清理数据！"

3.3 规则核心参数详解

• alert：告警名称，唯一标识，简洁易懂

• expr：PromQL 表达式，核心判断逻辑，必须精准匹配指标

• for：告警等待时间，避免瞬时抖动误报（生产必须配置）

• labels：自定义标签，用于告警分组、路由、分级

• annotations：告警详情，用于推送展示，包含故障描述、影响范围

四、第二步：Prometheus关联告警规则与Alertmanager

编写完规则后，需要修改 Prometheus 主配置，让其加载规则文件、绑定 Alertmanager 推送地址。

4.1 修改prometheus主配置文件

编辑 /usr/local/prometheus/prometheus.yml，添加规则文件路径和告警推送地址：

# 加载告警规则文件 rule_files: - "rules/node-rules.yml" # 配置Alertmanager推送地址 alerting: alertmanagers: - static_configs: - targets: - 127.0.0.1:9093 # Alertmanager默认端口

4.2 校验配置并重启服务

先校验配置语法，避免配置错误导致服务启动失败：

# 校验配置 /usr/local/prometheus/promtool check config /usr/local/prometheus/prometheus.yml # 重载Prometheus配置（不重启服务） kill -HUP $(pidof prometheus)

五、第三步：Alertmanager配置告警推送（钉钉实战）

Alertmanager 默认不会主动推送消息，需要配置告警路由、接收渠道、消息模板，这里以企业最常用的钉钉机器人推送为例实战。

5.1 获取钉钉机器人Webhook

1. 钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义机器人

2. 开启关键词校验（填写：告警、监控），复制 Webhook 地址备用

5.2 配置Alertmanager主配置

编辑 /usr/local/alertmanager/alertmanager.yml，实现告警分组、去重、钉钉推送：

global: resolve_timeout: 5m # 告警恢复等待时间 route: group_by: ['instance', 'severity'] # 按实例、告警级别分组 group_wait: 10s # 首次告警等待10s，合并同批次告警 group_interval: 10s # 同组告警间隔时间 repeat_interval: 30m # 告警重复推送间隔，避免轰炸 receiver: 'dingtalk-receiver' receivers: - name: 'dingtalk-receiver' webhook_configs: - url: 'https://oapi.dingtalk.com/robot/send?access_token=你的钉钉机器人token' send_resolved: true # 开启告警恢复通知 # 告警降噪：抑制级别，严重告警触发时抑制同级普通告警 inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['instance']

5.3 重启Alertmanager并校验

# 重启服务 systemctl restart alertmanager # 查看端口监听 ss -lnp | grep 9093

六、第四步：自定义告警消息模板（美化推送内容）

默认推送消息格式简陋、信息不全，生产环境建议自定义模板，展示告警时间、实例、级别、详情、恢复状态。

6.1 创建钉钉模板文件

新建 /usr/local/alertmanager/template/dingtalk.tmpl：

{{ define "dingtalk.message" }} {{ range .Alerts }} {{ if eq .Status "firing" }} ### 🔴 监控告警触发 {{ else }} ### 🟢 监控告警恢复 {{ end }} **告警级别**：{{ .Labels.severity }} **告警实例**：{{ .Labels.instance }} **告警类型**：{{ .Labels.module }} **告警标题**：{{ .Annotations.summary }} **详细描述**：{{ .Annotations.description }} **触发时间**：{{ .StartsAt.Format "2006-01-02 15:04:05" }} {{ end }} {{ end }}

6.2 加载模板文件

在 alertmanager.yml 全局配置中添加模板路径：

global: resolve_timeout: 5m templates: - '/usr/local/alertmanager/template/dingtalk.tmpl'

修改后重启 Alertmanager 生效。

七、告警测试：快速验证全链路可用性

为了确认整个告警链路正常，添加一条永久触发的测试规则，快速验证推送功能。

在 node-rules.yml 中添加测试规则：

- alert: TestAlwaysFiring expr: vector(1) for: 10s labels: severity: warning annotations: summary: "Prometheus告警测试" description: "测试告警推送链路正常，可删除此规则！"

重载 Prometheus 配置，10秒后即可收到钉钉告警，测试完成后删除该规则即可。

八、生产告警核心优化（避坑必备）

很多线上告警泛滥、误报、漏报问题，均是配置不规范导致，以下是生产最佳实践：

8.1 规避瞬时抖动误报

所有规则必须配置 for 持续时间，CPU、内存类指标建议 3-5分钟，避免瞬时峰值触发无效告警。

8.2 告警分级治理

• critical（严重）：服务宕机、端口失联、核心业务不可用，立即处理

• warning（警告）：资源使用率过高、性能下降，择机处理

8.3 告警降噪与抑制

配置 inhibit_rules，当服务器宕机（critical）时，自动抑制该机器的CPU、内存等所有次要告警，避免批量轰炸。

8.4 合理配置推送频率

repeat_interval 建议设置 30分钟以上，避免同一故障持续刷屏，影响运维判断。

九、常见问题排查

• 规则配置不生效：通过 Prometheus 页面 Status → Rules 查看规则是否加载成功，检查语法错误

• 触发告警无推送：检查 Alertmanager 日志、webhook 地址是否正确、机器人关键词是否匹配

• 大量误报：调大 for 持续时间、优化PromQL表达式、添加告警抑制规则

• 无恢复通知：确认 Alertmanager 配置中 send_resolved 为 true

十、总结

Prometheus 告警的核心不在于“配置触发阈值”，而在于精准规则 + 合理降噪 + 闭环推送。本文搭建的全链路方案，覆盖了服务器基础监控告警，可直接落地生产。

在此基础上，你可以延伸拓展：业务接口错误率告警、日志告警、K8s集群资源告警、告警静默时间配置、多渠道（企业微信、邮件、短信）推送等，打造完整的企业级监控告警体系。