[譯] 如何定義日誌訊息的級別？詳解日誌的 5 個級別

摘要： 作者 | aib42 譯者 | 劉嘉洋，無明 日誌級別如何劃分？ 日誌記錄是軟體開發的一個概念，幾乎所有（可能並不是所有）軟體都能從日誌記錄中獲得很多好處。在開始一個大專案時，日誌記錄通常是我第一個要搭建的子系統。關於它的好處，我可以說出一大堆，但我想把這個機會留給其他人...

作者 | aib42

譯者 | 劉嘉洋，無明

日誌級別如何劃分？

日誌記錄是軟體開發的一個概念，幾乎所有（可能並不是所有）軟體都能從日誌記錄中獲得很多好處。在開始一個大專案時，日誌記錄通常是我第一個要搭建的子系統。關於它的好處，我可以說出一大堆，但我想把這個機會留給其他人（或者哪一天我想說了再說）。現在，我想說一說日誌級別。

日誌級別是對基本的“滾動文字”式日誌記錄的一個重要補充。每條日誌訊息都會基於其重要性或嚴重程度分配到一個日誌級別。例如，“你的電腦著火了”是一個非常重要的訊息，而“無法找到配置檔案”的重要等級可能就低一些。

很多應用程式和庫會根據自己或使用者的需求定義自己的日誌級別（參考文末的“外部例子”瞭解這方面的內容）。當然，並沒有一種約定俗成的方法來做這件事，想怎麼做都是可以的，但我想要說說我認為的最重要的五個（或者六個，或者四個）日誌級別，它們應該是你自定義日誌級別的基礎。

我還將討論給這些級別分配的顏色（或者說風格），因為帶有不同顏色（或風格）的日誌更容易追蹤。如果採用了這樣的系統，就可以很容易檢查你的程式狀態，就算沒有受過訓練的人也可以輕易分辨。誰知道呢，你可能留下電腦跑去吃午飯了，如果出現問題只能找別人來檢視日誌。

Error   

錯誤已經發生了，這是毫無疑問的。錯誤的來源可能是在外部，但不管怎樣都需要看一下是怎麼回事。

可以用這個級別來表示需要引起人們注意（大多數時候需要採取行動）的錯誤。大多數難以優雅處理的異常都屬於 Error 範疇。

風格：能引起人們注意的東西。我使用紅色文字來表示（我的終端背景是黑色的）。

例子：

• 無法找到"crucial.dat"檔案

• 錯誤的處理資料： <Exception>[ 堆 棧追蹤或後續 的 除錯訊息]

• <Exception> 在連線資料庫時 在連線資料庫時

Warn   

錯誤有可能已經發生了。我只是一條日誌訊息，無法分析到底發生了什麼，或許需要其他人來看看是不是有問題。

這可能是一個平行空間裡的錯誤。它可能是當前或未來潛在問題（比如響應速度慢、連線斷開、記憶體吃緊等等）的預兆，也可能是程式在處理某些任務時出現錯誤（但可能不一會再發生類似的情況）。

風格：能引起人們注意但又不會讓人感到厭煩的風格，以免你在解決其他問題時沒空來處理這些錯誤。與 Error 的風格不同，我使用黃色的文字來表示 Warn。

例子：

• 連線關閉，在 2 秒後重新連線

• 無法找到"logging.conf"[在配置檔案中指定的]，回到預設配置

• 30 秒後嘗試連線超時

• 出現 FileVersionTooOldException 異常，回到 Version12Parser

Info   

通知使用者一個操作或狀態發生了變化。別緊張，繼續手頭的活。

Info 可以說是（一般的非技術）使用者可以接觸到的最“囉嗦”的日誌級別。如果有人把它們大聲念給你聽，你也不會介意，這是你最樂於見到的日誌記錄。它不會包含很多技術細節，可能只包含普通使用者會關注的資訊（比如檔名等）。

風格：可以和背景顏色區分開來，我使用白色文字。

例子：

• 代理初始化完畢

• 載入存檔"yeti02"

• 進入高速模式

• 當前目錄是"/tmp"

• 上行線路已建立

• 渲染完成，耗時 42.999 秒

Debug

如果你能讀懂這個級別的日誌，那麼你離程式已經很近了。

這就是為什麼你需要儲存日誌檔案，在修復 bug 時需要這些日誌。這是開發人員最關心的內容。

在轉儲程式執行流程和其他技術問題時，應該使用 Debug 級別的日誌。除非日誌太多了（在這種情況下使用 Trace 級別更合適）或者更適合使用更高級別的日誌，否則 Debug 日誌是非常值得保留的，畢竟是你自己在程式碼中記錄這些日誌的。如果和其他的 Debug 或更高級別的訊息重疊，而且沒有包含更多的資訊，那麼可以考慮將其刪除。

風格：可以很容易就忽略的風格。我使用淺灰色或米黃色文字，也就是我的終端的預設文字顏色。

例子：

• 從"/etc/octarine/octarine.conf"讀取配置

• 使用"/home/aib/.octarinerc"覆蓋配置

• 分析完成，建立圖…

• 作為”user”連線到伺服器:4242

• 傳送兩條訊息

• 渲染時故障：

• Foo 0.990 秒

• Bar 42.009 秒

Trace  

這些技術細節可能與程式不是很相干，除非你正好需要它們。

Trace 的資訊是更加具體的除錯資訊，你可能並不想看到它（除非你向儲存日誌的人賣硬碟的時候需要）。它會包含比如說呼叫了什麼函式（函式名），或是和客戶端交換了什麼網路包等內容。它善於找到一些低階錯誤，但通常你可以在除錯訊息中縮小範圍，找到問題。

大多數 Trace 訊息包含了你已經知道的資訊（Debug 訊息中說了是“登入”，所以這肯定是登入相關的資料包），所以可能對你不是很有用，除非你的假設是錯誤的。（”它會不會是登出訊息？！“、”這裡應該呼叫 foo。為什麼 foo 的 Trace 資訊沒有打印出來呢？”）

風格：使用比 Debug 訊息更加不顯眼的風格。我使用深灰色，通常用來表示禁用的顏色。

例子：

• 呼叫引數 ("baz", "bar", 42) 函式”foo”

• ->GET / HTTP/1.1\nHost: localhost\n\n

• 收到: <?xml version="1.0" encoding="UTF-8" ?>\n \n [...]

Fatal  

發生了一個致命錯誤，我們要退出了。祝你好運！

它應該比 Error 更嚴重，但使用它的頻率比 Trace 還少，所以我把它放在文章的最後。顧名思義，致命錯誤表示這種情況的發生將導致程式無法繼續執行。因此，給它們專門設定一個級別沒什麼意義。但是致命的錯誤也可能是常見和可恢復的（比如重啟就能解決），因此仍然值得一提。

風格：如果你想不出其他樣式的話，可以選擇比 Error 更顯眼的風格。我使用紫色文字，從遠處看的話和 Error 的紅色文字相近，但近看就不一樣。

例子：

• 記憶體不足

• 無法分配 65536 位元組的磁碟空間

• 許可過期，切換到免費軟體模式

外部例子

任何成熟的日誌記錄 API 或庫都應該有自己的日誌級別（可能支援使用者自定義）。以下是廣泛使用的庫，僅供參考：

• Linux 的 printk（https://en.wikipedia.org/wiki/Printk#Logging_Levels）

• Python 的 logging（https://docs.python.org/library/logging.html#logging-levels）

• Java 的 java.util.logging.Level（https://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html）或 log4j 的 org.apache.log4j.Level（https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html）

• JavaScript 的 console.level 呼叫（WHATWG 或 Node.js 的 Console API 規範）

• NLog 的日誌級別（https://github.com/nlog/nlog/wiki/Log-levels）

英文原文：https://www.aib42.net/article/five-levels-of-logging

活動推薦

微服務架構提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。企業轉型微服務，有哪些技術需要調整？業界有哪些最佳實踐？大企業在實踐微服務中如何成長？

InfoQ 主辦的第四屆 CNUTCon 全球運維技術大會，邀請了 Twitter、RIOT Games、BAT 等國內外一線專家，分享智慧時代下運維的新趨勢、新思路、新技術和實戰經驗，包括探討微服務的應用場景、企業整合架構的演進以及微服務轉型思路和技術決策考慮等內容。

目前，大會 8 折限時優惠，立減 720 元，團購更優惠！掃描下方二維碼或點選閱讀原文了解，有任何問題歡迎諮詢 Joy 小同學，電話：13269078023（微信同號）。