一、聊聊以前

        最近因為在搭建公司框架，日誌是必須加入的一部分。目前因為還未將公司業務做成微服務，所以暫時是在框架基礎上整合日誌框架，滿足框架專案的需要。當後面將公司業務進行微服務實戰，當落地成功的時候，日誌也將是一個微服務式的日誌系統。

        最開始工作的時候，接觸的日誌就是專案中使用Log4j來實現，後面換成logback，但都是較為簡單的列印DEBUG和ERROR 級別的日誌，然後按天輸出日誌檔案。後來通過AOP將方法的入參、介面呼叫、出參等內容列印，不止是DEBUG和ERROR級別的。這樣在看日誌檔案時，通過規定的列印格式，容易定位到某個方法，方法的入參和出參都有詳細的列印，有時候出現了問題，光通過分析日誌檔案就知道在哪裡。不像以前，當出現問題時，大部分只打印一句錯誤提示，很難具體定位到問題，只是大概的知道。這對於開發和維護，是一個不小的進步。

        但這依然不夠，這只是初步解決了問題定位的事情，對於通過日誌來分析效能，基本是沒有的。從資料探勘方面，日誌資料的採集、查詢展示等都沒有。所以一次較好的日誌整合，是需要解決這些問題的。

二、日誌的作用

        到此對日誌的作用進行了大致的歸納，主要是用於問題定位、效能分析和資料的採集挖掘。

    2.1 問題定位

        線下開發時，可以通過debug模式一步步調式，跟蹤解決問題，但當系統上線後，是不可能進行除錯的。如果在方法中將方法的輸入引數、引數值、輸出引數、輸出結果、方法中呼叫的介面、呼叫的介面引數與值都打印出來，尤其是ERROR級別的 日誌，在try-catch程式碼塊，將堆疊資訊打印出來。當出現問題後，檢視日誌檔案，就容易定位到問題了，不管是資料問題還是程式碼問題。

    2.2 效能分析

        不過是開發還是上線執行，我們要分析程式的效能問題時，通過日誌來記錄程式執行前後的時間，都是一個很好的辦法。列印INFO級別的日誌，記錄程式前後執行的時間差，進而分析程式效能，是否需要進行優化。

    2.3 資料採集挖掘

        在現在這個資訊化的時代，資料就是價值。有不少公司就會根據系統使用的情況，進行資料分析，然後賣資料分析的資訊來掙取利潤。雖然不少公司還不需要進行資料探勘，但對於很大較大公司或者資料本身有很大利用價值的，資料探勘很有必要。比如我們在網上搜索一些商品或在淘寶上買一些東西的時候，我們可能會看到有些網上會顯示剛才所瀏覽商品的推薦資訊，這就是很好的一個例子。這一般是通過埋點日誌或為使用者打標籤的方式來實現，然後進行實時資料流的分析。