軟體執行日誌主要的作用是記錄各項操作，登入等資訊：

簡單的日誌可以直接寫txt文字檔案，如果軟體有異常，也可以根據日誌資訊來排查、解決問題。

其實，在實際開發中，每個軟體都有自己的日誌系統，每種語言都有自己的日誌框架/模組，隨著網際網路和大資料的蓬勃發展，分散式的日誌系統，以及日誌分析系統也應用的越來越廣泛，越來越成熟。

從以下幾方面深入日誌設計

第一，誰在使用日誌

有一個問題，可能很多開發人員並沒有認真思考過，就是日誌到底是給誰用的？使用者，運維，開發人員，軟體學習愛好者？當然，答案是全部。

第二，不同的角色，有不同的視角，在不同的階段，有不同的需求，那麼日誌就應該提供不同的幫助。在做日誌模組的內容設計時，也應該站在不同的角度去考慮，要思維清晰，哪些資訊給使用者看，哪些給運維人員看，哪些給程式設計師看。要講究輕重主次，不是說詳細就一定好。

第三，日誌的等級

開發過一些系統，大體的感受是這樣的：剛開始的時候，大家都相對比較講究，日誌的等級、內容、位置都會去思考、選擇。但是隨著時間不斷的延伸，功能不斷的擴充套件，日誌逐漸變的混亂，最終淪落為亂麻一片！

日誌通常有多個等級，等級並不單單指“詳細程度”，還關係到適用場景，服務物件，目的功能等。

第四，日誌使用的幾種場景

1） 開發過程中：

日誌是一種友好、強大的記錄軟體執行時內部結構和狀態的工具，是除錯利器，當然每種語言都會提供專門的除錯工具，比如c/c++ gdb，java 的 jdb 等等。但是涉及到業務邏輯，併發，互動等情況時，還是日誌更輕巧、便捷！我一般是在對“陌生”程式碼（比如開源軟體）學習時，才會用gdb等除錯工具，強大但笨重，更適合梳理程式碼結構，而不是功能或業務結構!

2） 測試過程中：

在進行功能測試時，透過debug或trace資訊，就像看監控回放一樣，讓犯罪分子無處遁行！

3） 軟體學習時：

學習軟體時，包括軟體的架構設計、業務功能、程式碼邏輯，日誌總能提供很多線索、很多幫助。記得很久以前，看某個開源系統的程式碼，部署完以後，直接開啟trace跑一邊，系統的整體結構及內容，一目瞭然，再結合設計文件，很快就沒明白了！就那一刻，讓我深刻的記住，好的日誌系統，原來是這麼的神奇啊!

4） 正常執行：

一定不要開著 debug 跑系統，沒有意義！前提是，ERROR資訊要準確、規範，客戶只關係生死問題，再多的資訊對他們也沒有意義！