拓冰网站定制 
凌晨三点你的手机突然响起。不是闹钟是监控告警。你睡眼惺忪地打开电脑面对满屏的红色警告CPU 100%、内存 99%、磁盘 IO 飙升、网络连接数爆表……问题出在哪里是应用 Bug还是恶意攻击是先重启服务还是先查日志如果你也经历过这种“运维惊魂夜”就会明白服务器巡检绝不是定时跑几个脚本那么简单。它更像老中医的“望闻问切”在系统看似健康时就能通过几个关键指标预判出潜在的“病灶”。网上充斥着各种“Linux巡检脚本大全”动辄几十个命令输出几十页报告。新手运维往往被淹没在数据海洋里分不清主次抓不住重点。真正有经验的老师傅在接手一台陌生服务器时往往不会先看那些花里胡哨的监控图而是固定先看五个最基础、也最致命的指标。这五项就像人体的体温、脉搏、血压一旦异常系统离“大病”就不远了。本文将彻底拆解这五项核心巡检指标。我们不追求大而全的命令列表而是聚焦于为什么看、怎么看、以及看到异常后怎么办。你将学到一套可立即上手的“五分钟快速诊断法”无论是应对突发告警还是日常健康检查都能做到心中有数手中有策。1. 服务器巡检从“消防员”到“保健医”的思维转变在深入具体命令之前我们必须先统一思想巡检的目的是什么很多运维把巡检等同于“写报告”每天定时运行脚本把结果往邮件里一发任务就完成了。这是一种典型的“消防员”思维——只有等火着起来了才去救。而高水平的运维追求的是“保健医”思维通过定期体检发现亚健康状态在问题爆发前就进行干预。服务器巡检的核心价值在于建立系统的“健康基线”并发现“趋势性异常”。单次的数据点意义不大比如CPU使用率80%这可怕吗如果这是一台计算节点在业务高峰期这可能是正常的。但如果这是一台数据库从库在凌晨低峰期持续80%那就极不正常。健康基线就是你系统在正常状态下的指标范围而趋势性异常则是指标持续偏离基线的信号。那么面对一台服务器从何入手信息太多反而无从下手。根据无数线上故障的复盘经验以下五个指标的优先级最高它们直接关联到系统的可用性、稳定性和性能。任何一项出现严重异常都可能导致服务不可用。负载Load Average系统“忙不忙”的总体感受。CPU使用率与上下文切换计算资源的真实消耗与调度效率。内存使用与Swap内存是够用还是已经在“拆东墙补西墙”磁盘I/O与空间存储是否成为性能瓶颈数据会不会“无家可归”网络连接与流量服务是否可达是否存在异常连接或流量风暴接下来我们逐一拆解。我会给出最精简、最有效的命令并解释每个输出字段背后的“潜台词”。2. 第一项负载Load Average—— 系统压力的“晴雨表”命令uptime或top命令的第一行$ uptime 08:30:01 up 30 days, 12:15, 2 users, load average: 0.05, 0.10, 0.15这可能是Linux世界里最被误解的指标之一。很多人简单地认为“负载超过CPU核数就有问题”。这个说法对但不全对。负载Load Average表示的是系统处于可运行状态和不可中断状态的平均进程数。可运行状态正在使用CPU或等待使用CPU的进程。不可中断状态正在等待I/O通常是磁盘I/O完成的进程。这类进程不会响应信号故称“不可中断”。输出中的三个数字0.05, 0.10, 0.15分别代表过去1分钟、5分钟、15分钟的平均负载。怎么解读看绝对值与CPU核数的关系这是基础。如果你的服务器是4核CPU那么负载持续在4.0以下比较轻松。负载持续在4.0左右CPU资源被充分利用。负载持续远高于4.0例如8.0意味着有进程在排队等待CPU资源系统过载。看趋势三个值的对比这比绝对值更重要0.05, 0.10, 0.15递增负载在上升可能有一个新任务启动并持续消耗资源。0.15, 0.10, 0.05递减负载在下降一个高消耗任务可能刚刚结束。三个值都持续很高系统持续过载需要立即处理。三个值都接近0系统非常空闲。关键洞察高负载不一定等于高CPU使用率。如果负载很高但top看到CPU使用率%Cpu(s)却不高比如只有30%那么瓶颈很可能在I/O磁盘或网络。因为大量进程卡在了等待I/O的不可中断状态。这时你就应该去检查磁盘I/O第四项。巡检动作例行巡检记录负载趋势与历史同期对比观察是否有缓慢增长的趋势。告警触发当15分钟负载持续超过CPU核数 * 0.7时就应引起警惕并开始分析原因。3. 第二项CPU使用率与上下文切换——计算资源的“效率审计”命令top进入后按1展开所有CPU核心或vmstat 1top命令的CPU行是关键%Cpu(s): 5.6 us, 1.2 sy, 0.0 ni, 93.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stus (user)用户空间进程占用CPU百分比。这是应用代码本身消耗的CPU。如果这项持续很高说明你的应用程序逻辑可能比较重或者存在性能问题。sy (system)内核空间进程占用CPU百分比。这是系统调用、内核管理消耗的CPU。这项过高可能意味着系统调用频繁如大量短生命周期进程创建、锁竞争激烈或中断处理过多。id (idle)CPU空闲百分比。我们希望它高但也不是越高越好适度利用是合理的。wa (iowait)CPU等待I/O完成的时间百分比。这是最重要的指标之一如果wa持续高于5%甚至达到10%-20%几乎可以肯定磁盘I/O是系统瓶颈。此时系统响应会非常慢但CPU看起来却很“闲”。st (steal)在虚拟化环境中被宿主机“偷走”的CPU时间。如果这项持续很高说明你的虚拟机所在的物理主机资源竞争激烈。另一个关键指标上下文切换Context Switch使用vmstat 1查看cs列。$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1024000 51232 1048576 0 0 12 45 123 456 5 1 94 0 0cs (context switch)每秒上下文切换次数。上下文切换是CPU从一个进程/线程切换到另一个的过程本身有开销。in (interrupt)每秒中断次数。怎么解读单核CPU上下文切换次数在几千次/秒以内通常是正常的。如果cs值异常高例如上万甚至十万同时sy系统CPU也很高说明系统可能因为过多的进程/线程争抢CPU或者锁竞争导致大量时间花在了调度上而非实际计算。这常见于不恰当的多线程/多进程应用设计。巡检动作首先看wa高则转向磁盘I/O分析。看us和sy的比例如果是计算密集型服务us高正常如果是Web代理、网关类sy略高也正常。但sy异常高如持续20%需要警惕。结合vmstat看cs如果负载和CPU使用率都不高但cs极高应用可能存在“伪并发”问题需要优化程序逻辑或调整内核参数如/proc/sys/kernel/threads-max。4. 第三项内存使用与Swap——内存管理的“生死线”命令free -h和top$ free -h total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 345M 3.3G 3.8G Swap: 2.0G 0B 2.0G这是另一个重灾区。很多人看到used很高、free很少就慌了。在Linux中这是完全正常的Linux内核会充分利用空闲内存来缓存磁盘数据buff/cache以提升性能。当应用程序需要更多内存时这部分缓存会被自动释放。因此free内存少不代表内存不足。真正应该关注的指标是available。available字段估算的是在不进行Swap的情况下可供新应用程序使用的内存量。它包含了当前free的内存和可回收的buffer/cache。Swap是最后一道防线也是性能的“悬崖”。Swap交换分区是磁盘上的一块空间当物理内存不足时内核会将不常用的内存页“换出”到Swap腾出物理内存。由于磁盘速度比内存慢几个数量级一旦发生频繁的Swap称为Swap颠簸系统性能会呈断崖式下跌。查看Swap活动情况si(swap in): 每秒从Swap读入到内存的数据量kB。so(swap out): 每秒从内存写入到Swap的数据量kB。 使用vmstat 1或sar -W 1可以查看。怎么解读健康状态available内存充足例如大于总内存的20%si和so持续为0。预警状态available内存持续减少si和so偶尔有数值说明内存开始紧张内核在尝试平衡。危险状态si和so持续有较高的数值例如每秒几百kB以上。这意味着系统正在发生频繁的Swap性能已经严重受损必须立即处理此时通常会伴随极高的waI/O等待和缓慢的系统响应。巡检动作日常巡检关注available内存的长期趋势如果它随时间缓慢下降可能存在“内存泄漏”。告警设置对si和so设置监控告警任何持续的非零值都应触发告警。问题排查使用top或ps aux --sort-%mem命令找出内存消耗最大的进程。5. 第四项磁盘I/O与空间——存储系统的“吞吐与容量”命令df -h,iostat -x 1,iotop磁盘问题分为两类容量不足和性能瓶颈。1. 容量巡检df -h$ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 45G 2.0G 96% / /dev/vdb1 200G 80G 110G 40% /data一目了然。关键点是Use%和Avail。告警阈值通常使用率超过80%就应关注超过90%必须处理。不要等到95%以上因为有些文件系统如ext4预留了部分空间给root用户普通用户无法使用且磁盘满可能导致数据库等应用直接崩溃。/根分区尤其需要关注因为很多临时文件、日志默认写在这里。2. I/O性能巡检iostat -x 1$ iostat -x 1 Linux 5.4.0-... (hostname) 06/01/2024 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 5.60 0.00 1.20 0.50 0.00 92.70 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util vda 0.00 5.00 0.00 20.00 0.00 0.00 0.00 0.00 0.00 1.20 0.00 0.00 4.00 0.20 0.10重点关注以下列%util设备利用率表示设备有I/O请求的时间百分比。如果持续接近100%说明磁盘I/O已饱和成为瓶颈。r/s,w/s每秒读/写请求数。rkB/s,wkB/s每秒读/写数据量KB。r_await,w_await读/写请求的平均等待时间毫秒。这个值直接影响到应用程序的响应延迟。如果持续很高例如10ms即使%util不高也说明磁盘响应慢。aqu-sz平均请求队列长度。如果大于1说明请求在排队。3. 进程级I/O查看iotop需要root权限安装运行。它可以实时查看每个进程的磁盘读写速度对于定位“哪个进程在疯狂写磁盘”非常有用。巡检动作容量每日检查关键分区使用率设置80%、90%、95%三级告警。性能结合CPU的wa指标。如果wa高立即用iostat查看%util和await。再用iotop定位具体进程。对于数据库服务器要特别关注数据文件和日志文件所在磁盘的I/O状况。6. 第五项网络连接与流量——服务通路的“流量与安全”命令ss -tunlp,netstat -s,sar -n DEV 1网络巡检关注两点连接状态和流量带宽。1. 连接状态巡检ss -tunlp(推荐比netstat更快)$ ss -tunlp | head -20 Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 128 *:22 *:* users:((sshd,pid1234,fd3)) tcp LISTEN 0 100 127.0.0.1:25 *:* users:((master,pid5678,fd13)) tcp ESTAB 0 0 10.0.0.1:22 10.0.0.100:54322 users:((sshd,pid8888,fd3))LISTEN监听端口。检查是否有不该开放的端口被打开。ESTAB已建立连接。数量是否正常是否有大量来自同一IP的连接可能是攻击或客户端BugTIME-WAIT,CLOSE-WAIT如果这两种状态连接数量异常多成千上万可能意味着应用程序没有正确关闭连接存在socket泄漏会快速消耗端口资源。查看TIME-WAIT数量ss -tan | grep TIME-WAIT | wc -l查看CLOSE-WAIT数量ss -tan | grep CLOSE-WAIT | wc -l2. 网络错误统计netstat -s这个命令输出大量网络栈的统计信息。在怀疑有网络问题时可以查看是否有错误计数在快速增长。关注segments retransmitted重传报文、errors、dropped等关键词。3. 网络流量巡检sar -n DEV 1$ sar -n DEV 1 Linux 5.4.0-... (hostname) 06/01/2024 _x86_64_ (4 CPU) 08:30:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 08:30:02 AM eth0 100.00 200.00 50.00 100.00 0.00 0.00 0.00 0.01 08:30:02 AM lo 10.00 10.00 1.00 1.00 0.00 0.00 0.00 0.00rxkB/s,txkB/s每秒接收/发送的千字节数。可以判断网络带宽是否打满。rxpck/s,txpck/s每秒收/发包数量。如果包数量很大但字节数很小可能是小包攻击或应用设计问题。%ifutil网络接口利用率需要内核支持。接近100%表示网卡带宽瓶颈。巡检动作日常检查监听端口是否符合预期TIME-WAIT连接数是否在正常范围通常几百几千以内取决于系统配置。告警时使用ss快速查看异常连接使用sar查看流量是否突增使用netstat -s查看是否有大量错误。7. 实战构建你的“五分钟巡检脚本”理解了五项核心指标后我们可以将这些命令整合成一个快速巡检脚本。这个脚本的目标是在60秒内获取一份涵盖核心健康度的快照报告。#!/bin/bash # filename: quick_check.sh # 使用方法bash quick_check.sh [输出文件路径可选] LOG_FILE${1:-/tmp/server_health_$(date %Y%m%d_%H%M%S).log} echo 服务器快速健康检查 $(date) | tee -a $LOG_FILE echo 主机名: $(hostname) | tee -a $LOG_FILE echo 运行时间: $(uptime) | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 1. 负载与进程概览 ------ | tee -a $LOG_FILE echo 负载: $(uptime | awk -Fload average: {print $2}) | tee -a $LOG_FILE echo CPU核心数: $(grep -c ^processor /proc/cpuinfo) | tee -a $LOG_FILE echo 当前高CPU进程: | tee -a $LOG_FILE ps aux --sort-%cpu | head -6 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 2. 内存与Swap使用 ------ | tee -a $LOG_FILE free -h | tee -a $LOG_FILE echo | tee -a $LOG_FILE # 检查Swap活动采样2次间隔1秒 echo Swap活动(si/so): | tee -a $LOG_FILE vmstat 1 2 | tail -n 1 | awk {print \si: \$7\, so: \$8} | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 3. 磁盘空间使用 ------ | tee -a $LOG_FILE df -h | grep -E ^(Filesystem|/dev/) | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 4. 磁盘I/O等待 ------ | tee -a $LOG_FILE echo 最近1分钟CPU I/O等待(%wa): | tee -a $LOG_FILE iostat -c 1 2 | tail -n 2 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 5. 网络连接摘要 ------ | tee -a $LOG_FILE echo 监听中的TCP端口: | tee -a $LOG_FILE ss -tln | head -10 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo TCP连接状态统计: | tee -a $LOG_FILE ss -tan | awk {print $1} | sort | uniq -c | sort -rn | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 6. 关键错误日志最后10行 ------ | tee -a $LOG_FILE # 检查系统日志中的错误这里以messages为例实际可能为syslog或journalctl LOG_PATH/var/log/messages if [ -f $LOG_PATH ]; then tail -10 $LOG_PATH | grep -i error\|fail\|critical | head -5 | tee -a $LOG_FILE else echo 日志文件 $LOG_PATH 不存在尝试 journalctl。 | tee -a $LOG_FILE journalctl -xe --since 5 minutes ago | grep -i error\|fail\|critical | head -5 | tee -a $LOG_FILE 2/dev/null || echo 无法获取日志。 | tee -a $LOG_FILE fi echo | tee -a $LOG_FILE echo 检查完成 | tee -a $LOG_FILE echo 详细报告已保存至: $LOG_FILE | tee -a $LOG_FILE脚本使用与解读将脚本保存到服务器例如/usr/local/bin/quick_check.sh。赋予执行权限chmod x /usr/local/bin/quick_check.sh。直接运行bash quick_check.sh。报告会同时打印在屏幕和保存到/tmp目录下的文件。你可以通过Crontab定时运行此脚本并将输出发送到邮箱或日志中心实现自动化日常巡检。这个脚本的输出就是你的“体检报告”。每天花五分钟阅读这份报告对比历史数据你就能对服务器的健康状况了如指掌。8. 常见问题与排查思路速查表当你巡检发现异常时可以按照下表快速定位问题方向问题现象可能原因下一步排查命令/思路负载高但CPU使用率低I/O瓶颈磁盘或网络1. 检查iostat -x 1看%util和await。2. 检查sar -n DEV 1看网络流量。3. 使用iotop定位高I/O进程。CPU使用率高 (us高)应用程序自身消耗大1.top或ps aux --sort-%cpu找进程。2. 对Java应用用jstack分析线程栈。3. 对Python/Node.js等用perf或py-spy做性能剖析。CPU使用率高 (sy高)系统调用频繁、上下文切换多1.vmstat 1看cs(上下文切换)。2.pidstat -w 1查看哪个进程导致上下文切换。3. 检查是否进程/线程数过多。wa(I/O等待) 高磁盘速度慢或请求过多1.iostat -x 1确认磁盘%util。2.iotop定位读写进程。3. 检查是否Swap活跃vmstat 1看si/so。内存available持续减少可能内存泄漏1.top看常驻内存 (RES) 增长的进程。2. 对Java应用观察jstat -gcutil pid看GC情况。3. 使用smem或slabtop分析内核内存使用。Swap (si/so) 持续活动物理内存不足1. 立即按上一条排查内存泄漏。2. 考虑增加物理内存或优化应用内存使用。3.紧急缓解找出最大内存进程并重启风险操作。磁盘空间使用率 90%日志、临时文件、业务数据增长1.du -sh /* | sort -rh | head -10找大目录。2.lsof | grep deleted找已删除但未释放的文件被进程持有。3. 清理日志使用logrotate、归档旧数据。TIME-WAIT连接数过多短连接频繁端口快速耗尽1. 优化应用使用连接池。2. 调整内核参数 (net.ipv4.tcp_tw_reuse,tcp_tw_recycle-谨慎使用)。3. 增加可用端口范围。网络rxkB/s打满可能被攻击或正常业务高峰1.iftop或nethogs查看具体连接流量。2. 分析访问日志判断是否为正常业务流量。3. 联系云服务商或部署DDoS防护。9. 从巡检到预警构建可持续的运维体系手动巡检是基础但无法应对7x24小时的服务。真正的运维高手会将这套“望闻问切”的方法体系化、自动化。1. 监控告警平台化将上述五项核心指标负载、CPU、内存、磁盘、网络纳入你的监控系统如Zabbix, Prometheus Grafana, Nagios等。设置合理的告警阈值负载15分钟负载 CPU核数 * 2CPUwa 10% 持续5分钟内存available 总内存10% 或 Swap使用率 0磁盘使用率 85% 预警 90% 严重网络带宽使用率 80% 持续5分钟2. 日志集中与分析使用ELKElasticsearch, Logstash, Kibana或Loki Grafana集中管理日志。在巡检脚本中检查的错误日志应该被实时采集和分析并设置关键字告警如“OutOfMemoryError”, “Connection refused”。3. 建立健康基线与趋势分析不要只看瞬时值。通过监控系统记录各项指标的历史数据建立每台服务器、每个服务的“健康基线”。例如数据库服务器在每天凌晨的备份时段磁盘I/O会很高这是正常的。趋势分析能帮你发现缓慢恶化的问题比如磁盘空间每天增长1%内存可用量每周减少2%。4. 巡检清单与应急预案将本文的“五项核心指标”和“排查速查表”整理成团队的运维手册。并为每类常见问题如磁盘满、内存泄漏、CPU飙高制定清晰的应急预案Emergency Runbook。预案里应包含第一步做什么定位第二步做什么缓解第三步做什么根因分析与修复。服务器日常巡检看似是重复性的“体力活”实则是运维工程师理解系统、掌控全局的基本功。它考验的不是你记住了多少命令而是你能否从纷繁的数据中一眼看出系统的“精气神”。从今天起放下那些冗长的万能脚本抓住负载、CPU、内存、磁盘、网络这五个生命体征坚持每天花五分钟“把把脉”。用不了多久你就能像老师傅一样在问题冒头之前就闻到它的味道。 Linux服务器核心巡检：负载、CPU、内存、磁盘、网络五项关键指标详解
凌晨三点你的手机突然响起。不是闹钟是监控告警。你睡眼惺忪地打开电脑面对满屏的红色警告CPU 100%、内存 99%、磁盘 IO 飙升、网络连接数爆表……问题出在哪里是应用 Bug还是恶意攻击是先重启服务还是先查日志如果你也经历过这种“运维惊魂夜”就会明白服务器巡检绝不是定时跑几个脚本那么简单。它更像老中医的“望闻问切”在系统看似健康时就能通过几个关键指标预判出潜在的“病灶”。网上充斥着各种“Linux巡检脚本大全”动辄几十个命令输出几十页报告。新手运维往往被淹没在数据海洋里分不清主次抓不住重点。真正有经验的老师傅在接手一台陌生服务器时往往不会先看那些花里胡哨的监控图而是固定先看五个最基础、也最致命的指标。这五项就像人体的体温、脉搏、血压一旦异常系统离“大病”就不远了。本文将彻底拆解这五项核心巡检指标。我们不追求大而全的命令列表而是聚焦于为什么看、怎么看、以及看到异常后怎么办。你将学到一套可立即上手的“五分钟快速诊断法”无论是应对突发告警还是日常健康检查都能做到心中有数手中有策。1. 服务器巡检从“消防员”到“保健医”的思维转变在深入具体命令之前我们必须先统一思想巡检的目的是什么很多运维把巡检等同于“写报告”每天定时运行脚本把结果往邮件里一发任务就完成了。这是一种典型的“消防员”思维——只有等火着起来了才去救。而高水平的运维追求的是“保健医”思维通过定期体检发现亚健康状态在问题爆发前就进行干预。服务器巡检的核心价值在于建立系统的“健康基线”并发现“趋势性异常”。单次的数据点意义不大比如CPU使用率80%这可怕吗如果这是一台计算节点在业务高峰期这可能是正常的。但如果这是一台数据库从库在凌晨低峰期持续80%那就极不正常。健康基线就是你系统在正常状态下的指标范围而趋势性异常则是指标持续偏离基线的信号。那么面对一台服务器从何入手信息太多反而无从下手。根据无数线上故障的复盘经验以下五个指标的优先级最高它们直接关联到系统的可用性、稳定性和性能。任何一项出现严重异常都可能导致服务不可用。负载Load Average系统“忙不忙”的总体感受。CPU使用率与上下文切换计算资源的真实消耗与调度效率。内存使用与Swap内存是够用还是已经在“拆东墙补西墙”磁盘I/O与空间存储是否成为性能瓶颈数据会不会“无家可归”网络连接与流量服务是否可达是否存在异常连接或流量风暴接下来我们逐一拆解。我会给出最精简、最有效的命令并解释每个输出字段背后的“潜台词”。2. 第一项负载Load Average—— 系统压力的“晴雨表”命令uptime或top命令的第一行$ uptime 08:30:01 up 30 days, 12:15, 2 users, load average: 0.05, 0.10, 0.15这可能是Linux世界里最被误解的指标之一。很多人简单地认为“负载超过CPU核数就有问题”。这个说法对但不全对。负载Load Average表示的是系统处于可运行状态和不可中断状态的平均进程数。可运行状态正在使用CPU或等待使用CPU的进程。不可中断状态正在等待I/O通常是磁盘I/O完成的进程。这类进程不会响应信号故称“不可中断”。输出中的三个数字0.05, 0.10, 0.15分别代表过去1分钟、5分钟、15分钟的平均负载。怎么解读看绝对值与CPU核数的关系这是基础。如果你的服务器是4核CPU那么负载持续在4.0以下比较轻松。负载持续在4.0左右CPU资源被充分利用。负载持续远高于4.0例如8.0意味着有进程在排队等待CPU资源系统过载。看趋势三个值的对比这比绝对值更重要0.05, 0.10, 0.15递增负载在上升可能有一个新任务启动并持续消耗资源。0.15, 0.10, 0.05递减负载在下降一个高消耗任务可能刚刚结束。三个值都持续很高系统持续过载需要立即处理。三个值都接近0系统非常空闲。关键洞察高负载不一定等于高CPU使用率。如果负载很高但top看到CPU使用率%Cpu(s)却不高比如只有30%那么瓶颈很可能在I/O磁盘或网络。因为大量进程卡在了等待I/O的不可中断状态。这时你就应该去检查磁盘I/O第四项。巡检动作例行巡检记录负载趋势与历史同期对比观察是否有缓慢增长的趋势。告警触发当15分钟负载持续超过CPU核数 * 0.7时就应引起警惕并开始分析原因。3. 第二项CPU使用率与上下文切换——计算资源的“效率审计”命令top进入后按1展开所有CPU核心或vmstat 1top命令的CPU行是关键%Cpu(s): 5.6 us, 1.2 sy, 0.0 ni, 93.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stus (user)用户空间进程占用CPU百分比。这是应用代码本身消耗的CPU。如果这项持续很高说明你的应用程序逻辑可能比较重或者存在性能问题。sy (system)内核空间进程占用CPU百分比。这是系统调用、内核管理消耗的CPU。这项过高可能意味着系统调用频繁如大量短生命周期进程创建、锁竞争激烈或中断处理过多。id (idle)CPU空闲百分比。我们希望它高但也不是越高越好适度利用是合理的。wa (iowait)CPU等待I/O完成的时间百分比。这是最重要的指标之一如果wa持续高于5%甚至达到10%-20%几乎可以肯定磁盘I/O是系统瓶颈。此时系统响应会非常慢但CPU看起来却很“闲”。st (steal)在虚拟化环境中被宿主机“偷走”的CPU时间。如果这项持续很高说明你的虚拟机所在的物理主机资源竞争激烈。另一个关键指标上下文切换Context Switch使用vmstat 1查看cs列。$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1024000 51232 1048576 0 0 12 45 123 456 5 1 94 0 0cs (context switch)每秒上下文切换次数。上下文切换是CPU从一个进程/线程切换到另一个的过程本身有开销。in (interrupt)每秒中断次数。怎么解读单核CPU上下文切换次数在几千次/秒以内通常是正常的。如果cs值异常高例如上万甚至十万同时sy系统CPU也很高说明系统可能因为过多的进程/线程争抢CPU或者锁竞争导致大量时间花在了调度上而非实际计算。这常见于不恰当的多线程/多进程应用设计。巡检动作首先看wa高则转向磁盘I/O分析。看us和sy的比例如果是计算密集型服务us高正常如果是Web代理、网关类sy略高也正常。但sy异常高如持续20%需要警惕。结合vmstat看cs如果负载和CPU使用率都不高但cs极高应用可能存在“伪并发”问题需要优化程序逻辑或调整内核参数如/proc/sys/kernel/threads-max。4. 第三项内存使用与Swap——内存管理的“生死线”命令free -h和top$ free -h total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 345M 3.3G 3.8G Swap: 2.0G 0B 2.0G这是另一个重灾区。很多人看到used很高、free很少就慌了。在Linux中这是完全正常的Linux内核会充分利用空闲内存来缓存磁盘数据buff/cache以提升性能。当应用程序需要更多内存时这部分缓存会被自动释放。因此free内存少不代表内存不足。真正应该关注的指标是available。available字段估算的是在不进行Swap的情况下可供新应用程序使用的内存量。它包含了当前free的内存和可回收的buffer/cache。Swap是最后一道防线也是性能的“悬崖”。Swap交换分区是磁盘上的一块空间当物理内存不足时内核会将不常用的内存页“换出”到Swap腾出物理内存。由于磁盘速度比内存慢几个数量级一旦发生频繁的Swap称为Swap颠簸系统性能会呈断崖式下跌。查看Swap活动情况si(swap in): 每秒从Swap读入到内存的数据量kB。so(swap out): 每秒从内存写入到Swap的数据量kB。 使用vmstat 1或sar -W 1可以查看。怎么解读健康状态available内存充足例如大于总内存的20%si和so持续为0。预警状态available内存持续减少si和so偶尔有数值说明内存开始紧张内核在尝试平衡。危险状态si和so持续有较高的数值例如每秒几百kB以上。这意味着系统正在发生频繁的Swap性能已经严重受损必须立即处理此时通常会伴随极高的waI/O等待和缓慢的系统响应。巡检动作日常巡检关注available内存的长期趋势如果它随时间缓慢下降可能存在“内存泄漏”。告警设置对si和so设置监控告警任何持续的非零值都应触发告警。问题排查使用top或ps aux --sort-%mem命令找出内存消耗最大的进程。5. 第四项磁盘I/O与空间——存储系统的“吞吐与容量”命令df -h,iostat -x 1,iotop磁盘问题分为两类容量不足和性能瓶颈。1. 容量巡检df -h$ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 45G 2.0G 96% / /dev/vdb1 200G 80G 110G 40% /data一目了然。关键点是Use%和Avail。告警阈值通常使用率超过80%就应关注超过90%必须处理。不要等到95%以上因为有些文件系统如ext4预留了部分空间给root用户普通用户无法使用且磁盘满可能导致数据库等应用直接崩溃。/根分区尤其需要关注因为很多临时文件、日志默认写在这里。2. I/O性能巡检iostat -x 1$ iostat -x 1 Linux 5.4.0-... (hostname) 06/01/2024 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 5.60 0.00 1.20 0.50 0.00 92.70 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util vda 0.00 5.00 0.00 20.00 0.00 0.00 0.00 0.00 0.00 1.20 0.00 0.00 4.00 0.20 0.10重点关注以下列%util设备利用率表示设备有I/O请求的时间百分比。如果持续接近100%说明磁盘I/O已饱和成为瓶颈。r/s,w/s每秒读/写请求数。rkB/s,wkB/s每秒读/写数据量KB。r_await,w_await读/写请求的平均等待时间毫秒。这个值直接影响到应用程序的响应延迟。如果持续很高例如10ms即使%util不高也说明磁盘响应慢。aqu-sz平均请求队列长度。如果大于1说明请求在排队。3. 进程级I/O查看iotop需要root权限安装运行。它可以实时查看每个进程的磁盘读写速度对于定位“哪个进程在疯狂写磁盘”非常有用。巡检动作容量每日检查关键分区使用率设置80%、90%、95%三级告警。性能结合CPU的wa指标。如果wa高立即用iostat查看%util和await。再用iotop定位具体进程。对于数据库服务器要特别关注数据文件和日志文件所在磁盘的I/O状况。6. 第五项网络连接与流量——服务通路的“流量与安全”命令ss -tunlp,netstat -s,sar -n DEV 1网络巡检关注两点连接状态和流量带宽。1. 连接状态巡检ss -tunlp(推荐比netstat更快)$ ss -tunlp | head -20 Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 128 *:22 *:* users:((sshd,pid1234,fd3)) tcp LISTEN 0 100 127.0.0.1:25 *:* users:((master,pid5678,fd13)) tcp ESTAB 0 0 10.0.0.1:22 10.0.0.100:54322 users:((sshd,pid8888,fd3))LISTEN监听端口。检查是否有不该开放的端口被打开。ESTAB已建立连接。数量是否正常是否有大量来自同一IP的连接可能是攻击或客户端BugTIME-WAIT,CLOSE-WAIT如果这两种状态连接数量异常多成千上万可能意味着应用程序没有正确关闭连接存在socket泄漏会快速消耗端口资源。查看TIME-WAIT数量ss -tan | grep TIME-WAIT | wc -l查看CLOSE-WAIT数量ss -tan | grep CLOSE-WAIT | wc -l2. 网络错误统计netstat -s这个命令输出大量网络栈的统计信息。在怀疑有网络问题时可以查看是否有错误计数在快速增长。关注segments retransmitted重传报文、errors、dropped等关键词。3. 网络流量巡检sar -n DEV 1$ sar -n DEV 1 Linux 5.4.0-... (hostname) 06/01/2024 _x86_64_ (4 CPU) 08:30:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 08:30:02 AM eth0 100.00 200.00 50.00 100.00 0.00 0.00 0.00 0.01 08:30:02 AM lo 10.00 10.00 1.00 1.00 0.00 0.00 0.00 0.00rxkB/s,txkB/s每秒接收/发送的千字节数。可以判断网络带宽是否打满。rxpck/s,txpck/s每秒收/发包数量。如果包数量很大但字节数很小可能是小包攻击或应用设计问题。%ifutil网络接口利用率需要内核支持。接近100%表示网卡带宽瓶颈。巡检动作日常检查监听端口是否符合预期TIME-WAIT连接数是否在正常范围通常几百几千以内取决于系统配置。告警时使用ss快速查看异常连接使用sar查看流量是否突增使用netstat -s查看是否有大量错误。7. 实战构建你的“五分钟巡检脚本”理解了五项核心指标后我们可以将这些命令整合成一个快速巡检脚本。这个脚本的目标是在60秒内获取一份涵盖核心健康度的快照报告。#!/bin/bash # filename: quick_check.sh # 使用方法bash quick_check.sh [输出文件路径可选] LOG_FILE${1:-/tmp/server_health_$(date %Y%m%d_%H%M%S).log} echo 服务器快速健康检查 $(date) | tee -a $LOG_FILE echo 主机名: $(hostname) | tee -a $LOG_FILE echo 运行时间: $(uptime) | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 1. 负载与进程概览 ------ | tee -a $LOG_FILE echo 负载: $(uptime | awk -Fload average: {print $2}) | tee -a $LOG_FILE echo CPU核心数: $(grep -c ^processor /proc/cpuinfo) | tee -a $LOG_FILE echo 当前高CPU进程: | tee -a $LOG_FILE ps aux --sort-%cpu | head -6 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 2. 内存与Swap使用 ------ | tee -a $LOG_FILE free -h | tee -a $LOG_FILE echo | tee -a $LOG_FILE # 检查Swap活动采样2次间隔1秒 echo Swap活动(si/so): | tee -a $LOG_FILE vmstat 1 2 | tail -n 1 | awk {print \si: \$7\, so: \$8} | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 3. 磁盘空间使用 ------ | tee -a $LOG_FILE df -h | grep -E ^(Filesystem|/dev/) | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 4. 磁盘I/O等待 ------ | tee -a $LOG_FILE echo 最近1分钟CPU I/O等待(%wa): | tee -a $LOG_FILE iostat -c 1 2 | tail -n 2 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 5. 网络连接摘要 ------ | tee -a $LOG_FILE echo 监听中的TCP端口: | tee -a $LOG_FILE ss -tln | head -10 | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo TCP连接状态统计: | tee -a $LOG_FILE ss -tan | awk {print $1} | sort | uniq -c | sort -rn | tee -a $LOG_FILE echo | tee -a $LOG_FILE echo ------ 6. 关键错误日志最后10行 ------ | tee -a $LOG_FILE # 检查系统日志中的错误这里以messages为例实际可能为syslog或journalctl LOG_PATH/var/log/messages if [ -f $LOG_PATH ]; then tail -10 $LOG_PATH | grep -i error\|fail\|critical | head -5 | tee -a $LOG_FILE else echo 日志文件 $LOG_PATH 不存在尝试 journalctl。 | tee -a $LOG_FILE journalctl -xe --since 5 minutes ago | grep -i error\|fail\|critical | head -5 | tee -a $LOG_FILE 2/dev/null || echo 无法获取日志。 | tee -a $LOG_FILE fi echo | tee -a $LOG_FILE echo 检查完成 | tee -a $LOG_FILE echo 详细报告已保存至: $LOG_FILE | tee -a $LOG_FILE脚本使用与解读将脚本保存到服务器例如/usr/local/bin/quick_check.sh。赋予执行权限chmod x /usr/local/bin/quick_check.sh。直接运行bash quick_check.sh。报告会同时打印在屏幕和保存到/tmp目录下的文件。你可以通过Crontab定时运行此脚本并将输出发送到邮箱或日志中心实现自动化日常巡检。这个脚本的输出就是你的“体检报告”。每天花五分钟阅读这份报告对比历史数据你就能对服务器的健康状况了如指掌。8. 常见问题与排查思路速查表当你巡检发现异常时可以按照下表快速定位问题方向问题现象可能原因下一步排查命令/思路负载高但CPU使用率低I/O瓶颈磁盘或网络1. 检查iostat -x 1看%util和await。2. 检查sar -n DEV 1看网络流量。3. 使用iotop定位高I/O进程。CPU使用率高 (us高)应用程序自身消耗大1.top或ps aux --sort-%cpu找进程。2. 对Java应用用jstack分析线程栈。3. 对Python/Node.js等用perf或py-spy做性能剖析。CPU使用率高 (sy高)系统调用频繁、上下文切换多1.vmstat 1看cs(上下文切换)。2.pidstat -w 1查看哪个进程导致上下文切换。3. 检查是否进程/线程数过多。wa(I/O等待) 高磁盘速度慢或请求过多1.iostat -x 1确认磁盘%util。2.iotop定位读写进程。3. 检查是否Swap活跃vmstat 1看si/so。内存available持续减少可能内存泄漏1.top看常驻内存 (RES) 增长的进程。2. 对Java应用观察jstat -gcutil pid看GC情况。3. 使用smem或slabtop分析内核内存使用。Swap (si/so) 持续活动物理内存不足1. 立即按上一条排查内存泄漏。2. 考虑增加物理内存或优化应用内存使用。3.紧急缓解找出最大内存进程并重启风险操作。磁盘空间使用率 90%日志、临时文件、业务数据增长1.du -sh /* | sort -rh | head -10找大目录。2.lsof | grep deleted找已删除但未释放的文件被进程持有。3. 清理日志使用logrotate、归档旧数据。TIME-WAIT连接数过多短连接频繁端口快速耗尽1. 优化应用使用连接池。2. 调整内核参数 (net.ipv4.tcp_tw_reuse,tcp_tw_recycle-谨慎使用)。3. 增加可用端口范围。网络rxkB/s打满可能被攻击或正常业务高峰1.iftop或nethogs查看具体连接流量。2. 分析访问日志判断是否为正常业务流量。3. 联系云服务商或部署DDoS防护。9. 从巡检到预警构建可持续的运维体系手动巡检是基础但无法应对7x24小时的服务。真正的运维高手会将这套“望闻问切”的方法体系化、自动化。1. 监控告警平台化将上述五项核心指标负载、CPU、内存、磁盘、网络纳入你的监控系统如Zabbix, Prometheus Grafana, Nagios等。设置合理的告警阈值负载15分钟负载 CPU核数 * 2CPUwa 10% 持续5分钟内存available 总内存10% 或 Swap使用率 0磁盘使用率 85% 预警 90% 严重网络带宽使用率 80% 持续5分钟2. 日志集中与分析使用ELKElasticsearch, Logstash, Kibana或Loki Grafana集中管理日志。在巡检脚本中检查的错误日志应该被实时采集和分析并设置关键字告警如“OutOfMemoryError”, “Connection refused”。3. 建立健康基线与趋势分析不要只看瞬时值。通过监控系统记录各项指标的历史数据建立每台服务器、每个服务的“健康基线”。例如数据库服务器在每天凌晨的备份时段磁盘I/O会很高这是正常的。趋势分析能帮你发现缓慢恶化的问题比如磁盘空间每天增长1%内存可用量每周减少2%。4. 巡检清单与应急预案将本文的“五项核心指标”和“排查速查表”整理成团队的运维手册。并为每类常见问题如磁盘满、内存泄漏、CPU飙高制定清晰的应急预案Emergency Runbook。预案里应包含第一步做什么定位第二步做什么缓解第三步做什么根因分析与修复。服务器日常巡检看似是重复性的“体力活”实则是运维工程师理解系统、掌控全局的基本功。它考验的不是你记住了多少命令而是你能否从纷繁的数据中一眼看出系统的“精气神”。从今天起放下那些冗长的万能脚本抓住负载、CPU、内存、磁盘、网络这五个生命体征坚持每天花五分钟“把把脉”。用不了多久你就能像老师傅一样在问题冒头之前就闻到它的味道。