服务器监控搭建起来并不难，难的是把告警阈值（threshold，触发提醒的临界数值）配得既灵敏又不扰人。很多人装完 Grafana 和 Prometheus 后，面板上能看到曲线，却始终没有一条像样的告警规则——直到磁盘写满、接口超时才追悔莫及。本文从一套真实可复用的监控部署出发，讲解 Grafana 告警规则配置的完整路径，帮助你理解阈值背后的判断逻辑，并落地一套从采集到通知的闭环。
我们以一台应用服务器和一台监控服务器为例。业务服务器跑网站或接口，监控服务器负责采集指标、保存时间序列数据，并通过 Grafana 展示与告警。这种拆分适合中小团队，后续扩展新节点也方便。
先回答三个问题：告警规则到底在监控什么
在写第一条规则之前，建议先想清楚监控目标。对承载网站或接口的服务器，第一阶段通常只需盯住四类核心信号：CPU 使用率、内存占用、磁盘空间、端口连通性。它们覆盖了「机器还能不能稳定工作」的大部分场景。如果你把 Grafana 部署在 VPS（虚拟专用服务器） 或独立主机上，这套思路同样成立，区别只在于是否需要额外开放防火墙端口。
Grafana 本身的定位是可视化与告警编排，数据通常来自 Prometheus。Prometheus 负责按周期拉取目标地址的指标（metrics，以时间序列保存的数值），Grafana 负责查询、绘图，并把告警规则（alerting rule，判断某个条件是否成立的规则）落到实际通知里。三者协作，才构成完整的监控闭环。
部署一套最小可用的监控与告警环境
在监控节点安装 Prometheus 与 Grafana
推荐先在监控节点上安装 Prometheus，再装 Grafana。安装时用固定版本目录，并把数据目录单独放在 /var/lib/prometheus，方便后续升级和备份。下面是一组典型安装命令（示例环境，请按你的实际版本与系统适配）：
sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus sudo mkdir -p /etc/prometheus /var/lib/prometheus sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
在业务服务器上安装 Node Exporter 后，先用本机访问确认是否有指标输出。Node Exporter 负责把操作系统层的指标暴露出来，Grafana 告警规则配置的很多表达式都要依赖它的指标名：
curl http://127.0.0.1:9100/metrics | head
如果能看到类似 node_cpu_seconds_total、node_memory_MemAvailable_bytes 的输出，说明采集端已工作。接着把监控节点的 prometheus.yml 指向业务服务器地址：
global:
scrape_interval: 15s
scrape_configs:
- job_name: "node"
static_configs:
- targets: ["业务服务器内网地址:9100"]
15 秒采集一次适合入门测试。生产环境可根据服务器数量和磁盘保留周期调整到 30 秒或 60 秒，避免时间序列过多把监控系统自身拖慢。关于服务资源规划的思路，可参考 Nginx 请求频率限制 一文，其中对并发与资源评估的取舍同样适用于监控规模设计。
连接数据源并做一次查询验证
Grafana 安装完成后，在「数据源」里新增 Prometheus，URL 通常填写 http://监控节点地址:9090。若 Grafana 与 Prometheus 同机，可填 http://localhost:9090。添加成功后，用下面这条查询验证 CPU 指标是否返回数据：
rate(node_cpu_seconds_total{mode!="idle"}[5m])
面板能出图，只代表数据链路通了，离告警还差一步。
Grafana 告警规则配置：规则文件与阈值怎么定
Grafana 的告警既可以写在数据源的规则文件里，也可以在 Grafana 的「告警」页面里配置。下面先看 Prometheus 侧的规则写法，因为它更贴近「表达式 + 阈值」的本质。每条规则由四部分组成：名称、表达式、持续时间和通知信息。
例如磁盘空间告警可以这样写（根分区可用空间低于 15%，持续 10 分钟才触发，属于典型区间，可据磁盘容量调整）：
groups:
- name: server-basic-alerts
rules:
- alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) < 0.15
for: 10m
labels:
severity: warning
annotations:
summary: "root filesystem free space below threshold"
持续时长 for: 10m 用于过滤短时间抖动。比如 CPU 瞬时冲到 90% 未必是故障，但持续 10 分钟通常需要处理。阈值与持续时长的组合，是告警不扰民的关键。
常用阈值参考：典型区间而非固定值
阈值没有放之四海皆准的唯一答案，但可以给出可落地的典型区间。下面的数值是示例数据，请按你的应用与团队响应能力调整：
CPU 使用率：持续 15 分钟高于 85% 提醒，持续 30 分钟高于 95% 升级为紧急。内存可用量：可用内存低于 300MB，或 Swap（交换分区，用磁盘临时充当内存的机制）使用持续高于 50% 时提醒。磁盘使用率：根分区可用低于 15%、数据盘低于 20% 时提醒，低于 10% 升级为紧急。端口连通：业务端口无法连接持续 3 分钟即告警。
上面这些「持续时长」建议在测试期放宽，验证告警链路稳定后再收紧，避免误报淹没人。
通知渠道：让告警到达能处理的人
规则命中后，通知渠道决定告警能否真正被看到。Grafana 通过联系点（contact point）分发告警，可接入邮件、钉钉、Slack 等。第一次配置建议先接一个通道验证，再接生产通道。
通知分组（grouping）也值得关注。多个同类告警可以收敛为一条通知，避免告警风暴。例如同一台机器的多条磁盘告警，可合并为一条「DiskSpaceLow」通知。对数据库相关的慢查询、死锁类监控，可以先参考 MySQL 慢查询分析 一文，把指标与告警阈值映射得更有针对性。
验证链路：用一次模拟故障跑通通知
上线前必须做一次端到端验证。只看 Prometheus 页面显示 UP 不够，因为它只能证明采集端可访问，不能证明规则、通知渠道和处理手册都有效。建议做一次低风险模拟：临时停止测试节点的 Node Exporter，确认 Prometheus 变为 DOWN，再观察 Grafana 面板与告警状态是否同步变化。
sudo systemctl stop node_exporter
等待一个采集周期后，在 Prometheus 查询：
up{job="node"}
如果结果从 1 变为 0，说明采集状态已被识别。再恢复服务：
sudo systemctl start node_exporter
这个验证动作能暴露很多真实问题：安全组没放通端口、目标地址写错、规则文件没被加载、通知邮箱配错等。对 WordPress 站点，可把应用层慢查询、缓存命中和服务器资源变化放进同一套排查路径，结合 Nginx 缓存清理 的思路一起核对。
落地时容易忽略的 4 个细节
保留周期先从 15 天开始：单机指标增长快，用 --storage.tsdb.retention.time=15d 控制磁盘占用，再按审计需求延长。阈值按业务调整：CPU 短时 90% 未必是故障，但磁盘低于 15% 持续 10 分钟通常需要处理。记录每次修改：改查询或阈值时，在团队文档记录日期、原因与影响。监控服务也要被监控：Prometheus 所在机器的磁盘、内存和进程同样需要采集，否则监控系统故障时没有任何提醒。
如果你正在规划新网站或业务迁移，建议把监控纳入上线验收项。对需要托管环境支持的用户，Hostease 可以在主机选择与基础环境规划阶段提供参考，但具体阈值仍应根据你的访问量、应用类型和团队响应时间设定。
总结：先小范围闭环，再逐步扩展
Grafana 告警规则配置不是一次安装就完成的事。推荐的落地顺序是：先采集一台业务服务器的核心指标，做一屏总览面板，再配置 CPU、内存、磁盘、端口四条核心规则，用一次模拟故障验证通知链路。等这条链路稳定，再扩展到数据库、缓存、反向代理和应用自定义指标，参考 Redis 持久化与恢复 的思路，把缓存类监控一并纳入。
如果这套监控要长期维护，建议把「采集正常、面板可读、告警可达、处理动作明确」当作上线验收标准。这样做的价值不只是看到曲线，而是在问题扩大前留下足够线索。更多服务器部署与运维思路，可以从 Hostease 中文站 继续查看。