linux服务器主机异常重启故障分析报告

 2021年3月12日18时左右，收到客户通知，业务主机dpm1，在下午02:38:19发生重启，目前业务已经恢复，定位故障原因

服务器宕机主要有3条分析思路。

是否内存或者CPU爆满，导致服务器OOM，导致服务器重启
是否硬件导致重启
是否触发系统BUG

本着这3条思路，我们接下来分头排查。

观察系统日志（/var/log/messages、/var/log/dmesg）
登录管理卡地址，查看是否有硬件告警，并收集硬件信息，报告厂商协助排查
检查是否是系统内核bug导致，所以得看kdump在系统崩溃保留的信息

 系统信息：
 服务器类型：Dell PowerEdge R815
 操作系统版本：RHEL 7.5
 内核版本：3.10.0-862.el7.x86_64

1：查看messages

Mar 12 14:25:39 localhost NetworkManager[1322]: <warn>  [1615530339.3652] device (em1): Activation: failed for connection 'em1'
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3661] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Mar 12 14:25:39 localhost avahi-daemon[1351]: Withdrawing address record for fe80::588d:95aa:af7a:9e93 on em1.
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3709] policy: auto-activating connection 'em1'
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3759] device (em1): Activation: starting connection 'em1' (4c75e26f-7a3b-4981-a6fe-f0e190616c60)
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3764] device (em1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3774] device (em1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Mar 12 14:25:39 localhost NetworkManager[1322]: <info>  [1615530339.3781] device (em1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Mar 12 14:25:39 localhost avahi-daemon[1351]: Registering new address record for fe80::588d:95aa:af7a:9e93 on em1.*.
Mar 12 14:26:01 localhost systemd: Started Session 362331 of user aspire.
Mar 12 14:26:01 localhost systemd: Starting Session 362331 of user aspire.
Mar 12 14:26:11 localhost NetworkManager[1322]: <info>  [1615530371.3530] device (em1): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Mar 12 14:26:11 localhost NetworkManager[1322]: <warn>  [1615530371.3541] device (em1): Activation: failed for connection 'em1'
Mar 12 14:26:11 localhost NetworkManager[1322]: <info>  [1615530371.3550] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Mar 12 14:26:11 localhost avahi-daemon[1351]: Withdrawing address record for fe80::588d:95aa:af7a:9e93 on em1.
Mar 12 14:27:01 localhost systemd: Started Session 362332 of user aspire.
Mar 12 14:27:01 localhost systemd: Starting Session 362332 of user aspire.
Mar 12 14:38:06 localhost journal: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 62.8G available → current limit 4.0G).
Mar 12 14:38:06 localhost kernel: Initializing cgroup subsys cpuset
Mar 12 14:38:06 localhost kernel: Initializing cgroup subsys cpu
Mar 12 14:38:06 localhost kernel: Initializing cgroup subsys cpuacct
Mar 12 14:38:06 localhost kernel: Linux version 3.10.0-1127.13.1.el7.x86_64 (mockbuild@x86-034.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Fri Jun 12 14:34:17 EDT 2020
Mar 12 14:38:06 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-1127.13.1.el7.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
Mar 12 14:38:06 localhost kernel: e820: BIOS-provided physical RAM map:
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cf678fff] usable
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000cf679000-0x00000000cf68efff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000cf68f000-0x00000000cf6cdfff] ACPI data
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000cf6ce000-0x00000000cfffffff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fec8ffff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000fec94000-0x00000000feccffff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x00000000fecd4000-0x00000000ffffffff] reserved
Mar 12 14:38:06 localhost kernel: BIOS-e820: [mem 0x0000000100000000-0x000000202effffff] usable
Mar 12 14:38:06 localhost kernel: NX (Execute Disable) protection: active
Mar 12 14:38:06 localhost kernel: SMBIOS 2.6 present.
Mar 12 14:38:06 localhost kernel: DMI: Dell Inc. PowerEdge R815/0FH3FC, BIOS 3.2.1 09/12/2013
Mar 12 14:38:06 localhost kernel: AGP: No AGP bridge found

上图是日志估值发生时候的日志，我们可以看出，这里只是故障发生后的服务器启动日志，故障发生时并没留下什么蛛丝马迹。所以这里并没有可用的信息，可以忽略。

2、硬件检测
厂商回复，硬件一切正常，没有故障

3:我们分析一下系统崩溃时候kdump给我们留下来的信息。
什么是kdump

kdump 可以说是服务器的黑匣子，是一种的基于 kexec 的内核崩溃转储机制。系统一但崩溃，内核无法正常记录信息了，这时kdump将转入带第二个捕获内核，将第二个内核加载的内存中，对第一个内核的信息进行捕获。由于 kdump 利用 kexec 启动捕获内核，绕过了 BIOS，所以第一个内核的内存得以保留。这是内核崩溃转储的本质。kexec是一个快速启动机制，可以通过已经运行的内核，启动另外一个内核并且不需要经过bios。

安装启动kdump

[root@centos7 /]# yum install kdump crash -y

也可以去centOS下载安装

wget http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-common-x86_64-3.10.0-514.el7.x86_64.rpm
wget http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-3.10.0-514.el7.x86_64.rpm

在发生故障的时候会在/var/crash/生产一个主机+故障时间目录，并产生两个文件vmcore vmcore-dmesg.txt

vmcore-dmesg.txt 记录的是粗略的信息。主要能分析出两个问题：
例如：

divide error、BUG之类的关键词

cat vmcore-dmesg.txt

我这边发现有明显的硬件报错信息

3****然后我们再通过sar日志分析
sar简介：
sar（System Activity Reporter, 系统活动情况报告）: 是用于监控Linux系统各个性能的优秀工具，包括：文件的读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状况、进程活动及IPC有关的活动等。

sar命令常用格式

sar [ options ] [ <interval> [ <count> ] ]
其中：
interval: 采样周期，单位是秒；
count：采样次数，默认值是连续采样；
options：命令行选项。

sar命令的选项很多，下面只列出常用选项：
-A：所有报告的总和
-u：输出整体CPU使用情况的统计信息
-v：输出inode、文件和其他内核表的统计信息
-d：输出每一个块设备的活动信息
-r：输出内存和交换空间的统计信息
-b：显示I/O和传送速率的统计信息
-a：文件读写情况
-c：输出进程统计信息，每秒创建的进程数
-R：输出内存页面的统计信息
-y：终端设备活动情况
-w：输出系统交换活动信息

sar常用性能数据分析
下文将说明如何使用sar获取以下性能分析数据：

• 整体CPU使用统计
• 各个CPU使用统计
• 内存使用情况统计
• 整体I/O情况
• 各个I/O设备情况
• 网络统计

准备分析当日的sar日志

用cat命令查看太大了，shell工具不够显示，所以我记录了shell共计的日志用netepad查看：
查看到内存使用记录部分发现：

使用率太高了。

 问题处理及结果
1.根据vmcore-dmesg.txt日志显示，该业务主机硬件故障导致系统出现kernel panic，建议由硬件工程师重点进行硬件内存的检查。
2.同时主机内存资源使用率稍高，建议对该业务主机资源进行重点监控。（如有必要可以进行业务拆分或者内存扩容）