为什么需要为服务器配置 Prometheus 指标告警规则
服务器一旦出现 CPU 满载、内存耗尽或磁盘写满，往往不是瞬间发生的，而是有一个逐渐恶化的过程。如果等到用户反馈网站打不开才去处理，损失已经造成。Prometheus 作为一套开源监控系统，能够持续采集服务器各项指标，并通过告警规则在问题恶化前主动通知运维人员。这篇文章会教你如何配置一套实用的 Prometheus 指标告警规则，让服务器在真正宕机之前就发出预警。
很多站长把监控停留在”能看图表”的层面，却忽略了告警才是监控的核心价值。图表只能让你事后复盘，告警才能让你提前介入。我们建议的做法是：先明确哪些指标最值得关注，再为它们编写告警规则，最后通过 Alertmanager 把通知送到你的邮箱或即时通讯工具。下面我们按这个思路一步步展开。如果你刚开始接触服务器运维，可以先阅读我们关于服务器配置与性能的系列文章，建立基础认知。
告警规则的基本结构与触发逻辑
Prometheus 的告警规则写在独立的规则文件中，通过 rule_files 字段加载到 Prometheus 配置里。一条规则由 expr（表达式）、for（持续时间）和 labels/annotations（标签与注解）组成。expr 用 PromQL 查询语言描述”什么情况下算异常”，for 表示该异常需要持续多久才真正触发告警，annotations 则用来填写告警标题和详细描述。
一个典型的规则文件片段如下：
groups:
- name: server-alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} CPU 使用率过高"
description: "服务器 CPU 使用率已持续超过 85%，请检查是否有异常进程。"
这里 for: 5m 的作用很关键。它要求 CPU 使用率连续 5 分钟都超过 85% 才触发告警，可以避免瞬时峰值造成的误报。比如网站做促销活动时 CPU 短暂冲到 90%，只要很快回落，就不会打扰你。
关键指标与告警阈值设计
服务器监控最值得关注的指标集中在 CPU、内存、磁盘、网络和负载五个方面。下面我们给出每个指标的告警表达式和推荐阈值，你可以根据自己服务器的实际规格调整。
CPU 使用率告警
CPU 是服务器最核心的资源。当 CPU 长期满载，网站响应会明显变慢。除了整体使用率，还要关注单核是否被打满，因为单核瓶颈同样会拖慢服务。
- alert: HighCPUUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} CPU 使用率过高"
description: "CPU 使用率超过 85% 已持续 5 分钟。"
内存使用率告警
内存不足会导致系统开始使用交换分区（swap），磁盘 I/O 急剧上升，网站速度断崖式下跌。内存告警建议分两级：使用率超过 85% 先警告，超过 95% 再升级为严重。如果你使用的是共享资源受限的虚拟主机，内存告警尤其重要，可以参考我们关于虚拟主机与 VPS 的区别来理解不同方案的内存隔离差异。
- alert: HighMemoryUsage
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} 内存使用率过高"
description: "内存使用率超过 85%，系统可能开始使用 swap。"
磁盘空间告警
磁盘写满是导致服务不可用的常见原因，尤其是日志文件、数据库和备份目录。磁盘告警要按挂载点分别判断，因为根分区和数据分区的情况可能完全不同。
- alert: DiskSpaceLow
expr: (1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})) * 100 > 90
for: 5m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }} 根分区磁盘空间不足"
description: "根分区使用率超过 90%，请及时清理或扩容。"
网络与负载告警
网络流量异常和系统负载过高同样需要关注。负载（load average）反映系统整体繁忙程度，通常建议以 CPU 核心数为基准，负载持续超过核心数就说明系统过载。
- alert: HighSystemLoad
expr: node_load1 > (count by (instance) (node_cpu_seconds_total{mode="system"})) * 2
for: 10m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} 系统负载过高"
description: "1 分钟平均负载超过 CPU 核心数的 2 倍，系统可能过载。"
通过 Alertmanager 把告警送到你的手上
规则触发后，Prometheus 会把告警推送给 Alertmanager，由它负责去重、分组并发送通知。Alertmanager 支持邮件、Webhook、企业微信、钉钉等多种渠道。下面是一个把告警发送到邮箱的最小配置：
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: 'ops@example.com'
from: 'alert@example.com'
smarthost: 'smtp.example.com:587'
auth_username: 'alert@example.com'
auth_password: 'your-password'
repeat_interval: 4h 表示同一告警在 4 小时内不会重复发送，避免告警刷屏。如果你希望告警直接推送到手机，可以接入企业微信或钉钉的 Webhook，配置方式类似，只是把 email_configs 换成对应的 webhook_configs。告警通知的及时性也取决于服务器本身的稳定性，选择可靠的独立服务器方案可以减少因宿主机故障导致的监控中断。
告警规则上线前的验证与排障
规则写好后，不要直接上线，先用 Prometheus 自带的工具做校验。promtool 是官方提供的规则检查工具，可以快速发现语法错误：
promtool check rules /etc/prometheus/rules/server-alerts.yml
如果输出 SUCCESS，说明规则语法没有问题。接着重启 Prometheus 加载新规则，然后在 Prometheus 的 Web 界面进入”Alerts”页面，确认规则状态为 inactive（未触发）或 pending（等待持续时长）。你可以临时把阈值调低，人为制造一次触发，验证告警链路是否真的能送到你的邮箱或手机，验证完再改回正常阈值。
常见问题有两个。一是 for 时长设置过短导致频繁误报，建议至少 5 分钟。二是表达式里没有按 instance 分组，导致多台服务器共用一条告警时无法区分是哪台机器出问题，务必在 expr 中加上 by (instance)。
总结与下一步建议
Prometheus 指标告警规则的核心价值，是把”事后救火”变成”事前预警”。我们建议你先从 CPU、内存、磁盘三个最基础的指标开始，用本文给出的表达式搭建第一套规则，再逐步补充网络和负载告警。告警阈值不要照搬，要根据自己服务器的规格和业务特点调整，避免误报和漏报。
如果你需要一台稳定、可扩展的服务器来承载监控系统，可以考虑 Hostease 的 VPS（虚拟专用服务器）主机方案，它提供独立的 CPU 和内存资源，适合部署 Prometheus 这类常驻监控服务。配置好告警后，建议定期检查规则是否仍然符合当前业务，比如服务器扩容后及时调整阈值。如果你需要更完整的监控方案，也可以参考我们关于网站性能优化的其他文章，把监控和优化结合起来，让网站长期保持稳定。