關于日志記錄的一些感想

剛剛我們組的産品經理和法務部的同僚找我，說公司正在和某個客戶打官司。為了反駁客戶的某一些說辭，需要我幫忙找一找某個客戶的某一份合同檔案的記錄檔。也就是：

需要确定就是這個客戶在某一天的某個時間進入我們的某個系統進行了「合同簽署」這個操作

事後我想了一下，裡面确實有很多我們平時設計系統，實作系統功能時需要注意的一些點，是以我基于我目前的眼界和經驗，總結一下，希望對大家有所幫助，争取不浪費讀者朋友們的寶貴的時間。

我覺的最基本的但是也是最重要的事情就是日志的輸出。因為沒有日志輸出也就沒有下面要說的「存儲收集」和「查詢展示」了。

我不确定讀者所在的格式是否有日志規範，我覺的有一份好的日志規範還是很重要的，但是最重要的還是有效的執行下去。

java裡存在衆多的開源日志架構，比如：<code>slf4j, logback, log4j, jcl(apache common logging), jul(jdk自帶的java.util.logging)</code>。

也許你們并不需要切換日志架構的實作這個功能，但往往我們的項目都會依賴很多的第三方的開源架構，而這些第三方的開源架構有可能采用不同的日志架構，而不同的日志架構可能需要的配置也不盡相同，不同的配置又可能導緻日志輸出到不同的位置，這就很不友善我們後續的日志收集和管理。

為了友善我們将日志統一收集和管理起來，我們可以使用slf4j的擴充卡将第三方庫中各種日志的實作接管，接管之後就可以統一配置這些第三方庫中使用的日志了。

日志有：<code>trace， debug， info， warn， error， fatal</code>這幾個隔離級别。

一定要用好日志級别。我的習慣和了解如下：

trace 一般情況下我會用來記錄業務日志

warn 我一般會在出現了異常情況，但是又在業務的合理範圍之類的時候我會适應warn

info 一般非常重要的日志，關鍵系統參數的回顯、背景服務的初始化狀态、需要開發者确認的資訊我都會适應info這個級别。

debug 詳細的記錄流程的關鍵路徑，這種級别的日志是為了友善我們開發和調試系統功能的，在生産環境預設是關閉的。

error 系統出現了異常情況的時候時候

fatal 說實話我沒有用過，我都用error代替了。

統一定義日志檔案的名稱，日志内容的格式，可以極大的友善後續日志的收集和解析工作。

大的指導原則是：

info 及以上的系統日志統一輸出到console

業務日志、系統日志、異常日志分别輸出到不同的檔案中，更加友善異常問題的排查

根據系統使用場景不同，對日志的側重點就不一樣。導緻這些不同側重點的原因可能有：

排查問題的需要

來自審計部門的需要

資料挖掘的需要

為了避免糾紛（這個挺重要的）

。。。。。

比如我們做兩個系統，一個是「權限管理系統」，另外一個是「資訊通知系統」，幹一些發郵件，短信等的消息。前者我們需要詳細的記錄檔，記錄「誰在某年某月某日為某人配置設定了什麼權限」，因為審計部門需要。而後者即便發送出錯了，重試或者忽略都可以考慮，甚至都不需要記錄任何的日志。

系統可能有點大，系統中的一些子產品、重要接口對日志的要求也很高，比如我文章開頭舉得例子，代理商說合同我沒有簽訂，死不承認。這個時候怎麼辦呢，隻能找當時的系統日志來說了。假設當時系統沒有輸出日志，或者輸出的日志資訊對于打官司一點用都沒有，那麼就比較尴尬了。

我不确定大家是否遇到過下面的情況：*排查問題時，發現那塊出現錯誤的地方有日志輸出，但是輸出的日志對于排查問題一點用都沒有**，每當出現這種情況的時候我都想罵人。

好的日志需要有哪些内容呢？

發生時間

出現問題的線程

日志級别

出現問題的類檔案，類的哪一行，異常棧

程式入參

相應的程式員的注釋等

重要api，系統間互動等地方是加日志，監控的重點位置

臨時想到一個，就是日志輸出時，盡量輸出一些「不可變的或者唯一」的資訊。舉個例子：

為了在日志中記錄某個使用者的行為，但是使用者的身份可以用自己生成的userid，手機号，身份證号，昵稱等。

考慮到昵稱和手機号可能會變化，是以使用這兩個來在日志中表示使用者身份可能就不合适了。也許查詢一年前的日志是，但是記錄的手機号已經不屬于這個使用者了。

關于日志的存儲方式，無論是使用mysql，elasticsearch，hdfs等，都已經很有多的文章和教程了，我就不詳細提了。

主要需要注意點是：日志的存儲時需要了解清楚日志存儲的作用，然後按照某些次元來組織，比如時間，比如操作人等，友善後續聚合、查詢，分析等。

另外還需要注意的是日志的存儲時間，如果你們的日志是永久存儲的話，當我沒說哈。一般公司會為了節省存儲空間成本，會定期删除一些日志，這個時候需要根據日志的重要性确定是否永久存儲，或者定期删除的時間長短。