普通程式設計師怎麼理解日誌系統

當我們在做系統開發時,日誌系統是繞不開的話題。作為日誌系統的最終使用者,我們會接觸不同的日誌系統,比如 log4j、 logback 和 slf4j 等等,還會接觸到日誌系統的各種概念,比如 Formatter、Appender 和 Priority 等。這些日誌系統有什麼區別,這些概念又該怎麼理解呢?

普通程序員怎麼理解日誌系統

今天我們就聊下:我們普通程序員,也就是日誌系統最終使用者,可以怎麼理解日誌系統。

Logging 系統的雛型

讓我們回到計算機世界的遠古時期或者我們剛剛接觸計算機世界的時期,那個時候我們有兩種調試程序的辦法:1)單步調試,一步步地跟蹤,查看代碼中變量的值。2) 是 printf 大法 —— 在特定的地方打印日誌, 通過日誌的輸出,幫助快速定位。

單步調試方法費時費力,但能準確定位問題。printf 大法簡單粗暴,需要嘗試,大部分情況能快速找到問題。單步調試和 printf 方法搭配使用,相得益彰。但是單步調試止步於 gdb 等調試工具,而 printf 大法最終發展出了一系列的日誌系統。原因就在於單步調試在程序員調試才能用,而 printf 大法可以在調試和生產線上都能用,並且輸出的日誌被各方面的人利用和解讀。

什麼時候打印日誌是個問題 —— Level

printf 大法是很簡陋的。在調試過程中,有可能日誌打到很細粒度,比如每條數據的第三個字段是什麼都打印出來了,但是真正運行又要把這些細粒度的日誌刪除。等到下次調試,我們又要知道每條數據的第三個字段是什麼了。為此,我們希望日誌打印是智能:調試或者線上出問題的時候,各種細粒度的日誌全部打印出來,正常運行的時候輸出一些最簡單的信息就可以了。

針對這個問題,日誌系統引入日誌級別(Level)的辦法解決。引入日誌級別的概念之後,我們編程時打印日誌,需要指明這條日誌的級別。由於日誌級別是最重要的參數,現在的日誌系統都是直接通過使用不同的函數來指明級別的,包括 logger.TRACE、logger.DEGUB、logger.INFO、logger.WARN、logger.ERROR、logger.FATAL。其中級別的對比是 TRACE < DEBUG < INFO

我們編程時 DEBUG 或者 TRACE 級別打出細粒度的信息,比如每條數據的樣子。當我們調試時或者線上有問題時,我們將程序的當前日誌級別設置成 TRACE 或者 DEBUG,從而將細粒度的信息打出來。而正常運行時,我們將當前日誌級別設置成 INFO 或者 WARN 級別,從而忽略細粒度的信息,降低 IO 操作和提升系統性能。

普通程序員怎麼理解日誌系統

打印日誌到哪裡是還是一個問題 —— Appender

有了 Level,我們可以隨心意寫點 log 了,只要控制好日誌級別就行。默認情況下,我們的日誌是打印到 Console 裡,我們直接人眼看。隨著時間的推移,情況變得複雜起來。比如我們需要將日誌打入文件裡,方便以後查看。即使日誌打到文件,我們也需要登錄到機器才能查看,我們需要在發生錯誤時收到郵件或者短信。為了滿足這些需求,我們在日誌系統中加入 Appender 部件。Appender 部件負責將日誌寫的不同的目的。

普通程序員怎麼理解日誌系統

比如下圖就是 Log4j 的日誌配置示例。這個示例會打印出所有的信息,每次大小超過size,則這size大小的日誌會自動存入按年份-月份建立的文件夾下面並進行壓縮,作為存檔。

普通程序員怎麼理解日誌系統

日誌系統可以自定多種 Appender,人們基於這套邏輯發明了一套日誌收集和實時檢索的系統,也稱之為日誌系統。在這裡為了區別,我們將日誌收集和檢索系統稱之為日誌收集檢索系統。日誌收集檢索系統一般有 Kafka 流、實時處理組件 Spark Streaming 或者 Storm、實時檢索系統 ElasticSearch 組成。後臺系統通過日誌系統的 Appender 組件將日誌打到 Kafka 流,然後 Spark Streaming 或者 Storm 處理流數據並將之寫入 ElasticSearch 檢索系統。這樣開發和運維就可以在 ElasticSearch 提供的 Web 查看可視化的日誌了。日誌收集檢索系統的主要好處是,1) 日誌集中管理,不需要登錄到不同機器;2) 提供可視化的日誌查看;3) 提供基於日誌的監控、監測服務等。

普通程序員怎麼理解日誌系統

目前最有名的日誌收集檢索系統應該是上圖的 Splunk 了。

日誌什麼樣也是個問題 —— Formatter

有了日誌的 Level 和 Appender,我們還需要解決日誌樣式的問題。一般情況,我們希望的日誌格式包括:Level,函數名,文件名和打日誌的代碼行數。這可以通過日誌系統的 Formatter 組件來實現的。下圖是一個 Python 自定義的Formatter。

import logging

def AltCustomFormatter(logging.Formatter):

def __init__(self, fmt=None, datefmt=None):

super(AltCustomFormatter, self).__init__(fmt, datefmt)

def format(self, record):

# 如果你添加了多個handler,你會發現我們的定製消息被重複了多次,

# 我們在record裡設置一個marker來避免

if record.levelno > logging.INFO and not hasattr(record, 'is_custom'):

record.msg = "[%s, %s, %s] %s" % (record.filename, record.lineno, record.funcName, record.msg)

record.is_custom = True

return super(AltCustomFormatter, self).format(record)

在引入 Level、Formater 和 Appender 概念之後,整個日誌系統的架子算是搭起來了,如下圖所示。作為一個普通程序員,可以安心使用這個日誌系統了。

普通程序員怎麼理解日誌系統

高效地打印日誌是另外一個問題 —— Efficient

但是作為一個有追求的普通程序,我們想知道大規模系統的極限環境中,日誌系統能不能撐得住。答案嘛,是按照上面設計的日誌系統是撐不住的。因為大規模系統的極限環境,實時要求高,不能忍受寫文件或者寫網絡的延遲。怎麼辦呢?有請對付 IO 延遲利器 —— Buffer。基於 Buffer,並考慮到 Buffer 所帶來的線程同步的問題, 人們設計了下面的方案。在這個方案中,每個線程生成一個 Buffer,然後寫線程輪詢從 Buffer 讀入信息,並寫目的地。在這套方案中,寫日誌並不會導致服務延遲。

普通程序員怎麼理解日誌系統

除了架構上的設計,還有一些小 trick 提高性能。比如我們在 log4j 官方 API 查到醜陋的 INFO 函數們。Java 語言不支持不定長參數的情況下,log4j 強行搞一個支持不定長的 INFO 函數,就只能靠著寫不同的函數重載,最終也只支持 9 個參數。

普通程序員怎麼理解日誌系統

但這些醜陋的 INFO 是有意義的。這些醜陋的 INFO 是為了能夠實現下表中不定長參數的方式。這種不定長參數方式相比字符串拼接方式的區別在哪裡呢? 當前級別是 ERROR 時,INFO 級別的信息是不用輸出的,字符串拼接方式還是要拼字符串,而不定長參數方式就可以不用拼接字符串了。

普通程序員怎麼理解日誌系統

總結

上面就是日誌系統基本概念的介紹了。從遠古時期的 printf 大法到現代化的日誌系統,為了讓我們普通程序員也能直觀地瞭解系統運行狀態,大神們引入了 Level, Appender, Formatter 等日誌系統核心概念,開發了 log4j, logback 和 tinylog 等著名日誌系統。


分享到:


相關文章: