如果服务器出现 CPU 长时间飙高、磁盘空间突然耗尽、应用响应变慢，排障的第一步不是反复刷新后台，而是把异常变成可查询的指标。本文会教你如何用 Linux 服务器监控指标建立 Prometheus 采集、Grafana 趋势面板和告警规则，重点解决 CPU、磁盘、内存三类常见问题。
这篇文章面向有基础命令行经验的站长、开发者和运维人员。我们会从单机部署开始，覆盖 Node Exporter 指标采集、Prometheus 拉取配置、Grafana 数据源、告警规则设计和上线验证。
一、先确认监控目标：别一上来就堆面板
对一台生产服务器来说，第一阶段建议先覆盖 4 类指标：CPU 使用率、内存可用量、磁盘空间和网络吞吐。它们对应最常见的故障路径：计算资源被打满、进程内存泄漏、日志撑爆分区、异常流量拖慢服务。如果网站还依赖数据库或反向代理，可以在第二阶段再接入对应 exporter；运行在 虚拟主机 上的站点，则应优先结合面板统计和应用日志判断瓶颈。
二、准备运行环境与目录结构
本文示例使用一台 2 核 4GB 内存的 Linux 服务器，系统账号具备 sudo 权限。Prometheus 与 Grafana 可以直接安装二进制包，也可以通过容器运行。为了便于复用、备份和迁移，下面采用 Docker Compose 方式演示；如果你的生产环境不允许容器，也可以把同样的端口、配置文件和数据目录思路迁移到 systemd 服务。
先创建监控目录，并准备 3 个子目录：
sudo mkdir -p /opt/monitoring/{prometheus,grafana,node-exporter}
sudo chown -R $USER:$USER /opt/monitoring
cd /opt/monitoring接下来准备 docker-compose.yml。核心配置只需要 3 个服务：Prometheus 使用 prom/prometheus:v2.54.1，挂载 ./prometheus/prometheus.yml 与数据卷；Grafana 使用 grafana/grafana:11.2.0，暴露 3000 端口；Node Exporter 使用 prom/node-exporter:v1.8.2，暴露 9100 端口并读取宿主机根文件系统。生产环境中不建议把 9090 和 9100 直接开放到公网，后文会说明访问控制方式。
三、配置 Prometheus 抓取 Node Exporter 指标
有了运行定义后，还需要告诉 Prometheus 去哪里抓指标。创建 /opt/monitoring/prometheus/prometheus.yml，把 scrape_interval 和 evaluation_interval 都设为 15s，再配置两个抓取目标：Prometheus 自身使用 prometheus:9090，Linux 服务器指标使用 node-exporter:9100，并给该目标增加 instance="web-01" 标签。这个标签后续可与 服务器配置 记录保持一致，方便排查硬件资源变化。
global.scrape_interval 设置为 15 秒，适合中小型站点的基础监控。如果服务器数量较多，可以改成 30 秒或 60 秒，以减少存储写入压力。instance 标签建议写成稳定名称，例如 web-01、db-01，不要写随机容器名，否则后续面板和告警会难以维护。
启动服务：
cd /opt/monitoring
docker compose up -d
docker compose ps验证 Prometheus 是否能看到采集目标：打开 http://服务器IP:9090/targets，确认 prometheus 和 linux-server 都是 UP。如果 linux-server 显示 DOWN，先在服务器上执行 curl http://127.0.0.1:9100/metrics | head，确认 Node Exporter 是否正常输出指标，再检查容器网络和防火墙规则。
四、在 Grafana 中接入数据源并配置告警
Grafana 初次访问地址是 http://服务器IP:3000，默认账号通常为 admin/admin，首次登录后必须立即修改密码。进入 Grafana 后添加 Prometheus 数据源，地址填写 http://prometheus:9090，保存并测试通过后，再创建 CPU、内存和磁盘 3 个基础面板。CPU 使用率可用 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)，内存可用率可用 node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100，根分区可用率可用 node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{mountpoint="/",fstype!~"tmpfs|overlay"} * 100。
只看面板仍然依赖人工打开浏览器，告警才是监控闭环的关键。第一批告警建议控制在 3 条：CPU 使用率连续 10 分钟高于 85%，根分区可用率低于 15%，内存可用率连续 10 分钟低于 10%。告警通知内容要包含实例名、指标值、持续时间和排查入口。例如 web-01 CPU 90% 持续 10 分钟，查看 Grafana 面板 /d/server-overview。如果只写“CPU high”，值班人员还要二次打开系统确认，响应时间会被拉长。
五、安全加固与数据保留策略
监控系统本身也需要保护。Prometheus 和 Grafana 都可能暴露服务器指标、主机名、挂载路径等内部信息，不应该裸露在公网。至少应做到：Grafana 使用强密码和 HTTPS（安全传输协议），Prometheus 9090 与 Node Exporter 9100 只允许内网或指定管理 IP 访问。
更稳妥的做法是把 Grafana 放在反向代理后面，使用 HTTPS（安全传输协议）证书和基础认证；Prometheus 与 Node Exporter 仅在容器网络或内网中通信。对于企业站点，还可以结合 WordPress 主机 或应用服务器的访问策略，把监控入口接入 VPN（虚拟专用网络）或堡垒机，减少暴力扫描风险。
数据保留时间也要提前规划。本文示例中 --storage.tsdb.retention.time=15d 表示保留 15 天原始指标。如果需要按月分析容量趋势，可以改成 30d 或 60d。
六、上线后的验证清单与常见排障
完成安装不代表监控已经可用，至少要做一次“人为制造小异常”的演练。比如临时运行 CPU 压力命令 2 到 3 分钟，观察 Grafana 曲线是否抬升；把告警阈值临时调低，验证通知通道是否能收到消息。
常见问题可以按同一条路径排查。Prometheus targets 页面为 DOWN 时，先在容器内或宿主机执行 curl http://node-exporter:9100/metrics，判断是服务未启动还是网络不可达。Grafana 数据源测试失败时，确认地址应使用 http://prometheus:9090，不是宿主机公网地址；同一 compose 网络下服务名可直接解析。面板显示 No data 时，重点检查 PromQL 标签是否写死了错误的 instance，也要确认时间范围不是过短。告警频繁误报时，把持续时间从 1 分钟提高到 10 分钟，并为 CPU、磁盘、内存设置不同阈值。
如果你正在做 网站性能优化，建议把监控上线时间与优化动作记录在同一份变更表中，再回看 CPU、内存、响应时间和错误率变化。
总结：先做小闭环，再扩展多节点监控
Prometheus + Grafana 的价值不在于面板有多漂亮，而在于帮助你把服务器状态从“事后猜测”变成“持续可验证”。建议第一阶段只监控 1 到 3 台核心服务器，采集 CPU、内存、磁盘、网络 4 类基础指标，设置 3 到 5 条低噪音告警，并完成一次通知演练。等这套闭环稳定运行 1 到 2 周后，再考虑接入数据库、反向代理、应用指标和多节点聚合。
如果你的业务对稳定性要求较高，可以优先选择资源余量更清晰、扩展更方便的 Hostease VPS（虚拟专用服务器）或独立服务器（专用物理服务器）方案，并把监控部署作为上线前标准步骤。最后推荐把配置文件、告警规则和面板 JSON 一起纳入备份；当服务器迁移或重建时，你可以在 30 分钟内恢复监控能力，而不是从零重新配置。