服务器监控不是把几条曲线放到面板上就结束了。真正有价值的监控，要能回答三个问题：服务为什么变慢、故障如何提前发现、告警触发后该看哪一组数据。本文用 Prometheus 与 Grafana 搭建一套可复用的服务器监控方案，帮助你从安装、采集、面板到告警验证完成闭环，而不是停留在“能看到数据”的阶段。
我们假设你有两台主机：一台业务服务器，一台监控服务器。业务服务器负责运行网站或接口服务；监控服务器负责拉取指标、保存时间序列数据，并通过浏览器展示图表。这样的拆分适合中小团队起步，也方便后续扩展到更多节点。
先确定监控目标：不要一上来就堆面板
很多监控系统失败，不是工具选错，而是指标没有服务于真实问题。对于一台承载网站或应用的服务器，第一阶段建议只盯 4 类核心信号：CPU 使用率、内存占用、磁盘空间、网络连接状态。它们不能解释所有问题，但足够覆盖“机器是否还能稳定工作”的大多数场景。
如果你的业务部署在 VPS（虚拟专用服务器）主机、物理主机或托管环境中，这套思路都适用。区别只在于你能否安装采集组件，以及是否需要额外开放防火墙端口。对于新手，我们建议先在测试环境跑通，再放到生产环境中逐步加告警。
安装 Prometheus 与 Node Exporter
Prometheus 的核心逻辑是“主动拉取”。它不会等待业务服务器推送数据，而是按照配置周期访问目标地址。Node Exporter 则安装在被监控服务器上，负责把系统级指标暴露出来。为了减少排障难度，建议先使用固定版本目录安装，并把数据目录单独放在 /var/lib/prometheus。
在监控服务器上创建目录并下载 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 后，先用本机访问确认是否有数据输出：
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 秒，避免时间序列过多导致监控系统本身变成负担。关于基础服务器规划，也可以参考 服务器相关文章 中对资源与运维场景的整理。
用 Grafana 做可读面板，而不是只追求好看
Grafana 的价值在于把原始指标变成运维人员能快速判断的视图。面板越多并不代表越专业，入门阶段建议先做一屏总览：上方显示 CPU、内存、磁盘使用率，中间显示负载与网络连接，下方保留最近 6 小时的趋势图。这样排查问题时不用在多个页面之间切换。
连接 Prometheus 数据源时，URL 通常填写 http://监控服务器地址:9090。如果 Grafana 与 Prometheus 部署在同一台机器，也可以使用 http://localhost:9090。添加完成后，用下面这条查询测试 CPU 指标是否返回数据：
rate(node_cpu_seconds_total{mode!="idle"}[5m])
面板命名要贴近排障动作。例如“CPU 5 分钟平均使用率”比“CPU Panel 01”更容易理解；“根分区剩余空间”比“Disk Usage”更适合中文团队协作。团队如果同时管理网站性能，还可以把 TTFB 与主机优化 这类内容作为排查延迟问题的背景资料，把监控指标和页面体验联系起来。
告警规则要能指导处理动作
告警的目的不是制造噪音，而是提醒你在故障扩大前采取动作。建议从三条规则开始：磁盘空间不足、内存持续吃紧、业务端口不可达。每条规则都要包含阈值、持续时间和处理指向。
例如磁盘告警可以这样写：
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"
这条规则的含义是：根分区可用空间低于 15%，并持续 10 分钟才触发告警。这样可以过滤短时间波动，同时给运维人员留下清理日志、扩容磁盘或迁移数据的窗口。
验证链路：让一次模拟故障跑完整流程
监控上线前必须做验证。只看 Prometheus 页面显示 UP 并不够，因为它只能说明采集端可访问，不能证明告警规则、通知渠道和处理手册都有效。我们建议至少做一次低风险模拟：临时停止测试节点的 Node Exporter，确认 Prometheus 变为 DOWN，再观察 Grafana 面板和告警状态是否同步变化。
可以用以下命令临时停止采集端：
sudo systemctl stop node_exporter
等待一个采集周期后，在 Prometheus 查询：
up{job="node"}
如果结果从 1 变为 0，说明采集状态已经被识别。再恢复服务：
sudo systemctl start node_exporter
这个验证动作看起来简单，却能暴露很多配置问题，例如安全组没有放通端口、目标地址写错、规则文件没有被加载、Grafana 数据源连接错误。对于运行 WordPress 的站点，还可以结合 WordPress 相关运维内容，把应用层慢查询、缓存命中和服务器资源变化放在同一套排查路径里。
落地时最容易忽略的 4 个细节
工具跑起来后，真正决定监控质量的是维护习惯。下面 4 个细节建议写进团队的上线清单，而不是等故障后再补。
- 保留周期先从 15 天开始：单机监控数据增长很快，先用
--storage.tsdb.retention.time=15d控制磁盘占用，再根据审计需求延长。 - 告警阈值要按业务调整：CPU 短时 90% 未必是故障，但磁盘剩余低于 15% 持续 10 分钟通常需要处理。
- 面板修改要留记录：每次改查询语句或变量范围，至少在团队文档里记录日期、原因和影响范围。
- 监控服务也要被监控：Prometheus 所在机器的磁盘、内存和进程状态同样需要采集，否则监控系统故障时你可能没有任何提醒。
如果你正在规划新网站或业务迁移，监控不应该等上线后才补。可以在服务器交付、应用部署、域名解析、日志轮转之后，把 Prometheus 和 Grafana 作为验收项一起检查。对需要托管环境支持的用户，Hostease 可以在主机选择和基础环境规划阶段提供参考，但具体阈值仍应根据你的访问量、应用类型和团队响应时间来设定。
总结：先小范围闭环，再逐步扩展
Prometheus 与 Grafana 的组合适合做服务器监控，但它不是一次安装就完成的项目。推荐的落地顺序是：先采集一台业务服务器的基础指标，再做一屏总览面板，然后配置 3 条最关键的告警，最后用模拟故障验证通知链路。等这条链路稳定后，再扩展到数据库、缓存、反向代理和应用自定义指标。
如果你需要把服务器监控纳入网站上线流程，可以考虑把“采集正常、面板可读、告警可达、处理动作明确”作为验收标准。这样做的价值不只是看到曲线，而是在问题出现前留下足够线索，让团队更快判断原因并采取下一步行动。更多主机方案与部署思路，也可以从 Hostease 中文站 继续查看。