🎯 什麼情境該想到我
當你「日誌全印成一坨、真正要命的訊息跟印表機碳粉不足混在一起」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓每一個功能都有足夠的 production telemetry，並用分級把「誰在什麼時候該被吵醒」寫進日誌本身。
前提：每一個功能都應該被埋點——書中的判準是「如果一個功能重要到值得工程師去實作，它就一定重要到值得產生足夠的生產遙測」，好確認它照設計運作、並且達成了預期成果。
五個層級（有些層級會觸發告警）：
- DEBUG：程式裡發生的任何事，最常用於除錯。生產環境通常關閉，只在排錯時暫時打開。
- INFO：使用者驅動或系統特有的動作（例：「beginning credit card transaction」）。
- WARN：可能會變成 error 的狀況（例：一次 database call 花的時間超過某個預設值）。這一級很可能會啟動告警與排錯，其他日誌訊息則幫助理解是什麼導致了這個狀況。
- ERROR：錯誤狀況本身（例：API call 失敗、內部錯誤狀況）。
- FATAL：必須終止的情況（例：network daemon 無法 bind 一個 network socket）。
分級的那把尺（Dan North）：在猶豫某個訊息該是 ERROR 還是 WARN 時，想像自己凌晨四點被叫醒——「碳粉不足」不是 ERROR。
必須產生 log 的事件清單（Anton A. Chuvakin，Gartner GTP 安全與風險管理研究副總裁彙整）：
- Authentication／authorization decisions（含登出）
- System and data access
- System and application changes（特別是特權變更）
- Data changes：新增、編輯、刪除資料
- Invalid input（可能的惡意注入、威脅等）
- Resources：RAM、disk、CPU、bandwidth，或任何有硬性／軟性上限的資源
- Health and availability
- Startups and shutdowns
- Faults and errors
- Circuit breaker trips
- Delays
- Backup success／failure
再進一步：建立階層式的日誌分類，一軸是非功能屬性（performance、security），一軸是功能相關屬性（search、ranking），讓日誌好解讀、有意義。
規模參照（CSG，Scott Prugh）：2014 年一天產生超過十億筆 telemetry events，埋點的 code location 超過十萬處。他把「建立應用與基礎設施遙測」列為投報率最高的投資之一。
原文：「whether a message should be ERROR or WARN, imagine being woken up at 4」（L7680，接 L7681「a.m. Low printer toner is not an ERROR.」）
原文：「In 2014, we created over one billion telemetry events per day, with over one」（L7639，接 L7640「hundred thousand code locations instrumented.」）
原文：「potentially become an error (e.g., a database call taking longer than some」（L7667）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 分級選錯會直接製造告警疲勞：把不需要人半夜起床的事情標成 ERROR，等於自己造出噪音，接著就是 均值與標準差告警 裡講的 alert fatigue。
- DEBUG 在生產環境預設關閉，所以不要把只有 DEBUG 才記得到的關鍵資訊當成事後追查的依據。
- 光有日誌不等於有洞察——書中的下一步是把日誌轉成 metrics，才能對它做統計運算與異常偵測。
- Chuvakin 那份清單偏重安全與可稽核性；業務面的成果指標要另外從 五層遙測覆蓋 的 Business level 補。