Prometheus告警规则与Alertmanager配置教程

一、文档目标

本文档用于说明Prometheus告警规则配置，以及Alertmanager本地告警链路的验证方法。

完整告警链路如下：

Prometheus Rules → Prometheus Alerts → Alertmanager → 通知渠道

本次配置完成到Alertmanager本地链路验证，邮件、企业微信、钉钉和Webhook等通知渠道可以根据实际需求继续接入。

二、规则文件路径

当前告警规则文件为：

/etc/prometheus/rules/node-alerts.yml

Prometheus主配置文件中，通过以下配置加载规则文件：

rule_files:
  - /etc/prometheus/rules/*.yml

只要规则文件符合匹配路径，Prometheus就会在启动或重新加载配置时读取对应规则。

三、当前告警规则

当前规则组名称为：

small-site-node

规则组中包含以下告警：

• HostDown
• HighCpuUsage
• HighMemoryUsage
• DiskSpaceLow

在Prometheus中打开Rules页面，可以查看规则加载状态和当前规则信息。

四、规则说明

1. HostDown

up{job="node"} == 0

当Node Exporter无法被Prometheus正常采集时，该规则会满足触发条件。

2. HighCpuUsage

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
) > 85

该规则根据最近5分钟的CPU空闲时间计算使用率。当CPU使用率持续高于85%时触发告警。

3. HighMemoryUsage

(
  1 - (
    node_memory_MemAvailable_bytes
    / node_memory_MemTotal_bytes
  )
) * 100 > 90

该规则根据可用内存和总内存计算使用率。当内存使用率持续高于90%时触发告警。

4. DiskSpaceLow

该规则用于监控磁盘使用情况。当磁盘使用率超过设定阈值时触发告警。

具体阈值和PromQL表达式以当前规则文件中的配置为准。

五、规则文件校验

修改告警规则后，应先使用promtool校验规则文件：

promtool check rules /etc/prometheus/rules/node-alerts.yml

同时检查Prometheus主配置文件：

promtool check config /etc/prometheus/prometheus.yml

只有校验通过后，才执行Prometheus重启：

sudo systemctl restart prometheus

重启后，可以查看服务状态：

sudo systemctl status prometheus --no-pager

如果服务没有正常启动，继续查看日志：

sudo journalctl -u prometheus --no-pager -n 100

六、查看告警状态

打开Prometheus的Alerts页面，可以查看当前告警状态。

告警状态通常包括以下几种：

• inactive：规则当前没有满足触发条件。
• pending：规则已经满足触发条件，但还没有达到for指定的持续时间。
• firing：告警已经正式触发。

例如，规则中设置了：

for: 5m

表示条件需要持续满足5分钟，告警才会从Pending变为Firing。

七、接入Alertmanager

在Prometheus配置文件中增加Alertmanager地址：

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - localhost:9093

完成配置后，先检查主配置文件：

promtool check config /etc/prometheus/prometheus.yml

然后重启Prometheus：

sudo systemctl restart prometheus

也可以根据实际环境使用配置热加载方式。

八、验证Prometheus与Alertmanager连接

首先检查Prometheus是否识别到Alertmanager：

curl http://127.0.0.1:9090/api/v1/alertmanagers

正常返回结果中，应包含类似以下地址：

http://localhost:9093/api/v2/alerts

然后检查Alertmanager是否已经准备完成：

curl http://127.0.0.1:9093/-/ready

如果返回OK或正常的Ready响应，说明Alertmanager服务已经可以接收请求。

还可以查看服务状态：

sudo systemctl status prometheus-alertmanager --no-pager

九、Alertmanager页面说明

部分Ubuntu或Debian软件包默认不提供完整的Alertmanager Web UI，访问页面时可能会提示使用API或amtool进行管理。

出现该提示并不代表Alertmanager不可用。

只要满足以下条件，本地告警链路就已经连通：

• Alertmanager的/-/ready检查正常。
• Prometheus能够识别Alertmanager。
• Prometheus的告警可以正常进入Firing状态。
• Alertmanager服务进程正常运行。

后续可以通过API、amtool或已接入的通知渠道继续验证告警处理结果。

十、接入通知渠道

Alertmanager可以根据实际需求接入不同通知方式，包括：

• 邮件。
• 企业微信。
• 钉钉。
• Webhook。

通知渠道通常会涉及Token、Secret、邮箱密码等敏感信息。配置和排查时需要注意：

• 不要在截图中展示完整密钥。
• 不要将密码写入公开文档。
• 不要将包含Secret的配置文件提交到公开代码仓库。
• 使用完成后及时更换已经暴露的凭据。

接入通知后，应主动触发一次测试告警，确认消息能够正常到达。

十一、常见问题

问题一：Rules页面没有显示新规则

先检查Prometheus主配置文件：

promtool check config /etc/prometheus/prometheus.yml

然后确认：

• rule_files路径是否正确。
• 规则文件是否位于指定目录。
• 文件扩展名是否符合匹配规则。
• YAML格式和缩进是否正确。
• Prometheus是否已经重新加载配置。

问题二：Prometheus重启失败

查看Prometheus服务日志：

sudo journalctl -u prometheus --no-pager -n 100

重点检查规则文件语法、主配置文件格式、端口占用和文件权限。

问题三：Alertmanager没有收到告警

先检查Prometheus是否识别到Alertmanager：

curl http://127.0.0.1:9090/api/v1/alertmanagers

再检查Alertmanager服务：

sudo systemctl status prometheus-alertmanager --no-pager

同时确认：

• Alertmanager是否监听9093端口。
• Prometheus配置中的地址是否正确。
• 防火墙是否影响本机访问。
• 告警是否已经进入Firing状态。
• for设置的持续时间是否已经满足。

问题四：告警一直处于Pending状态

Pending表示告警条件已经满足，但尚未达到规则中for指定的持续时间。

例如：

for: 10m

需要条件持续满足10分钟后，告警才会进入Firing状态。

十二、总结

Prometheus告警规则不宜一次配置过多，可以先覆盖以下核心场景：

• 主机无法采集。
• CPU使用率过高。
• 内存使用率过高。
• 磁盘空间不足。
• 网站或服务无法访问。

规则配置完成后，应先使用promtool校验，再查看Prometheus的Rules和Alerts页面，最后验证Alertmanager连接状态。

告警规则需要能够正常触发，通知消息需要能够准确到达，同时还要根据实际业务调整阈值和持续时间，减少误报。

• 

  广告合作

• 

  QQ群号：4114653