做运维这行，跟服务器打交道是每天的必修课。我见过不少同事，机器一亮红灯就到处翻"常用命令大全"，临时抱佛脚。其实服务器运维监测没那么玄乎，翻来覆去就是那么几十条命令，关键是你得知道每条命令在什么场景下用、输出怎么看、哪些指标才是真正要命的。这篇内容我不打算给你列一个几百条的清单，那没有意义。我想从一个实际干活的角度，把日常巡检、故障排查时真正高频用到的监测命令拆开揉碎，讲清楚原理、参数和实战场景，顺便把我这些年踩过的坑一并交代了。
这套内容适合刚入行的运维工程师、兼职管服务器的后端开发，以及那些被老板要求"顺便看下服务器"的全栈同学。反正不管你是用云服务器还是自建机房，主流Linux发行版上这些命令基本通用，看完可以直接对着终端实操。
1. 先搞清楚监测什么：从目标反推命令
很多人学命令是零散的，今天看到一个top觉得有用，明天看到一个iostat又收藏起来，真到用的时候脑子里一团浆糊。我建议换个思路——先确定你要监测什么目标，再去找对应命令。只有这样才能建立自己的排查体系。
1.1 监测体系的四个核心维度
服务器监测说白了就四件事：资源用没用完、网络通不通、进程活没活着、业务还慢不慢。对应到系统层面就是CPU、内存、磁盘IO和网络；对应到命令层面，就是top/vmstat、free/sar、iostat/df、ping/ss/tcpdump这几组工具。
举个例子，用户反馈"网站打开很慢"，你先别急着重启服务。第一步看uptime判断系统负载高不高，第二步看top定位是CPU被打满还是内存不够触发swap，第三步用iostat看看磁盘是不是在疯狂读写，最后用ss确认连接数是否异常。这个排查链路就是由目标驱动命令选择的过程。如果没有体系，你大概率会东敲一下西敲一下，最后只能重启大法。
1.2 理解两条时间线：实时快照与持续趋势
监测命令还得分两类：一类是实时快照型，抓的是当前瞬间的状态，比如top、ps、free；另一类是持续趋势型，能按时间窗口记录历史数据，比如sar、vmstat带间隔参数跑一段时间、iotop持续刷新。
日常巡检两种都要用。快照型适合登录服务器那一刻快速判断有没有问题，趋势型适合在问题发生时拉长观察窗口，确认是偶发还是持续。我见过有同事拿top按一次空格就说"CPU不高啊"，结果问题在凌晨三点出现，这就是只看快照不看趋势的典型失误。生产环境建议把趋势型命令配合定时任务写进监控脚本，这样你睡觉的时候脚本还在替你盯着机器。
2. 系统负载与CPU监测：看懂top、vmstat和uptime
资源监测里面CPU最容易理解，但恰恰也是最容易误判的。很多新手看到top里的CPU百分比超过80%就慌了，实际上CPU高不等于有问题，关键要看是用户态的高还是等待IO的高，这完全是两回事。
2.1 uptime与load average：别被负载数值骗了
uptime会输出三组负载均值，分别代表过去1分钟、5分钟、15分钟的平均活跃进程数。注意这个值对多核CPU有特殊意义——负载5在单核机器上已经算饱和，但在四核机器上只用了大约四分之三的算力。所以我通常用"负载除以核数"来判断繁忙程度，比值超过0.7就要留意，超过1.0基本算满载。
我踩过的坑是：某次线上机器负载冲到30多，我第一反应是CPU不够，结果一看核数才知道是64核的物理机，31的负载连一半都没用上。所以看负载前先执行nproc确认核数，这个习惯能避免不少误判。另外三个时间点的数值差异也有讲究——1分钟远高于15分钟，说明是突发负载，可能是定时任务在跑或流量尖峰；三个值都高且稳定，说明服务器已经持续高负荷运转，需要扩容或优化业务逻辑。
2.2 top与htop：交互式资源监视的关键字段
top是进服务器后几乎必敲的第一条命令。但很多人只会看CPU和MEM两列，其实最关键的是上面那几行统计信息。%Cpu(s)里的us表示用户态占用，sy是内核态占用，wa是等待IO完成的时间——如果wa很高而us不高，说明CPU在等磁盘或网络，瓶颈根本不在CPU上。st代表被虚拟机管理程序偷走的时间，云服务器上st偏高说明隔壁邻居在抢资源。
进程列表里我一般按大写P键按CPU排序，看谁在吃计算资源；按M键按内存排序，看谁是内存大户。还要养成按H键切换线程视图的习惯，有些问题是某个进程里特定线程卡死导致的，只看进程级根本定位不到。htop是top的增强版，支持鼠标操作和树形进程展示，新机器我通常直接装htop，它对人类友好太多，但脚本里解析还是得靠top -bn1这种批处理模式。
2.3 用vmstat定位CPU等待与内存瓶颈
vmstat 1 5的意思是每秒采样一次，连续采5次。输出里的r列代表运行队列中的进程数，这个值长期大于核数说明CPU算力不够；b列是阻塞在IO上的进程数，经常大于0就要怀疑磁盘出问题了。us和sy分别对应user和system占用率，sy老高的话可能是频繁的系统调用，比如文件读写太多或网络中断过密。
vmstat最值钱的是si和so两列——swap in和swap out。只要这两个数字持续不为0，说明物理内存已经不够用，系统正在用磁盘充当内存。这个状态非常伤性能，因为磁盘读写速度和内存差着几个数量级。我曾经处理过一台内存4G的机器跑Java应用，so每秒几十兆，整个服务卡到几乎不可用，最后解决办法不是调JVM参数，而是直接加内存条。所以看到swap活动先别调优，先想物理内存是不是真的不够了。
3. 内存与磁盘监测：free、df、iostat配合使用
内存和磁盘是连在一起的冤家——内存不够会swap到磁盘，磁盘IO慢会拖慢所有进程。所以排查的时候这两块要一起看。
3.1 free命令：看懂buffer/cache和available
free -h输出里最容易误解的是buff/cache这一列。不少新手看到缓存占了好几个G就紧张，以为内存泄漏，其实这是Linux的正常行为——它把空闲内存用来缓存文件读取，一旦应用需要，内核会立刻回收这部分内存。真正该看的是available这一列，它表示可供新应用使用的内存估计值，比used更有参考意义。
判断内存够不够用，我的经验是看available占总内存的比例，长期低于20%就该告警了。另外free建议加-w参数看详细列，能区分buffer和cache——buffer是块设备缓冲，cache是文件页缓存，虽然日常排查不用分得那么细，但真遇到诡异问题，区分这俩有助于缩小排查范围。
3.2 实时查看内存排名与OOM风险
监控内存除了free看总量，还得知道谁在吃内存。ps aux --sort=-%mem能按内存占用降序排列进程，一眼找出内存大户。每次我在服务器上看这个命令的输出，排第一的一般是Java进程或Elasticsearch，这是常态不是异常。
真正要警惕的是OOM Killer。当系统内存耗尽，内核会挑一个进程杀掉来释放内存，这往往导致服务突然挂掉。查看dmesg -T | grep -i oom或journalctl -k -f能看到OOM记录。我遇到过数据库在凌晨被OOM干掉的情况，原因就是前一天业务导入数据时内存暴涨，而导入完成后内存没及时回收。所以内存监测的日常姿势是：跑一个定时任务记录free -h的输出，同时监控dmesg有没有OOM痕迹，双管齐下才稳。
3.3 磁盘容量与inode：df命令的两个维度
df -h看容量，df -i看inode，两条都要会。硬盘满了是个小问题，好排查；inode满了才是隐蔽杀手——文件系统能创建的条目数是有限的，哪怕磁盘还剩几十G，inode耗尽了一样写不进任何新文件。
我之前在给客户排查"服务器报磁盘满但df显示还有空间"的问题时，就是靠df -i发现inode使用率100%，一查全是邮件系统的死信文件和小缓存文件，几十万个小文件把inode占满了。清理起来也费劲，要find /var -type f -size +1k逐个找源头，这种经验你光看文档是学不来的。顺带说一句，du -sh和du -sh .[!.]*配合能找到隐藏文件的大小，清理磁盘时不能漏。
3.4 iostat与iotop：磁盘IO性能分析
iostat -x 1 3能按设备输出详细IO统计。%util是最多人看的指标，但我要提醒一句：%util在传统的机械盘上基本等于磁盘利用率，但在SSD和云盘上意义已经弱化，因为硬件支持并发IO，%util到100%也可能只是瞬时高并发。更可靠的指标是await——平均每次IO请求的处理时间，机械盘通常几十毫秒正常，SSD应该在个位数毫秒级别，一旦await飙高，说明磁盘响应变慢。
iotop则是看哪个进程在捣乱。执行iotop -o只看有IO操作的进程，你能直观看到某进程磁盘读速率几十MB/s在拖垮磁盘。上次排查数据库慢查询，我就是靠iotop发现有个备份进程在高峰期全量打包日志，和业务抢IO，后来把备份任务错峰执行就解决了。注意iotop需要root权限，没有的话用pidstat -d一样能看到每进程的读写速率。
4. 网络监测：连通性、端口与连接状态排查
网络问题是运维里最让人头大的类型。因为链路涉及的环节太多——本机网卡、交换机、路由器、防火墙、对方服务器，任何一环出问题都会表现为"连不上"，排查命令自然也要分层。
4.1 ping与mtr：连通性测试的正确姿势
ping是最基础的连通性测试，但很多人只会ping几下网关就完事。我建议用ping -c 10看丢包率，如果丢包大于1%就要警惕链路质量。另外mtr命令强烈推荐，它是traceroute的增强版，能持续显示从本机到目标的每一跳丢包率和延迟，快速定位是局域网内丢包还是公网出口问题。
遇到"云服务器可以Ping通但业务连不上"的情况，基本可以排除链路问题，重点转向端口监听和防火墙。Ping通只证明网络层的ICMP协议通，不代表TCP端口能连，这是两类完全不同的问题。我处理过无数次这种工单，用户信誓旦旦说"网络没问题"，结果最后发现是安全组或iptables没放行端口。
4.2 ss命令：端口监听与连接状态速查
ss -tlnp查TCP监听端口，-u换成UDP，-p显示进程信息。很多老教程还在推荐netstat，但netstat在处理大量连接时又慢又耗CPU，ss内核直接读套接字信息，效率高一个量级。连接状态里我最关注ESTABLISHED的数量是否异常上升——如果某服务established连接数持续暴涨，要么是流量真的来了，要么就是连接泄漏没释放。
ss -s能给出全系统连接统计摘要，TIME_WAIT状态的连接大量堆积时，通常需要检查代码里连接池是否正确复用。过高TIME_WAIT有个解决思路是开启tcp_tw_reuse和调整tcp_fin_timeout，但不建议无脑开，有的环境开了反而引发问题。端口数不够时用ss -lnt看listen队列溢出情况，如果Send-Q数值大于0说明有连接被丢弃，这时候要调net.core.somaxconn和应用程序自己的队列参数。
4.3 实时带宽与流量监控
外部的ifstat和iftop可以实时看网卡流量，iftop -n -P能看到每个连接的传输速率和端口，对定位"哪台机器在偷跑带宽"特别有用。有一次用户说服务器流量异常，出口带宽打满，我上机器跑iftop，一眼看到一个非业务端口正和某个IP大量通信——带宽跑满，直接顺藤摸瓜找到问题。
从网卡角度看，sar -n DEV 1 3能统计每块网卡的收发包量和错误包，rxdrop和txdrop有数值通常意味着缓冲区不足。云服务器遇到持续流量激增时，优先想到的是云厂商的安全控制台和流量监控面板，它们能提供VPC粒度的流量统计，比自己抓包全面得多。完整的抓包分析留给tcpdump，下一节单独展开。
4.4 tcpdump抓包：让网络问题不再玄学
tcpdump -i eth0 port 80 -c 100是抓固定端口流量的基础用法。-w保存成pcap文件，用Wireshark打开分析，-v输出详细协议信息。新手容易忽略权限——抓包一般需要root或者有CAP_NET_RAW能力，普通用户执行会报权限错误。
tcpdump最常用来验证"双方都说自己在发数据但对方没收到"。抓包能看到SYN包发出去了没、对端有没有回SYN-ACK、连接在哪一步断了。这个命令是排查网络问题的终极大招，比猜和试高效得多。但注意别在业务高峰期长时间抓包，抓包本身有一定性能开销，生产环境用-c限制包数量，抓几十个包够分析就够了。
5. 进程与服务监测：从看到状态到看懂状态
进程监测不只是ps aux看一眼这么简单。每个字段、每种状态都有明确含义，组合起来能告诉你系统到底在经历什么。
5.1 ps命令：状态字段深度解读
ps aux的输出里，STAT字段非常关键。S表示可中断睡眠（正常等待资源），R是运行中，D是不可中断睡眠——通常是等IO，大量D状态进程出现说明IO子系统出问题。Z是僵尸进程，出现一两只是程序正常的fork-收尸时序，扎堆出现就要检查父进程为什么不回收子进程。
排查内存泄漏或线程问题时，ps -T -p PID能列出指定进程的所有线程；pstree -p PID能以树状展示父子关系。我在定位一次PHP-FPM子进程异常增多的问题时，靠ps -eLf统计线程数，发现单个请求竟然fork出上百个子进程，最后定位到业务代码里无限递归创建进程的bug，这种问题不敢想象没有进程树分析工具怎么查。
5.2 systemctl与journalctl：现代服务守护排查体系
CentOS 7和Ubuntu 16以后统一走systemd体系，systemctl status 服务名一条命令能看运行状态、主进程PID、最近日志、监听端口等关键信息。systemctl list-units --failed能列出所有启动失败的单元，服务器重启后先跑它准没错。
journalctl -u 服务名 -f能实时跟踪某服务的日志输出，journalctl -u 服务名 --since "1 hour ago"查最近一小时日志。这套体系比老SysVinit的service命令信息量大多了。我还习惯用journalctl -p err -b查看本次开机以来所有错误级别日志，快速了解启动过程有没有异常。
5.3 用lsof和strace精确到"卡住的调用"
服务卡死是最难排查的问题之一。lsof -p PID列出某进程打开的所有文件，包括普通文件、socket、管道等——连接数异常时能看到进程到底还持有多少文件描述符。默认limit一般是1024，高并发应用很容易撞上，此时ulimit -n和/etc/security/limits.conf一会儿说。
往下钻取，strace -p PID能实时打印进程的系统调用序列。当服务无响应时，strace会显示它停在哪个系统调用上——通常是read等你或者卡在某个锁上。这个方法定位"代码到底卡在哪"非常锋利，我解决过一次"Java进程CPU 100%但堆没溢出"的疑难问题，jstack看一眼线程dump，发现有个线程在无限循环做正则匹配，strace确认了这个线程的调用链路，问题瞬间清晰。注意strace对性能有影响，生产环境不要长时间挂，抓几秒就够。
6. 把命令串成巡检脚本：从"人盯"到"脚本盯"
运维终极目标不是你会敲多少命令，而是能不能把常用操作固化下来，让机器自己替你做采集和告警。这个环节我分享一个我一直在用的巡检脚本思路。
6.1 巡检脚本的四大模块设计
我维护的巡检脚本分四个模块：系统资源（内存、CPU、负载、swap）、磁盘状态（使用率、inode、磁盘IO）、网络状态（丢包率、TCP状态统计、监听端口）、关键服务（进程存活性、端口响应）。脚本核心逻辑是用命令采集数据，然后做阈值比较和告警输出。
实际执行中，定时任务cron每5分钟跑一次，结果追加进日志文件。写脚本有几个细节经验：一是命令路径要写全，cron环境变量PATH往往不包含/usr/sbin等目录，直接写/usr/bin/free比free稳；二是采集结果加时间戳，方便事后回溯；三是判断条件写成函数，新指标直接加函数就行，不用改主流程。
6.2 一个简洁实用的监测告警样例
下面的脚本是基础模板，逻辑清晰容易扩展。我在生产环境跑过很长时间，直接拷贝就能用。
#!/bin/bash # 极简服务器监测告警脚本 THRESHOLD_MEM=80 THRESHOLD_DISK=90 THRESHOLD_LOAD=4 # 采集时间戳 TS=$(date "+%Y-%m-%d %H:%M:%S") # 检查内存使用率 MEM_USE=$(free | awk '/Mem:/{printf "%.0f", $3/$2*100}') if [ "$MEM_USE" -gt "$THRESHOLD_MEM" ]; then echo "$TS WARN MEMORY $MEM_USE%" >> /var/log/monitor.log fi # 检查磁盘使用率 DISK_USE=$(df / | awk 'NR==2{print $5}' | sed 's/%//') if [ "$DISK_USE" -gt "$THRESHOLD_DISK" ]; then echo "$TS WARN DISK $DISK_USE%" >> /var/log/monitor.log fi # 检查负载均值（一核阈值取1.0，多核按核数算） LOAD_NOW=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | tr -d ' ') if [ "$(echo "$LOAD_NOW > $THRESHOLD_LOAD" | bc)" -eq 1 ]; then echo "$TS WARN LOAD $LOAD_NOW" >> /var/log/monitor.log fi # 检查nginx进程是否存活 if ! pgrep nginx > /dev/null 2>&1; then echo "$TS ERROR nginx not running" >> /var/log/monitor.log # 这里可以接上重启动作或企业微信通知 fi脚本用数值比较加awk浮点运算，不用依赖太多外部工具，任何自带bash的主机都能跑。要接告警通知的话，在判断里面加curl调用即可——企业微信机器人、钉钉机器人、飞书机器人API都是一通curl的事。
6.3 指标留存与趋势分析：从监测到预测
光有告警还不够，日志文件里攒下的指标就是你的金矿。我习惯每天凌晨用sar命令汇总一天的历史数据，因为sysstat服务默认会采集系统活动记录。sar -u看CPU趋势，sar -r看内存，sar -d看磁盘，配合sa二进制数据文件仓库，能查询任意时间段的数据。
有了趋势数据，判断"磁盘会不会下周满"、"内存够不够撑到下次扩容"就不是拍脑袋了。我在一家公司接班时，上一任运维从没看过趋势，某天凌晨磁盘满导致数据库写不进去，业务停了半小时。我接手后做了个计划任务每周生成磁盘增长率报表，问题直接扼杀在摇篮里。这也就是为什么我强调趋势比快照值钱——快照只能告诉你现在坏了，趋势能告诉你什么时候要坏。
7. 实战复盘：一次深夜故障的完整排查过程
讲了这么多命令，最后用一个真实的排查案例把它们串起来。一次凌晨两点，线上一台MySQL服务器出现大量连接超时，我登录服务器的排查链路是这样的：
第一步查负载和资源——uptime显示负载从平时的1.5涨到了12，top看到CPU的wa占比超过60%，排第一的是一个kworker内核线程在刷盘。这个信号基本指向磁盘IO瓶颈。第二步用iostat -x 1确认磁盘await冲到200多毫秒，%util飙到99%，确认是磁盘问题。
第三步排查是谁在写盘。iotop -o看到两个进程在疯狂写：一个mysqld在跑批量更新，一个logrotate在做日志切割。晚高峰跑大批量更新本来就够呛，日志切割同时叠加更是雪上加霜。第四步看vmstat的b列持续大于10，大量进程阻塞在IO等待上，服务卡顿的逻辑链彻底闭合。
解决办法并不复杂——把logrotate任务从凌晨2点改到凌晨4点，错开业务高峰期，同时跟业务方确认批量更新改为限速分批执行。第二天观察iostat，await回到个位数，所有指标恢复正常。整个过程从发现问题到解决不到40分钟，靠的不是什么高端监控平台，就是这几条基础命令加一个清晰的排查思路。
8. 最后的经验沉淀：几个我必须提醒你的细节
命令人人会敲，差距在细节。我把这几年的实践心得浓缩成下面几条，每一条都有血泪代价在里面。
第一，看任何指标都要结合核数、版本和业务特点。负载要看核数，%util要看设备类型，内存要看available而不是used，这些都是我用真实事故换来的，不能盲信单个数字。
第二，命令输出要留痕。我见过太多人排查时只看命令输出，看完就关了，后面复盘时啥都拿不出来。建议排查复杂问题时用tee把输出同时写到文件里，top -bn1 | tee -a /tmp/capture.log这种写法养成分屏留痕的习惯，备查和交接都有底。
第三，工具只是辅助，思路才是核心。你把top、free、iostat、ss这四条命令学透，胜过生吞一百条孤立命令。排查问题的本质是定位瓶颈链路，工具再多，不会分析链路照样抓瞎。
第四，别忽视日志的力量。命令监测的是现状，日志记录的是因果。journalctl、/var/log/messages、应用自己的日志文件，配合命令一起看，你能得到的答案远比单看命令多得多。比如OOM Killer的记录就在dmesg里，你不看日志怎么知道是内核杀了进程呢？
最后再分享一个小技巧：把你自己最常用的十来个命令组合写成一个alias或脚本，比如alias topm='top -b -n 1 -o %MEM | head -20'，省得每次重复敲。我自己的~/.bashrc里这样的别名至少有20个，都是长年积累出来的肌肉记忆。运维这活不复杂，贵在熟练和有条理，希望这篇文章能让你少走点弯路。
