歡迎光臨
每天分享高質量文章

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

當我們在做系統開發時,日誌系統是繞不開的話題。作為日誌系統的最終使用者,我們會接觸不同的日誌系統,比如 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 級別的信息是不用輸出的,字串拼接方式還是要拼字串,而不定長引數方式就可以不用拼接字串了。

日誌字串處理方式 示例 特點
不定長引數 logger.INFO(“Encounter %s, but %s required”, “current_value”, “required_value”) 日誌不輸出,就不用字串拼接。運行效率高。
字串拼接 logger.INFO(“Encounter %s, but %s required”.format(“current_value”, “required_value”)) 日誌不輸出,也要拼接字串。


總結

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

Kubernetes專案實戰訓練營

Kubernetes專案實戰訓練將於2018年8月17日在深圳開課,3天時間帶你系統掌握Kubernetes本次培訓包括:Docker介紹、Docker鏡像、網絡、儲存、容器安全;Kubernetes架構、設計理念、常用物件、網絡、儲存、網絡隔離、服務發現與負載均衡;Kubernetes核心組件、Pod、插件、微服務、雲原生、Kubernetes Operator、集群災備、Helm等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂