一、什么是日志
日志用來記錄用戶操作、系統運行狀態等，是一個系統的重要組成部分。然而，由於日志通常不屬於系統的核心功能，所以常常不被團隊成員所重視。對於一些簡單的小程序，可能並不需要在如何記錄日志的問題上花費太多精力。但是對於作為基礎平台為很多產品提供服務的后端程序，就必須要考慮如何依靠良好的日志來保證系統可靠的運行了。
好的日志可以幫助系統的開發和運維人員：
- 了解線上系統的運行狀態
- 快速准確定位線上問題
- 發現系統瓶頸
- 預警系統潛在風險
- 挖掘產品最大價值
不好的日志導致：
- 對系統的運行狀態一知半解，甚至一無所知
- 系統出現問題無法定位，或者需要花費巨大的時間和精力
- 無法發現系統瓶頸，不知優化從何做起
- 無法基於日志對系統運行過程中的錯誤和潛在風險進行監控和報警
- 對挖掘用戶行為和提升產品價值毫無幫助
二、日志分類
日志從功能來說，可分為診斷日志、統計日志、審計日志。
診斷日志， 典型的有：
- 請求入口和出口
- 外部服務調用和返回
- 資源消耗操作: 如讀寫文件等
- 容錯行為： 如雲硬盤的副本修復操作
- 程序異常： 如數據庫無法連接
- 后台操作：定期執行刪除的線程
- 啟動、關閉、配置加載
統計日志：
- 用戶訪問統計：用戶IP、上傳下載的數據量，請求耗時等
- 計費日志（如記錄用戶使用的網絡資源或磁盤占用，格式較為嚴格，便於統計）
審計日志：
- 管理操作
對於簡單的系統，可以將所有的日志輸出到同一個日志文件中，並通過不同的關鍵字進行區分。而對於復雜的系統，將不同需求的日志輸出到不同的日志文件中是必要的，通過對不同類型的文件采用不同的日志格式（例如對於計費日志可以直接輸出為Json格式），可以方便接入其他的子系統。
三、日志中記錄什么
理想的日志中應該記錄不多不少的信息。
所謂不多，是指不要在日志中記錄無用的信息。實踐中常見到的無用的日志有：1）能夠放在一條日志里的東西，放在多條日志中輸出；2）預期會發生且能夠被正常處理的異常，打印出一堆無用的堆棧；3）開發人員在開發過程中為了調試方便而加入的“臨時”日志
所謂不少，是指對於日志的使用者，能夠從日志中得到所有需要的信息。在實踐中經常發生日志不夠的情況，例如：1）請求出錯時不能通過日志直接來定位問題，而需要開發人員再臨時增加日志並要求請求的發送者重新發送同樣的請求才能定位問題；2）無法確定服務中的后台任務是否按照期望執行；3）無法確定服務的內存數據結構的狀態；4）無法確定服務的異常處理邏輯（如重試）是否正確執行；5）無法確定服務啟動時配置是否正確加載；
四、關於日志級別
我們通常使用的日志庫，將日志基本分為以下幾類（從低到高）： TRACE – The TRACE Level designates finer-grained informational events than the DEBUG DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application. INFO – The INFO level designates informational messages that highlight the progress of the application at coarse-grained level. WARN – The WARN level designates potentially harmful situations. ERROR – The ERROR level designates error events that might still allow the application to continue running. FATAL – The FATAL level designates very severe error events that will presumably lead the application to abort.
開發人員對於何種日志輸出為何種級別通常有自己的理解，那在實踐中，是否所有的日志級別都有必要存在，哪些操作需要記入日志，哪種錯誤應該記為WARN級別，而哪種錯誤又為ERROR級別呢？關於該問題，可以參考StackOverflow上的一個討論。
此處對貼子中的一些觀點，加上我們在平時運維過程中遇到的相關問題進行歸納：
- 一個項目各個日志級別的定義應該是清楚明確的，需要團隊的每個開發人員共同遵守；
- 即使是TRACE或者DEBUG級別的日志，也應該有一定的規范，要保證除了開發人員自己以外，包括測試人員和運維人員都可以方便地通過日志定位問題；
- 對於日志級別的分類，有以下參考： FATAL — 表示需要立即被處理的系統級錯誤。當該錯誤發生時，表示服務已經出現了某種程度的不可用，系統管理員需要立即介入。這屬於最嚴重的日志級別，因此該日志級別必須慎用，如果這種級別的日志經常出現，則該日志也失去了意義。通常情況下，一個進程的生命周期中應該只記錄一次FATAL級別的日志，即該進程遇到無法恢復的錯誤而退出時。當然，如果某個系統的子系統遇到了不可恢復的錯誤，那該子系統的調用方也可以記入FATAL級別日志，以便通過日志報警提醒系統管理員修復； ERROR — 該級別的錯誤也需要馬上被處理，但是緊急程度要低於FATAL級別。當ERROR錯誤發生時，已經影響了用戶的正常訪問。從該意義上來說，實際上ERROR錯誤和FATAL錯誤對用戶的影響是相當的。FATAL相當於服務已經掛了，而ERROR相當於好死不如賴活着，然而活着卻無法提供正常的服務，只能不斷地打印ERROR日志。特別需要注意的是，ERROR和FATAL都屬於服務器自己的異常，是需要馬上得到人工介入並處理的。而對於用戶自己操作不當，如請求參數錯誤等等，是絕對不應該記為ERROR日志的； WARN — 該日志表示系統可能出現問題，也可能沒有，這種情況如網絡的波動等。對於那些目前還不是錯誤，然而不及時處理也會變為錯誤的情況，也可以記為WARN日志，例如一個存儲系統的磁盤使用量超過閥值，或者系統中某個用戶的存儲配額快用完等等。對於WARN級別的日志，雖然不需要系統管理員馬上處理，也是需要及時查看並處理的。因此此種級別的日志也不應太多，能不打WARN級別的日志，就盡量不要打； INFO— 該種日志記錄系統的正常運行狀態，例如某個子系統的初始化，某個請求的成功執行等等。通過查看INFO級別的日志，可以很快地對系統中出現的 WARN,ERROR,FATAL錯誤進行定位。INFO日志不宜過多，通常情況下，INFO級別的日志應該不大於TRACE日志的10%； DEBUG or TRACE — 這兩種日志具體的規范應該由項目組自己定義，該級別日志的主要作用是對系統每一步的運行狀態進行精確的記錄。通過該種日志，可以查看某一個操作每一步的執 行過程，可以准確定位是何種操作，何種參數，何種順序導致了某種錯誤的發生。可以保證在不重現錯誤的情況下，也可以通過DEBUG（或TRACE）級別的日志對問題進行診斷。需要注意的是，DEBUG日志也需要規范日志格式，應該保證除了記錄日志的開發人員自己外，其他的如運維，測試人員等也可以通過 DEBUG（或TRACE）日志來定位問題；