故障处理机制各专业提炼的标准检查动作思维导图

U788978660

2025-05-28

浏览量: 21

主机本地登录数据库

主机查看

故障处理机制各专业提炼的标准检查动作内容详述

树图思维导图提供《故障处理机制各专业提炼的标准检查动作》在线思维导图免费制作，点击“编辑”按钮，可对《故障处理机制各专业提炼的标准检查动作》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：b6efb8c80337165b9d3d625ef8bf87f1

思维导图大纲

应用

1.查看服务是否正常

动作

ps -ef|grep 进程关键字

netstat -tunlp|grep 进程端口

标准

进程及端口正常监听

2.查看负载（内存、cpu等）资源使用情况

动作

top、free -h

标准

内存不超过90%

CPU不超过90%

磁盘使用率不到95%

1、5、15分钟负载不高于cpu核数的2倍

3.做快照

内存

动作

jmap -dump:live,format=b,file=/app/scripts/log/`hostname`.PID.HeapDump.`date +%Y%m%d%H%M` PID

./2_getCPUInfo.sh pid

标准

确认是否内存泄漏，分析heapdump文件泄露疑点内存占用情况并确认占用空间最大线程。

线程

动作

jstack -l PID > /app/scripts/log/`hostname`.ThreadDump.PID.`date "+%Y%m%d%H%M"`

./3_getHeapDump.sh pid

标准

确认线程阻塞情况，分析WAITING状态线程堆栈信息造成的堆栈阻塞。

4.查看日志报错

动作

less/cat/tail 日志文件

标准

日志无error、exception等报错输出则服务正常

工具

smartlog

5.检查接口响应情况

动作

登录apm 系统，查看故障系统的接口响应时间

标准

是否超时

工具

apm

主机

操作系统层面

查看资源使用率

CPU总使用率、进程使用率、单颗CPU使用率

动作

top查看CPU使用率，按照cpu使用率高低排序

标准

整体使用率不超过90%，单个进程CPU使用率不超过整体90%

内存总使用率、进程使用率

动作

top查看内存使用率，按照内存使用率高低排序

标准

整体使用率不超过90%

io延迟

动作

使用命令统计历史io及当前io，查看趋势

sar -u 1

top

mpstat -P ALL

标准

不应该高于15，或与平时差距较大

负载

动作

使用命令查看负载情况

uptime

top

sar -q

标准

1、5、15分钟负载不超过cpu核数2倍

云主机

宿主机资源抢占情况

动作

查看st值指标

sar -u 1

top

mpstat -P ALL

标准

不超过10且与平时指标差距不大

监控

查看各指标历史趋势

动作

登录各监控平台

标准

未达到告警指标及观察趋势图

查看系统日志

动作

登录主机查看/var/log/messages日志

标准

日志内无错误信息

底层方面

物理机

动作

查看硬件是否有告警

标准

无告警

存储

块存储与对象存储

动作

主要是查看当前存储集群有无异常盘，当前集群存储读写负载状态，集群服务进程是否异常

标准

有无异常盘或者异常存储节点

交换机

查看日志

动作

检查查看设备日志

display logbuffer reverse

标准

日志内容无报错

查看设备进出口流量

动作

display counters rate

标准

流量无异常波动

查看cpu/内存使用率/板卡状态

动作

display cpu/memory/device

标准

状态正常

防火墙会话及会话量

动作

display session table/statistics

标准

会话量无异常

查看接口状态

动作

display interface brief

标准

状态正常

堆叠状态

动作

display irf

标准

状态正常

端口收发光

动作

display transceiver diagnose interface

标准

状态正常

路由表

动作

display ip routing-table

标准

状态正常

数据库

mysql

1.登录服务器查看MySQL进程

动作

ps -ef | grep mysql

标准

有mysqld进程

2.查看系统资源使用情况

动作

uptime

sar 1 5

iostat -x

标准

1、显示的load值低于逻辑CPU数量/2为正常负载，load值接近逻辑CPU数量属于繁忙，达到瓶颈，load值高于逻辑CPU数量属于超载

2、%iowait小于10属于正常范围内，超过15%表示I/O存在瓶颈，性能明显下降。 %user超过50%表示业务繁忙，%system超过15%表示操作系统内核或硬件资源繁忙。

3、最后一列为I/O使用率百分比，低于30%表示I/O正常，超过50%表示I/O繁忙，90%以上I/O缓慢。

3.主机本地登录数据库

动作

mysql -uroot -p'密码'

标准

可以正常登录，无报错

4.在数据库内查看线程

动作

show processlist;

标准

返回查询结果，无报错

5.主机查看keepalived

动作

ps -ef | grep keepalived

ip a查看VIP是否在主节点

systemctl status keepalived

标准

1、主节点业务网卡下应该有2个ip，一个是该节点物理ip，一个是vip。

2、返回结果中Active状态为 active (running)。

6.查看mysql锁信息

当前运行的所有事务

动作

select * from information_schema.innodb_trx\G

标准

返回结果即为当前运行的事务。

当前出现的锁

动作

select * from information_schema.innodb_locks\G

标准

返回结果即为当前出现的锁。

锁等待的对应关系

动作

select r.trx_isolation_level, r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_trx_thread, TIMESTAMPDIFF(SECOND, r.trx_wait_started, CURRENT_TIMESTAMP) AS wait_time, r.trx_state waiting_trx_state, lr.lock_mode waiting_trx_lock_mode, lr.lock_type waiting_trx_lock_type, lr.lock_table waiting_trx_lock_table, lr.lock_index waiting_trx_lock_index, r.trx_query waiting_trx_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_trx_thread, b.trx_state blocking_trx_state, lb.lock_mode blocking_trx_lock_mode, lb.lock_type blocking_trx_lock_type, lb.lock_table blocking_trx_lock_table, lb.lock_index blocking_trx_lock_index, b.trx_query blocking_query from information_schema.innodb_lock_waits w inner join information_schema.innodb_trx b on b.trx_id=w.blocking_trx_id inner join information_schema.innodb_trx r on r.trx_id=w.requesting_trx_id inner join information_schema.innodb_locks lb on lb.lock_trx_id=w.blocking_trx_id inner join information_schema.innodb_locks lr on lr.lock_trx_id=w.requesting_trx_id\G

标准

trx_isolation_level: REPEATABLE READ # 隔离级别 waiting_trx_id: 473168430 #等待锁的事务的ID waiting_trx_thread: 16 #等待锁释放的线程ID wait_time: 16 #等待了多久，单位秒 waiting_trx_state: LOCK WAIT #等待锁释放的这个事务的状态，也就是上面473168430的状态 waiting_trx_lock_mode: X waiting_trx_lock_type: RECORD #锁类型，测试中这是行锁 waiting_trx_lock_table: `tmp`.`student` #等待锁释放，这个事务要操作的库和表 waiting_trx_lock_index: GEN_CLUST_INDEX waiting_trx_query: insert into Student values('08' , 'name' , '1990-01-20' , 'nv') #等待锁释放的这个事务要执行的SQL，也就是被阻塞的SQL blocking_trx_id: 473168425 #持有锁的事务ID blocking_trx_thread: 13 #持有锁的线程ID，必要时候，要kill这个线程 blocking_trx_state: RUNNING #持有锁的事务当前的状态 blocking_trx_lock_mode: X blocking_trx_lock_type: RECORD blocking_trx_lock_table: `tmp`.`student` #持有锁的事务正在操作的库和表 blocking_trx_lock_index: GEN_CLUST_INDEX blocking_query: NULL 1 row in set, 3 warnings (0.00 sec)

oracle

1.检查数据库进程

动作

ps -ef|grep -i local=no

sqlplus

select open_mode from v$database

标准

存在远程连接说明有应用程序正常连接到数据库

显示为read write，表示数据库处于可读写状态

2.检查数据库集群状态

动作

ASM、磁盘组、网络、VIP、SCAN、db

标准

3.检查系统资源使用情况

动作

uptime

sar 1 5

iostat -x

标准

1、显示的load值低于逻辑CPU数量/2为正常负载，load值接近逻辑CPU数量属于繁忙，达到瓶颈，load值高于逻辑CPU数量属于超载。

2、%iowait小于10属于正常范围内，超过15%表示I/O存在瓶颈，性能明显下降。 %user超过50%表示业务繁忙，%system超过15%表示操作系统内核或硬件资源繁忙。

3、最后一列为I/O使用率百分比，低于30%表示I/O正常，超过50%表示I/O繁忙，90%以上I/O缓慢。

4.检查等待事件

动作

select inst_id, username, osuser, sid, serial#, machine, client_info, event, program, sql_id,last_call_et runtime, blocking_instance bk_inst, blocking_session bk_sess from gv$session where status='ACTIVE' and last_call_et > 1 and username is not null;

标准

latch：相关内存结构、CPU争用 enq: 相关锁等待 log file sync 日志同步等待。 px、pq 相关并行SQL direct path read I/O相关 read by other sessions 等待数据从磁盘读入内存

5.查看alert日志

动作

$ORACLE_BASE/diag/rdbms/admin/`hostname`/$ORACLE_SID/trace

标准

关注ORA-开头的警告