使用Log4j進行日誌記錄

1996 年初，歐洲安全電子市場(EU SEMPER)專案組決定編寫自己的日誌記錄API，後來這個API演變成了Log4j。Log4j是一個開放原始碼專案，一個非常流行的Java日誌記錄包。它允許開發者向程式碼中插入日誌記錄語句，還允許在不修改應用程式原始碼的情況下修改日誌記錄的行為。幾乎每一個專案都會使用日誌記錄，但是由於日誌記錄不是專案的核心，因此受重視的程度一般不是很高。我們認為使用日誌記錄是一件非常嚴肅的事情，而且做好使用日誌記錄的規劃比單純記錄日誌本身更加重要。本文將比較全面的闡述Log4j的設計原理和使用方法。

日誌記錄 日誌記錄記錄的是應用程式執行的軌跡。我們可以透過檢視這些軌跡來除錯應用程式，這可能也是日誌記錄最為流行的用法了。但是我們必須意識到規劃良好的日誌記錄中還含有豐富的資訊，透過手工的方式或藉助一些工具(大多數時候需要自己來書寫這些工具)來分析挖掘這些資訊。例如，如果我們在規劃中指出必須記錄使用者的每一次操作，記錄的樣式為 [日誌資訊]-[操作開始的時間]-[日誌級別]-[日誌類別]-[使用者名稱]-[操作名]-[訊息]，這只是我們假設的一種樣式，實際的日誌中一般會含有比這更加豐富的資訊。為了更好的理解，我們根據該樣式構造了一些日誌記錄(其中日誌類別org.fulin.Main、org.fulin.Parser 和org.fulin.UserOperator使用了不同的樣式)：
[日誌資訊]-[2006-07-30 08:54:20]-[INFO]-[org.fulin.Main]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:55:20]-[INFO]-[org.fulin.UserOperator]
-[User1]-[查詢報表1]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:55:30]-[INFO]-[org.fulin.UserOperator]
-[User1]-[查詢報表2]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:56:01]-[INFO]-[org.fulin.Parser]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:57:26]-[INFO]-[org.fulin.UserOperator]
-[User2]-[新增使用者User3]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:58:20]-[INFO]-[org.fulin.UserOperator]-[User1]
-[查詢報表3]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:59:38]-[INFO]-[org.fulin.UserOperator]-[User3]-[查詢報表1]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:59:39]-[INFO]-[org.fulin.UserOperator]-[User2]-[退出系統]-[具體的訊息]從上面的日誌記錄中我們很容易抽取出某一使用者的操作列表，如對於使用者User1我們的結果為：
[日誌資訊]-[2006-07-30 08:55:20]-[INFO]-[org.fulin.UserOperator]-[User1]-[查詢報表1]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:55:30]-[INFO]-[org.fulin.UserOperator]-[User1]-[查詢報表2]-[具體的訊息]
[日誌資訊]-[2006-07-30 08:58:20]-[INFO]-[org.fulin.UserOperator]-[User1]-[查詢報表3]-[具體的訊息]這樣我們就得到了某一時間段中User1的操作列表，可以利用這一列表來進行安全分析。我們還可以從另外的角度來分析上面的日誌記錄，如我們很容易統計出操作(日誌類別為org.fulin.UserOperator)發生的總次數(6 次)，其中操作[查詢報表1]為2次，[查詢報表2]為1次，[查詢報表3]為1次，[新增使用者User3]為1次，[退出系統]為1次。這樣我們就可以得出系統中的那些操作使用者使用的比較頻繁。以上我們從兩個角度對日記記錄中的資訊進行了簡單的挖掘，實際中待挖掘的方面要豐富的多，這取決於您的意圖和您的想象力。這裡我們還要特別強調一下：所有這一切都需要有使用日誌記錄的良好規劃。如果規劃不好(即日誌記錄沒有規律性)，那麼我們挖掘時的任務就會非常繁重或者使挖掘成為一個不可能的任務。文章到了這裡我們要來描述日誌記錄的最為流行的用法了，即除錯應用程式。我們在除錯應用程式時一般會使用兩種方法，除了日誌記錄之外，還有debugger偵錯程式。我們不想把他們放到一起來描述，因為這是兩個完全不同的問題，雖然他們都用來除錯應用程式。使用debugger偵錯程式我們可以清楚的知道引發錯誤的上下文及其相關資訊，也可以使用單步執行、設定斷點、檢查變數以及暫掛和恢復執行緒等等比較高階的能力，但是儘管這樣它也不能替代日誌記錄，同樣日誌記錄也不能替代debugger偵錯程式。我們要結合使用這兩種方法，不同的場景使用不同的方法會有更好的效果。我們認為使用日誌記錄來除錯應用程也應該充分考慮軟體的開發週期。這裡我們只考慮軟體開發週期中的與日誌記錄有關的兩個階段：
* 開發階段，用來記錄應用程式的方方面面和各種細節，非常詳細，使得一看到它就知道那裡出了問題，出了什麼樣的問題。
* 出品階段，要能夠記錄各種級別的錯誤和警告，同時也要適度記錄應用程式正常執行的關鍵資訊，這些資訊可以給相關人員(開發人員、測試人員、使用者等)極大的信心，使他們可以毫不猶豫的告訴您–瞧我們的軟體在正常的執行。如一個好的web伺服器的啟動日誌記錄不僅要包含錯誤和警告，還要包含伺服器正在啟動，正在載入某某元件等等，最後還要提示啟動是成功還是失敗。閱讀到這裡我們就應該著手實現我們的日誌記錄了。比較幸運的是我們有好多日誌記錄軟體包可選，這就使我們不必關心日誌記錄的細節，只要把主要的精力放到日誌記錄的規劃上就好了。我們選擇的是Log4j，文章的餘下部分將主要介紹這個Java日誌記錄軟體包。

log4j的特性
log4j的特性列表：
* 在執行速度方面進行了最佳化
* 使用基於名稱的日誌(logger)層次結構
* 是fail-stop的
* 是執行緒安全的
* 不受限於預定義的實用工具集
* 可以在執行時使用property和xml兩種格式的檔案來配置日誌記錄的行為
* 在一開始就設計為能夠處理Java異常
* 能夠定向輸出到檔案(file)、控制檯(console)、java.io.OutputStream、java.io.Writer、遠端伺服器、遠端Unix Syslog守護者、遠端JMS監聽者、NT EventLog或者傳送e-mail
* 使用DEBUG、INFO、WARN、ERROR和FATAL五5個級別
* 可以容易的改變日誌記錄的佈局(Layout)
* 輸出日誌記錄的目的地和寫策略可以透過實現Appender介面來改變
* 支援為每個日誌(logger)附加多個目的地(appender)
* 提供國際化支援

log4j的設計原理Log4j有三個主要的元件：Logger、Appender和Layout。這三個元件相互配合使得我們可以獲得非常強大的日誌記錄的能力。
Logger
Logger的名稱是區分大小寫的，依據名稱可以確定其層次結構(即父子關係)，規則如下：
* 如果Logger A的名稱後跟一個點(.)是Logger B的名稱的字首就認為Logger A是Logger B的祖先。
* 如果在Logger A和Logger B之間，Logger B沒有任何其它的祖先就認為Logger A是Logger B的父親。在Logger的層次結構的最頂層是root logger，它會永遠存在，而且不能透過名字取到。
Loger x.y是Logger x.y.z的祖先，因為x.y.是x.y.z的字首，這符合規則的前一條。另外在Logger x.y和Logger x.y.z之間，Logger x.y.z沒有其它的祖先，因此Logger x.y是Logger x.y.z的父親，這符合規則的後一條。這樣我們依據上面的規則就可以構造出如圖1所示的Logger的層次結構。每一個Logger都有一個Level，根據該Level的值Logger決定是否處理對應的日誌請求。如果Level沒有被設定，可以從祖先那裡繼承。如果Logger C沒有被設定Level，那麼它將沿著它的層次結構向上查詢,如果找到就繼承並結束，否則會一直查詢到root logger結束。因為log4j在設計時保證root […]

[@more@]