服务器监控告警配置：Prometheus 与 Grafana 核心验收清单

这篇帖子想解决一个很常见的问题：服务器监控告警配置到底应该先看哪些指标，才不会把 Prometheus（开源监控采集与查询系统）和 Grafana（开源可视化看板工具）做成“看起来很完整、出事时没用”的摆设。很多站长把 CPU、内存、磁盘、Ping 全部接上后就认为监控完成，但真正发生故障时，常见情况是告警太晚、通知没人收到、图表看不出瓶颈，最后还是靠用户反馈发现问题。

TL;DR：先别急着堆看板。我的建议是先围绕 4 条线验收：资源是否快满、网络是否抖动、服务是否可用、告警是否能到人。以一台 2 核 4GB 的 VPS（虚拟专用服务器）为例，CPU 5 分钟平均使用率超过 85%、可用内存低于 15%、根分区使用率超过 80%、站点 HTTP 5xx 在 5 分钟内超过 3 次，都应该进入告警讨论范围。

这类落地清单对 WHT 用户尤其有价值：不少人手里同时跑着企业官网、跨境电商站、API 服务和几个测试小鸡，一旦只靠人工登录服务器排查，晚高峰问题很容易拖到第二天才复盘。Hostease 场景下也应把大陆方向访问质量单独纳入告警。

1. 先确认采集范围：不要只看机器活着没有

服务器监控告警配置的第一步不是安装面板，而是列出必须采集的对象。最小范围建议包含主机资源、磁盘 I/O、网络质量、应用进程、外部访问结果。只看 node exporter 的 CPU 与内存，最多说明机器还在跑；如果 Nginx 进程挂了、证书过期、数据库连接池打满，单机资源图可能仍然很平稳。

在我的测试环境中，一台美国节点 VPS（虚拟专用服务器）跑 WordPress、Nginx、PHP-FPM 和 MariaDB。仅接入 node exporter 后，Grafana（开源可视化看板工具）能看到 CPU 峰值从 22% 突然到 91%，但无法解释 502 的来源。补充 Nginx 5xx 和 PHP-FPM 进程数据后，才发现晚高峰 20:30-21:10 期间 PHP-FPM 子进程长期打满，平均响应时间从 280ms 拉到 1.8s。

• 主机层：CPU 5 分钟平均值、load average、内存可用率、swap 使用量、磁盘剩余空间。
• I/O 层：磁盘 util 超过 80%、await 超过 50ms、数据库目录写入延迟异常。
• 网络层：入站/出站带宽（单位时间可传输的数据量）使用率、丢包率、跨境链路延迟。
• 应用层：HTTP 状态码、进程存活、队列长度、数据库连接数。
• 外部层：从用户主要地区发起的 HTTP 探测，至少每 60 秒一次。

2. Prometheus 侧重点：指标命名、采集间隔和保留周期

Prometheus（开源监控采集与查询系统）最容易踩的坑是“什么都采”。采集项越多，磁盘越快涨，查询越慢，真正有用的指标反而被淹没。对中小站点来说，建议先按 15 秒或 30 秒采集主机与应用指标，保留 15-30 天原始数据。

一个实用判断标准：每个指标都要能回答一个运维问题。比如 node_filesystem_avail_bytes 能回答“根分区还能撑多久”；nginx_http_requests_total 能回答“5xx 是否突然增加”；probe_success 能回答“外部用户是否能访问”。如果某个指标 30 天内没人看、没人用它触发告警，就先不要进入核心看板。

配置上，采集间隔不要盲目压到 5 秒。以 20 台服务器、每台 800 个时序估算，15 秒采集会带来持续写入压力；再叠加标签维度，Prometheus 本地磁盘写入和查询压力会明显上升。站点级监控通常 15-30 秒足够。

3. Grafana 看板：少做大而全，多做能定位问题的视图

Grafana（开源可视化看板工具）的价值不是把所有指标摆满一屏，而是让值班人员在 30 秒内判断问题在哪一层。我的习惯是把首页控制在 8-12 个核心面板。如果首页超过 20 个面板，故障时反而会变成“到处都像有问题”。

看板区域	建议指标	验收标准
可用性	probe_success、HTTP 状态码	连续 2 次失败触发告警，恢复后自动关闭
性能	P95 响应时间、请求量	P95 超过 1.5s 持续 5 分钟进入观察
资源	CPU、内存、磁盘、I/O	资源告警必须能关联到服务异常
网络	丢包率、延迟、带宽（单位时间可传输的数据量）	丢包率超过 1% 持续 3 分钟标记链路风险

为了避免看板“好看但无用”，建议每个面板标题都用运维问题命名，例如“用户是否能访问首页”“数据库连接是否打满”，而不是只写指标名。WHT 用户如果需要对比不同节点，也可以参考 BGP 线路在国内的真实表现，把早晚高峰拆成单独视图。

4. 告警规则：阈值要能触发行动，不要只制造噪音

监控系统最伤士气的不是没告警，而是每天几十条没意义的告警。CPU 瞬间到 95% 并不一定要半夜叫醒人；根分区 90% 且过去 24 小时持续增长，才更值得处理。告警规则应该包含 3 个字段：阈值、持续时间、处理动作。

• P1：外部探测连续 2 次失败，或 5xx 比例 5 分钟内超过 5%，必须 5 分钟内确认。
• P2：磁盘使用率超过 85% 且 6 小时增长超过 5GB，要求当天清理或扩容。
• P3：内存可用率低于 20% 但服务正常，进入周度容量复盘。
• 恢复通知：告警恢复也要通知，避免值班人员不知道问题是否已结束。

5. 通知链路与值班验证：发出去不等于有人处理

很多团队把告警接到邮件、Telegram 或企业微信后就结束了，但实际验收应该继续往后走：谁收到、谁确认、谁处理、谁复盘。建议每条 P1 告警都设置 10 分钟未确认升级规则，避免告警发出后无人处理。

验证通知链路时，不要只点“测试发送”。更可靠的做法是人为制造一次低风险故障，例如临时停止测试站点的 Nginx 30 秒，观察 Prometheus（开源监控采集与查询系统）是否采集到异常、Alertmanager 是否触发、通知渠道是否收到、恢复后是否发送恢复消息。

6. 落地清单：上线前至少跑完这 12 项

前面讲的是方法，真正上线时可以直接按清单验收。清单不求复杂，但每一项都要能在 Grafana（开源可视化看板工具）或告警记录里找到证据。对于只有 1-3 台 VPS（虚拟专用服务器）的小团队，先把下面 5 项跑通更实际。

• 外部 HTTP 探测间隔不高于 60 秒，并覆盖首页、登录页、核心 API。
• 根分区、数据盘、日志目录分别设置阈值，磁盘超过 80% 先提醒。
• CPU 与内存告警设置持续时间，避免 30 秒尖峰反复打扰。
• 数据库连接数、慢查询、磁盘 await 至少进入一个服务看板。
• SSL（安全传输协议）证书有效期低于 14 天时提前提醒。

如果你正在规划海外 VPS（虚拟专用服务器）或独服（独立服务器）环境，可以参考 Hostease 主机讨论专区 和 美国 VPS 速度影响因素与优化 的思路，把机器性能、线路质量和告警指标放在同一张验收表里看，而不是单独比较价格。

总结：先做能救火的监控，再做漂亮的看板

总结一下，服务器监控告警配置的核心不是“装上 Prometheus（开源监控采集与查询系统）和 Grafana（开源可视化看板工具）”，而是让它们在故障发生前后都能帮助人行动。能提前发现磁盘快满、能确认站点不可访问、能把通知送到值班人员、能在恢复后留下记录，这才算基本合格。

建议新手按三步推进：第一周只接入主机资源、外部探测和 3 条 P1 告警；第二周补齐数据库、Web 服务和证书有效期；第三周再优化看板分层、通知升级和容量趋势。这样做的好处是风险可控，每一步都有可验证结果。如果你需要把监控清单和主机选型一起落地，可以考虑先从核心业务服务器开始，逐台复制规则。

最后提醒一句：监控不是为了证明服务器没问题，而是为了在问题刚出现时缩短定位时间。对论坛站长、跨境电商和中小企业 IT 来说，一套能在 5 分钟内发现故障、10 分钟内通知到人的告警链路，往往比多加几张炫酷面板更有价值。如果你需要继续完善主机运营体系，推荐结合 美国/香港主机备案与合规常见问题，把访问、合规和运维监控放到同一个运营视角下评估。