1. 記錄日誌

1.1. 傳統的日誌文件仍然是最可靠和最靈活的信息載體

1.2. 日誌文件反映應用程式內部的活動，因此它們能揭示應用程式的即時行為

1.3. 沒有比日誌文件更鬆散的耦合方式了，而且每個框架或工具都可以抓取日誌文件

2. 成功運用日誌的關鍵事項

2.1. 日誌的存放位置

2.1.1. 對物理機器來說，將它們保存在單獨的驅動器上是個很好的做法

2.1.2. 實例在虛擬機中運行，將日誌文件從應用程式代碼中分離出來也是一個好主意

2.1.2.1. 需要鎖定代碼目錄，並且寫入許可權要儘可能小，甚至沒有

2.2. 日誌級別

2.2.1. 大多數開發人員在編寫日誌時，仿佛自己是日誌文件的主要消費者

2.2.2. 運維團隊的系統管理員和運維工程師將花費更多的時間與這些日誌文件打交道

2.2.3. 記錄日誌應該面向生產環境的運維人員，而非開發人員或測試人員

2.2.4. 任何級別為“錯誤”或“嚴重”的日誌記錄都需要交由運維人員來採取措施

2.2.4.1. 並非所有異常都需要記錄為錯誤，如果僅僅因為用戶輸錯了信用卡號碼，造成驗證組件拋出一個異常，就不需要運維團隊處理

2.2.4.2. 用“錯誤”標記嚴重的系統問題，如斷路器跳閘至“斷開”

2.2.5. 在生產環境中調試日誌

2.2.5.1. 構建過程中添加一個步驟，自動刪除任何啟用“調試”級別或“跟蹤”級別的配置

2.3. 日誌讀者

2.3.1. 需要便於讀者閱讀，這一點高於一切

2.3.1.1. 對信息的誤解會造成經濟損失，影響聲譽

2.3.2. 必須確保日誌文件能向其讀者傳達清晰、準確和可操作的信息

2.3.3. 在格式上應儘可能地便於讀取

2.3.3.1. 缺乏列對齊，且需要從左到右“掃描”來閱讀的格式絕對不能採用

2.4. 巫毒運維

2.4.1. 對早期人類來說，那些能探知不存在的模式的人比不能探知真實模式的人更容易將基因傳遞下來

2.4.1.1. 前者在看到類似豹子身上明暗相間的花紋，便從灌木叢中逃跑

2.4.1.1.1. 假陽性錯誤（所探知的模式是不存在的）的代價很低

2.4.1.2. 後者甚至不能辨認叢林中的豹子

2.4.1.2.1. 假陽性錯誤（所探知的模式是不存在的）的代價很低

2.5. 日誌信息應包含可用於跟蹤事務步驟的標識符，這可能是用戶ID、會話ID、事務ID，甚至是接受請求時分配的任意數字

3. 實例的健康度量指標

3.1. 實例是組成系統的基本構件

3.2. 實例本身並不能說明整個系統的健康狀況

3.3. 可以發出一些度量指標，這些指標可被集中地收集、分析和可視化

3.3.1. 只需要定期在日誌文件中插入一行統計信息，日誌抓取工具越強大，這種做法的優勢越明顯

3.4. 健康狀況檢查是流量管理的重要組成部分

3.4.1. 解釋度量指標是有難度的

3.4.2. 當新實例的健康狀況檢查結果從失敗轉移到通過時，就意味著該應用程式已完成啟動