2011-09-20 73 views
12

這可能是一個純粹主觀的問題(如果沒有組織試圖將其標準化),但我的團隊在這方面比您想象的更努力。Commons日誌記錄優先最佳實踐

我們使用Apache Commons Logging作爲我們的日誌記錄界面,而且我們的開發團隊通常使用優先級不一致。例如,有些開發人員將任何捕獲的異常記錄爲致命(log.fatal(message)),即使流程能夠處理錯誤,而其他人員只有在某些事件導致程序因某種原因必須停止執行時纔會致命。

我想知道其他團隊如何定義每個優先級。有沒有人在明確試圖爲此定義最佳實踐的公司工作?雅加達對此有所權衡嗎?

我的目標是向我的整個團隊發送每個優先級的簡單建議,以便我們能夠以一致的方式更有效地處理難以處理的應用程序日誌記錄。

+0

我在這裏真正想找的是一個普遍接受的最佳實踐指南,可以跨組織使用。一個可靠的網絡資源將是偉大的。 – smp7d

+0

我認爲你有三個大致相同的答案這一事實表明這**是**普遍接受的最佳做法?我認爲你可能會爲你的團隊尋找100%的「論證證明」,但也許這裏的意見分量可能足夠了? – Brian

+0

好點。在我的組織內部可能有足夠的意見,但是我想知道各個組織是否有建議的標準。我們使用的許多軟件包都使用公共日誌記錄,並且很高興知道它們應該與某些建議保持一致。這可能太多問,也許這就是爲什麼我沒有在任何地方找到它。 – smp7d

回答

9

下面是我們用什麼(我會說一些其他的方面):

  • FATAL:錯誤危及系統的一致性,並可能要求立即關閉/重新啓動 - 很少用手動
  • 錯誤:不應拋出的異常,並且表示系統中的錯誤(通常不會被捕獲到某個點的所有異常)
  • WARN:可能發生但可能會導致邏輯/使用錯誤 - 我們決定是否跟蹤這些錯誤
  • 信息:無論你需要在日誌中有什麼,例如用戶目前正在做什麼(在我們的Web應用程序中:用戶正在瀏覽的頁面等)
  • 調試:僅調試消息,如時間等,通常在日誌中關閉
  • TRACE:我們不使用這一點,你可以用它來更具體的調試信息

在某些情況下,我們用日誌消息的錯誤開始,爲了得到通知時,一些我們通常不喜歡發生的發生。稍後,如果我們確定無法刪除該錯誤的來源,我們會處理它並將日誌級別更改爲WARN。

請注意,我們的測試和生產系統設置爲發送致命和錯誤的電子郵件。因此,我們不必手動檢查這些日誌文件,但只需檢查一個電子郵件收件箱。

希望有所幫助。

編輯:你已經看到了Apache Commons Logging best pratices

+0

是的,那個鏈接是我需要的。我無法相信我沒有發現我自己......謝謝。對於任何有興趣的人,請查看該鏈接中的「消息優先級/級別」。 – smp7d

6

我一直以此爲指導;我使用Log4j比Commons Logging更多,但這可能仍然有幫助:

DEBUG - 用於真正的調試級別信息;將不會在生產或運輸產品中看到,因爲INFO將是最低級別;捕獲時間的好,事件的發生次數等。

信息 - 生產/出貨使用的最低水平;記錄可能對法醫調查有用的數據並確認成功的結果(「在DB中保存999項」);這裏所有的信息必須是這樣的,你會與最終用戶/客戶看到它,併發送你就OK,如果需要的話

WARN(沒有祕密,沒有褻瀆!) - 不是一個錯誤水平等,但有助於瞭解系統可能進入狡猾的領域,例如業務邏輯的東西,如「訂購產品數量< 0」,這表明某處存在缺陷,但不是系統異常;我傾向於不使用它那麼多,說實話,找東西更趨於自然擬合到INFO或ERROR

錯誤 - 用這個異常(除非有一個很好的理由,以減少WARN或者INFO);記錄完整的堆棧跟蹤以及重要的變量值,但不能診斷;只能使用應用程序/系統錯誤,不壞的業務邏輯的情況下

FATAL - 僅使用這麼高的嚴重性的錯誤,它確實可以防止應用程序無法啓動/繼續

另外 - 檢查你的日誌通常,在DEBUG和INFO級別都處於活動狀態的情況下,您希望能夠遵循一個好的敘述,並且容易找到突出的事件,並確保您沒有做任何過於冗長的事情,從而降低可讀性。

此外,請確保您使用的模式能夠爲時間戳,源代碼類和嚴重程度等方面帶來整齊的列 - 同樣,它可以大量提高可讀性。

+0

那麼說。你有沒有使用TRACE? – cherouvim

+0

我沒有,但只是因爲我使用log4j沒有跟蹤級別;否則我認爲這將是非常有用的 – Brian

+2

TRACE確實存在。 http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#TRACE – cherouvim

2

我採取

  • 致命:該程序是在不能被處理,並且必須被終止(自動地或由用戶)的狀態。
  • 錯誤:程序的操作失敗,用戶可檢測到(更改未保存/文件無法讀取),但程序仍然可以工作(嘗試加載另一個文件)。
  • 警告:有些東西沒有按計劃進行,但用戶沒有注意到它(服務器沒有應答ping;可能需要該服務器時會導致錯誤/致命)
  • 信息:用戶操作/主要程序動作(文件加載,自動備份存儲)。
  • 調試:跟蹤信息。哪一部分的程序正在運行,這是參數的值
1

這是我公司建議:

TRACE - 消息在開發過程中可能唯一有用的,並可能產生太多經常適用於生產。例如,如果我在內部循環中記錄了 中間值,我會使用TRACE。

調試 - 消息用於記錄服務器正常運行中的各個步驟。通常這些將針對開發人員而不是操作人員。

INFO - 我們期望在生產環境中記錄的積極或中性性質的消息。應該對操作人員有意義。

警告 - 消息指示可能危及服務器以準確和及時的方式響應請求的能力的情況。

錯誤 - 指示意外行爲或狀況的消息。

致命 - 消息指示意外的行爲或狀況,導致應用程序進程繼續運行變得不可能或危險。

我們預計生產中的日誌將被設置爲INFO,並且我們期望它們被開發人員以外的人閱讀。日誌消息的風格是一個整體的其他談話...

0

我用一個簡單的方法:

  • DEBUG:在生產熄滅,因此主要使用由開發商來登錄某些查詢,時序,參數值等

  • 信息:登錄的一切,讓你知道現在回想起來一切解釋如何您的結果進行計算,並且使您可以修復bug

  • 錯誤:一切都需要某人(開發者/操作)注意

我不使用WARN,因爲沒有人曾經濾波器WARN消息的所有日誌文件。如果它很重要,那麼它是錯誤的(並且有人必須關心它),如果不是的話,它是INFO(並且沒有人對它感興趣直到有問題)。 FATAL相同。我也不使用TRACE。我在開發過程中需要了解的一切都是DEBUG。

1

如果您正在尋找簡單建議,行業支持,爲什麼不看看行業簡單的實施/文檔?

我們使用logback/log4j API作爲logging level guide =>這使得它簡單/記錄/被業界支持:

  • 級別ALL具有最低的等級,旨在開啓所有記錄。

  • 等級DEBUG指定對於調試應用程序最有用的細粒度信息事件。

  • 級別錯誤指示可能仍允許應用程序繼續運行的錯誤事件。

  • 等級致命錯誤表示非常嚴重的錯誤事件,可能導致應用程序中止。

  • 等級信息指定以粗粒度級別突出顯示應用程序進度的信息性消息。

  • 級別關閉具有最高可能排名,旨在關閉日誌記錄。

  • 級別TRACE指定細粒度信息事件比DEBUG

  • 級別WARN表示可能有害的情況。