Linux死機問題分析定位

1、【精品文檔】如有侵權(quán)，請聯(lián)系網(wǎng)站刪除，僅供學(xué)習(xí)與交流一、二、三、四、五、六、七、 Linux死機問題分析定位.精品文檔.八、 現(xiàn)象初步判斷：1、 判定是否死機：首先需要確定是否真正的死機了，而往往有些現(xiàn)象被現(xiàn)場誤認(rèn)為是死機了。是否死機的確定方法有如下：A、 對于直接死掉的，沒有任何反應(yīng)的情況下，看看鍵盤輸入是否有效，putty是否能夠登陸，BMC是否能夠登錄；B、 通過last reboot確認(rèn)是否死機？死機的時間？C、 通過在messages中對應(yīng)的時間點看是否有imklog啟動的日志？并在這個時間點前是否收到關(guān)機信號或者異常打??？D、 通過在boot.msg中對應(yīng)時間點有啟動的相關(guān)記錄，并

2、同時查看在boot.omsg中是否有關(guān)機的相關(guān)日志打??？搜索：Shutting down關(guān)鍵字看是否存在關(guān)機2、 是否人為操作出現(xiàn)系統(tǒng)重啟現(xiàn)象，往往被認(rèn)為是系統(tǒng)死機后然后重啟的，這就通過重啟現(xiàn)象了來認(rèn)為系統(tǒng)死機過，但是這種系統(tǒng)重啟是否是由于死機造成的，需要進行確定。A、 通過同現(xiàn)場人員進行溝通，確認(rèn)是否為人為的重啟？比如按電源、拔電源等人為動作？B、 通過history中查詢在系統(tǒng)重啟時的時間點附近有reboot或halt、shutdown、init？C、 通過在BMC日志中確認(rèn)是否有通過BMC的操作進行系統(tǒng)的重啟操作？對于直接拔電源致使系統(tǒng)重啟的操作，在messges和boot.omsg中是

3、沒有相關(guān)的信息記錄的，表現(xiàn)為系統(tǒng)日志和業(yè)務(wù)運行日志在同一時間全部消失。對于按電源、命令進行重啟操作，在messages中能夠看到系統(tǒng)收到關(guān)機或者重啟的信息，同時在boot.omsg中會有關(guān)機時的關(guān)閉系統(tǒng)服務(wù)的關(guān)機過程信息。對于在BMC上直接進行關(guān)機或者重啟操作，信息記錄就比較復(fù)雜了。而對于此種情況，在messages中和boot.omsg中是看不到相關(guān)的信息記錄，同直接拔電源一樣的。九、 處理步驟：1、日志盡快獲?。涸诂F(xiàn)場反饋出現(xiàn)死機問題后，第一時間反饋相關(guān)日志，并盡量多盡量準(zhǔn)確全面，等待的時間越長日志可能就已覆蓋，或清除，或環(huán)境重搭，致使定位工作受到阻礙。A、 死機問題發(fā)生的時間點如果發(fā)生死

4、機問題時測試或維護人員在場，需反饋死機問題發(fā)生的精確時間。B、 死機具體現(xiàn)象描述死機問題的發(fā)生通常伴隨著系統(tǒng)和業(yè)務(wù)方面的異?，F(xiàn)象，系統(tǒng)異常包括服務(wù)器重啟、系統(tǒng)掛死（如BMC黑屏）、系統(tǒng)遲緩（如命令無法執(zhí)行或響應(yīng)時間過長）、網(wǎng)絡(luò)中斷（如Ping檢測失?。?、登陸失?。ㄈ鐭o法遠程登陸或卡死在登陸界面）、文件系統(tǒng)異常（如文件只讀或系統(tǒng)命令失效）等等；操作失敗、超時、執(zhí)行無返回等。項目結(jié)果服務(wù)器重啟OK/NOK系統(tǒng)掛死（BMC或KVM黑屏）OK/NOK系統(tǒng)延緩（如命令無法執(zhí)行或響應(yīng)時間過長）OK/NOK網(wǎng)絡(luò)中斷（如Ping檢測失敗）OK/NOK登陸失?。ㄈ鐭o法遠程登陸或卡死在登陸界面）OK/NOK文件系

5、統(tǒng)異常（如文件只讀或系統(tǒng)命令失效）OK/NOK業(yè)務(wù)異常則包括主備HAOK/NOK操作失敗OK/NOK命令執(zhí)行超時OK/NOK此外，同樣現(xiàn)象的死機問題是否多次出現(xiàn)、出現(xiàn)頻率也需要反饋。C、 死機時段具體操作主要指死機時段內(nèi)對整個系統(tǒng)（包括硬件和軟件）進行的各種操作，包括但不限于對服務(wù)器上下電、更換硬件、拔插網(wǎng)線、更改交換機配置、監(jiān)控及日志查詢。此外還包括死機之前對問題服務(wù)器的各種操作，如執(zhí)行腳本或系統(tǒng)命令、拷貝/刪除/修改文件、啟動/停止系統(tǒng)服務(wù)、掛載本地或遠端目錄等。2.組網(wǎng)、硬件和BMC信息反饋組網(wǎng)、硬件信息有助于定位人員從宏觀把握整個系統(tǒng)以及借鑒之前的經(jīng)驗，而內(nèi)置在服務(wù)器中BMC系統(tǒng)收集的

6、信息有時更能為死機問題定位提供直接的依據(jù)。A、 組網(wǎng)信息組網(wǎng)信息主要包括網(wǎng)絡(luò)規(guī)模（服務(wù)器、交換機數(shù)目）、硬件類型（防火墻、服務(wù)器、交換機型號）、網(wǎng)絡(luò)配置（IP地址規(guī)劃、交換機配置）、物理連線圖等。B、 硬件信息硬件信息主要包括發(fā)生死機的服務(wù)器類型（RH2285、E6000、T6000或其它服務(wù)器）、CPU型號與數(shù)目、內(nèi)存大小、本地硬盤容量與數(shù)目、BIOS配置等，此外建議信息收集人員盡可能反饋組網(wǎng)內(nèi)其它服務(wù)器、其它設(shè)備的硬件信息，便于定位人員橫向?qū)Ρ?。服?wù)器各種硬件信息查詢?nèi)缦拢海?） CPU型號與數(shù)目對于管理、存儲節(jié)點，使用“cat /proc/cpuinfo”命令獲得；對于計算節(jié)點使用“ca

7、t /proc/cpuinfo”僅能獲得domain0中的CPU信息，可以通過“xm dmesg”命令查看所有的CPU信息。（2） 內(nèi)存大小對于管理、存儲節(jié)點，使用“cat /proc/meminfo”命令獲得；對于計算節(jié)點使用“cat /proc/meminfo”僅能獲得domain0中的內(nèi)存信息，可以通過“xm dmesg”命令查看內(nèi)存總大小。（3） 本地硬盤容量與數(shù)目本地硬盤容量可以通過“fdisk l”命令獲得，考慮RAID組以及掛載遠端磁盤的因素，本地硬盤數(shù)目最好通過BMC界面直接查看，在BMC界面，系統(tǒng)信息->系統(tǒng)狀態(tài)中可以看到硬盤槽位和硬盤狀態(tài)。3、BMC信息BMC是公司自

8、研的RH2285、E6000、T6000等型號服務(wù)器內(nèi)嵌的服務(wù)器管理控制單元，能夠?qū)崿F(xiàn)對服務(wù)器的多種管理、查詢、監(jiān)控功能，發(fā)生死機問題時需要從BMC收集的信息包括（1） BMC系統(tǒng)事件日志登陸B(tài)MC提供的web界面后，查看系統(tǒng)日志事件，反饋死機發(fā)生時間點前后一段時間（建議取死機發(fā)生前后12小時）的日志截圖。通過ftp方式登陸B(tài)MC的文件系統(tǒng)，反饋data目錄下的sel.bin文件。（2） BMC、BIOS版本號在BMC的web界面，選擇系統(tǒng)信息-> 固件版本查詢，反饋版本信息：（3） BMC與OS的時間差由于BMC和OS使用不同的時間芯片，因此這兩者之間可能存在時間差，需要現(xiàn)場

9、人員通過登陸B(tài)MC系統(tǒng)和OS進行時間的比對，并截圖表示兩者之間的時間差異，這樣便于定位人員分析BMC日志和OS的日志（時間差）。十、 系統(tǒng)信息Linux的日志系統(tǒng)能夠記錄系統(tǒng)的登陸情況、操作記錄、異常事件等，多數(shù)情況下為系統(tǒng)側(cè)死機問題提供重要的線索，發(fā)生死機問題時，建議從系統(tǒng)方面獲得如下信息：1.系統(tǒng)message日志系統(tǒng)的message日志會記錄在cd /var/log/目錄下，并根據(jù)日志產(chǎn)生時間和日志文件大小壓縮備份為“messages-<時間戳>.bz”的形式，請盡可能在反饋全部的日志文件（包括當(dāng)前日志文件/var/log/messages以及所有的bz壓縮文件）。3、 系統(tǒng)

10、boot日志操作系統(tǒng)能夠記錄當(dāng)前和前一次啟動時的日志，兩次啟動記錄保存在/var/log/boot.msg和/var/log/boot.omsg中，請全部反饋。4、 系統(tǒng)登錄和使用情況使用last可以查看系統(tǒng)每次啟動的時間點、用戶登陸情況等，建議使用：“l(fā)ast reboot >> last.txt”命令將last命令的執(zhí)行結(jié)果保存為文本文件進行反饋。5、 系統(tǒng)歷史操作記錄使用history可以查看系統(tǒng)的歷史操作信息，建議使用“history >> history.txt”命令將history命令的執(zhí)行結(jié)果保存為文本文件進行反饋。6、 系統(tǒng)黑匣子記錄系統(tǒng)中提供黑匣子功能

11、收集節(jié)點操作系統(tǒng)Crash（如panic、oops、BUG、oom等）時的異常信息，黑匣子功能實現(xiàn)的機制和記錄存放位置不同，請注意按照不同的操作系統(tǒng)類型和發(fā)生死機的時間反饋對應(yīng)的黑匣子日志。系統(tǒng)監(jiān)控記錄GalaX系統(tǒng)提供對操作系統(tǒng)各種資源進行監(jiān)控的功能，并生成監(jiān)控日志保存在每個節(jié)點的/opt/osinfo/statistics/目錄中，監(jiān)控日志會根據(jù)大小和時間在同一目錄下保存為“statistics<時間戳>.tgz”格式，請注意按照發(fā)生死機的時間反饋對應(yīng)的系統(tǒng)監(jiān)控日志。A、 系統(tǒng)串口消息如果出于調(diào)測的目的開放系統(tǒng)的串口，請反饋問題服務(wù)器的串口打印信息，通常情況下GalaX系統(tǒng)中各

12、個節(jié)點的串口功能是關(guān)閉的。串口打印的堆棧信息、臨終遺言對死機定位非常有用，如果沒有部署串口，請盡量將串口部署上，串口信息對于死機問題的定位很重要。B、底層日志：C、收集系統(tǒng)的打印信息：命令：cat /proc/sys/kernel/printk1、 定位方法1.是否硬件狗復(fù)位A.在死機問題中，較多的死機問題都是由于軟件狗未喂硬件狗，或者喂狗不成功，導(dǎo)致硬件狗超時(超時時間為20Min)，從而重啟服務(wù)器，這樣就認(rèn)為系統(tǒng)死機后的重啟。B.因此查看watchdog的日志，看是否是喂狗的時候出現(xiàn)問題。首先需要判定是否由于watchdog自身的原因或者某些規(guī)則導(dǎo)致硬件狗超時而重啟服務(wù)器，這樣的原因下就是

13、上層業(yè)務(wù)造成的，不是OS本身的問題。C.同時在查看watchdog的日志時，注意查看是否是喂狗的腳本執(zhí)行不成功？有無及時的返回喂狗腳本執(zhí)行的結(jié)果？這樣判定是否是由于喂狗腳本阻塞引起的硬件狗超時？同時比對是否在其它的業(yè)務(wù)模塊日志中也有執(zhí)行腳本不成功的情況？這樣如果所有的模塊都存在這種執(zhí)行腳本不成功、卡死的話，那就不是watchdog本身的原因，而是在系統(tǒng)中的其它原因造成，需要向系統(tǒng)更深入的排查原因了。如果是由硬件狗復(fù)位服務(wù)器，在BMC界面日志中能夠記錄到相應(yīng)的日志，通過此可以進行判定;2. 是否系統(tǒng)負載過高Linux系統(tǒng)不是孤立的存在的，其上往往是運行這產(chǎn)品自身的業(yè)務(wù)，而業(yè)務(wù)既然使用語言代碼編程

14、，那也就存在Bug，而對于這些Bug也可能引起Linux的崩潰或者類似死機的現(xiàn)象。這類問題往往最常見的現(xiàn)象是系統(tǒng)響應(yīng)緩慢，或者無法響應(yīng)，從而認(rèn)為系統(tǒng)死機，這往往從監(jiān)控日志中能夠看到內(nèi)存和CPU使用飆高，而這往往是由于系統(tǒng)負載過高導(dǎo)致的。由于系統(tǒng)負載過高導(dǎo)致的卡死，一定是解決的越快越好！需要通過命令行終端進行定位。通過CtrlAltF1(通常F1F6都可以進行切換)，此時可能鍵盤的輸入速度比較慢，請耐性等候，在提示符后輸入top回車，看到一張動態(tài)的表，上面列出了耗用資源最多的進程。觀察到刷新幾次后，按q退出，然后輸入kill PID，其中PID為top中顯示的占用資源較多的進程，此時系統(tǒng)應(yīng)該會快

15、不少，如果沒有結(jié)束掉進程，通過kill -9，這樣基本上沒有問題了(這個動作一般不要做)。3. 是否業(yè)務(wù)導(dǎo)致判斷到是由于系統(tǒng)的負載過高導(dǎo)致系統(tǒng)的死機，然后就是判定是否是由于業(yè)務(wù)導(dǎo)致的？業(yè)務(wù)模塊相對來說是一個比較新開發(fā)的，出現(xiàn)問題的幾率還是相對來說比較大的。因此首先是從業(yè)務(wù)模塊下手。1. 在出現(xiàn)問題時，現(xiàn)場是否做了哪些的操作？2. 而這些操作是否會引起某些系統(tǒng)資源的過載使用？3. 結(jié)合業(yè)務(wù)模塊的日志，分析在出現(xiàn)問題時是否有某些異常的日志記錄？4. 如果有，則找到出現(xiàn)這些異常的原因，向上找到出現(xiàn)這些異常的起始點，再向上查找比較長的時間段日志，看是否有明顯的異常。4. 是否硬件相關(guān)因此首先需要同判定現(xiàn)場環(huán)境中的BIOS中的某些項的設(shè)置是否正確？看當(dāng)時配套版本中說明的設(shè)置，以及此版本是否本身就存在此問題？在判定完上述后，如果都不符合，則有可能是出現(xiàn)了新的問題，獲取到messages和監(jiān)控日志等，在其中進行查看是否有報硬件相關(guān)的錯誤，針對這些錯誤，判斷分析是否正常？而同時這些錯誤有可能在出現(xiàn)問題之前比較長的時間，需要向上回溯。需要專業(yè)硬件人員來分析。5. 是否內(nèi)核問題問題與kernel可能也有關(guān)系了，而如果同kernel有較大關(guān)系的話，系統(tǒng)會產(chǎn)生kbox文件，而管理節(jié)點由于使用LinuxIMG，則產(chǎn)生的黑匣子日志文件在本地/var目錄