Day 10｜小公司第一條告警規則：容量門檻與異常等級

歷史資料開始累積後，我很自然地加上第一條規則：「磁碟超過 90% 就通知。」沒想到測試沒多久，告警不是太晚，就是一直被忽略。500GB 系統碟剩 10% 和 20TB 備份碟剩 10%，雖然百分比相同，能使用的空間與處理急迫性卻差很多。單一門檻看似方便，實際上很難照顧所有機台。

所以專案讓每台主機自行設定 warning 與 critical 門檻，再由 monitor.py 的 level_for 判斷狀態。除了百分比，我也會看剩餘空間、成長速度和磁碟用途。主機離線或資料拿不到時，更不能偷偷顯示綠燈。

我希望 warning 代表「排進待辦」，critical 則是「現在就處理」。告警只要能引導行動，才不會變成大家都想忽略的通知。

本篇學習重點

• 設計 normal、warning 與 critical 三段容量門檻。
• 理解判斷條件必須由嚴重到輕微排列的原因。
• 使用邊界值測試確認門檻行為。

重點程式碼：先判斷嚴重，再判斷警告

if used_percent >= critical_percent:
    return "critical"
if used_percent >= warning_percent:
    return "warning"
return "normal"

文章可搭配 79%、80%、89%、90% 四個案例，示範門檻邊界測試。

程式碼運作方式

1. 第一個條件先確認使用率是否到達 critical。
2. 未達嚴重門檻時，才繼續判斷 warning。
3. 兩者都未達才回傳 normal，因此三種狀態互斥。

邊界值要使用大於等於；若誤寫成大於，剛好 80% 或 90% 時就不會進入預期狀態。

實際使用範例

host = {"warning_percent": 80, "critical_percent": 90}

cases = {
    79: "normal",
    80: "warning",
    89: "warning",
    90: "critical",
}

for used, expected in cases.items():
    assert level_for({"used_percent": used}, host) == expected

這組邊界案例能立即抓出大於與大於等於寫錯的回歸問題。

實作時遇到的問題

初版只相信 collector 回傳的 level，但有些舊快照沒有等級，或主機門檻更新後仍顯示先前狀態，造成畫面與設定不一致。修復時我把判斷集中到 level_for，由目前使用率與該主機門檻重新計算；離線與缺資料則使用獨立狀態，不再顯示成 normal。測試也補上門檻邊界值，確認剛好等於 warning 或 critical 時的結果，避免最常見的大於、小於判斷錯誤。

今日心得

今天我學到，告警只有能引導行動才有價值。下一篇會加入歷史基準，從目前用量進一步看見容量變化。

連載頁
HardwareMonitor目錄

認識我們
聯繫我們