Day 11｜同樣是 70%，為什麼今天特別危險？

某天早上，兩台主機的磁碟都顯示 70%。第一台長期維持在這個範圍，第二台昨天卻只有 45%。如果只看目前使用率，兩台看起來一樣；但從維運角度來看，第二台很可能正在產生異常資料，應該優先處理。

因此我開始把目前快照與指定時間前的歷史資料比較。系統透過 history_snapshot_before 找到符合比較週期的基準，再由 used_space_changes 依主機與磁碟計算使用量差值及變化率。Dashboard 除了顯示現在用了多少，也能回答「這段時間增加了多少」。

新加入的主機可能還沒有歷史基準，磁碟名稱也可能改變，主機離線時更拿不到目前值。這些情況不能顯示成增加 0GB，否則使用者會誤以為資料穩定。畫面必須明確說明比較資料尚未累積，並標出實際基準與掃描時間。

本篇學習重點

• 同時閱讀目前使用率與一段時間內的容量變化。
• 使用穩定鍵值配對不同快照中的同一顆磁碟。
• 避免資料順序與顯示名稱變動造成錯誤比較。

重點程式碼：以穩定鍵值比對同一顆磁碟

def host_disk_key(host, disk):
    return (
        host.get("name") or host.get("host"),
        disk.get("mount"),
    )

沒有穩定識別鍵，歷史比較很容易把不同主機或不同磁碟混在一起。

程式碼運作方式

1. 主機優先使用可讀名稱，沒有名稱時退回連線位址。
2. 再搭配磁碟 mount，組成可雜湊、可比較的 tuple。
3. 目前快照與歷史快照只要得到相同鍵值，就能找到同一顆磁碟。

若主機名稱會被使用者任意修改，更穩定的做法是加入不變的 host ID；這是目前模型未來可演進之處。

實際使用範例

baseline = {host_disk_key({"name": "NAS-01"}, {"mount": "D:"}): 420}
current_key = host_disk_key({"name": "NAS-01"}, {"mount": "D:"})
current_used_gb = 468

growth_gb = current_used_gb - baseline[current_key]
print(f"D 槽一天增加 {growth_gb} GB")
# D 槽一天增加 48 GB

先用同一套鍵值建立歷史索引，再用目前資料查找，才不會因陣列順序改變而比錯磁碟。實務上看到一天增加 48 GB，就能把這台主機排到待查清單前面。

實作時遇到的問題

專案曾固定用七天前資料比較，但部署未滿七天時，成長分析按鈕完全無法使用。後來把比較週期做成設定，預設調整為一天；沒有合格基準時仍允許建立首次檔案快照。另一個 Bug 是表格標題顯示的期間和實際查詢週期不一致，修復時統一從設定產生標題與查詢時間。

我後來更在意變化，而不只是絕對值。容量監控真正有用的地方，是讓我們在磁碟還沒滿以前，就看見不尋常的成長。

今日心得

今天我從靜態數字走向趨勢判斷，也確認基準時間必須透明。下一篇會繼續追查究竟是哪個檔案讓磁碟長大。

連載頁
HardwareMonitor目錄

認識我們
聯繫我們