服务器挂了业务停了老板电话打过来了——这是每个运维工程师最怕的噩梦。很多时候这种“惊喜”并非毫无征兆而是日常巡检中那些被忽略的“小问题”积累而成的。你可能每天都会登录服务器敲几个命令但你真的知道应该看什么、怎么看、以及看到异常后意味着什么吗网上充斥着各种“Linux巡检脚本大全”动辄几十个命令输出几十页日志。新手运维往往被淹没在信息海洋里分不清主次抓不住重点。而经验丰富的老师傅则有一套自己的“定式”他们不会面面俱到而是像老中医“望闻问切”一样直奔几个最关键的生命体征指标。这篇文章我们不搞命令大杂烩。我将为你拆解一位十年运维老兵的实战经验聚焦于服务器日常巡检中必须优先关注、且能最快发现潜在风险的5个核心项。这5项就像汽车的“仪表盘”看一眼就能知道服务器是健康、亚健康还是即将“趴窝”。掌握它们你就能用最少的时间获得最大的巡检收益把问题扼杀在摇篮里。1. 为什么你的巡检总是低效从“信息收集”到“风险预判”的转变很多运维同学的日常巡检更像是一种机械的“打卡”行为登录服务器执行一串脚本把top、df、free的输出保存下来然后扫一眼只要没有明显的“爆红”告警就认为一切正常。这种巡检方式存在三个典型问题信息过载重点模糊几十项指标同时摆在面前新手很难快速识别出哪一项的细微变化是危险的先兆。缺乏基线无法判断你知道CPU使用率30%算高吗内存用了80%需要紧张吗没有历史基线数据做对比单次数值的意义有限。被动响应而非主动预防往往等到监控系统告警如磁盘使用率95%才去处理此时可能已影响业务处理窗口非常紧张。高效的巡检核心在于“风险预判”。我们不是要记录服务器的所有状态而是要主动寻找那些“现在看起来还行但趋势不对”或者“暂时没告警但已触及安全线”的隐患。下面这5项就是经过大量线上故障复盘后筛选出的最高效“风险探测器”。2. 核心五项巡检老师傅的“定盘星”这五项检查建议按顺序进行它们分别对应着计算、内存、存储、连接和稳定性的最核心维度。2.1 第一项CPU负载Load Average—— 看“排队”长度而非“忙碌”程度新手误区只盯着top命令里%CPU的数值看到CPU使用率不高就以为万事大吉。老师傅怎么看首要关注Load Average平均负载。它表示系统在特定时间间隔内处于可运行状态和不可中断状态的平均进程数。通俗讲就是CPU的“排队长度”。查看命令# 最直接的方式 uptime输出示例16:30:01 up 30 days, 2:15, 1 user, load average: 0.05, 0.10, 0.15这里load average: 0.05, 0.10, 0.15分别表示过去1分钟、5分钟、15分钟的平均负载。关键解读负载数值的含义对于单核CPU负载1.00表示刚好满负荷。对于4核CPU负载4.00表示所有核心刚好满负荷。负载持续高于CPU核心数 * 0.7就需要警惕高于CPU核心数 * 1.5则表明进程已经开始排队等待系统响应会变慢。看趋势比较1分钟、5分钟、15分钟的三个值。0.05, 0.10, 0.15递增负载在缓慢上升需要关注。2.00, 1.50, 1.00递减负载在下降表明一个高压力事件正在缓解。4.50, 4.50, 4.50持平系统持续处于高负载状态必须立即排查。结合%CPU如果负载很高但top看到的%CPU并不高很可能瓶颈在I/O磁盘或网络进程在等待IO而处于“不可中断状态”。此时需要用iostat或iotop进一步检查。风险预判持续走高的5/15分钟负载是系统性能瓶颈的早期信号远比CPU使用率瞬间冲高100%更值得警惕。2.2 第二项内存与交换分区Memory Swap—— 警惕“无声的杀手”新手误区看到free -m显示内存快用完了就慌张或者完全忽略Swap的使用。老师傅怎么看关注可用内存available和Swap交换活动si/so。查看命令free -h输出示例total used free shared buff/cache available Mem: 7.6G 3.2G 200M 1.1G 4.2G 3.0G Swap: 2.0G 0B 2.0G关键解读重点看available这个值表示系统估算的、真正可被应用程序使用的内存量。它比free列更有意义因为Linux会利用空闲内存做缓存buff/cache这部分内存在需要时可被快速回收。只要available还有较多空间比如大于总内存的20%就不用担心。警惕Swap被使用使用vmstat 1命令观察siswap in和soswap out列。vmstat 1如果si或so持续大于0特别是数值较大时说明物理内存不足系统正在频繁使用硬盘Swap分区做内存交换。这会导致磁盘IO飙升系统性能急剧下降是必须立即处理的严重问题。风险预判available内存持续减少以及出现任何持续的Swap交换活动是内存瓶颈的明确信号需要在内存耗尽导致OOMOut-Of-Memory killer杀死关键进程前进行扩容或优化。2.3 第三项磁盘空间与InodeDisk Usage Inode—— 别等“100%”才行动新手误区只检查磁盘使用率df -h并且认为使用率到90%以上再处理也来得及。老师傅怎么看同时检查磁盘使用率和Inode使用率并为关键分区如/、/var、/home设置“软警戒线”如80%。查看命令# 查看磁盘空间使用情况人类可读格式 df -h # 查看Inode使用情况 df -i输出示例 (df -h)Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 40G 7.0G 85% / /dev/vdb1 200G 50G 140G 25% /data输出示例 (df -i)Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3.2M 1.1M 2.1M 35% / /dev/vdb1 12M 200K 11M 2% /data关键解读磁盘空间对于根分区/使用率超过80%就应该开始着手清理或扩容。因为很多临时文件、日志增长可能很快留足缓冲时间。对于/var日志、/home用户数据等根据业务特点设定阈值。Inode 耗尽即使磁盘空间还有剩余如果df -i显示IUse%达到100%系统也将无法创建新文件或目录导致服务异常。这常发生在存在大量小文件的场景如邮件服务器、缓存目录。找到大文件/目录发现某个分区使用率高时用以下命令快速定位# 查看当前目录下各子目录/文件的大小 du -sh ./* | sort -hr | head -10 # 或查找整个分区下大于100M的文件 find / -type f -size 100M 2/dev/null | head -20风险预判将处理磁盘空间的行动线提前到80%并定期检查Inode可以避免在业务高峰时因磁盘满而手忙脚乱。2.4 第四项网络连接与监听端口Network Ports—— 守好“城门”新手误区认为服务器能ping通就表示网络正常。老师傅怎么看检查异常连接数、监听端口变化以及网络错误包。查看命令# 1. 查看所有TCP连接状态统计 (快速发现异常) ss -ant | awk NR1 {print $1} | sort | uniq -c | sort -rn输出示例150 ESTAB 12 TIME-WAIT 3 LISTEN 1 CLOSE-WAIT重点关注CLOSE-WAIT和TIME-WAIT数量是否异常增多这可能意味着应用程序没有正确关闭连接。# 2. 查看服务器正在监听的端口 (确认关键服务端口在监听) netstat -tlnp | grep -E :(80|443|22|3306|6379|5432)\s # 查看常用服务端口 # 或使用更现代的 ss 命令 ss -tlnp关键解读端口监听确保必要的服务如SSH的22Web的80/443数据库的3306等处于LISTEN状态。同时检查是否有非预期的端口在监听这可能是安全风险。连接状态CLOSE-WAIT过多通常意味着你的应用程序没有主动调用close()关闭连接需要检查代码或配置。TIME-WAIT过多在高并发短连接服务中常见可通过调整内核参数net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle谨慎操作来缓解。网络错误使用netstat -s或ip -s link查看error、drop、overrun等计数器是否有持续增长这可能指示网卡、驱动或网络拥塞问题。风险预判异常的连接状态和突增的错误包往往是应用Bug、网络攻击或硬件故障的前兆。2.5 第五项系统日志与关键进程Logs Critical Processes—— 翻阅“病历本”新手误区不看日志或者只在出问题时才去翻看海量的日志文件。老师傅怎么看有重点、有规律地“扫读”关键日志的最后若干行并确认核心守护进程如sshdcrondnginxmysqld的存活状态。查看命令# 1. 查看系统最近的重要日志内核、系统级错误 sudo tail -50 /var/log/messages # CentOS/RHEL sudo tail -50 /var/log/syslog # Ubuntu/Debian # 2. 查看认证相关日志SSH登录成功/失败 sudo tail -100 /var/log/secure # CentOS/RHEL (SSH日志) sudo tail -100 /var/log/auth.log # Ubuntu/Debian (SSH日志) # 3. 查看内核环形缓冲区的最新信息dmesg dmesg | tail -20 # 4. 检查关键进程是否存活 pgrep -l sshd crond nginx mysqld # 查看这些进程的PID # 或使用 systemctl systemctl status sshd crond nginx mysql --no-pager -l关键解读/var/log/messages或syslog寻找error、warning、fail、panic等关键词关注硬件错误如磁盘I/O error、服务启动失败等信息。secure或auth.log关注异常的、频繁的SSH登录失败记录这可能是暴力破解攻击。dmesg查看最新的内核消息常用于发现硬件如硬盘、内存的突然故障。进程状态systemctl status命令不仅能看是否活跃active还能看最近是否有重启restart、退出exit code以及相关的日志片段。风险预判日志中的重复警告和错误是系统性问题的“慢性病历”。定期扫读能让你在用户投诉之前提前发现文件系统错误、内存故障、服务频繁重启等问题。3. 实战将五项检查整合为一个高效巡检脚本手动执行这些命令效率低下。我们可以将其整合成一个Shell脚本运行后生成一份清晰的报告。#!/bin/bash # filename: server_health_check.sh # 描述服务器核心健康状态快速巡检脚本 # 使用方法bash server_health_check.sh echo 服务器核心健康巡检报告 echo 生成时间$(date %Y-%m-%d %H:%M:%S) echo 主机名$(hostname) echo 运行时间$(uptime | awk -F, {print $1}) echo echo --------------------- 1. CPU负载检查 --------------------- echo 负载平均值(1,5,15分钟): $(uptime | awk -Fload average: {print $2}) CPU_CORES$(nproc) LOAD_1$(uptime | awk -Fload average: {print $2} | awk -F, {print $1} | xargs) LOAD_1_PER_CORE$(echo $LOAD_1 $CPU_CORES | awk {printf %.2f, $1/$2}) echo CPU核心数: $CPU_CORES echo 单核平均负载(1分钟): $LOAD_1_PER_CORE echo 提示持续负载0.7*核心数需关注。 echo echo --------------------- 2. 内存与Swap检查 --------------------- free -h | head -2 AVAILABLE_MEM$(free -m | awk NR2{print $7}) TOTAL_MEM$(free -m | awk NR2{print $2}) AVAILABLE_RATIO$(echo $AVAILABLE_MEM $TOTAL_MEM | awk {printf %.1f, ($1/$2)*100}) echo 可用内存占比: ${AVAILABLE_RATIO}% echo 提示可用内存占比20%需关注。 echo Swap使用情况: free -h | grep -i swap echo 提示若Swap used不为0请用 vmstat 1 观察 si/so 列。 echo echo --------------------- 3. 磁盘空间与Inode检查 --------------------- echo 磁盘空间使用率超过80%的分区 df -h | awk NR1 $5 80 {printf %-20s %-10s %-10s %-10s %-10s\n, $1, $2, $3, $4, $5} echo echo Inode使用率超过80%的分区 df -i | awk NR1 $5 80 {printf %-20s %-10s %-10s %-10s %-10s\n, $1, $2, $3, $4, $5} echo echo --------------------- 4. 网络连接状态统计 --------------------- ss -ant | awk NR1 {print $1} | sort | uniq -c | sort -rn | head -10 echo 提示关注 CLOSE-WAIT, TIME-WAIT 数量是否异常。 echo echo --------------------- 5. 关键服务进程检查 --------------------- SERVICES(sshd crond nginx mysqld docker) for svc in ${SERVICES[]}; do if pgrep -x $svc /dev/null; then echo [运行中] $svc else echo [未运行] $svc --- 注意 fi done echo echo --------------------- 6. 关键日志尾部检查 --------------------- LOG_FILES(/var/log/messages /var/log/syslog /var/log/secure /var/log/auth.log) for log in ${LOG_FILES[]}; do if [ -f $log ]; then echo 检查文件: $log (最后3行含Error/Warn/Fail): sudo tail -100 $log 2/dev/null | grep -i -E error|warn|fail|panic | tail -3 echo --- fi done echo 巡检结束 脚本使用与解读将脚本保存为server_health_check.sh。赋予执行权限chmod x server_health_check.sh。以root或有sudo权限的用户运行sudo ./server_health_check.sh。脚本会输出一份结构化的报告直接聚焦于可能存在的问题点如高负载、低可用内存、磁盘空间不足、异常连接、服务未运行、日志错误。4. 进阶如何实现自动化与无人化巡检手动执行脚本是第一步真正的效率来自于自动化。方案一Crontab 定时任务 邮件报警将脚本配置为定时任务如每天凌晨2点运行并将输出结果通过邮件发送给自己。# 编辑当前用户的crontab crontab -e # 添加一行例如每天凌晨2点运行并发送邮件 0 2 * * * /path/to/server_health_check.sh | mail -s Daily Health Check Report for $(hostname) your-emailexample.com需要系统配置好mail命令或使用sendmail、msmtp等工具。方案二集成到监控系统如 Prometheus Grafana对于成规模的服务器集群建议使用专业监控系统。Node Exporter部署在每台服务器上自动采集系统指标CPU、内存、磁盘、网络等。Prometheus定时拉取Node Exporter的数据并存储。Grafana从Prometheus读取数据配置丰富的仪表盘和告警规则。 在这种体系下日常巡检就变成了“看 Grafana 仪表盘”所有核心指标一目了然并且可以设置阈值自动告警。5. 常见问题与排查思路问题现象可能原因排查方式解决方案负载高但CPU使用率低I/O 瓶颈磁盘或网络1. 使用iostat -x 1查看%util和await。2. 使用iotop查看具体进程的I/O。优化慢查询、升级磁盘SSD、检查网络带宽。可用内存持续减少内存泄漏1. 使用top排序查看内存占用高的进程。2. 使用pmap -x PID分析进程内存详情。3. 分析应用日志和GC日志Java等。重启有问题的应用进程联系开发修复内存泄漏代码。磁盘空间增长过快日志未轮转、临时文件堆积、业务数据暴增1. 使用du和find命令定位大文件/目录。2. 检查日志配置如logrotate。配置日志轮转清理临时目录评估业务数据增长是否正常考虑扩容或归档。大量 CLOSE-WAIT 连接应用程序未正确关闭连接Socket泄漏1.netstat -antp | grep CLOSE-WAIT查看是哪个进程。2. 使用lsof -p PID查看进程打开的文件描述符。重启该应用可临时缓解根本解决需要修改应用代码确保连接关闭。关键服务进程消失进程崩溃、被误杀、配置错误1. 检查系统日志/var/log/messages或服务日志。2. 检查systemctl status service的输出。3. 检查资源限制如ulimit、OOM Killer日志dmesg | grep -i kill。根据日志错误修复配置或Bug配置进程守护如systemd的Restartalways。6. 最佳实践与工程建议建立个人基线在新服务器上线或应用稳定运行后运行几次巡检脚本记录下各项指标的“正常范围”作为你个人的判断基线。巡检不是监控的替代品日常巡检是主动的、概括性的检查而监控系统如Zabbix, Prometheus是被动的、持续性的、细粒度的。两者必须结合。巡检用于发现监控规则可能未覆盖的“灰色地带”问题。关注变化率而非绝对值磁盘一天用了1%很正常但一天用了10%就必须立刻查明原因。关注指标的变化趋势比看单点数值更重要。安全第一巡检脚本中涉及sudo的命令要确保执行权限可控。通过邮件发送报告时注意避免包含敏感信息如内网IP、具体错误堆栈。形成清单与 SOP将本文的“五项检查”固化为你的个人或团队的《日常巡检清单》。对于每项检查发现的问题进一步形成《标准处理流程》SOP例如发现磁盘空间告警后第一步做什么第二步做什么。理解业务上下文最有效的运维是懂业务的运维。知道哪个服务最重要它的关键指标是什么例如数据库的QPS和慢查询Web服务的响应时间。在巡检时对这些关键业务指标给予额外关注。高效的服务器巡检不是命令的堆砌而是思路的提炼。从今天起忘掉那些冗长的检查列表每天上班第一件事就用这五项“定式”快速给你的服务器把个脉一看负载排队长度二看内存Swap动静三查磁盘空间Inode四观网络连接状态五扫日志进程异常。坚持下来你不仅能更快地发现问题更能深刻地理解系统运行的规律从被动的“救火队员”成长为主动的“系统守护者”。这套方法就是运维工程师从新手走向资深的第一块重要基石。
Linux服务器高效巡检：聚焦5项核心指标，实现风险预判
服务器挂了业务停了老板电话打过来了——这是每个运维工程师最怕的噩梦。很多时候这种“惊喜”并非毫无征兆而是日常巡检中那些被忽略的“小问题”积累而成的。你可能每天都会登录服务器敲几个命令但你真的知道应该看什么、怎么看、以及看到异常后意味着什么吗网上充斥着各种“Linux巡检脚本大全”动辄几十个命令输出几十页日志。新手运维往往被淹没在信息海洋里分不清主次抓不住重点。而经验丰富的老师傅则有一套自己的“定式”他们不会面面俱到而是像老中医“望闻问切”一样直奔几个最关键的生命体征指标。这篇文章我们不搞命令大杂烩。我将为你拆解一位十年运维老兵的实战经验聚焦于服务器日常巡检中必须优先关注、且能最快发现潜在风险的5个核心项。这5项就像汽车的“仪表盘”看一眼就能知道服务器是健康、亚健康还是即将“趴窝”。掌握它们你就能用最少的时间获得最大的巡检收益把问题扼杀在摇篮里。1. 为什么你的巡检总是低效从“信息收集”到“风险预判”的转变很多运维同学的日常巡检更像是一种机械的“打卡”行为登录服务器执行一串脚本把top、df、free的输出保存下来然后扫一眼只要没有明显的“爆红”告警就认为一切正常。这种巡检方式存在三个典型问题信息过载重点模糊几十项指标同时摆在面前新手很难快速识别出哪一项的细微变化是危险的先兆。缺乏基线无法判断你知道CPU使用率30%算高吗内存用了80%需要紧张吗没有历史基线数据做对比单次数值的意义有限。被动响应而非主动预防往往等到监控系统告警如磁盘使用率95%才去处理此时可能已影响业务处理窗口非常紧张。高效的巡检核心在于“风险预判”。我们不是要记录服务器的所有状态而是要主动寻找那些“现在看起来还行但趋势不对”或者“暂时没告警但已触及安全线”的隐患。下面这5项就是经过大量线上故障复盘后筛选出的最高效“风险探测器”。2. 核心五项巡检老师傅的“定盘星”这五项检查建议按顺序进行它们分别对应着计算、内存、存储、连接和稳定性的最核心维度。2.1 第一项CPU负载Load Average—— 看“排队”长度而非“忙碌”程度新手误区只盯着top命令里%CPU的数值看到CPU使用率不高就以为万事大吉。老师傅怎么看首要关注Load Average平均负载。它表示系统在特定时间间隔内处于可运行状态和不可中断状态的平均进程数。通俗讲就是CPU的“排队长度”。查看命令# 最直接的方式 uptime输出示例16:30:01 up 30 days, 2:15, 1 user, load average: 0.05, 0.10, 0.15这里load average: 0.05, 0.10, 0.15分别表示过去1分钟、5分钟、15分钟的平均负载。关键解读负载数值的含义对于单核CPU负载1.00表示刚好满负荷。对于4核CPU负载4.00表示所有核心刚好满负荷。负载持续高于CPU核心数 * 0.7就需要警惕高于CPU核心数 * 1.5则表明进程已经开始排队等待系统响应会变慢。看趋势比较1分钟、5分钟、15分钟的三个值。0.05, 0.10, 0.15递增负载在缓慢上升需要关注。2.00, 1.50, 1.00递减负载在下降表明一个高压力事件正在缓解。4.50, 4.50, 4.50持平系统持续处于高负载状态必须立即排查。结合%CPU如果负载很高但top看到的%CPU并不高很可能瓶颈在I/O磁盘或网络进程在等待IO而处于“不可中断状态”。此时需要用iostat或iotop进一步检查。风险预判持续走高的5/15分钟负载是系统性能瓶颈的早期信号远比CPU使用率瞬间冲高100%更值得警惕。2.2 第二项内存与交换分区Memory Swap—— 警惕“无声的杀手”新手误区看到free -m显示内存快用完了就慌张或者完全忽略Swap的使用。老师傅怎么看关注可用内存available和Swap交换活动si/so。查看命令free -h输出示例total used free shared buff/cache available Mem: 7.6G 3.2G 200M 1.1G 4.2G 3.0G Swap: 2.0G 0B 2.0G关键解读重点看available这个值表示系统估算的、真正可被应用程序使用的内存量。它比free列更有意义因为Linux会利用空闲内存做缓存buff/cache这部分内存在需要时可被快速回收。只要available还有较多空间比如大于总内存的20%就不用担心。警惕Swap被使用使用vmstat 1命令观察siswap in和soswap out列。vmstat 1如果si或so持续大于0特别是数值较大时说明物理内存不足系统正在频繁使用硬盘Swap分区做内存交换。这会导致磁盘IO飙升系统性能急剧下降是必须立即处理的严重问题。风险预判available内存持续减少以及出现任何持续的Swap交换活动是内存瓶颈的明确信号需要在内存耗尽导致OOMOut-Of-Memory killer杀死关键进程前进行扩容或优化。2.3 第三项磁盘空间与InodeDisk Usage Inode—— 别等“100%”才行动新手误区只检查磁盘使用率df -h并且认为使用率到90%以上再处理也来得及。老师傅怎么看同时检查磁盘使用率和Inode使用率并为关键分区如/、/var、/home设置“软警戒线”如80%。查看命令# 查看磁盘空间使用情况人类可读格式 df -h # 查看Inode使用情况 df -i输出示例 (df -h)Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 40G 7.0G 85% / /dev/vdb1 200G 50G 140G 25% /data输出示例 (df -i)Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3.2M 1.1M 2.1M 35% / /dev/vdb1 12M 200K 11M 2% /data关键解读磁盘空间对于根分区/使用率超过80%就应该开始着手清理或扩容。因为很多临时文件、日志增长可能很快留足缓冲时间。对于/var日志、/home用户数据等根据业务特点设定阈值。Inode 耗尽即使磁盘空间还有剩余如果df -i显示IUse%达到100%系统也将无法创建新文件或目录导致服务异常。这常发生在存在大量小文件的场景如邮件服务器、缓存目录。找到大文件/目录发现某个分区使用率高时用以下命令快速定位# 查看当前目录下各子目录/文件的大小 du -sh ./* | sort -hr | head -10 # 或查找整个分区下大于100M的文件 find / -type f -size 100M 2/dev/null | head -20风险预判将处理磁盘空间的行动线提前到80%并定期检查Inode可以避免在业务高峰时因磁盘满而手忙脚乱。2.4 第四项网络连接与监听端口Network Ports—— 守好“城门”新手误区认为服务器能ping通就表示网络正常。老师傅怎么看检查异常连接数、监听端口变化以及网络错误包。查看命令# 1. 查看所有TCP连接状态统计 (快速发现异常) ss -ant | awk NR1 {print $1} | sort | uniq -c | sort -rn输出示例150 ESTAB 12 TIME-WAIT 3 LISTEN 1 CLOSE-WAIT重点关注CLOSE-WAIT和TIME-WAIT数量是否异常增多这可能意味着应用程序没有正确关闭连接。# 2. 查看服务器正在监听的端口 (确认关键服务端口在监听) netstat -tlnp | grep -E :(80|443|22|3306|6379|5432)\s # 查看常用服务端口 # 或使用更现代的 ss 命令 ss -tlnp关键解读端口监听确保必要的服务如SSH的22Web的80/443数据库的3306等处于LISTEN状态。同时检查是否有非预期的端口在监听这可能是安全风险。连接状态CLOSE-WAIT过多通常意味着你的应用程序没有主动调用close()关闭连接需要检查代码或配置。TIME-WAIT过多在高并发短连接服务中常见可通过调整内核参数net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle谨慎操作来缓解。网络错误使用netstat -s或ip -s link查看error、drop、overrun等计数器是否有持续增长这可能指示网卡、驱动或网络拥塞问题。风险预判异常的连接状态和突增的错误包往往是应用Bug、网络攻击或硬件故障的前兆。2.5 第五项系统日志与关键进程Logs Critical Processes—— 翻阅“病历本”新手误区不看日志或者只在出问题时才去翻看海量的日志文件。老师傅怎么看有重点、有规律地“扫读”关键日志的最后若干行并确认核心守护进程如sshdcrondnginxmysqld的存活状态。查看命令# 1. 查看系统最近的重要日志内核、系统级错误 sudo tail -50 /var/log/messages # CentOS/RHEL sudo tail -50 /var/log/syslog # Ubuntu/Debian # 2. 查看认证相关日志SSH登录成功/失败 sudo tail -100 /var/log/secure # CentOS/RHEL (SSH日志) sudo tail -100 /var/log/auth.log # Ubuntu/Debian (SSH日志) # 3. 查看内核环形缓冲区的最新信息dmesg dmesg | tail -20 # 4. 检查关键进程是否存活 pgrep -l sshd crond nginx mysqld # 查看这些进程的PID # 或使用 systemctl systemctl status sshd crond nginx mysql --no-pager -l关键解读/var/log/messages或syslog寻找error、warning、fail、panic等关键词关注硬件错误如磁盘I/O error、服务启动失败等信息。secure或auth.log关注异常的、频繁的SSH登录失败记录这可能是暴力破解攻击。dmesg查看最新的内核消息常用于发现硬件如硬盘、内存的突然故障。进程状态systemctl status命令不仅能看是否活跃active还能看最近是否有重启restart、退出exit code以及相关的日志片段。风险预判日志中的重复警告和错误是系统性问题的“慢性病历”。定期扫读能让你在用户投诉之前提前发现文件系统错误、内存故障、服务频繁重启等问题。3. 实战将五项检查整合为一个高效巡检脚本手动执行这些命令效率低下。我们可以将其整合成一个Shell脚本运行后生成一份清晰的报告。#!/bin/bash # filename: server_health_check.sh # 描述服务器核心健康状态快速巡检脚本 # 使用方法bash server_health_check.sh echo 服务器核心健康巡检报告 echo 生成时间$(date %Y-%m-%d %H:%M:%S) echo 主机名$(hostname) echo 运行时间$(uptime | awk -F, {print $1}) echo echo --------------------- 1. CPU负载检查 --------------------- echo 负载平均值(1,5,15分钟): $(uptime | awk -Fload average: {print $2}) CPU_CORES$(nproc) LOAD_1$(uptime | awk -Fload average: {print $2} | awk -F, {print $1} | xargs) LOAD_1_PER_CORE$(echo $LOAD_1 $CPU_CORES | awk {printf %.2f, $1/$2}) echo CPU核心数: $CPU_CORES echo 单核平均负载(1分钟): $LOAD_1_PER_CORE echo 提示持续负载0.7*核心数需关注。 echo echo --------------------- 2. 内存与Swap检查 --------------------- free -h | head -2 AVAILABLE_MEM$(free -m | awk NR2{print $7}) TOTAL_MEM$(free -m | awk NR2{print $2}) AVAILABLE_RATIO$(echo $AVAILABLE_MEM $TOTAL_MEM | awk {printf %.1f, ($1/$2)*100}) echo 可用内存占比: ${AVAILABLE_RATIO}% echo 提示可用内存占比20%需关注。 echo Swap使用情况: free -h | grep -i swap echo 提示若Swap used不为0请用 vmstat 1 观察 si/so 列。 echo echo --------------------- 3. 磁盘空间与Inode检查 --------------------- echo 磁盘空间使用率超过80%的分区 df -h | awk NR1 $5 80 {printf %-20s %-10s %-10s %-10s %-10s\n, $1, $2, $3, $4, $5} echo echo Inode使用率超过80%的分区 df -i | awk NR1 $5 80 {printf %-20s %-10s %-10s %-10s %-10s\n, $1, $2, $3, $4, $5} echo echo --------------------- 4. 网络连接状态统计 --------------------- ss -ant | awk NR1 {print $1} | sort | uniq -c | sort -rn | head -10 echo 提示关注 CLOSE-WAIT, TIME-WAIT 数量是否异常。 echo echo --------------------- 5. 关键服务进程检查 --------------------- SERVICES(sshd crond nginx mysqld docker) for svc in ${SERVICES[]}; do if pgrep -x $svc /dev/null; then echo [运行中] $svc else echo [未运行] $svc --- 注意 fi done echo echo --------------------- 6. 关键日志尾部检查 --------------------- LOG_FILES(/var/log/messages /var/log/syslog /var/log/secure /var/log/auth.log) for log in ${LOG_FILES[]}; do if [ -f $log ]; then echo 检查文件: $log (最后3行含Error/Warn/Fail): sudo tail -100 $log 2/dev/null | grep -i -E error|warn|fail|panic | tail -3 echo --- fi done echo 巡检结束 脚本使用与解读将脚本保存为server_health_check.sh。赋予执行权限chmod x server_health_check.sh。以root或有sudo权限的用户运行sudo ./server_health_check.sh。脚本会输出一份结构化的报告直接聚焦于可能存在的问题点如高负载、低可用内存、磁盘空间不足、异常连接、服务未运行、日志错误。4. 进阶如何实现自动化与无人化巡检手动执行脚本是第一步真正的效率来自于自动化。方案一Crontab 定时任务 邮件报警将脚本配置为定时任务如每天凌晨2点运行并将输出结果通过邮件发送给自己。# 编辑当前用户的crontab crontab -e # 添加一行例如每天凌晨2点运行并发送邮件 0 2 * * * /path/to/server_health_check.sh | mail -s Daily Health Check Report for $(hostname) your-emailexample.com需要系统配置好mail命令或使用sendmail、msmtp等工具。方案二集成到监控系统如 Prometheus Grafana对于成规模的服务器集群建议使用专业监控系统。Node Exporter部署在每台服务器上自动采集系统指标CPU、内存、磁盘、网络等。Prometheus定时拉取Node Exporter的数据并存储。Grafana从Prometheus读取数据配置丰富的仪表盘和告警规则。 在这种体系下日常巡检就变成了“看 Grafana 仪表盘”所有核心指标一目了然并且可以设置阈值自动告警。5. 常见问题与排查思路问题现象可能原因排查方式解决方案负载高但CPU使用率低I/O 瓶颈磁盘或网络1. 使用iostat -x 1查看%util和await。2. 使用iotop查看具体进程的I/O。优化慢查询、升级磁盘SSD、检查网络带宽。可用内存持续减少内存泄漏1. 使用top排序查看内存占用高的进程。2. 使用pmap -x PID分析进程内存详情。3. 分析应用日志和GC日志Java等。重启有问题的应用进程联系开发修复内存泄漏代码。磁盘空间增长过快日志未轮转、临时文件堆积、业务数据暴增1. 使用du和find命令定位大文件/目录。2. 检查日志配置如logrotate。配置日志轮转清理临时目录评估业务数据增长是否正常考虑扩容或归档。大量 CLOSE-WAIT 连接应用程序未正确关闭连接Socket泄漏1.netstat -antp | grep CLOSE-WAIT查看是哪个进程。2. 使用lsof -p PID查看进程打开的文件描述符。重启该应用可临时缓解根本解决需要修改应用代码确保连接关闭。关键服务进程消失进程崩溃、被误杀、配置错误1. 检查系统日志/var/log/messages或服务日志。2. 检查systemctl status service的输出。3. 检查资源限制如ulimit、OOM Killer日志dmesg | grep -i kill。根据日志错误修复配置或Bug配置进程守护如systemd的Restartalways。6. 最佳实践与工程建议建立个人基线在新服务器上线或应用稳定运行后运行几次巡检脚本记录下各项指标的“正常范围”作为你个人的判断基线。巡检不是监控的替代品日常巡检是主动的、概括性的检查而监控系统如Zabbix, Prometheus是被动的、持续性的、细粒度的。两者必须结合。巡检用于发现监控规则可能未覆盖的“灰色地带”问题。关注变化率而非绝对值磁盘一天用了1%很正常但一天用了10%就必须立刻查明原因。关注指标的变化趋势比看单点数值更重要。安全第一巡检脚本中涉及sudo的命令要确保执行权限可控。通过邮件发送报告时注意避免包含敏感信息如内网IP、具体错误堆栈。形成清单与 SOP将本文的“五项检查”固化为你的个人或团队的《日常巡检清单》。对于每项检查发现的问题进一步形成《标准处理流程》SOP例如发现磁盘空间告警后第一步做什么第二步做什么。理解业务上下文最有效的运维是懂业务的运维。知道哪个服务最重要它的关键指标是什么例如数据库的QPS和慢查询Web服务的响应时间。在巡检时对这些关键业务指标给予额外关注。高效的服务器巡检不是命令的堆砌而是思路的提炼。从今天起忘掉那些冗长的检查列表每天上班第一件事就用这五项“定式”快速给你的服务器把个脉一看负载排队长度二看内存Swap动静三查磁盘空间Inode四观网络连接状态五扫日志进程异常。坚持下来你不仅能更快地发现问题更能深刻地理解系统运行的规律从被动的“救火队员”成长为主动的“系统守护者”。这套方法就是运维工程师从新手走向资深的第一块重要基石。