1. 記錄日志

1.1. 傳統的日志檔案仍然是最可靠和最靈活的資訊載體

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

1.3. 沒有比日志檔案更松散的耦合方式了，而且每個框架或工具都可以抓取日志檔案

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

2.1. 日志的存放位置

2.2. 日志級別

2.3. 日志讀者

2.4. 巫毒運維

2.5. 日志資訊應包含可用于跟蹤事務步驟的識別符號，這可能是用戶ID、會話ID、事務ID，甚至是接受請求時分配的任意數字

3. 實體的健康度量指標

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

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

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

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

讀發布！設計與部署穩定的分布式系統（第2版）筆記22_實體層之日志

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. 當新實體的健康狀況檢查結果從失敗轉移到通過時，就意味著該應用程式已完成啟動