事件背景
2020年9月25日18點18分，收到告警，大數據02節點宕機，發現此問題出現過3次，分別在生成大數據服務器的2個節點上發生。這次決心要查處問題。
服務是CDH節點，就是大數據那一套東西。
系統版本：CentOS Linux release 7.3.1611
內核版本：3.10.0-514.el7.x86_64
服務器廠商：Dell R730
故障分析
服務器宕機主要有3條分析思路。
- 是否內存或者CPU爆滿，導致服務器OOM，導致服務器重啟
- 是否硬件導致重啟
- 是否觸發系統BUG
本着這3條思路，我們接下來分頭排查。
- 觀察系統日志（/var/log/messages、/var/log/dmesg）
- 登錄管理卡地址，查看是否有硬件告警，並收集硬件信息，報告廠商協助排查
- 檢查是否是系統內核bug導致，所以得看kdump在系統崩潰保留的信息
分析過程：
1、登錄服務器查看系統日志
上圖是日志估值發生時候的日志，我們可以看出，這里只是故障發生后的服務器啟動日志，故障發生時並沒留下什么蛛絲馬跡。所以這里並沒有可用的信息，可以忽略。
2、硬件檢測
DELL廠商回復，硬件一切正常，沒有故障
3、我們分析一下系統崩潰時候kdump給我們留下來的信息。
什么是kdump
kdump 可以說是服務器的黑匣子，是一種的基於 kexec 的內核崩潰轉儲機制。系統一但崩潰，內核無法正常記錄信息了，這時kdump將轉入帶第二個捕獲內核，將第二個內核加載的內存中，對第一個內核的信息進行捕獲。由於 kdump 利用 kexec 啟動捕獲內核，繞過了 BIOS，所以第一個內核的內存得以保留。這是內核崩潰轉儲的本質。kexec是一個快速啟動機制，可以通過已經運行的內核，啟動另外一個內核並且不需要經過bios。
安裝啟動kdump，我們這里是默認啟動的
安裝crash命令和kdump相關工具，分析數據
yum install crash -y
下載
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
安裝
rpm -ivh kernel-debuginfo-common-x86_64-3.10.0-514.el7.x86_64.rpm kernel-debuginfo-3.10.0-514.el7.x86_64.rpm
crash解析奔潰日志
在發生故障的時候會在/var/crash/生產一個主機+故障時間目錄，並產生兩個文件vmcore vmcore-dmesg.txt
vmcore-dmesg.txt 記錄的是粗略的信息。主要能分析出兩個問題：
錯誤類型：
例如：
divide error、BUG之類的關鍵詞
錯誤地點：
RIP為造成內核崩潰的指令，Call Trace為函數調用棧，通過RIP和Call Trace可以確定函數的調用路徑，以及在哪個函數中的哪條指令引發了錯誤。
例如本次錯誤是RIP: 0010:[<ffffffffa03742fb>] [<ffffffffa03742fb>] xfs_vm_writepage+0x58b/0x5d0 [xfs]
<ffffffffa03742fb> <ffffffffa03742fb> 是指內存地址
xfs_vm_writepage 是錯誤函數
Call Trace為函數的調用棧，是從下往上看的。可以用來分析函數的調用關系。
本次故障是通過vmcore-dmesg.txt文件觀察到的，錯誤信息如下：
我們還可以使用vmcore解析出詳細日志，並進入當時的內核，查看一些當時的情況，具體可以查看此鏈接https://www.bladewan.com/2017/09/21/kdump/
這時候我們找到的問題，接下來是解決或者是怎么防止故障了，我們谷歌搜索一下kernel BUG at fs/xfs/xfs_aops.c:1062!，可以看到紅帽的官方文章https://access.redhat.com/solutions/2779111。或者https://blog.51cto.com/jiaxiaolei/2140212
通過文章我們可以得知是內核BUG，起因是JAVA的JVM的“hsperf”內存映射可寫“hsperfdata”文件
解決辦法：
升級內核3.10.0-693以上。但有的環境升級內核不方便，同時應用是java應用，可以使用臨時方法jvm 中關閉hsperf的特性。
參考鏈接：
https://blog.51cto.com/jiaxiaolei/2140212
https://www.bladewan.com/2017/09/21/kdump/