Linux运维--系统卡死排查思路

现象：Linux系统卡慢甚至卡死的现象
问题定位：
首先查看系统版本，虽然对于解决此问题没有太大作用，但是方便自己向公司同事或领导报告此事，总得是要有系统版本的
如果是自己公司的操作系统，那么查看系统版本可能有专门的命令，比如我们公司的Kylin操作系统查看系统版本使用：
cat /etc/.productinfo
一、接下来了解当前系统正在运行使用的应用大概都有哪些，如果系统桌面已经卡死，无法看到运行的应用，可以终端ssh连接上此电脑，（如果ssh都已经连接不上了，要么是sshd服务也调不起来了，要么是此电脑与其他电脑的网本来就不通。可以尝试ctrl+alt+F2切到字符终端，在字符终端查看进程等）
先使用top实时查看一下进程占cpu以及内存的情况，因为top是实时刷新的，比较直观
但与此同时，top也有弊端，当进程占资源变化比较快的时候，进程跳来跳去，不方便确认进程名称，所以这个时候用ps命令
使用ps -aux可以查看哪些进程占cpu或者内存较高，如果有的进程的值不是特别确定是否正常，可以在其他电脑同环境的情况下也查看一下做一下对比。如果有进程占cpu或内存的比例特别高，且居高不下，基本就可以确定是该进程卡死了，如果需要急切恢复，可以kill -9杀进程来恢复。
因为排查到这里只是排查出来是哪一个进程，但这个进程可能是某个服务的子进程，系统环境下如果装了好多的软件，那就需要确定这个进程属于哪个软件应用的。如果需要查看到底哪个应用出了问题，就需要根据之前查出来的异常进程进一步查，可以通过进程ID一点点查看父进程，直到追溯到其应用进程名。此过程中，如果发现应用名已基本显示出来了，继续往上追溯，很有可能查出来父进程是系统本身的进程，比如systemd进程，查到类似于这样的地方的时候其实已经追溯“过头了”。
根据进程ID往上追溯父进程的方式是：
1、确定了某一个异常进程之后，根据那个进程的ID，使用
ps -ef | grep 进程ID
然后会显示出来该进程对应的父进程（PPID）
2、中间往上追溯的过程是一样的，但是要注意判别是否到临界

至此是卡死时能够切换到终端输命令时的排查手段，但有的时候现实情况并非如此，有可能当时电脑卡死时，sshd服务调不起来导致没办法另找一台电脑ssh连过去查信息，也有可能与此同时，ctrl+alt+F2切字符终端的时候也切不过去了，这个时候有两种可能，一种是系统卡的死死的，一种是硬件出问题了，比如硬盘故障了，文件系统直接不工作了。在以上情况下，在保留现状的情况下基本没有什么好排查的了，能做的就是检查一下硬件状态，比如硬盘灯亮不亮，以及画面最后停留在什么情况下，方便判断死机前大概都做了哪些操作。

在这里需要提醒一下的是
1、在到现场排查问题之前，尽量不要让用户轻易恢复故障现场，现象还在的时候比较好排查问题，但是系统一重启可能就不太好查了，因为重启能解决99%的问题，但是重启后卡死现象可能就不出现了，那么想要判断之前死机的原因可能就不太好查，毕竟日志能记录的异常信息是有限的
2、卡死之前客户都做了哪些操作这是必须要问的，因为如果之后确实没有通过日志排查出来哪里出了问题，那也基本可以从用户那里获得一些信息，方便自己对某些可能出现此现象的原因做一个大致的判断

二、接下来说一下在完全卡死，不能切终端，也不能ssh进去的时候怎么办
此时，保留的故障现场已经基本没什么好查的了，因为命令什么的都用不了。接下来再把问题记录清楚然后重启恢复现状，开始排查日志，看能不能获得有用的信息
1、首先是messages日志，/var/log目录下。messages日志记录的信息是比较全的，所以一般先排查这个。
用vim编辑器打开后，可以先搜索Runtime journal，定位一下卡死之前系统什么时间开机的，messages日志信息里的各种信息都有，可以搜最左侧的时间，快速定位发生故障时的那段时间的日志。也可以通过关键字“failed” “error”“false”等搜索一下看有没有错误日志，如果有一些稀奇古怪的日志不要紧，有的可能是软件应用运行时的正常日志信息，如果确定不了那段日志里的信息到底算不算一种异常，那么可以找其他电脑做对比
2、其次是服务日志（这个是确定了哪个应用的问题时查这个），一般在/var/log底下也会有那些应用对应的日志信息，日志名可能跟软件名或软件对应的进程名差不多，当然也不排除有的软件做的日志信息不往messages里写，也不保存在/var/log下，有可能是在软件安装的路径或者其他相关路径下
3、dmesg日志，该日志是记录系统最近一次开机时加载的驱动信息，以及开机后键鼠等硬件的一些响应信息，查看该日志可以看一下有没有什么报错之类的
4、Xorg.0.log日志，该日志是记录的图形化服务相关的一些日志信息，看一下图形化服务方面有什么异常没
5、lightdm.log日志，该日志是和登录界面相关的一些日志信息，如果系统卡死的时候是在用户登录界面的时候卡死了，这个日志就有必要也看一眼
6、.xsession-errors日志，该日志在用户家目录下（root用户的是在/root下，普通用户是在/home/username/下），是隐藏文件，该日志信息是某用户环境下的图形化日志信息

如果日志里没什么异常信息，但是系统确实是完全卡死了，那有可能硬件出问题了，比如硬盘故障了，文件系统直接崩了，也有可能是其他硬件故障，这个时候就需要叫上硬件厂商一起来看这个问题了
现场的问题如果通过自己的排查手段暂时没有排查出来，需要请大佬进一步排查，那么需要记得保存现场的日志信息，记录出问题的时间点