一文詳解 C-- 日誌框架

1

日誌框架

 日誌框架

一個經過專門設計的實用程序,用於規範應用程序的日誌記錄過程。

日誌框架可以自己編寫(需要一定的能力哦),也可以由第三方(例如:log4cplus)提供。對於不同的日誌框架,各自在實現方式上也有所不同。

雖然可以簡單地 “標準化” 日誌(例如:調用文件系統 API,將信息寫入名爲 log.txt 的文件),但是要成爲一個嚴格意義上的框架,必須要超越標準化。也就是說,日誌框架必須通過處理日誌記錄來標準化解決方案,從而暴露一個標準的 API。

沒明白?那就再具體一些,設想一個日誌框架,封裝了三個主要部分:

當想要捕獲程序的運行時信息時,首先要發出要記錄的信息。然後格式化這些信息,最後決定將它輸出到哪裏。一般情況下,會輸出到文件中,但是也可以將其輸出到控制檯、數據庫,或者任何能夠接收數據的地方。

如果有一系列代碼,能夠解決這些問題,那麼就可以被看作是一個日誌框架。

2

爲什麼不是 cout

使用日誌,只爲成爲更好的攻城獅。

也許有人會問:既然 C++ 中有 cout,爲什麼還要使用日誌呢?

無法否認,在使用像 C++、Java、PHP 這樣的編程語言時,我們會經常將消息打印到控制檯,因爲這是開發、測試和調試程序的一部分。但倘若我們正在處理一個服務端程序,卻無法看到其內部發生了什麼,這時該怎麼辦?唯一的可見性工具是日誌文件,如果沒有日誌,我們就不能進行任何調試,也無法知道程序內部在做什麼。

儘管 C++ 中有相當方便的 cout 輸出流,可以在控制檯上打印一些信息,或者可以通過其他方式將這些信息重定向到文件中,但這對於實際的應用程序來說根本不夠。尤其對於複雜的 C++ 程序來說,像 log4cplus 或任何其他日誌框架能夠提供了更多的靈活性,而這是 cout 不可能完成的。

在編寫代碼時,使用日誌框架是一種很好的實踐。即使像《代碼整潔之道》這樣的書籍,也建議學習像 Log4 這樣的框架進行日誌記錄。所以,應儘可能的在生產代碼中使用日誌,而不是用 cout 來打印東西(這是不可接受的)。

3

使用日誌的好處

日誌是一個優秀系統不可或缺的組成部分。

對於很多人來說,日誌的作用僅限於調試。其實不然,它在很多方面都非常有用。

日誌是最好的診斷工具

絕大多數人都曾面臨這樣的困境 - 一旦程序出現問題,很長時間都找不出原因!

缺少日誌,我們將不得不依賴於客戶或技術支持,讓他們描述在什麼情況下發生了什麼(很可能會存在一些誤導)。隨後我們需要通過開發環境重現問題,並進行各種調試,直至錯誤修復爲止,然而這一般會耗費很長時間。但若有日誌的幫助,我們便能迅速擺脫這種困境,可以很快地發現異常,並快速定位、解決問題!

日誌讓我們有機會監測模塊的瓶頸

隨着項目規模的增加,模塊會越來越多,調優也變成了一場持久戰。

通過記錄某些操作所花費的時間,我們可以及時地檢測模塊的瓶頸,並針對性地對一些耗時操作做出優化。

日誌有助於我們瞭解用戶的行爲

爲了提高產品質量,提供個性化服務,就必須瞭解用戶行爲 - 他們做了什麼,想要什麼。

要搞清楚這些,當然要有數據,所以需要採集和分析用戶的行爲,而日誌無疑是最主要的數據來源。

4

要不要重新發明輪子

不要去重新發明輪子 - 《麥肯錫方法》

既然已經對日誌框架有了明確的瞭解,那麼應該使用現有的日誌框架,還是構建自己的日誌框架呢?其實,這是一個老生常談的問題了 - 要不要重新發明輪子?引用莎士比亞戲劇《哈姆雷特》中的一句名言:

To be or not to be - that is the question.

現在我們正處於技術大爆發的時代,每一個技術領域中都有很多優秀的解決方案。因此,自己完全不需要、也不應該去寫日誌框架。就像不應該寫版本控制工具或 Bug 跟蹤管理工具一樣,其他人已經把這些東西搞出來了,而且搞的很好,Git、SVN,Bugzilla、Trac ...... 應有盡有,我們完全可以花很少的錢,甚至是免費使用它們。

所以,請避免重複勞動,不要去重新發明輪子。應該堅持在自己的領域解決問題,將時間花在刀刃上。話雖如此,但我們還是需要了解關於輪子的一些細節(誰造的?怎麼創造的?如何使用?),以從中接受靈感,並把自己的知識加進去。

因此,當需要一個日誌框架時,應該使用現有的框架,而不是去重新發明輪子。那麼,問題來了,日誌框架都有哪些呢?

5

日誌框架都有哪些

C++ 中的日誌框架有很多,其中比較著名的有:

這麼多框架,應該選擇哪一個呢?

由於每個人的需求和技術棧都不一樣,所以很難直接回答這個問題,但是有一些選擇標準可供參考。

6

日誌選擇標準

易用性

易於使用的框架,能讓你事半功倍。

易用性,是優秀框架的一個重要特性。所以無論使用什麼框架,都應優先考慮這一點。

對於日誌框架而言,一旦被選定,在後期開發過程中,項目組中的每個人都會頻繁使用。如果易用性不好的話,那絕對是一個噩夢!所以,在選擇日誌框架時,應儘量找那些由簡單、直觀的 API 實現的方案。衡量標準可參考:對於缺乏經驗的團隊成員,應該在查看文檔和簡單示例之後,就能夠快速上手。

性能(效率)

功能決定當下,性能決定未來。

另一個要考慮的重要因素是性能影響。正如上面提到的,我們會經常調用日誌,這可能會對程序的性能產生巨大的影響。

想象一下,一個日誌框架,需要花費很長的時間才能啓動,在每次調用時阻塞並執行文件 I/O,缺少緩衝機制…… 對於這樣的框架,你會用嗎?

因此,在評估日誌框架時,可以參考網上的一些文章來比較,也可以自己做一些比較性實驗(基準測試),例如:吞吐量 - 測量每秒可以完成多少次方法調用(越高越好);採樣 - 測量每次調用執行究竟花費了多少時間(越低越好)。

對現有代碼的影響

影響越小,越容易維護。

在以後的使用中,日誌將無處不在。就像會影響運行時性能一樣,它們也會影響源碼的可維護性。

從應用程序的角度來看,日誌所處的位置比較尷尬。之所以這麼說,是因爲我們盡力隔離依賴性,提供良好的接口,並最小化耦合,在編程時考慮的是單一職責原則。然後日誌出現了,它到處都是,與周圍的代碼無關。與這些優秀的設計原則相比,日誌顯得有些背道而馳。

因此,應充分考慮所引入日誌的影響範圍,儘量讓我們的代碼改動最小化!

社區支持

每一個成功框架的背後,都有一個偉大的社區。

框架的生命力源於不斷地完善和發展,如果沒有強大的社區做支撐,這個框架便失去了源動力。

因此,在選擇框架時,這一點非常重要 - 所選的框架是否有專門的團隊做支撐?在像 Stack Overflow 這樣的問答網站上,它是否有很強的存在感?確保一點,如果在使用過程中遇到了問題,你能有辦法快速解決。倘若選擇了一個不知名的框架,當遇到了 Bug 時,那麼可能會浪費大量的時間來解決問題。

完整性

完整的框架,鑄就完美的生產力。

在最前面,我們將日誌的功能分爲三個主要部分:日誌記錄、格式化和輸出地,所以要確保所選的日誌框架徹底解決了這些問題。

日誌記錄和輸出地比較基礎,幾乎所有日誌框架都有這些概念。話雖如此,但對於好的框架來說,應該巧妙地將日誌記錄與輸出地分開,並且還應該有多種可選的輸出地。在理想情況下,最好能夠自定義輸出地。

一般情況下,格式化日誌文件會整齊地排列,並具有很好的可讀性。但在 DevOps 的世界裏,這些遠遠不夠。具體來說,日誌文件需要被格式化爲可解析的數據。通過將日誌輸出作爲數據處理,可以很容易地聚合、搜索和可視化日誌,從而能夠在生產支持方面助你一臂之力。所以,要確保日誌框架擁有這種能力。

發展前景

只有前途光明,方能大行其道。

無法繞過這一點 - 在選擇日誌框架時,不僅要考慮它的現狀,還應該注重它的發展前景。

像上面提到的 C++ 日誌框架,每一個都非常優秀且特點鮮明。但有一些卻獲得了更多的關注度,例如 log4cplus、glog,爲什麼如此呢?因爲它們有很強大的 “基因” 和“後臺”,一個是著名的 Log4j 的衍生品,另一個則是 Google 的“親兒子”。

一個框架的發展前景,取決於衆多因素 - 關注度、用戶基數、社區活躍度 …… 要想大行其道,這些幾乎都不能少。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/cSDdK6Ii0-E3dHugzZd_tg