華為雲國際帳號代開 國內伺服器系統日誌分析與排查：如何查找伺服器自動重啟的原因

第一章 先把問題釘死：重啟到底在什麼時候、由誰觸發？

伺服器「自動重啟」聽起來像同一件事，但實際上可能由完全不同的機制觸發：硬體看門狗、電源波動、BIOS/UEFI設定、BMC遠端重啟、操作系統kernel panic、OOM殺進程導致服務連鎖崩潰、磁碟故障引發檔案系統只讀、甚至是安全策略導致的重啟腳本。要排查，第一步不是找某一段日誌，而是把「時間線」建立起來。

建議你先做三件事：一是記錄你觀察到的重啟時間（精確到分鐘甚至秒），以及重啟前後的現象（是否有告警燈、是否有服務中斷、是否有人改配置）；二是確認重啟範圍：全機重啟還是僅某些服務重啟、是否是單節點還是叢集多節點同時；三是留存證據：在重啟當天或出現問題後，立刻保存關鍵日誌文件，避免後續覆蓋。很多機房的日誌有輪轉策略，錯過當天就難以追溯。

當你手上沒有BMC告警或重啟觸發原因資訊時，日誌就成了唯一的「目擊者」。而要讓日誌有用，就要做到：把每次重啟與日誌中的事件一一對齊。

華為雲國際帳號代開 1.1 建立重啟時間線（最重要，但最容易被忽略）

時間線的做法很簡單：列出每一次重啟的時間點T1、T2、T3……並在同一時段去找「當次」的關鍵記錄。你不必一開始就查全量日誌，先抓全量線索中的最上游痕跡：系統關機/重啟事件、kernel是否出現panic、BMC是否上報重啟原因、硬體告警是否出現。

如果你用的是Linux，常見入口包括：/var/log/messages、/var/log/syslog、/var/log/kern.log（視發行版而定）、/var/log/dmesg、/var/log/boot.log（部分發行版）、以及系統自帶的journal（若是systemd系統）。如果你用的是Windows，則可用事件檢視器的System日誌、關機/啟動事件、BugCheck事件等。

重點是：用同一套時間基準。很多人忽略時區或NTP同步問題，導致你以為事件發生在重啟之前，實際上可能是之後。

1.2 判斷是「硬體重啟」還是「軟體觸發」

你可以用一個快速判斷來縮小範圍：看重啟前是否出現kernel panic訊息；若沒有任何明顯panic，卻反覆在固定周期或在高負載時立刻重啟，就要優先懷疑看門狗、電源、溫度或硬體保護機制。反之，如果有清晰的panic、OOM、或檔案系統錯誤導致系統崩潰，才更可能是軟體或資源問題。

這不是絕對，但能讓你把排查路徑從「海量日誌」縮小到「少數幾類」。

第二章 日誌從哪裡找：BMC、OS、Kernel、服務各自負責什麼

自動重啟的根因常常出現在日誌體系的「上游」。換句話說：越靠近硬體控制面的資訊越值錢。BMC（Baseboard Management Controller，主板管理控制器）通常比操作系統先知道重啟或告警原因。核心層面的kernel log則提供系統崩潰的直接證據。服務與應用日誌則更多是間接線索：是它們先觸發了資源耗盡，還是它們只是被重啟打斷。

2.1 BMC/主機管理口：先查重啟原因與告警事件

如果你的機房有集中管理平台或每台機器都有BMC web界面/命令行介面，優先在重啟當天查看：

• 重啟類事件：例如“System Reset”“Hard Reset”“Power Cycle”“Watchdog Reset”。
• 電源相關：電源模組故障、瞬斷恢復、電壓異常、PSU紅燈告警。
• 溫度與風扇：CPU/主板溫度過高、風扇轉速不足、過熱保護。
• 硬體錯誤：ECC記憶體錯誤、PCIe AER、儲存控制器告警。

很多時候，BMC會直接給出“為何重啟”。即使沒有明確原因，它也會提供告警時間點，讓你回到OS日誌對齊。你要做的是：把BMC事件作為主軸，OS日誌作為佐證。

2.2 內核與啟動日誌：看見系統當次是怎麼死的

Linux常見排查入口包括：

• kernel ring buffer：dmesg 或 /var/log/dmesg。
• 啟動日誌：/var/log/boot.log（若有）、或journal中boot相關字段。
• 系統崩潰：panic、Oops、BUG、soft lockup/hard lockup、watchdog訊息。
• 記憶體問題：OOM-killer、Out of memory、page allocation failure。
• 檔案系統：EXT4 errors、XFS log I/O error、remount-ro。

你要找的是「第一次嚴重事件」而不是最後一行。很多人只抓最後幾十行，結果只是看到重啟後的正常啟動過程，錯過了真正觸發點。

實操建議：以重啟時間點為界，在重啟前後各截一段窗口，例如重啟前5分鐘與重啟後5分鐘。然後從重啟前窗口中，找最高級別的錯誤（emerg/alert/crit）或明顯的panic前訊息。

2.3 服務與應用日誌：它們通常是「誘因」而非「根因」

應用層的日誌常見於：redis、mysql、kafka、tomcat、nginx、各種自研服務。它們可能因為崩潰、配置錯誤或依賴不可用而退出，但要注意：服務退出通常不等於主機重啟。若出現服務反覆崩潰，應用可能觸發運維腳本，該腳本可能選擇重啟系統（例如為了“恢復到可用狀態”）。因此，服務日誌提供的是“誰先出事”，而BMC和kernel提供的是“主機怎麼被迫重啟”。兩者要串起來。

華為雲國際帳號代開 另外，某些高風險操作會導致內核觸發保護。例如大量寫入磁碟導致I/O錯誤、或某些程式吃滿內核資源引發硬鎖死，最終被看門狗重置。

第三章 核心機制大盤：最常見的自動重啟原因與日誌特徵

在國內伺服器環境裡，自動重啟最常見的原因通常集中在幾個類型。你可以把它當成“排查地圖”。每一類都有典型日誌特徵，你只要對上特徵，就能迅速收斂。

3.1 Kernel Panic / BUG / Oops：軟體或硬體觸發的崩潰

當你在重啟前窗口看到kernel panic、Oops或BUG信息，這通常是「主因」。常見表現包括：

• “kernel panic - not syncing: ...”
• “Oops: ...”
• 華為雲國際帳號代開 “BUG: unable to handle kernel NULL pointer dereference”

這類問題可能由驅動bug、內核版本與硬體不兼容、或記憶體/存儲錯誤引發。你需要進一步看panic前是否有硬體錯誤痕跡，例如ECC報錯、PCIe error、SATA/NVMe重置等。若有，根因可能在硬體。

若是驅動或內核版本問題，升級到穩定版本、或回退特定驅動/內核常能解決。但在未確認之前，別急著重裝：先做完整日誌與dump保存。

3.2 看門狗（Watchdog）：硬鎖死、卡死或系統無響應

看門狗重啟常見於“系统長時間無法正常調度”或“某些核彈性要求未被滿足”。日誌中你可能看到：

• soft lockup/hard lockup
• watchdog: BUG: soft lockup - CPU#... stuck
• BMC上報“Watchdog Reset”“System Reset due to Watchdog”

此類問題常和高負載、驅動問題、CPU中斷風暴、網卡或儲存驅動卡死有關。排查上要回到“觸發前的負載”。你可以看監控系統的CPU飆升、IO延遲、網卡錯誤、系統load飆高，並與日誌對齊。

如果重啟出現於特定高峰時段，且CPU或IO延遲明顯上升，那通常不是隨機硬體故障，而是某個路徑在特定條件下觸發鎖死。

3.3 OOM：記憶體不足導致嚴重連鎖，最終或被系統保護重置

OOM-killer通常會殺掉進程而不一定重啟整機。但在某些場景下，它可能引發關鍵服務退出，配合“守護腳本重啟整機”或“某些代理重啟策略”造成更大動作，間接導致重啟。

日誌常見關鍵字：

• 華為雲國際帳號代開 OOM-killer invoked
• Out of memory
• Memory cgroup out of memory

處理方式通常包括：調整記憶體限制、檢查是否存在記憶體洩漏、優化緩存策略、限制單次任務資源、或調整swap與OOM策略。若重啟由守護腳本觸發，你應該去看運維腳本或systemd的重啟策略（Restart=always等）是否設計不當。

3.4 檔案系統錯誤：磁碟/IO異常導致remount只讀或崩潰

磁碟或檔案系統問題是另一大類常見根因。日誌可能出現：

• EXT4-fs error、XFS log I/O error
• Buffer I/O error on dev ...
• remount-ro（變更為只讀）
• NVMe reset controller
• SATA timeout、I/O error

當關鍵分區變成只讀、或核心檔案寫入失敗，某些服務可能無法維持，進而觸發重啟策略。更糟的是，若IO錯誤非常嚴重，內核也可能直接觸發panic或被看門狗保護。

因此，查日誌時要同時關注：儲存錯誤是否反覆出現、是否在重啟前同時存在SMART異常、是否有RAID卡告警。

3.5 電源/溫度/風扇：硬體保護重啟或斷電恢復

如果日誌裡你找不到kernel panic，也看不到明顯鎖死資訊，但BMC顯示“過熱/電源異常/硬重置”，那就是硬體主導。典型線索：

• 溫度過高、風扇速度不足、CPU熱保護事件
• PSU故障或電壓跌落、瞬斷恢復
• 電源模組在重啟前後有告警

這類問題的“日誌”不只在OS，BMC是關鍵。你也要檢查機房側供電品質、UPS切換是否頻繁，以及機箱內風道是否被堵。只看一次日誌很難，通常要看告警在一段時間內是否呈現趨勢。

3.6 外部觸發：運維腳本、管理平臺、配置變更

有時候重啟不是故障，而是“被設計成發生”。例如：

• 華為雲國際帳號代開 cron或自研任務在某時刻重啟
• logrotate觸發後續腳本
• 運維工具（含自動化平台）在健康檢測失敗時重啟主機
• 配置變更（例如更新核心參數、驅動重載）需要重啟，但流程沒有同步風險

查證方法是：搜尋是否存在“reboot”“shutdown -r”“systemctl reboot”等命令觸發的痕跡。對Linux而言，/var/log/cron、/var/log/auth.log（或journal中）、以及systemd的日志都可能提供答案。對Windows則看計畫任務、事件ID關機/重啟。

這類原因雖然“不夠像故障”，但排查時仍常被忽略，因為人們更願意把它歸因於硬體或內核。

第四章 可落地的排查流程：從重啟事件到根因驗證

下面給一套你可以直接照做的流程。目標是：每一步都有輸出，避免你停在“看了一堆日誌但不知道下一步”。

4.1 第一步：確定當次重啟的窗口與類型

華為雲國際帳號代開 輸入是：你觀察到的重啟時間T，以及是否多次連續重啟。輸出是：一次重啟的前後窗口、以及是否是Hard reset/Soft reset（若BMC可查）。

實操上，你可以先找到系統重啟/啟動事件，再回頭看重啟前的錯誤是否在同一窗口出現。例如在Linux journal中你可以查boot事件；在syslog中查“reboot”或“System is rebooting”。找到時間點後，鎖定同一段。

4.2 第二步：先看最上游——BMC是否記錄重啟原因

如果BMC已記錄“Watchdog reset/Power cycle/Overheat”，那基本就能判定方向。此時OS日誌更像是佐證，不需要你把所有錯誤都翻一遍。

你仍需要做兩件事：第一，確認BMC告警時間是否真的落在重啟前；第二，確認告警是否與重啟頻率相關，例如是否每次都伴隨同類告警。

4.3 第三步：回看重啟前的第一個高嚴重事件

在重啟前窗口內，找第一個高嚴重錯誤。常見做法是先抓emerg/alert/crit等級（若日誌格式支持），或抓“panic/Oops/watchdog/OOM/remount-ro”等關鍵字。

關鍵原則：不要只看最後幾十行。最後幾行常常是重啟後的啟動資訊；真正的觸發通常出現在更早的位置。

4.4 第四步：把事件與資源/負載對上號

如果日誌顯示watchdog或lockup，你要回看同時段監控：CPU飆升、CPU中斷增多、IO延遲、網卡錯誤率、儲存重置次數。若日誌顯示磁碟錯誤，你要對上該期間是否有高寫入、是否剛更新存儲配置、是否有SMART異常。

這一步能把“看起來像硬體”與“其實是特定任務觸發驅動bug”分開。很多根因不是單純壞硬體，而是壞硬體被某負載放大。

4.5 第五步：做根因驗證而不是停在推測

驗證方式因類型不同：

• 若疑似內核/驅動：在測試環境重現或回退版本；檢查是否存在已知bug與硬體組合已發布修復。
• 若疑似記憶體：跑memtest或檢查ECC事件；觀察是否在特定條件下再次觸發。
• 若疑似儲存：查看SMART、控制器日誌、RAID告警；做壓測或更換碟位比對。
• 若疑似電源/溫度：記錄BMC溫度曲線、風扇轉速、PSU告警；檢查機箱風道並做壓測監控。
• 若疑似腳本：反查cron/systemd timer/管理平台操作記錄；核對時間點是否剛好吻合。

驗證的本質是：你要能回答“如果我做X，重啟是否會消失”。沒有這個閉環，就很容易陷入反覆調參卻找不到根因。

第五章 關鍵字策略：不用盲翻，直接命中證據

日誌量大時，人很容易失去耐心。更好的做法是建立“關鍵字清單”，並按優先順序掃描。你不需要每次都全量搜尋，但要知道每類原因最常出現的字眼。

5.1 Linux常用關鍵字清單（按優先級）

• 重啟/系統級：reboot、shutdown -r、System rebooted、Starting reboot、power cycle
• 內核崩潰：kernel panic、Oops、BUG、soft lockup、hard lockup
• 看門狗：watchdog、WDT、hard watchdog、NMI watchdog
• 記憶體：OOM-killer、Out of memory、memory cgroup out of memory
• 儲存/檔案系統：remount-ro、I/O error、EXT4-fs error、XFS log I/O error、NVMe reset
• 硬體資源：PCIe AER、EDAC、CE/UE、Machine Check Exception

你可以先掃一遍重啟前窗口是否出現上述字眼。出現的字眼本身就是索引點，後面再展開具體上下文。

5.2 如果你只會一招：從“panic/watchdog/OOM/remount-ro”開始

實務上，很多案例都能在這四類關鍵字中找到突破口。即便不是完全對應，至少你會知道應該先查硬體保護、還是先查資源耗盡、或先查檔案系統。

當你遇到“日誌不完整”或“日誌被覆蓋”時，關鍵字策略依然有效，因為你把搜尋範圍縮小了。

第六章 典型案例拆解：如何把多份日誌拼成結論

下面用幾個常見情境示範“怎麼從日誌推到根因”，你可以把它當作演練模板。

6.1 案例一：BMC顯示Watchdog Reset，但OS沒看到panic

華為雲國際帳號代開 情境：某台應用伺服器在夜間高峰時段每隔固定幾十分鐘重啟一次。你在OS日誌中沒有看到kernel panic，但看到“watchdog: BUG: soft lockup”零星訊息。

排查：先以BMC事件為主軸，確認“Watchdog Reset”發生時間是否與重啟時間一致。再回看重啟前的系統負載曲線：若CPU突然飆升並伴隨中斷異常，推測某驅動在特定網路/儲存條件下卡死。最後檢查驅動版本與內核版本組合，確認是否存在已知兼容性問題。

結論通常是：不是應用程式直接重啟，而是某驅動在高負載下卡住，導致看門狗觸發重置。修復方式可能是升級內核或驅動、或調整網卡/儲存參數。

6.2 案例二：檔案系統報錯後服務失敗，最後觸發重啟

情境：應用服務在重啟前出現大量寫入失敗，之後主機也重啟。OS日誌中出現EXT4或XFS的錯誤，並有remount-ro。

排查：先確認remount-ro發生在重啟之前。再看BMC是否有硬體告警；若BMC無告警，硬體可能還沒進入保護，而是檔案系統先壞了。接著查磁碟錯誤：SMART或控制器日誌是否有I/O timeout或重置。

最後驗證：更換故障磁碟或修復RAID後觀察重啟是否停止。很多時候你會發現：應用只是被迫崩潰，重啟其實是因為磁碟I/O錯誤引發一連串不可逆錯誤，最終讓系統自動恢復機制重啟。

6.3 案例三：時間剛好吻合運維腳本，誤以為故障

情境：機房報“自動重啟”，但系統健康檢查也正常。日誌只顯示重啟前一瞬間logrotate或某服務更新。

排查：比對重啟時間是否固定在某個週期、是否在配置變更窗口內。檢查cron或systemd timer，搜尋含有reboot或shutdown命令的腳本。若使用了自動化平台，核對平台的操作記錄。

結論可能是：守護腳本為了更新配置或清理資源，設定了重啟整機，但策略寫得過激。例如在服務健康檢測失敗時立即重啟整機，而當時只是偶發連線超時。

這種案例的教訓是：先把“計畫性重啟”排除掉，別直接把鍋甩給硬體或內核。

第七章 常見坑與建議：讓排查更快、更穩

排查自動重啟，最常見的坑不是缺少日誌，而是使用日誌的方法不對。你可以避免以下幾種情形。

7.1 只看最後幾行：結果抓不到根因

最後幾行往往只是重啟後的正常流程。根因可能已在重啟前很久出現，但你沒有向前追溯。

華為雲國際帳號代開 7.2 忽略BMC：把硬體保護當成OS問題

當BMC告警清晰時，OS日誌再多也只是補充。反過來，忽略BMC會讓你把時間花在錯的方向。

7.3 重啟後覆蓋了證據：來不及追溯

很多系統的日誌輪轉會在數天後覆蓋。出現重啟後，立刻保存當次關鍵日誌與BMC事件。若可用，保存kernel dump或core。

7.4 沒有做“閉環驗證”：只改不證

如果只是觀察到重啟停止，但沒有確認關鍵變更是否真的消除了觸發條件，你仍可能在下一次負載上再次復發。

第八章 整理你的排查報告：讓下一次不必從頭來

最後一步常被忽略，但它是成熟運維的標誌。你應該把每次排查形成可複用的模板：重啟時間線、BMC告警、OS關鍵事件、推測路徑、最終驗證與修復手段，以及預防建議。

一份好的報告至少包含：

• 重啟發生時間（含時區）、頻率與持續時長。
• 觸發判定（BMC硬體重置/OS崩潰/腳本觸發）。
• 日誌證據（列出關鍵錯誤的時間點與摘要）。
• 華為雲國際帳號代開 根因與影響範圍（影響了哪些服務、是否叢集擴散）。
• 修復步驟（版本回退/參數調整/硬體更換/策略修改）。
• 驗證方式（觀察指標、復測條件、時間窗口）。
• 預防措施（監控告警、日誌保留策略、運維腳本修正）。

當你把這些沉澱成知識，下次同類問題出現時，你不需要再依賴運氣，而是沿著既有證據鏈快速定位。

結語：日誌不是資料，是推理的證據鏈

國內伺服器的自動重啟看似雜亂，但只要你把日誌當作證據鏈來使用，就能把排查從“翻到哪算哪”變成“按時間線、按層級、按關鍵字收斂”。BMC負責告訴你硬體是否觸發保護；kernel負責告訴你系統為何崩潰或卡死；服務日誌負責告訴你是否存在連鎖誘因或腳本觸發。當你能把這三者對齊，你就不再只是找出錯誤，而是找到了原因。

最終目標不是讓機器不再重啟一次，而是讓它在未來同樣條件下也不會再出現同類觸發。把證據保存、把時間線寫清、把修復驗證落地，你就能把一次排查變成長期可控的能力。