蜘蛛云建站网站,做网站用cms好吗,大连成品网站建设,php房产中介网站源码一、先搞清楚现状
当收到系统宕机告警或者故障反馈时#xff0c;需要先对情况进行核实。比如检查系统启动时间#xff0c;是不是真实发生了重启#xff1f;如果重启了#xff0c;什么时间点发生的重启#xff1f;重启了几次#xff1f;重启之前有无变更操作#xff1f;…一、先搞清楚现状
当收到系统宕机告警或者故障反馈时需要先对情况进行核实。比如检查系统启动时间是不是真实发生了重启如果重启了什么时间点发生的重启重启了几次重启之前有无变更操作主机上运行的是哪一类应用重启的主机是物理机还是虚拟机等等情况有助于对于故障的分析处理。
可以如下检查
1、last查看机器最近重启时间以及重启次数 2、确认重启后查看主机是物理机还是虚拟机
dmidecode -t 1 3、检查看看是否有人为重启的动作如果配置了命令审计可以从message日志中看是否有人敲过reboot命令。或者用history命令也可以看到一些但有时不一定会有记录下来。
主机命令审计配置和查看可参考这篇文章《LINUX加固之命令审计》
LINUX加固之命令审计-CSDN博客
4、检查看看主机上都跑了些啥例如oracle、mysql、ha、vcs等高可用集群软件相关的 。 二、硬件故障排查
在第一步做了相关检查后确认是发生重启了并且还是物理机可以考虑是否硬件故障导致硬件类内存、cpu故障频率高。系统内可以通过ipmitool工具检查如下: --安装工具 yum install OpenIPMI ipmitool -y modprobe ipmi_watchdog modprobe ipmi_poweroff modprobe ipmi_devintf modprobe ipmi_si modprobe ipmi_msghandler --查看日志 ipmitool sel list 如果看到类似CPU或内存异常日志同时时间点和机器重启时间对应上那就是重启原因。
PS硬件类问题机房值守人员可以现场查看和报修厂家检查系统内ipmitool工具是个补充手段方便远程轻松查看。如果ipmitool查看未有明显报错也未必硬件一定都正常建议还需要进行报修原厂再进一步深度检查。
三、系统内dump日志检查
如果硬件类排查没什么问题或者是个虚拟机可以进行系统内的日志分析首先应该看看是否有产生dump日志。参考如下
cd /var/crash目录下看是否有生成crash日志目录产生如下图有个127.0.0.1开头的目录 进到目录里就会有vmcore的dump日志重启的原因就可以从dump日志找到蛛丝马迹。
crash日志分析可参考这篇《LINUX常用工具之kdump》
LINUX常用工具之kdump分析-CSDN博客
四、系统日志及性能检查
如果硬件日志和crash日志检查了都还没有收获接下来要对系统日志及相关性能进行复盘检查检查分析看看故障重启前主机负载有没有突增日志中有无异常类报错。可参照如下
1、性能检查
这部分大部分系统应该都会接入到监控网管中心可从监控中心去找下历史指标趋势重点关注CPU、内存、磁盘IO、网络等指标是否有突增情况。
如果不具备监控中心的或者故障前相关指标没采集到监控采集有个时间差瞬间的问题可能未必会捕捉到可以从系统sar日志取查找相关信息
cd /var/log/sa,每天的系统监控会写到当天日期的sa文件中例如11号的性能日志可以查看sa11或者sar11文件。(注sar文件可以直接读取sa文件需要用sar命令加上-f参数指定具体sa文件读取内容) 关于sa文件的查看可以man 下sar去看看参数例如 -A所有报告的总和 -u输出CPU使用情况的统计信息 -v输出inode、文件和其他内核表的统计信息 -d输出每一个块设备的活动信息 -r输出内存和交换空间的统计信息 -b显示I/O和传送速率的统计信息 -a文件读写情况 -c输出进程统计信息每秒创建的进程数 -R输出内存页面的统计信息 -y终端设备活动情况 -w输出系统交换活动信息 示例查看11号当天故障某个时间点cpu情况就可以用
sar -u -f sa11 2、日志检查
/var/log/message 系统启动后的信息和错误日志是Red Hat Linux中最常用的日志之一其他软件日志有时也会打印输出到里面。 /var/log/secure 与安全相关的日志信息 /var/log/maillog 与邮件相关的日志信息 /var/log/cron 与定时任务相关的日志信息 /var/log/spooler 与UUCP和news设备相关的日志信息 /var/log/boot.log 守护进程启动和停止相关的日志消息 /var/log/wtmp 该日志文件永久记录每个用户登录、注销及系统的启动、停机的事件
重点检查/var/log/message、dmesg日志、/var/log/secure等日志查看是否有error、fail、critical等关键报错信息。
五、ha等高可用集群相关软件日志检查
如果以上步骤都排查了一通还是没找到重启的原因那么从ha高可用的方向去查查看如果有部署相关的软件则去排查这些集群的日志因为高可用集群通常会有一些驱逐、脑裂、重启节点等异常机制也会触发机器发生重启。这块遇到了可以反馈让集群专业同事去协助排查或者你也可以试着自己动手去检查相关日志从不会到会就是从每一次动手开始后面也会去分享一些集群软件故障触发的主机重启案例。
六、其他排查方向及建议
1、如果是虚拟机故障也建议虚拟化平台层去看看底层服务是否有异常。
2、各类日志不光是检查里面有没有异常内容还需要关注是否日志在之前有正常输出比如kdump是否做了配置配置是否生效如果不生效crash日志不会生成。其他日志也是一样。
3、操作系统一次重启可能涉及多多方面不妨多去请教和咨询有时是需要各专业同事共同诊断才能把问题彻底搞清楚。 There are many things that can not be broken 如果觉得本文对你有帮助欢迎点赞、收藏、评论
