Linux宕機故障分析案例
馬化輝
背景
在Linux系統環境下，服務器宕機發生的頻率比較小，但是不少工程師或多或少都會遇到這種情況，有時候會手足無措，不知從何入手。筆者將借助一次案例分析，展示下Linux宕機故障事件的處理方法和思路。
宕機發生的原因不一，或者是硬件原因，或者是性能原因，或者是服務器觸發了Linux的bug，導致內核崩潰等等。
案例分析
1、 案情還原；
生產系統服務器dcspodsaa1在4月25日凌晨00：49分發生服務器宕機故障，當時系統管理員對硬件報錯進行了截圖（保留現場很重要），看字面意思應該是服務器的swap設備發生損壞：
2、 分析方法一：使用sosreport收集系統日志，檢查/var/log/messages日志，查找系統重啟前是否存在錯誤日志，圖中kernel***/proc/kmsg started代表系統啟動的第一條日志，在此之前沒有發現異常日志，
3、 分析方法二：檢查服務器開啟了kdump服務，並在/var/crash目錄找到了當天生成的vmcore文件,使用crash工具分析vmcore文件，如下：
服務器發生了嚴重的系統崩潰panic錯誤
對kdmp文件的錯誤日志進行分析，發現了大量的swap 設備讀寫錯誤：
4、 根據報錯” Kernel panic –not syncing:Attempted to kill init”,查詢到紅帽官網的KB：https://access.redhat.com/solutions/1450043，得到此次宕機事件的原因是系統 swap設備I/O讀寫失敗，觸發系統kill掉主進程“init”，系統發生內核崩潰，而關於系統swap分區讀寫錯誤產生的深層原因，涉及到Redhat底層內核的程序，建議開啟紅帽的官方case進行深度的分析處理。
5、 分析方法三：檢查系統歷史性能記錄，/var/log/sa/路徑下記錄了每天由sysstat服務收集的sar（system activity report）文件，默認每10分鍾記錄一次系統資源使用情況的信息，包括CPU、內存等。通過sar命令查看系統宕機時負載情況，沒有發現資源使用異常，基本可以排除不是系統因性能不足從而導致宕機
4.25號性能記錄文件
使用命令sar –A –F sa25 | more檢查CPU性能信息和內存性能信息，沒有發現異常情況。
其他配置
1. 開啟kdump：
安裝依賴包
啟動服務
設置開啟啟動
修改默認crashkernel參數為256M, 注意需重啟系統才生效
2. 使用crash工具分析vmcore文件：
1) 安裝crash包，可使用yum安裝
2) 安裝kernel-debug內核版本，該rpm包必需和故障系統的內核版本一致
先使用unamre –r查看故障機版本
安裝相應包
3) 啟動crash檢查
小結
因此，在處理故障時，一般的思路是：
1. 首先應查找故障前的錯誤日志線索，可以通過檢查系統messages日志中的錯誤日志；
2. 如果沒有，進而排查系統是否觸發kdump服務（在系統由於內核崩潰而導致宕機時，可以捕獲故障時內存中的故障信息）；
3. 另外也需要分析系統資源（CPU、內存等）使用上出現異常。
http://learningfuture.net/Extend/ArticleContent?id=d363c713-2225-4b93-a159-bb52e3434b15