服务器监控怎么做？20条命令建立性能基线

很多人的建站顺序是：买服务器 → 装面板 → 传程序 → 上线。然后就不管了，直到某天网站慢得打不开，才开始慌。问题是，这时候你手里没有任何对比数据——不知道它是「一直就这么慢」，还是「昨天开始变慢的」。这篇讲怎么在服务器上做一套轻量的监控与基线，让你随时能回答「它现在正常吗」。

一、先装一个「能看到历史」的工具

默认情况下，服务器不记录任何历史性能数据。你看到的永远是「此刻」，而排查问题需要的是「过去」。

最轻量的方案：装一套基础监控。以常见的方式为例：

# 安装 node_exporter（Prometheus 体系的标准采集器）
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

# 注册为系统服务
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

为什么要用这套？因为它只负责「采集」，数据格式是标准的，后面接什么可视化都行。如果只想快速看，也可以直接用 vmstat 这类一次性命令，但那样就没有历史曲线了。

检查是否跑起来：

curl -s localhost:9100/metrics | head -20
sudo systemctl status node_exporter

安全提醒：9100 端口绝对不要对公网开放。它会把机器的详细状态暴露出去。只在本地或内网访问，用防火墙挡住。

二、三个必看的即时命令

没有监控系统时，这三条命令能快速判断「现在正不正常」。

命令一：看负载。

uptime

输出末尾三个数字是 1 分钟、5 分钟、15 分钟的平均负载。

关键判读：负载要对照核心数看。

nproc    # 查看核心数

4 核机器负载 4.0 就已经满载；8 核机器负载 4.0 只用了一半。很多人看到负载是 2 就以为出问题，实际上在 8 核机器上非常健康。

还要看趋势：如果 1 分钟负载远高于 15 分钟，说明刚刚突然升高；如果三个数字依次递减，说明高峰已经过去。

命令二：看内存的真实余量。

free -h

这里有个反直觉的点必须说清：看 available 列，不是 free 列。

Linux 会把空闲内存拿去做文件缓存，所以 free 显示很小是正常且健康的——那些内存没浪费，只是被用作加速。真正代表「还能给应用多少」的是 available。

什么情况才是真不够？看 swap 的使用量。如果 swap 持续增长，说明内存确实吃紧，系统开始把数据换到磁盘，性能会明显下降。

命令三：看磁盘和 inode。

df -h
df -i

df -h 看空间使用率，df -i 看 inode 使用率。

inode 是很多人没听过的概念。文件系统给每个文件分配一个 inode，inode 数量是有限的，而且和文件大小无关——一百万个 1KB 的小文件，和一百万个 100MB 的大文件，占用的 inode 一样多。

典型的故障场景：空间还剩 40%，但 inode 用完了，表现是「无法创建新文件」，日志、缓存、上传全部失败。这种情况在存大量小文件的服务器上很常见（比如图片站、邮件服务器、代码仓库）。

三、找出到底是什么在吃资源

知道「资源被吃掉了」，下一步是找出「谁吃的」。

按内存排序：

ps aux --sort=-%mem | head -10

按 CPU 排序：

ps aux --sort=-%cpu | head -10

这两条命令分别列出占内存和占 CPU 最多的 10 个进程。排查「不知道为什么变慢」时，先跑这两条，往往立刻就有答案。

看实时状态：

top -bn1 | head -20

-b 是批处理模式（适合脚本和远程执行），-n1 是只刷新一次。

top 输出里最该看的三行：

load average——和 uptime 一样的负载值。

%Cpu(s)——注意看 wa（iowait，磁盘等待）这一项。如果 wa 很高，说明 CPU 在等磁盘，加 CPU 没用，该换 SSD 或优化 IO。

MiB Mem 里的 available——同上，看可用而不是 free。

看磁盘 IO 的细节：

iostat -x 1 3

如果没有这个命令，装 sysstat 包。重点看 %util 这一列——接近 100% 说明磁盘已经跑满，这是判断「是否该升级磁盘」最直接的依据。

这张表的用法是「从上往下查」。先看负载，负载正常再看内存，内存正常再看磁盘。哪一项先出问题就处理哪一项，不要一上来就加配置——磁盘 IO 慢的时候加 CPU 是完全无效的浪费。

四、建立性能基线：现在就测，以后才有对比

这一节是整个监控体系里最有价值的部分。

核心思想：在「正常状态」下测一遍，把数字记下来。以后觉得异常时再测一遍，两个数字一对比，就知道是不是真的退化了。

测磁盘写入：

dd if=/dev/zero of=testfile bs=1M count=512 conv=fdatasync
rm -f testfile

最后一行显示的 MB/s 就是写入速度。记下来。如果某天变成原来的一半，说明磁盘或 IO 出了问题。

测磁盘读取：

dd if=/dev/zero of=testfile bs=1M count=512 conv=fdatasync
dd if=testfile of=/dev/null bs=1M
rm -f testfile

测网络下载：

curl -o /dev/null -w "%{speed_download}\n" http://speedtest.tele2.net/100MB.zip

返回值除以 131072 就是 Mbps。

测 CPU：

time sha256sum /dev/zero & sleep 10; kill %1

简单粗暴地跑 10 秒计算，看能处理多少。这个方法不精确，但作为「前后对比」足够用。

把这些结果记在一个文件里：

cat > ~/baseline.txt <<'EOF'
日期: $(date +%F)
核心数: $(nproc)
内存: $(free -h | awk '/Mem:/{print $2}')
磁盘写入: XXX MB/s
磁盘读取: XXX MB/s
网络下载: XXX Mbps
EOF

这份基线文件的价值在于：当你说「服务器变慢了」，你有数据支撑。没有基线，你和客服各说各话；有基线，你可以直接说「上个月写入是 500MB/s，现在是 120MB/s」。

五、日志：容量与轮转

日志是双刃剑。没有日志无法排查，日志太多会撑爆磁盘。

查看日志占用的空间：

du -sh /var/log/*
journalctl --disk-usage

系统日志（journald）的清理：

# 只保留最近 7 天
sudo journalctl --vacuum-time=7d

# 或限制总量为 500MB
sudo journalctl --vacuum-size=500M

应用日志的轮转：如果应用自己写日志文件，必须配置轮转，否则文件会无限增长。

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

参数解释：daily 每天轮转一次，rotate 7 保留 7 份，compress 压缩旧文件，copytruncate 复制后清空原文件——这一项对「应用一直打开着日志文件」的场景很关键，不加的话应用会继续往旧文件句柄写。

测试配置是否正确：

logrotate -d /etc/logrotate.d/myapp

-d 是 dry-run 模式，只显示会做什么，不实际执行。配置改完先跑这个验证。

六、报警：不要等用户告诉你

监控的价值在于「提前知道」，而提前知道的前提是有报警。

最简单的报警：磁盘使用率。这是最容易出也最容易预防的故障。

# 超过 85% 就发通知
df -h | awk '$5+0 > 85 {print "警告: "$6" 已用 "$5}'
加入 crontab，每小时检查一次：
0 * * * * df -h | awk '$5+0 > 85 && $6=="/"' | mail -s "磁盘告警" you@example.com

其他该设报警的项：

服务是否存活。定期访问一个健康检查接口，返回非 200 就报警。

证书到期。证书过期会导致整站不可访问，而且完全可以通过监控提前一周发现。

swap 使用量。swap 持续增长说明内存不足，是性能恶化的早期信号。

一个原则：报警要少而准。如果报警太多，你会开始忽略它，那这套监控就废了。宁可少设几个，但每个都要是「真的需要人处理」的。

七、五家可纳入对比的渠道方向

在现有渠道里，以下几家在配置与地区上值得纳入对比。重点：它们的公开描述没有给出具体的监控与快照配套，实际功能需自行确认。

DigitalVirt：美国洛杉矶、香港、日本东京、德国法兰克福、英国伦敦五地，标注 CN2 GIA / 9929 / CMIN2 / 4837 四套线路。多地区意味着可以做跨区域监控对比。

恒创科技：标注 CN2 / GIA / BGP / HGC，具有自有 ASN 与 APNIC/ARIN 会员资质。自有 ASN 在配置反向解析时有实际用处。

justg：多档配置产品线，档位梯度清晰，便于按需求对照选择。

Zorocloud：覆盖美国 CERA 高防、新加坡、香港、台湾、英国等地。高防节点通常配套流量监控。

CloudCone 与 Backwaves 也提供多地区产品线。对比时可以重点问是否提供面板级监控图表。

注意：以上都是商家公开描述。本文所有命令都不依赖具体商家，任何 Linux 服务器都能照做。

八、结论：监控的核心是「有对比」

一、先有历史数据，才谈得上排查。默认服务器不记录历史，装一套采集工具是第一步。但要注意端口不要对公网开放。

二、三个反直觉的判读点必须记住。free 小是正常的（看 available）；负载要对照核心数；空间够也可能写不进（inode 耗尽）。这三点是最常见的误判来源。

三、基线要在「正常时」建立。刚部署完就跑一遍 dd、curl 和 CPU 测试，把数字存下来。以后变慢时有对比，才有说服力。

四、报警要少而准。磁盘使用率、服务存活、证书到期，这三项覆盖了大部分会导致整站不可用的故障。报警太多反而会被忽略。

最后一句：监控这件事的价值不在于「现在」，而在于「那时候」。今天花一小时装好、测好、记下来，某天凌晨出问题时，你能立刻判断是「突发」还是「早就开始恶化」——这个判断决定了你该重启还是该升级，也决定了故障持续十分钟还是两个小时。

本文所涉 Linux 系统监控命令、node_exporter 部署方式、性能测试方法与 logrotate 配置均整理自公开技术文档与通用运维实践，为 2026 年 11 月查询所得。命令语法与软件版本以主流发行版为准，不同版本存在差异，安装前请确认包源与版本兼容性。监控组件涉及端口暴露，部署时请务必配置防火墙规则。文中对渠道的描述均来自其公开页面，未做实测验证。本文内容仅供参考，不构成任何购买承诺或性能保证，亦不代表本站立场。读者应独立判断、自行决策，因执行命令或使用相关产品所产生的直接或间接损失，作者及本站不承担任何责任。