巡检对象与范围:五维巡检体系

做运维这些年,我最大的体会就是——巡检不能拍脑袋。你得知道看什么、怎么看、看到什么程度才算到位。今天咱们就聊聊巡检的五个核心维度:服务器硬件、操作系统、中间件、数据库、网络设备。

这五个维度,说白了就是运维的「五官」。缺一个,你都看不全系统的真实状态。

一、服务器硬件巡检

硬件是地基。地基不稳,上面跑什么都白搭。我见过太多案例,应用层查了半天,最后发现是内存条松了。

核心巡检项:

  • CPU:温度、频率、核心状态。别只看负载,温度过高会降频
  • 内存:ECC纠错计数、可用容量。ECC报错多了就该换条子了
  • 磁盘:SMART状态、读写延迟、坏道。SSD要注意寿命百分比
  • 电源:冗余状态、电压稳定性。双电源要确认都在线
  • 风扇:转速、异常噪音。转速归零基本就是挂了
  • 网卡:链路状态、丢包率、错包计数

我的习惯:每次巡检先看硬件告警灯。红灯亮着,你查日志就是浪费时间。物理巡检时,我还会用手背感受一下机箱温度——烫手的话,散热肯定有问题。

硬件巡检常用命令(Linux环境):

# CPU温度
sensors | grep "Core"

# 内存ECC错误
edac-util --status

# 磁盘SMART信息
smartctl -a /dev/sda | grep -E "Reallocated|Pending|Offline"

# 网卡丢包
ethtool -S eth0 | grep -E "error|drop"

二、操作系统巡检

操作系统是中间层,承上启下。我建议重点关注资源使用率和系统日志。

为什么会这样?因为很多故障其实早有预兆,只是被忽略了。比如磁盘空间到80%时你不处理,到95%应用就开始报错了。

巡检维度 关键指标 告警阈值
CPU 用户态/系统态/等待IO 持续>80%
内存 可用内存、Swap使用率 可用<10%,Swap>0
磁盘 使用率、inode使用率 使用率>85%
系统日志 /var/log/messages 中的error/warn 出现OOM、文件系统错误
进程 僵尸进程、高CPU进程 僵尸进程>0

我曾经踩过的坑:有一次巡检发现磁盘使用率才60%,但应用就是写不进去。查了半天,原来是inode用完了。小文件太多,把inode吃光了。从那以后,我巡检必看inode。

三、中间件巡检

中间件这块,我习惯按「连接-线程-队列-缓存」的顺序查。这个顺序是有讲究的——连接出问题,后面查再多也没用。

以Nginx和Tomcat为例:

# Nginx活跃连接
curl http://localhost/nginx_status
Active connections: 291 
server accepts handled requests
 16630948 16630948 31070465 
Reading: 6 Writing: 179 Waiting: 106 

# Tomcat线程池
curl http://localhost:8080/manager/status?XML=true
# 关注 maxThreads, currentThreadCount, currentThreadsBusy

核心巡检项:

  • 连接数:当前连接 vs 最大连接,预留20%缓冲
  • 线程池:活跃线程、排队任务数。排队太多说明处理不过来
  • 队列深度:消息中间件的积压情况。积压持续增长就是报警信号
  • 缓存命中率:Redis/Memcached的get_hits。命中率低于80%要优化
  • JVM:堆内存使用、GC频率和耗时。Full GC频繁就要调参了

你想想看,中间件就像系统的「关节」。关节卡住了,整个系统都动不了。所以巡检时一定要看连接池有没有耗尽、线程有没有死锁。

四、数据库巡检

数据库是核心中的核心。我个人的原则是:慢查询必查,死锁必查,主从延迟必查。

先看一个MySQL巡检的常用脚本:

# 慢查询
SHOW GLOBAL STATUS LIKE 'Slow_queries';

# 当前连接
SHOW PROCESSLIST;
# 关注 State 为 'Locked' 或 'Sending data' 的线程

# 主从状态
SHOW SLAVE STATUS\G
# 重点看 Seconds_Behind_Master 和 Slave_IO_Running

# 表空间
SELECT TABLE_SCHEMA, TABLE_NAME, 
       ROUND((DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) AS SIZE_MB
FROM information_schema.TABLES
ORDER BY SIZE_MB DESC LIMIT 10;
巡检项 说明 危险信号
慢查询 执行时间超过long_query_time的SQL 慢查询数量持续增长
连接数 当前连接数/最大连接数 使用率>80%
主从延迟 Seconds_Behind_Master 延迟>30秒且持续增长
锁等待 InnoDB行锁等待次数 出现锁超时
磁盘IO iowait、磁盘读写延迟 iowait>30%

我的经验:数据库巡检最好在业务低峰期做。有一次我在高峰期跑了个全表扫描的查询,直接把库拖垮了。嗯,从那以后我学乖了——先看连接数,再决定要不要执行查询。

五、网络设备巡检

网络设备巡检,很多人容易忽略。但你想啊,服务器再健康,网络断了也是白搭。

我建议重点关注这几个方面:

  • 端口状态:up/down、协商速率、双工模式。百兆口跑千兆流量,肯定丢包
  • 错误计数:CRC错误、碰撞计数、FCS错误。这些说明物理层有问题
  • 带宽利用率:进出流量占比。持续>70%就要考虑扩容了
  • CPU/内存:交换机的CPU和内存使用率。过高说明设备快扛不住了
  • STP状态:生成树协议状态,防止环路
# 思科设备常用巡检命令
show interface status
show interface counters errors
show processes cpu
show spanning-tree

# 华为设备
display interface brief
display interface counters error
display cpu-usage
display stp brief

我曾经遇到过一次:某天业务突然变慢,查了一圈服务器都没问题。最后发现是交换机的一个光模块坏了,端口在自动协商时降到了百兆。从那以后,我巡检网络设备必看端口协商速率。

五维巡检体系总览

下面这张图,是我自己总结的巡检体系。五个维度互相依赖,缺一不可。

五维巡检体系 服务器硬件 操作系统 中间件 数据库 网络设备 巡检项 • CPU温度/频率 • 内存ECC纠错 • 磁盘SMART • 电源/风扇状态 巡检项 • CPU/内存使用率 • 磁盘/inode使用率 • 系统日志检查 • 僵尸进程 巡检项 • 连接数/线程池 • 队列深度 • 缓存命中率 • JVM堆/GC 巡检项 • 慢查询/连接数 • 主从延迟 • 锁等待/死锁 • 表空间/磁盘IO 巡检项 • 端口状态/速率 • CRC/错误计数 • 带宽利用率 • CPU/STP状态 巡检原则:由底向上,逐层排查 硬件 → 操作系统 → 中间件 → 数据库 → 网络设备

这张图展示的就是我日常巡检的完整思路。从硬件开始,一层层往上查。每个维度都有明确的巡检项,不会漏也不会重复。

总结一下:

巡检不是走过场,而是发现隐患的过程。我建议你把这五个维度做成一个checklist,每次巡检逐项打勾。坚持三个月,你就能摸清系统的「脾气」了。


公众号:蓝海资料掘金营,微信deep3321