實體主機 ECC 錯誤監測：從核心事件到告警驗證

資料庫程序意外結束，核心日誌同時出現記憶體錯誤時，重新啟動應用程式只能恢復程序運作，無法釐清故障來源。ECC 能修正部分記憶體錯誤，卻不會自動完成事件留存、趨勢判讀與支援工單所需的證據蒐集。實體主機上線驗收時，應確認一條完整鏈路：硬體回報、核心接收、事件保存、監測識別、告警送達。

CloudSFP 的 AMD EPYC 7543P 實體主機採用 DDR4-3200 ECC，提供 128GB 與 256GB 兩種配置。以下以 Debian 12 為例建立巡檢流程，指令應在主機作業系統執行，而非客體作業系統。不同核心與韌體提供的資訊可能不同；缺少的資料來源必須個別記錄，不能視為零錯誤。

一、先區分錯誤與監測缺口

可修正錯誤通常標示為 CE，表示相關錯誤已被修正；不可修正錯誤通常標示為 UE，表示該錯誤無法由此錯誤修正機制修復。實際影響還取決於錯誤位置、核心的處理方式及受影響的程序，不能只憑縮寫就認定業務資料一定完整無損。

判讀 CE 時，重點是增量、是否在相同位置重複發生，以及發生當下的負載。單次孤立事件與同一位置持續發生的事件，應採取不同的處理優先順序。UE 則應優先保護資料，檢查程序結束、系統異常與現有備份，並停止增加相關負載。

「沒有紀錄」只有在確認蒐集鏈路正常運作時，才具有參考價值。EDAC 目錄為空、蒐集服務停止、事件資料庫無法讀取，都屬於監測缺口，不是系統健康的證明。

ECC 也不能取代資料驗證、儲存備援與備份。應用程式回傳錯誤結果或檔案損毀，是否與記憶體錯誤有關，必須透過時間與業務證據交叉比對，不能直接認定存在因果關係。

二、確認核心實際提供的資料來源

先記錄啟動識別碼與核心版本，再檢查記憶體控制器目錄及核心事件。以下指令只讀取目前狀態，不會載入驅動程式，也不會修改硬體設定。

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

目錄中的 mc_name 用於確認控制器名稱，ce_count 與 ue_count 則是對應控制器的累計計數。第一次讀到非零值時，應先保存為基準值，不要把所有歷史累計都當成剛發生的告警。

若目錄不存在，或沒有控制器項目，應保留指令輸出，並檢查核心日誌中的驅動程式初始化資訊。驅動程式支援情況、韌體設定與平台回報路徑，都可能影響資訊是否可見；不建議在正式環境的主機上反覆載入未知模組來試探。

核心日誌中的 MCE 或 Hardware Error 也不一定代表記憶體故障；事件可能來自其他硬體單元。必須保留完整的前後文，不能只擷取一行含有「error」的文字就加以歸類。

三、建立 rasdaemon 紀錄與計數基準

Debian 12 可透過發行版套件安裝 rasdaemon。變更前先保存現有服務設定；安裝後，應一併檢查服務狀態、啟動參數與實際執行中的程序。

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

--status 只是檢查的一部分，不能據此作出完整的健康判斷。還應檢查服務日誌，確認是否有事件訂閱失敗、權限錯誤或資料庫寫入問題。

sudo journalctl -u rasdaemon -b --no-pager

記錄程序運作，不代表紀錄已寫入磁碟

檢查啟動參數是否啟用 -r 或 --record，並確認目前使用的套件支援資料庫。若服務持續運作，卻未將紀錄持久化保存，重新啟動蒐集程序可能造成證據中斷。資料庫位置應以實際套件設定為準，不要直接套用其他發行版的路徑。

每次取樣至少應保存主機編號、啟動識別碼、取樣時間、控制器名稱，以及 CE、UE 計數。計數增量必須在相同啟動識別碼、相同資料來源的條件下比較。系統重新啟動、模組重新載入或計數下降時，應重新建立基準，而不是算出負數後直接忽略。

rasdaemon 與 EDAC 的資料涵蓋範圍未必完全相同。比較前應先核對事件類型、蒐集起點與控制器，不必要求兩套紀錄的總數機械式地一致。

四、讓告警傳達風險，而不是堆積訊息

建議將監測分成三類：蒐集鏈路失效、CE 新增、UE 新增。蒐集鏈路失效包括服務停止、讀值失敗與資料庫查詢錯誤，應獨立發出告警，不能以數值零掩蓋異常。

CE 新增通知應包含本次增量、控制器與原始事件。若紀錄提供位置欄位，可依位置彙整重複事件，但不應設定一個適用於所有主機的「安全次數」。是否升級處理，應綜合考量事件發生速率、集中程度與業務症狀。

UE 新增時應提高處理優先順序，保存現場資訊後再檢查業務資料完整性。不要透過壓力測試進一步驗證故障，也不要為了清空計數而先重新啟動主機。

告警鏈路驗收可使用離線樣本：建立前後兩份計數輸入，分別驗證零增量、CE 增量、UE 增量、讀值失敗與啟動識別碼變更。測試訊息應明確標示為演練，只送入監測解析器，不寫入真實硬體事件資料庫。

正式環境的主機不應透過錯誤注入來驗收通知。通知測試成功，只能證明解析與傳送功能正常；硬體事件能否被核心接收，仍須依據驅動程式狀態、事件來源與實際紀錄個別確認。

五、保留能推進硬體調查的證據

出現重複錯誤後，先匯出本次啟動期間的核心日誌、rasdaemon 服務日誌與事件查詢結果，再保存計數快照。蒐證目錄應限制存取權限；將檔案附至工單前，先檢查是否含有位址、帳號或業務敏感資訊。

工單內容依以下順序整理：

• 主機編號、系統與核心版本、啟動識別碼。
• 首次發現時間與明確的時區，以及錯誤是否持續新增。
• CE、UE 的原始事件與前後計數，不要只附告警截圖。
• 回報中的控制器與位置欄位；缺少的欄位應如實註明。
• 同期業務症狀，以及已執行的操作與結果。

不應自行將事件中的 DIMM 標籤或位址換算成實體插槽編號，因為平台的對應關係可能不同。硬體定位應交由支援人員結合主機資訊完成；租用方則負責保護作業系統、業務資料與備份。

巡檢的最終交付成果不是一張「全綠」截圖，而是可複核的基準、明確的資料來源涵蓋範圍、經過演練的告警鏈路，以及完整的故障證據。核心更新或主機重新啟動後，應再次確認這些條件，避免將蒐集失效誤認為錯誤已經消失。

常見問題