最近因為在搭建公司框架，日誌是必須加入的一部分。目前因為還未將公司業務做成微服務，所以暫時是在框架基礎上整合日誌框架，滿足框架專案的需要。當後面將公司業務進行微服務實戰，當落地成功的時候，日誌也將是乙個微服務式的日誌系統。
最開始工作的時候，接觸的日誌就是專案中使用log4j來實現，後面換成logback，但都是較為簡單的列印debug和error 級別的日誌，然後按天輸出日誌檔案。後來通過aop將方法的入參、介面呼叫、出參等內容列印，不止是debug和error級別的。這樣在看日誌檔案時，通過規定的列印格式，容易定位到某個方法，方法的入參和出參都有詳細的列印，有時候出現了問題，光通過分析日誌檔案就知道在**。不像以前，當出現問題時，大部分只列印一句錯誤提示，很難具體定位到問題，只是大概的知道。這對於開發和維護，是乙個不小的進步。
但這依然不夠，這只是初步解決了問題定位的事情，對於通過日誌來分析效能，基本是沒有的。從資料探勘方面，日誌資料的採集、查詢展示等都沒有。所以一次較好的日誌整合，是需要解決這些問題的。
到此對日誌的作用進行了大致的歸納，主要是用於問題定位、效能分析和資料的採集挖掘。
2.1 問題定位
線下開發時，可以通過debug模式一步步調式，跟蹤解決問題，但當系統上線後，是不可能進行除錯的。如果在方法中將方法的輸入引數、引數值、輸出引數、輸出結果、方法中呼叫的介面、呼叫的介面引數與值都列印出來，尤其是error級別的 日誌，在try-catch**塊，將堆疊資訊列印出來。當出現問題後，檢視日誌檔案，就容易定位到問題了，不管是資料問題還是**問題。
2.2 效能分析
不過是開發還是上線執行，我們要分析程式的效能問題時，通過日誌來記錄程式執行前後的時間，都是乙個很好的辦法。列印info級別的日誌，記錄程式前後執行的時間差，進而分析程式效能，是否需要進行優化。
2.3 資料採集挖掘
在現在這個資訊化的時代，資料就是價值。有不少公司就會根據系統使用的情況，進行資料分析，然後賣資料分析的資訊來掙取利潤。雖然不少公司還不需要進行資料探勘，但對於很大較大公司或者資料本身有很大利用價值的，資料探勘很有必要。比如我們在網上搜尋一些商品或在**上買一些東西的時候，我們可能會看到有些網上會顯示剛才所瀏覽商品的推薦資訊，這就是很好的乙個例子。這一般是通過埋點日誌或為使用者打標籤的方式來實現，然後進行實時資料流的分析。
Linux檔案系統與日誌
lsof檢視系統裡所有程序的檔案開啟數 ulimts n linux檔案系統與日誌 root wangna ls lhi total 28k 265490 drwxr xr x 2 root root 4.0k oct 26 22 01 aa 265485 rw 1 root root 1.2k o...
Linux 檔案系統與日誌分析
檔案資料報括元資訊與實際資料 檔案儲存在硬碟上，硬碟最小儲存單位事 扇區 每個扇區儲存512位元組 block 塊 連續的八個扇區組成乙個block 是檔案訪問的最小單位 inode 索引節點 中文譯名為 索引節點 也叫i節點 用於儲存檔案元資訊 inode包含檔案的元資訊 檔案的位元組數 檔案擁有...
find操作與日誌清理
周五有同事問起find命令中 mtime n mtime n以及 mtime n的用法區別，當時雖然記得這裡n是n個24個小時的意思，也是對所有這幾個屬性詳細的用法卻一知半解，索性週末仔細google並且實踐了一番，終於理清楚了個中乾坤。find atime n find ctimen find m...