CentOS服务器巡检最怕的不是发现报错，而是巡检本身流于形式。很多人每天登录服务器敲几条uptime、free -h、df -h就认为完成了日常保障，实际上这三条命令只能告诉你系统“还活着”，并不能告诉你系统是否“活得稳”。真正的日常巡检必须围绕资源瓶颈、服务状态、日志异常、安全风险和计划任务这五条线展开，并且要把检查动作变成可重复、可追溯的固定流程。

先看负载和CPU。uptime输出里的三个数字分别代表1分钟、5分钟、15分钟的平均负载，这个值要和CPU核心数对照。假设服务器是8核，负载持续超过8就说明有任务在排队，超过16就是明显过载。不要只看负载高就紧张，还要用top或htop看us、sy、wa三个指标。us高是用户态进程吃CPU，通常来自业务代码或数据库查询；sy高是内核态占用，常见于大量系统调用、网络中断或内核模块异常；wa高才是真正的危险信号，说明CPU在等磁盘IO，这时候加CPU没有用，要查磁盘和存储链路。一条实用的命令是top -bn1 | head -20，配合vmstat 1 5观察r列和b列，r大于CPU核数说明有进程在抢CPU，b不为零说明有进程阻塞在IO上。

内存检查不能只看free -h里的available。很多人看到available还有几个G就觉得内存没问题，但CentOS里内存压力往往体现在swap使用和脏页堆积上。如果swap开始被使用，哪怕只用了100MB，也要立刻查vmstat里的si和so两列。只要so持续大于0，说明系统在把内存页往外换，这时候业务响应会明显变慢。另外要关注/proc/meminfo里的Dirty和Writeback值，如果Dirty长期超过总内存的10%，说明有大量数据堆积在内存里没写到磁盘，一旦宕机可能丢数据。对于跑数据库或缓存的服务器，建议用ps aux按RSS排序，找出内存占用最高的前十个进程，记录趋势而不是只看单次快照。

磁盘巡检是日常最容易漏掉的一环。df -h只能看分区使用率，但真正致命的是inode耗尽和IO延迟。很多小文件场景下磁盘空间还剩30%，inode却已经用光，这时候所有写操作都会失败。用df -i检查inode使用率，特别是/var、/tmp和邮件队列目录。另外要用iostat -x 1 5看每个磁盘的await和util，await如果持续超过20ms说明磁盘已经出现性能瓶颈，util接近100%但await不高说明磁盘在满负荷但还健康，util不高await很高则要警惕存储链路或硬盘坏道。对于SSD还要关注wearout指标，用smartctl -a /dev/sda查看Media_Wearout_Indicator，低于10%就要准备更换。

服务状态检查要分两层。第一层是进程是否存活，用systemctl list-units --type=service --state=running可以快速列出所有运行中的服务，但服务在跑不代表服务正常。第二层是服务响应，比如nginx不仅要看进程在不在，还要实际请求一次本地端口，curl -I http://127.0.0.1/看返回码是不是200或301。对于MySQL或MariaDB，要执行mysqladmin ping和一条简单的SELECT 1，确认数据库能正常响应查询。Redis可以用redis-cli ping，返回PONG才算正常。把这些检查写成脚本，每次巡检直接跑一遍，比手动逐个敲命令可靠得多。

日志巡检的核心不是看有没有error，而是看error的增长速度和关联性。每天固定时间检查/var/log/messages、/var/log/secure、/var/log/nginx/error.log和应用程序日志，重点看过去24小时内新增的错误。用awk按时间段过滤，比如awk '$0 >= "2025-01-15 00:00:00"' /var/log/messages。发现一条磁盘IO error不可怕，可怕的是同一秒内出现几十条，那说明硬件或驱动出了问题。secure日志里如果出现大量Failed password，要立刻统计来源IP，用lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head看爆破来源，配合防火墙封禁。日志里还要留意OOM Killer的记录，grep -i "out of memory" /var/log/messages，一旦出现说明某个进程被内核杀掉过，要回头查内存趋势。

安全巡检在CentOS运维里必须日常化。首先是账户层面，检查/etc/passwd里是否有UID为0的非root账户，awk -F: '$3==0 {print $1}' /etc/passwd，正常应该只有root。检查是否有空密码账户，awk -F: '($2=="") {print $1}' /etc/shadow。然后看最近登录记录，last -20和lastb -20对比，如果有陌生IP成功登录过，要立即排查。防火墙规则也要每天确认，iptables -L -n或firewall-cmd --list-all看规则有没有被意外清空或修改。对于公网服务器，还要检查监听的端口，ss -tlnp看哪些服务暴露在0.0.0.0上，不必要的服务绑定到127.0.0.1或直接关闭。

计划任务和定时任务经常被当成“设置好就不用管”的东西，实际上crontab里的任务可能因为环境变量缺失、路径变化或依赖服务停止而悄悄失败。每天要检查/var/log/cron日志，确认关键任务是否按时执行。用grep CRON /var/log/cron | grep "日期"看当天执行记录。对于备份类任务，不能只看任务有没有跑，还要确认备份文件真的生成了，大小是否合理。一个常见的坑是备份脚本里用了相对路径，crontab的执行环境和工作目录和手动执行时不同，导致备份文件写到了意想不到的位置。建议所有crontab任务都写绝对路径，并且在脚本里加日志输出，方便追踪。

网络层面的巡检要覆盖连接数、丢包和DNS解析。用ss -s看当前TCP连接总数和状态分布，如果TIME_WAIT数量异常高，说明有大量短连接在快速建立和关闭，要检查应用是否没有复用连接。用netstat -i看网卡的错误计数，RX-ERR和TX-ERR如果持续增长，说明物理链路或网卡有问题。ping网关和外部DNS服务器，确认网络连通性和解析正常。对于多网卡服务器，还要检查路由表，ip route show，确认默认路由指向正确的出口，避免流量走了错误的链路。

把这些检查项整合成一个可执行的巡检脚本，是提升效率的关键。脚本不需要很复杂，但要覆盖核心指标，并且输出结果要能一眼看出异常。下面是一个精简版的巡检脚本框架：

#!/bin/bash
echo "=== 系统负载 ==="
uptime
echo "=== 内存使用 ==="
free -h
echo "=== 磁盘使用率 ==="
df -h | grep -v tmpfs
echo "=== Inode使用率 ==="
df -i | grep -v tmpfs
echo "=== 磁盘IO等待 ==="
iostat -x 1 3 | grep -E "Device|sd|vd|nvme"
echo "=== 服务状态 ==="
systemctl list-units --type=service --state=running | grep -E "nginx|mysql|redis|php|docker"
echo "=== 监听端口 ==="
ss -tlnp | awk '{print $4}' | grep -v "127.0.0.1" | sort -u
echo "=== 最近登录失败 ==="
lastb | head -20
echo "=== OOM记录 ==="
grep -i "out of memory" /var/log/messages | tail -5
echo "=== 防火墙状态 ==="
firewall-cmd --state 2>/dev/null || iptables -L -n | head -20

脚本跑完把输出保存下来，每天和前一天的结果做对比，异常变化比绝对值更有参考意义。比如内存使用率从60%涨到75%可能正常，但一天内涨了15%就要查原因。磁盘使用率每天增长1%和每天增长5%对应的处理优先级完全不同。建立趋势记录，才能从“被动救火”转向“主动预防”。

巡检频率要根据服务器的重要性和业务特点来定。核心数据库服务器建议每天巡检两次，上午和下午各一次，重点看慢查询、连接数、主从延迟和备份状态。Web服务器每天一次，重点看负载、错误日志和攻击尝试。测试环境可以放宽到每周两到三次，但安全相关的检查不能省。每次巡检都要记录结果，哪怕一切正常也要留档，这样出问题时可以回溯“从什么时候开始异常的”。

CentOS系统的稳定运行不是靠某一次大排查，而是靠每天雷打不动的固定动作积累出来的。巡检的意义在于把问题消灭在萌芽阶段，而不是等到用户投诉才去查服务器。把上面这些检查项真正落实到每天的工作里，比任何监控告警系统都更可靠，因为监控只能告诉你“出事了”，而巡检能告诉你“快出事了”。