Prometheus Node Exporter 监控 VPS（虚拟专用服务器）并不是为了把页面填满曲线，而是为了回答一个更实际的问题：网站为什么变慢、磁盘什么时候会满、负载升高前能不能提前解决。很多中小团队只有一两台业务服务器，平时靠登录面板或临时执行 top、df -h 排查；等访问异常才发现 CPU 长时间跑满、磁盘只剩几百 MB，处理成本会高很多。本文会用一条清晰主线，帮助你从指标采集、Prometheus 拉取配置、告警规则到容量复盘，建立一套适合 VPS（虚拟专用服务器）的基础监控指南。
先明确：Node Exporter 负责采集什么，不负责什么
Node Exporter 是 Prometheus 生态中常用的主机指标采集组件，它会把 Linux 系统的 CPU、内存、磁盘、网络、文件系统等指标暴露成 HTTP 接口。Prometheus 再按固定周期抓取这些指标，Alertmanager 或其他告警通道根据规则触发通知。你可以这样理解：Node Exporter 像服务器上的“体检仪”，Prometheus 是定时读取体检数据的记录系统，告警规则则是判断“哪些指标已经接近风险线”的标准。
在 VPS（虚拟专用服务器）场景里，优先关注 4 类指标就够了。第一类是 CPU 使用率和 1/5/15 分钟负载，适合判断瞬时尖峰还是持续压力。第二类是内存可用量与 swap 使用量，如果可用内存长期低于 10%，应用容易出现抖动。第三类是文件系统使用率，生产环境建议在 80% 设置提醒、90% 设置严重告警。第四类是网络收发速率与错误包，它能帮助定位突增流量或网卡异常。
这套监控不能替代应用日志，也不能直接告诉你某段业务代码为何慢。它的价值在于先确认底层资源是否健康，再决定要不要继续追查 Web 服务、数据库、缓存或代码逻辑。如果你还在规划服务器规格，可以先参考 Hostease 的 VPS（虚拟专用服务器）方案，把 CPU、内存和磁盘容量与实际监控阈值对应起来。
安装 Node Exporter，并把采集面控制在必要范围
Node Exporter 本身很轻量，常见部署方式是以 systemd 服务运行，并监听本机的 9100 端口。为了减少暴露面，我们建议只允许 Prometheus 服务器访问该端口，不要把 9100 直接开放给公网。对于单台 VPS（虚拟专用服务器）自监控，可以让 Prometheus 与 Node Exporter 在同一台机器上运行；对于多台服务器，则把 Prometheus 放在固定管理节点，再通过防火墙放行管理节点 IP。
下面是一套常见安装思路，版本号需要按官方发布页选择当前稳定版本，不要长期复制旧脚本：
useradd --no-create-home --shell /usr/sbin/nologin node_exporter mkdir -p /opt/node_exporter install -o node_exporter -g node_exporter -m 0755 node_exporter /usr/local/bin/node_exporter chown node_exporter:node_exporter /usr/local/bin/node_exporter
随后创建 systemd 服务文件，关键点是固定运行用户、重启策略和监听地址。如果 Prometheus 与 Node Exporter 在同一台机器上，可以把监听地址限制为 127.0.0.1:9100；如果需要远程拉取，则结合防火墙只放行 Prometheus 节点。
[Unit] Description=Node Exporter After=network.target [Service] User=node_exporter Group=node_exporter Type=simple ExecStart=/usr/local/bin/node_exporter --web.listen-address=127.0.0.1:9100 Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target
启用服务后，用 curl http://127.0.0.1:9100/metrics 检查是否能看到 node_cpu_seconds_total、node_memory_MemAvailable_bytes 等指标。若接口正常，再进入 Prometheus 配置；如果接口为空或返回连接失败，优先检查 systemd 日志、二进制权限和监听地址，而不是直接修改 Prometheus 配置。
配置 Prometheus 拉取，并用标签区分业务角色
Prometheus 的 scrape_configs 决定它从哪里拉取指标。小团队常见错误是把所有服务器都写成裸 IP，后期排障时只看到 instance="10.0.0.5:9100"，很难判断这是 Web 节点、数据库节点还是测试环境。更稳妥的做法是在配置中补充 job、role、env 等标签，让告警消息能直接说明风险来源。
一个基础配置可以这样写：
scrape_configs:
- job_name: "node"
scrape_interval: 15s
static_configs:
- targets: ["127.0.0.1:9100"]
labels:
env: "prod"
role: "web"
scrape_interval 不必一开始就设得很短。对普通网站服务器来说，15 秒到 30 秒足以发现持续性资源问题；如果设置成 1 秒，Prometheus 自身存储压力会增加，长期收益却有限。保存配置后执行 promtool check config prometheus.yml，再重载 Prometheus。进入查询页面后，先运行 up{job="node"}，返回 1 代表拉取正常，返回 0 则需要检查网络、防火墙或 Node Exporter 进程。
更多网站性能排查思路，也可以结合 TTFB 与主机性能优化指南 一起看。
把告警规则写成“可处理”的信号，而不是噪音
告警规则的目标不是越多越好，而是让值班人员收到后知道该做什么。以 CPU 为例，单次 90% 使用率并不一定是事故，可能只是备份任务或批量脚本；但 5 分钟平均负载持续高于 CPU 核心数的 1.5 倍，就更值得关注。内存也类似，Linux 会积极使用缓存，直接看 MemFree 容易误判，通常应使用 MemAvailable 判断可用内存。
下面是 3 条适合 VPS（虚拟专用服务器）起步的告警思路：
- 磁盘使用率超过 80% 且持续 10 分钟，先提醒清理日志、备份包或扩容；超过 90% 持续 5 分钟，升级为严重告警。
- 可用内存低于 10% 且 swap 持续增长，检查进程内存、缓存策略和计划任务，不要只重启服务。
up{job="node"} == 0持续 3 分钟，先判断是节点宕机、网络中断还是 Node Exporter 服务异常。
对应的 Prometheus 规则可以放在 node-alerts.yml，并通过 rule_files 引入。下面示例只保留核心表达式，实际环境应根据业务峰值调整阈值：
groups:
- name: node-alerts
rules:
- alert: NodeDiskUsageHigh
expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 > 80
for: 10m
labels:
severity: warning
annotations:
summary: "Disk usage is high"
写完规则后必须执行 promtool check rules node-alerts.yml。如果规则语法不通过，Prometheus 可能无法加载规则文件；如果标签选择过宽，容器临时文件系统、只读挂载或虚拟文件系统也会触发误报。我们建议每条规则上线前先在 Prometheus 查询页面跑一次表达式，确认返回的是你真正关心的磁盘或网卡。
用容量趋势决定扩容，而不是等故障发生
监控跑起来后，真正有价值的是趋势判断。单点阈值只能告诉你“现在是否越线”，容量趋势能告诉你“什么时候会越线”。例如某站点日志目录每天增长 2 GB，磁盘剩余 40 GB，看起来暂时安全；但如果备份保留策略没有调整，约 20 天后就会触发磁盘告警。相比临时清理，提前规划日志轮转、对象存储归档或磁盘扩容更稳妥。
每周复盘可以按固定顺序做：先查看 7 天 CPU 平均值和峰值，如果工作时间平均超过 60%、峰值多次超过 90%，记录对应访问时段和进程；再用“当前剩余 GB ÷ 最近 7 天日均增长 GB”估算磁盘剩余天数；随后检查内存可用量和 swap，若 swap 每天持续增加，优先排查应用泄漏或缓存配置；最后把网络出入站异常尖峰与访问日志、爬虫日志或营销活动时间对齐。
如果你同时维护多个站点，还可以把 Web、数据库、缓存拆成不同角色标签，分别设置阈值。和网站安全、备份策略相关的排查，也可搭配 服务器运维相关文章 做延伸阅读。容量复盘不是为了追求每个指标都很低，而是为了让资源与业务节奏匹配。
常见误区：监控系统本身也需要运维
很多监控项目失败，不是因为工具选错，而是因为告警没人维护。上线初期规则太宽，团队每天收到十几条无意义通知，几周后就会开始忽略；规则太窄，又可能错过真正风险。比较可行的方式是先覆盖 CPU、内存、磁盘、节点存活 4 类基础告警，再根据实际故障记录逐步增加应用层指标。
Prometheus 自身也会占用磁盘。建议从 15 秒或 30 秒采集间隔起步，并定期查看 Prometheus 数据目录；如果监控系统先把磁盘写满，业务排障反而会更被动。安全侧也要做到端口访问限制、固定运行用户和最小权限运行。对外提供业务网站时，SSL（安全传输协议）、DNS（域名解析系统）和带宽（单位时间内可传输的数据量）状态也应纳入整体可用性观察，而不是只盯着 CPU 曲线。
总结：先把基础指标做准，再逐步扩展应用监控
Prometheus Node Exporter 监控 VPS（虚拟专用服务器）的核心，不是一次性搭出复杂平台，而是先把基础指标采集准确、告警阈值可处理、容量趋势可复盘。建议你从一台服务器开始：确认 up 状态正常，设置磁盘 80%/90% 分级告警，观察 7 天 CPU、内存和网络曲线，再把同样方法复制到更多节点。
如果你需要为新网站或增长中的业务选择服务器，可以考虑先根据监控结果估算资源需求，再决定是否升级 VPS（虚拟专用服务器）规格、迁移到 独立服务器，或继续优化现有应用。Hostease 可为不同规模的网站提供主机与服务器方案，但最终选择仍应结合访问量、数据增长速度、运维能力和预算。把监控做好，后续扩容、迁移和排障都会更有依据。
对于已经上线的网站，我们推荐把本文中的安装、拉取、告警、复盘四步整理成内部运维清单，并在每次业务活动前检查一次。这样做不一定能消除所有故障，却可以让你更早看到风险、更快定位问题，也能避免很多“等用户反馈才发现服务器已经满了”的被动场景。