Day 09｜機台增加後才看得見趨勢：保存快照與歷史資料

有一天 Dashboard 顯示某顆磁碟用了 70%，同事問我：「這是一直都差不多，還是今天突然變大的？」我答不出來，因為系統只留下最新數字。70% 本身不一定危險，但如果昨天才 40%，就完全是另一回事。從那天開始，我不只想知道現在的狀態，也想留下機台一路變化的痕跡。

專案用 FileStorage 管理最新快照、歷史快照、告警事件和檔案大小基準。起步時我選檔案而不是資料庫，因為部署真的簡單不少，但也得處理讀寫競爭和檔案變大。檔案掃描基準特別拆成主機與磁碟，避免每次重寫一大包 JSON。

latest 與 history_snapshot_before 把儲存細節藏起來。以後想換 SQLite，也不必把監控邏輯全部重做。

本篇學習重點

• 區分目前快照與歷史快照的用途。
• 找出指定時間以前最接近的比較基準。
• 正確表達「尚無資料」，避免將缺少資料當成零變化。

重點程式碼：由儲存層尋找歷史基準

start = comparison_start(now, interval, unit)
baseline = storage.history_snapshot_before(start)
changes = used_space_changes(current_snapshot, baseline)

使用端不必知道歷史資料放在哪裡，替換儲存方式時修改範圍也更小。

程式碼運作方式

1. comparison_start 依設定的數量與單位，算出希望比較的時間點。
2. 儲存層尋找該時間以前最接近的歷史快照，而不是要求時間完全相等。
3. used_space_changes 將目前與基準快照配對，計算每顆磁碟的容量差。

baseline 可能不存在，呼叫端必須顯示「尚未累積資料」，不能把缺少基準解讀為沒有變化。

實際使用範例

now = datetime.now()
start = comparison_start(now, 1, "days")
baseline = storage.history_snapshot_before(start)

if baseline is None:
    print("尚未累積滿一天的比較資料")
else:
    for change in used_space_changes(storage.latest(), baseline):
        print(change["mount"], change["difference_bytes"])

缺少歷史基準是正常狀態，使用端要提供明確訊息，而不是讓 None 引發例外。

實作時遇到的問題

最初所有檔案大小基準都放在同一個 JSON。機台增加後，每掃描一顆磁碟都要讀取並重寫整份檔案，啟動期間甚至會和 Dashboard 讀取互相等待。修復方式是依主機與磁碟拆分基準檔，並把自動掃描延後到啟動完成後執行。寫入流程也要避免讓讀取端看到半份內容。這次調整讓我體會到，檔案儲存雖然簡單，仍需要像資料庫一樣認真處理一致性與競爭。

今日心得

今天的選擇是在部署簡單與長期成長間取得平衡。下一篇會利用保存的資料建立容量告警，檢視單一百分比門檻的限制。
連載頁
HardwareMonitor目錄

認識我們
聯繫我們