應用層日誌記錄
本文簡單探討一下在應用系統開發過程中記錄日誌需要注意的一些問題。
應用層日誌作用
總的來說,日誌的根本作用是記錄必要的程式執行過程和狀態,以便於以後追溯和參考。
跟蹤除錯
在很多特殊環境下,不能使用單步除錯等方法實時知道程式的執行情況,這時就需要使用日誌來記錄程式執行情況。
幫助開發人員或者測試人員知道程式的執行情況,進而修改程式和解決BUG等。
跟蹤排查錯誤
當錯誤發生時,我們需要知道當時的程式執行情況,比如執行到那一步,執行時的個變數狀態等。
我們需要通過對日誌追蹤,獲取該錯誤發生時的具體執行環境,只有通過這些資訊,我們才能分析出錯誤出現的原因,以及如何修正錯誤。
備案
另外,對於一些特別敏感資訊的操作,比如設計金錢的操作,需要記錄所有的流水日誌,以供以後對賬等參考。
而且這些日誌也能夠在系統出現問題時,恢復資料,降低經濟損失
日誌的分類
可以根據日誌的用途對日誌進行分類,也可以根據日誌的必要性或者等級來進行分類,常用的分級方法如下:
TRACE
級:儘量詳細的資訊,以便於開發過程中觀察,在開發完上線後應該被遮蔽,DEBUG
級:記錄用於除錯過程中的一些必要資訊,在開發完上線後應該被遮蔽INFO
級:記錄程式執行的關鍵步驟,在以後具有參考價值,在線上系統中有保留的價值WARN
級:屬於輕微的“警告”,記錄程式出現的異常情況,但是不影響正常使用ERROR
級:屬於“普通的錯誤”,在程式可以控制的範圍內,不會造成連鎖影響或巨大影響FATAL
級:屬於“致命錯誤”,可導致整個系統或者一系列功能無法使用,甚至導致系統癱瘓、關閉EMERG
級:屬於“災難”級,導致整個系統崩潰
其中TRACE
級和DEBUG
級的日誌,只用於開發除錯過程中,記錄資訊所在空間大,應該在開發完成後關閉。
在很多系統中可以不用這麼細緻的分類,但是一個完善的日誌系統最起碼包含三個以上基本基本的日誌:
如可以只包含DEBUG
級,INFO
級,ERROR
級。
日誌系統設計
在一個系統設計的前期,就應該規劃好完善的日誌記錄方案,因為日誌記錄伴隨在系統開發的沒一個部分。
如果指靠在系統完成後在新增必要的日誌記錄是不現實的。
明確日誌記錄的目的
需要明確記錄的日誌是什麼樣的人使用:
- 開發人員需要使用的資訊:
DEBUG
級等 - 運維人員需要知道的資訊:
ERROR
- 系統使用人員需要知道的資訊:日誌的輸出和反饋等
- 系統審計人員需要知道的資訊:關鍵業務
INFO
級日誌
針對不同的使用人員,我們還應該規劃合適的日誌記錄形式。
日誌格式
隨著系統的執行,日誌肯定是不斷增長的,為了以後能夠快速找到需要的日誌,需要注意一下幾點:
- 善於日誌分級,不濫用日誌,不關鍵的日誌應該在線上系統遮蔽
- 為不同的日誌總類新增標籤,以便快速查詢相同型別日誌
- 按照日期分級,一方面便於日誌轉存,另外也助於快速定位日誌
- 日誌應該有相對標準的格式,比如json,序列化等,以便於查詢關鍵資訊
總的來說,日誌的記錄一定是為了以後的追蹤和讀取,應充分考慮到以後獲取日誌的情形。
日誌記錄應注意的問題
- 效能損耗:日誌記錄不應過於頻繁,應考慮到日誌記錄到來的系統性能損耗
- 安全性:不在日誌中記錄涉及安全的敏感資訊,如在日誌中記錄使用者密碼是絕對禁止的
- 時效性:應該定期清理沒有參考意義的日誌,避免日誌積累過多佔用系統儲存空間
日誌的儲存方式
常見的日誌儲存系統如下:
- 系統自帶檔案系統
- 分散式檔案儲存系統
- Mysql資料庫
- Mongodb資料庫
無論是哪一種儲存方式,都要考慮到以後查詢日誌的遍歷性,日誌儲存的效能損害,日誌的用途等。
在一些需要對日誌進行大資料分析的場景,還需要把日誌轉存到HDFS等專門的環境中。
實際應用
在不同的業務場景,需要記錄的日誌內容是千差萬別的,但是它們的本質一定是為了之後的追溯使用。
在想Java,PHP等實際語言的開發中,可以為一個系統封裝一個統一的入口Log日誌記錄類。
在這個Log類中規定統一的日誌格式以及各種不同的日誌記錄級別,還可以在這個類中附加額外的資訊等。
絕對避免在系統中隨意記錄日誌。