巡检对象与范围:五维巡检体系
做运维这些年,我最大的体会就是——巡检不能拍脑袋。你得知道看什么、怎么看、看到什么程度才算到位。今天咱们就聊聊巡检的五个核心维度:服务器硬件、操作系统、中间件、数据库、网络设备。
这五个维度,说白了就是运维的「五官」。缺一个,你都看不全系统的真实状态。
一、服务器硬件巡检
硬件是地基。地基不稳,上面跑什么都白搭。我见过太多案例,应用层查了半天,最后发现是内存条松了。
核心巡检项:
- 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
我曾经遇到过一次:某天业务突然变慢,查了一圈服务器都没问题。最后发现是交换机的一个光模块坏了,端口在自动协商时降到了百兆。从那以后,我巡检网络设备必看端口协商速率。
五维巡检体系总览
下面这张图,是我自己总结的巡检体系。五个维度互相依赖,缺一不可。
这张图展示的就是我日常巡检的完整思路。从硬件开始,一层层往上查。每个维度都有明确的巡检项,不会漏也不会重复。
总结一下:
巡检不是走过场,而是发现隐患的过程。我建议你把这五个维度做成一个checklist,每次巡检逐项打勾。坚持三个月,你就能摸清系统的「脾气」了。
公众号:蓝海资料掘金营,微信deep3321