如何监控数据中心服务器？盯住这 10 个指标就够了

数据中心服务器监控的核心不是采集尽可能多的指标，而是盯住少数几个能提前暴露问题的领先指标：CPU、内存、磁盘 IO、磁盘空间、系统负载、交换分区、吞吐量、错误率、进程健康、硬件健康。这 10 个盯住了，绝大多数服务器故障都能在影响业务前被发现。下面逐个说为什么是它们、阈值怎么定。

先说清楚：什么样的指标才值得盯

服务器监控最常见的误区是“采得多等于监控得好”。Zabbix 默认模板一开就是几百个监控项，真正在故障前能给你报警的可能不到十分之一。

值得盯的指标要能回答三个问题：是不是故障的前兆？影不影响用户体验？能不能帮你定位瓶颈？三问都答不上来的指标，采了也只是占数据库空间。

判断标准就一条：这个指标变了，你会做什么动作。答不上来的，砍掉。

CPU 利用率：第一个要盯的，但别只看平均值

CPU 利用率衡量的是处理器被占用的程度，要看单核和总体两个维度。

行业实践里的参考线：跑批任务时冲到 95% 属于正常，但持续 20 分钟高于 90% 就要处理了。还有一个容易被平均值掩盖的坑——16 核的机器，总体利用率 40%，但可能有一个核跑满 100%（单线程应用就是这德行），总体数字看着没事，用户的请求照样卡。

排查看什么：top 里按 P 排序看单进程， 看单核分布。

mpstat -P ALL 1

内存使用率：服务器变慢的第一嫌疑

内存不够不会立刻崩，而是先变慢——应用开始频繁等内存，延迟一点点涨上去。所以内存是最值得提前报警的指标之一。

参考线：物理内存持续高于 85% 开始关注，高于 92% 且还在爬升就该动手了。动手的顺序也有讲究：先看是不是缓存占用（缓存高不是坏事，Linux 会拿空闲内存做缓存），再看有没有进程内存泄漏（RSS 持续上涨不回落），最后才考虑加内存。

磁盘 IO：最容易被忽视的瓶颈

CPU 和内存人人盯，磁盘 IO 是重灾区——但它恰恰是服务器性能问题里最常见的根因之一。

看三个数：读写吞吐量（MB/s）、IOPS、IO 等待时间（iowait）。iowait 持续高于 20% 说明 CPU 大量时间在等磁盘，典型场景是数据库没做读写分离、日志和数据盘混部、或者虚拟机宿主机磁盘超售。

里的 await 列（每次 IO 平均耗时），机械盘超过 15ms、SSD 超过 3ms 就值得查。

iostat -x 1

磁盘空间：最容易防、却最常见的低级事故

磁盘写满导致服务挂掉，是最不该发生的事故，但每年都在发生。日志没轮转、数据库膨胀、临时文件没人清——空间是温水煮青蛙式涨上去的。

监控别只设一个阈值，要设两个：80% 预警（你有时间从容处理）、90% 告警（该清理了）。更进一步的做法是按增长趋势做预测：按当前增速，这个卷还有几天写满，提前一周就知道。

系统负载（load average）：比 CPU 利用率更诚实的信号

load average 反映的是正在运行加正在等待 CPU（和 IO）的任务数，分 1 分钟、5 分钟、15 分钟三个值。

它的价值在“等待”这两个字：4 核的机器，15 分钟负载持续是 8，意味着平均有 8 个任务在抢 4 个核或卡在 IO 上——CPU 利用率可能还没到 90%，但负载已经告诉你饱和了。这也是负载比 CPU 利用率更早暴露问题的原因。

经验值：负载持续超过核数的 1.5~2 倍就要查。 一眼就能看。

cat /proc/loadavg

交换分区（swap）：性能劣化的隐形推手

swap 被用到，说明物理内存已经不够，系统在拿磁盘当内存使——而磁盘比内存慢几个数量级。

swap 使用率持续上涨或超过 20% 是明确信号。最麻烦的是“抖动”（thrashing）状态：系统忙着在内盘和磁盘之间倒腾数据，看起来像 CPU 问题也像应用问题，实际是内存不够。没有 swap 监控，这类故障基本查不出来。

吞吐量：判断“资源不够”还是“流量变大”

吞吐量衡量服务器单位时间实际干了多少活——每秒请求数、每秒事务数、传输速率。

它的价值在定位分叉：性能变差时，吞吐量涨了说明是流量变大（该扩容或限流），吞吐量没涨说明是资源瓶颈（该查 CPU/内存/IO）。没有这个指标，排查就少了最关键的分流依据。

应用错误率：服务器正常 ≠ 服务正常

HTTP 5xx、应用异常、失败事务——这些是用户真实感受到的故障。

基础设施指标全绿但错误率飙升的场景太常见了：应用内存泄漏还没到系统阈值、依赖的外部接口挂了、连接池耗尽。服务器在线和业务正常是两回事，只盯基础设施指标的监控体系，会在这一类故障面前失明。

进程和服务健康：应用挂了，服务器还“好好的”

核心服务（Web、数据库、后台任务进程）意外退出、反复重启、资源占用异常——这些发生在服务器指标恶化之前。

值得做的两个动作：关键进程的存活监控（挂了立刻告，而不是等用户报障）；进程资源基线（某进程平时吃 2G 内存，突然吃到 8G，还没崩但已经在路上了）。更进一步可以配自动恢复：进程挂了自动拉起，值班收到的是“已自动处理”通知而不是半夜的求助电话。

硬件健康：数据中心服务器的专属考点

这一条云上用户基本不用管，但自建机房和托管环境必须盯：CPU 和主板温度、风扇转速、电源状态、硬盘的 SMART 预警。

风扇坏一个、CPU 过热降频——性能先掉，过很久才彻底宕机。这种“慢性故障”没有硬件监控的话，表现是莫名其妙的性能抖动，查软件层查一周都查不出来。采集走 SNMP 或 IPMI，主流服务器（浪潮、联想、华为、戴尔）都支持。

指标之外：三条比阈值更重要的实践

看趋势，不看孤立值。
CPU 75% 这个数字什么都不是——相对昨天基线是 40%，就是大事；相对基线 70%，就是噪声。

指标要关联着看。
内存涨 + swap 涨 + IO wait 涨，三个一起看基本能锁定内存不足；单看任何一个都可能误判。这也是选监控工具时最该考察的能力——告警关联和压缩，把同一故障源的几十条告警压成一条带根因的。ManageEngine（卓豪）的 OpManager 在这类场景里把上面 10 个指标放进统一视图做事件关联，用下来的实际价值就一句话：故障发生时第一屏看到的是“哪里坏了、影响谁”，而不是 300 条告警刷屏。

告警要可行动。
如果超过 20% 的告警收到后不需要做任何事，说明阈值该重新标定。告警疲劳比没有监控更危险——真故障来的时候，没人再看告警了。

常见问题

监控工具怎么选？

三个硬标准：支持 Agent 和无 Agent（SNMP/IPMI）两种采集方式、有告警关联能力（不是纯阈值告警）、支持趋势预测（磁盘空间这类慢性问题靠预测不靠阈值）。开源方案 Zabbix/Prometheus 能力够，代价是配置和维护的人力；商业方案省人力，按需选。

这么多指标，多久巡检一次？

关键指标（CPU、内存、进程存活）1 分钟级采集；磁盘空间、硬件传感器 5~10 分钟足够。别追求全指标秒级——采集本身也是开销。

虚拟化和物理机监控有区别吗？

虚拟机要多盯一层宿主机：单台虚拟机 CPU 正常，宿主机超售照样卡。有条件的把宿主机的负载和 IO 也纳入同一平台，跨层关联。