Hostease 专区实测讨论：Node Exporter 容量告警先看磁盘、内存还是连接数

如果你已经把 Node Exporter 装到 VPS（虚拟专用服务器）上，下一步真正难的不是“如何看到指标”，而是为什么同样的告警规则，有些机器能提前解决容量风险，有些机器却每天误报。本文从 WHT 社区常见运维场景出发，讨论磁盘、内存、CPU、连接数和网络指标的优先级，帮助你把容量告警写成可处理的信号，而不是把群消息刷成噪音。

先说结论：单台业务 VPS（虚拟专用服务器）最先盯磁盘和内存，其次看 CPU 负载，再结合连接数与网络吞吐确认是否是访问峰值。Node Exporter 只负责采集主机层数据，Prometheus 负责拉取和计算，告警规则负责把“趋势接近风险线”翻译成行动。这个顺序适合大多数 WordPress、企业官网、轻量 API 和中小型电商站；如果你跑的是高并发网关或长连接业务，连接数的优先级要明显上调。

目录

• 为什么容量告警不能只看 CPU
• 磁盘、内存、CPU、连接数的优先级
• 一套可落地的 Prometheus 规则思路
• 怎样减少误报并做 7 天复盘
• 适合不同主机用户的配置建议

为什么容量告警不能只看 CPU

很多新手会把 CPU 使用率当成主告警，这是最容易误判的地方。一次备份、一次缓存预热、一次图片压缩任务，都可能让 CPU 在 1 到 3 分钟内冲到 90%。如果规则只写“CPU 大于 80% 就通知”，晚上一次计划任务可能触发十几条消息，值班的人很快就不看了。真正值得处理的是持续压力，比如 5 分钟平均负载超过核心数 1.5 倍，且业务响应同时变慢。

容量风险通常更早出现在磁盘和内存。磁盘剩余空间从 30GB 降到 10GB，看起来还没出故障，但如果日志每天增长 2GB，5 天后就可能写满；内存可用量长期低于 10%，再叠加 swap 持续增长，应用延迟会逐步抖动。CPU 峰值像“症状”，磁盘和内存趋势更像“病程”。这也是我在小型站点里更愿意先做容量趋势告警，而不是堆满瞬时性能告警的原因。

如果你还在做主机选型，可以把监控思路和 虚拟主机与 VPS（虚拟专用服务器）的差异放在一起看：权限越高，监控越要靠自己；资源越灵活，阈值越不能照抄默认模板。

磁盘、内存、CPU、连接数的优先级

对普通网站 VPS（虚拟专用服务器），我建议用“四层优先级”处理 Node Exporter 指标。第一层是磁盘，因为写满后数据库、日志、缓存、上传目录都会受影响。生产环境可以把 80% 设为 warning，90% 设为 critical；如果磁盘日均增长超过 3GB，还要单独估算剩余天数。第二层是内存，看 MemAvailable，而不是只看 MemFree。Linux 会把空闲内存用于缓存，MemFree 低并不必然危险，MemAvailable 低并且 swap 增长才更值得紧张。

第三层才是 CPU 和 load。CPU 使用率需要和核心数、负载、进程行为一起看。1 核机器 load 长期高于 1.5，2 核机器长期高于 3，基本就该排查 PHP-FPM、数据库慢查询、爬虫访问或计划任务。第四层是连接数、网络错误包和带宽（单位时间内可传输的数据量）利用率。短连接站点连接数偶尔升高不一定危险，但长连接、反向代理、下载站和 API 网关要把连接数放到更前面。

这张表不是固定答案，而是起步基线。比如图片站、下载站更依赖带宽（单位时间内可传输的数据量）和磁盘；企业官网更怕磁盘写满、内存抖动；论坛站除了数据库，还要看连接数和 PHP worker。把业务类型写进 Prometheus 标签，比只看 instance IP 更容易定位问题。

一套可落地的 Prometheus 规则思路

规则不一定要多，但每条都要能指向动作。磁盘告警可以排除 tmpfs、overlay 等临时文件系统，避免容器挂载产生误报；内存告警要结合 MemAvailable 和 swap；节点存活告警用 up 指标，但不要 10 秒不通就报警，持续 3 分钟更稳。Prometheus 的 scrape interval 建议从 15 秒或 30 秒开始，普通业务没必要一上来设 1 秒，否则监控系统自己的存储压力会变大。

可以把表达式按风险类型分组：容量类看“还剩多少”，可用性类看“是否还活着”，性能类看“是否持续超出承载范围”。上线前先在查询页面跑表达式，确认返回的是你想看的文件系统、网卡或实例。很多误报并不是 Prometheus 不准，而是标签选择过宽，把临时挂载、测试节点、备份盘都算进了生产告警。

如果你正在调网络和访问速度，也可以结合 美国 VPS（虚拟专用服务器）速度因素与优化思路一起复盘。Node Exporter 能告诉你主机资源是否异常，但访问慢还可能来自线路、应用缓存、数据库查询和前端资源。主机指标是第一层证据，不是全部答案。

怎样减少误报并做 7 天复盘

告警上线后的第一个星期，重点不是追求规则完美，而是记录误报来源。建议每天看一次告警历史，把“确实需要处理”“已知计划任务”“阈值太敏感”“标签选错”分成四类。只要一条规则连续 3 天触发但没人处理，就要么提高阈值，要么增加持续时间，要么改成日报观察。没人看的告警，比没有告警更危险，因为它会训练团队忽略真正的风险。

7 天复盘可以按固定流程做。先看磁盘剩余空间和日均增长量，用“剩余 GB ÷ 日均增长 GB”估算还能撑几天；再看 MemAvailable 的最低值和 swap 是否持续上升；接着对齐 CPU 峰值与访问日志，看是否集中在营销活动、爬虫抓取或备份窗口；最后检查网络出入站曲线和错误包。如果某项指标总在同一时段异常，优先修计划任务、缓存和限流，而不是立刻升级配置。

线路类问题则不要只靠 Node Exporter 判断。像 BGP 线路在国内早晚高峰的表现这类问题，需要结合 ping、MTR、访问日志和业务区域。Node Exporter 可以证明“服务器本机有没有忙”，但不能单独证明“用户到机房的路径是否稳定”。

适合不同主机用户的配置建议

如果你的业务刚上线，1 到 2 台 VPS（虚拟专用服务器）可以先用基础监控跑 7 天，再决定是否扩容。建议第一周只放 4 类规则：磁盘 80%/90% 分级、可用内存低于 10%、节点 up 持续 3 分钟为 0、5 分钟负载超过核心数 1.5 倍。等这些规则稳定后，再增加连接数、网络错误包、数据库进程和 Web 服务探活。

如果业务已经有稳定访问量，可以把标签设计得细一点：env 区分 prod 和 test，role 区分 web、db、cache，region 区分访问区域。这样告警消息里直接出现“prod-web-香港节点磁盘 88%”，比只看到一个 IP 更容易处理。对于需要更高独占资源的站点，Hostease 这类主机服务可以作为对照项，但仍要把 CPU、内存、磁盘、线路和运维能力放在同一张决策表里。

总结一下，Node Exporter 容量告警的重点不是把指标做满，而是把磁盘、内存、CPU、连接数和带宽（单位时间内可传输的数据量）放到正确顺序里。我的建议是：先让 4 条基础规则稳定运行 7 天，再根据真实故障记录扩展；先处理连续趋势，再处理瞬时尖峰；先确认主机资源，再追应用和线路。如果你需要新建或升级业务环境，可以考虑用这套监控结果反推资源规格，而不是只凭感觉加钱升配。

最后给一个可执行的落地顺序：今天先确认 Node Exporter 的 up 指标为 1，明天加磁盘和内存告警，跑满 7 天后做一次容量复盘；如果磁盘剩余天数低于 14 天，就处理日志、备份或扩容；如果内存连续 3 天低于 10%，再排查进程和缓存。这样做不一定让系统零故障，但能让你更早看到风险，也能让每一次告警都更接近可处理的问题。