摘要：然而，問題在于大量的日志可能會導(dǎo)致有用的事件日志被忽略掉，這樣完全達(dá)不到日志記錄的目的。高性能質(zhì)量的日志記錄中也會詳細(xì)闡述在不影響應(yīng)用性能的前提下能夠?qū)崿F(xiàn)質(zhì)量記錄的相關(guān)技術(shù)。

【編者按】本文作者是 Archanaa Panda ，從 2000 以來一直在軟件開發(fā)（構(gòu)架、設(shè)計(jì)和編程）團(tuán)隊(duì)擔(dān)任 Java / JavaEE 構(gòu)架師，目前立志于做一個與時俱進(jìn)的獨(dú)立的顧問架構(gòu)師。在本篇文章中，作者通過多個方面為生產(chǎn)環(huán)節(jié)的日志提供建議和指導(dǎo)，最后還介紹了一個高性能的智能日志技術(shù)，幫助大家構(gòu)建高性能的智能日志框架。
??

當(dāng)應(yīng)用在生產(chǎn)過程中，日志通常處于開發(fā)周期的次要位置，但實(shí)際上高性能的日志可能成為開發(fā)團(tuán)隊(duì)的重要生命線。在此我們假設(shè)讀者已熟悉了各種日志框架，如 Log4j 、 SLF4J 等，所以不再詳細(xì)介紹，本文旨在為「真實(shí)」的生產(chǎn)日志提供指南，檢測其對應(yīng)用質(zhì)量的影響，同時還為大家介紹了一個被遺忘已久的高性能的智能日志技術(shù)。

在為應(yīng)用搭建架構(gòu)、設(shè)計(jì)、開發(fā)甚至是提升性能的整個環(huán)節(jié)中，大家都常常忽略日志的重要性。最后當(dāng)應(yīng)用程序一切準(zhǔn)備就緒打算部署的時候，會發(fā)生什么呢？

糟糕！應(yīng)用程序已經(jīng)脫離你的開發(fā)環(huán)境，它無法運(yùn)行出你想要的 IDE 平臺，而且沒有對應(yīng)的調(diào)試器可用，此時你才想起來日志的重要性似乎為時已晚。然后當(dāng)你費(fèi)勁地想從一大堆日志中嘗試調(diào)試出應(yīng)用哪里出了問題，才發(fā)現(xiàn)這個任務(wù)不僅僅是艱巨，而且極其無聊、繁瑣，還會浪費(fèi)大量的時間。根據(jù)你多年的經(jīng)驗(yàn)和專業(yè)知識來看，這樣的做法毫無疑問是大海撈針！再或者你把這個任務(wù)分配給下屬或運(yùn)維團(tuán)隊(duì)，而這樣一份繁瑣無比費(fèi)力不討好的工作，擱誰身上都會招致抱怨！甚至他們也無功而返，集體抱怨你的失策，你只有讓專業(yè)架構(gòu)師和設(shè)計(jì)師參與進(jìn)來。

所以，日志應(yīng)該是生產(chǎn)應(yīng)用的重要生命線，誰都不應(yīng)該掉以輕心。當(dāng)然，眾所周知，可以根據(jù)需求開啟或關(guān)閉各種日志的記錄級別，市面上知道有多種日志類別和日志框架，如 Log4j 、 Commons Logging 或是 SLF4J ，我們可以直接將日志發(fā)到不同目的地，如文件、數(shù)據(jù)庫、 JMS 隊(duì)列等。

但是我們中有多少人會真正地計(jì)劃日志呢？又有多少人理解日志是如何影響系統(tǒng)質(zhì)量的呢？誰又會不斷地去優(yōu)化日志，時刻記得一旦應(yīng)用上線，日志會對系統(tǒng)和工作生活產(chǎn)生哪些影響？還有多少人已經(jīng)嘗試過利用日志框架的先進(jìn)功能來提升日志性能呢？

本文主要想喚醒大家對應(yīng)用日志的重視，同時為部署應(yīng)用日志提供基本指導(dǎo)。最后，本文會介紹一個被遺忘已久的日志技術(shù)，在不影響應(yīng)用性能和質(zhì)量的前提下，幫助大家實(shí)現(xiàn)高質(zhì)量的日志記錄。

日志記錄是最常見的質(zhì)量監(jiān)控方式，它可以幫助應(yīng)用開發(fā)者探究到問題的根源。但這些往往只通過監(jiān)控來實(shí)現(xiàn)，對于開發(fā)者來說，在代碼的各個地方編寫一個 System.out.println() 或 logger.log() 語句再簡單不過。然而，問題在于大量的日志可能會導(dǎo)致有用的事件日志被忽略掉，這樣完全達(dá)不到日志記錄的目的。所以，開發(fā)者可能會尋找其他系統(tǒng)監(jiān)控技術(shù)，如使用或開發(fā) JMX 控制臺。這一點(diǎn)會在后面的 「為待生產(chǎn)的應(yīng)用進(jìn)行日志記錄」章節(jié)中詳細(xì)討論。

不管咨詢哪位性能專家或架構(gòu)師，對于 90% 的應(yīng)用來說，過多的日志記錄都會對性能產(chǎn)生非常不利的影響。日志是一種 I/O 密集型活動，的確會對應(yīng)用性能產(chǎn)生不良影響，特別是傳統(tǒng)的日志方式還會寫入應(yīng)用線程環(huán)境的 FileAppender 中。不僅如此，日志代碼還會造成大量的堆消耗和垃圾收集，比如：

?if (logger.isDebugEnabled())
????
?????logger.debug("name "+person.name+" age "+person.age+" address "+person.address);

除此之外，內(nèi)部調(diào)用日志到 Log4J Appender 的 doappend() 方法，會與線程安全同步。這也意味著，應(yīng)用線程不僅在同步地進(jìn)行大量的磁盤 I/O 操作，還會在寫入日志時互相阻塞！在某電子政務(wù)門戶網(wǎng)站上最嚴(yán)峻的性能情形之一就是，線程轉(zhuǎn)儲顯示在日志記錄寫入到單個文件 appender 時，應(yīng)用日志也被寫入到這個的 appender 文件集中！

事實(shí)上，性能專家首先會確定應(yīng)用的當(dāng)前日志級別，然后通常只是把日志級別從 DEBUG 切換 INFO 或 WARNING 模式，來達(dá)到提升應(yīng)用性能的目的。但是，在完成性能基準(zhǔn)測試工作或即時可伸縮問題之后，應(yīng)用開發(fā)者在尋找應(yīng)用功能性 bug 的根本原因時，又會將日志級別改回到 DEBUG 模式。事實(shí)上，這并不是一個科學(xué)的日志操作。在「為待生產(chǎn)的應(yīng)用進(jìn)行日志記錄」中，我們還會進(jìn)一步討論日志規(guī)范和衛(wèi)生維護(hù)?！父咝阅苜|(zhì)量的日志記錄」中也會詳細(xì)闡述在不影響應(yīng)用性能的前提下能夠?qū)崿F(xiàn)質(zhì)量記錄的相關(guān)技術(shù)。

審核日志是一類特殊的日志，主要用于應(yīng)用的安全審核和跟蹤用戶操作。以下示例主要介紹了日志在安全性方面的幫助。

但是，如果走向另一個極端，日志中攜帶的敏感信息，如用戶的帳戶密碼，可能會暴露系統(tǒng)漏洞。

第三，記錄應(yīng)用程序的事件和流程可能有助于開發(fā)者監(jiān)控和調(diào)試，但同時可能會無意地暴露應(yīng)用的內(nèi)部架構(gòu)。

在當(dāng)前的云應(yīng)用環(huán)境中，應(yīng)用可以在公共云上托管，這樣的漏洞會對應(yīng)用所有者的知識產(chǎn)權(quán)構(gòu)成威脅。

日志記錄會和擴(kuò)展性、高可用性之間互相影響。利用「高性能質(zhì)量的日志」技術(shù)來提高應(yīng)用性能，用更少的硬件提高擴(kuò)展性和可用性，在現(xiàn)有的資源和條件下，你的應(yīng)用完全可以「重拳出擊」。

當(dāng)應(yīng)用被擴(kuò)展成能夠?qū)捎眯赃M(jìn)行主動或被動配置時，就會有多個應(yīng)用實(shí)例，而日志策略就顯得非常重要。應(yīng)用是否能支持，或者開發(fā)團(tuán)隊(duì)是愿意收集來自10個不同機(jī)器或目錄的日志，還是找一個位置能集中收集日志呢？此時，集中的分布式日志變得至關(guān)重要。

像如 Oracle 這樣的重要數(shù)據(jù)庫，已經(jīng)使用 Redo 日志來確保事務(wù)恢復(fù)。應(yīng)用也可以參考這種做法，使用一類特殊的日志幫助恢復(fù)，以防萬一。

在大多數(shù)應(yīng)用中，日志只是其中一種錯誤處理方式，有時只用來評估錯誤。在復(fù)發(fā)性錯誤，如短信/郵件服務(wù)器或數(shù)據(jù)庫長期不可用的情況下，重復(fù)地、頻繁地記錄錯誤是百害而無一利，特別在大量的異常堆棧跟蹤下，只會大大地增加 I/O 活動。在這個過程中，當(dāng)你要分析一個星期前被忽略的老問題時，這時候關(guān)于這個問題的日志早已滾動更新，這種方法只會「火上澆油」。

在考慮應(yīng)用的容量問題時，架構(gòu)師會參考生產(chǎn)環(huán)節(jié)的日志大小，再估計(jì)所需的磁盤空間、集中文件系統(tǒng)的配置等。

對于分布式環(huán)境中的集中式日志，也需要估計(jì)分布在網(wǎng)絡(luò)到遠(yuǎn)程機(jī)器的日志對象的大小。

本節(jié)主要介紹作者對嵌入式應(yīng)用案例的研究經(jīng)驗(yàn)，如果在架構(gòu)、設(shè)計(jì)和開發(fā)階段忽略了日志記錄的重要性，問題一旦發(fā)生，之前所做的一切可能功虧一簣，只得在慘痛的教訓(xùn)面前學(xué)著「吃一塹，長一智」。

舉一個大家都熟悉的場景， GPS 設(shè)備就是一個嵌入式應(yīng)用，裝載在車中可以進(jìn)行位置跟蹤。該設(shè)備不提供任何用戶界面，除了 LEDs 和幾個按鈕，所以幾乎沒有人來管理車輛內(nèi)部的應(yīng)用程序，不像豪華車型那樣會和服務(wù)器端應(yīng)用進(jìn)行交互。因此，如果設(shè)備應(yīng)用出現(xiàn)了問題，應(yīng)用開發(fā)者應(yīng)該如何診斷問題根源呢？隨著各種卡車被運(yùn)往全國各地，日志又是何時寫入車內(nèi)設(shè)備的呢？

應(yīng)用開發(fā)者可能會異想天開，全國各地都配備了服務(wù)工程師，能夠取下設(shè)備帶回去進(jìn)一步分析。以上設(shè)想純屬虛構(gòu)，實(shí)際上，開發(fā)者只會和服務(wù)工程師登入設(shè)備的操作系統(tǒng)去復(fù)制日志。但面對繁雜的日志，連續(xù)的加班作戰(zhàn)只會讓人身心疲憊！

為了更方便地完成這項(xiàng)工作，應(yīng)用開發(fā)者在設(shè)備的桌面服務(wù)應(yīng)用中加上「日志下載」按鈕。服務(wù)工程師就可以直接利用筆記本里的服務(wù)應(yīng)用下載相關(guān)的設(shè)備日志。這至少是一個進(jìn)步，至少不必再讓車停下來再取走設(shè)備了，也給了本該陪同服務(wù)工程師夜以繼日下載日志的可憐開發(fā)者們一絲喘息的空間。顯然，服務(wù)工程師也不至于全世界亂跑了，他們只要盯著應(yīng)用開發(fā)團(tuán)隊(duì)注意下載日志即可。

最后，開發(fā)團(tuán)隊(duì)不得不提高設(shè)備應(yīng)用的性能，讓它像發(fā)送其他跟蹤數(shù)據(jù)一樣，直接通過無線 GPRS 就可以發(fā)送日志到后端服務(wù)器。

需要注意是，在初始的預(yù)估和開發(fā)過程中，所有這些額外工作都沒有被計(jì)入需求池或預(yù)算中。開發(fā)團(tuán)隊(duì)已經(jīng)有一個典型的由客戶功能需求驅(qū)動的思維定勢。應(yīng)用日志既不是一個客戶驅(qū)動的需求，也并非是突出的非功能屬性。所以新手開發(fā)者通常缺乏遠(yuǎn)見，也無力說服高層或管理者給他們足夠的時間預(yù)算來建立這樣的設(shè)施。當(dāng)這些設(shè)備準(zhǔn)備上市時，他們遇到了這樣的問題，經(jīng)理和客戶氣得臉紅脖子粗，而他們不得不挑燈夜戰(zhàn)。真是一個費(fèi)力不討好的活兒！

and don"ts in this section, which would make an application production ready.
在上一節(jié)「記錄其他系統(tǒng)質(zhì)量屬性」中，我們已經(jīng)遇到了一些在生產(chǎn)環(huán)境中不得不面臨的問題。接下來在本節(jié)中，我們再羅列出哪些該做和哪些不該做，為應(yīng)用的待生產(chǎn)狀態(tài)做準(zhǔn)備。

-?日志規(guī)范和代碼審查

日志規(guī)范極其重要，因?yàn)檫@一步將為本文討論的其他最佳實(shí)踐鋪平道路。事實(shí)上，許多生產(chǎn)系統(tǒng)還會有那些無聊的日志，如 「 Hi 」 、 「 Came over here 」、「 Done 」、「 xxxyyyyzzzz 」。這些日志通常會在應(yīng)用調(diào)試階段或開發(fā)階段的單元測試中產(chǎn)生。

但生產(chǎn)階段還有人仍然采用這樣的無聊日志，其給出的理由是它們只會在調(diào)試時產(chǎn)生，而且便于關(guān)閉。但是，在實(shí)踐中開發(fā)者很少這樣做，關(guān)閉的同時也關(guān)掉了一些有價值的日志。為了更好地控制日志，需要開發(fā)者非常精細(xì)地配置日志框架，但在生產(chǎn)中卻常常忽略這一點(diǎn)

同時，代碼審查必須提高效率。當(dāng)高級開發(fā)者或團(tuán)隊(duì)領(lǐng)導(dǎo)審查日志時，必須確保刪除掉無用的日志，即使要面對一些挑釁的言論，比如有人說「我已經(jīng)在測試時刪過日志了」，「不就是個日志么！它又不是引發(fā)問題的原因」。但這是一個很好的規(guī)則，日志并不是開發(fā)過程中用來調(diào)試問題的方式，負(fù)責(zé)調(diào)試的是我們 IDE 的調(diào)試器！

-?當(dāng)你對應(yīng)用進(jìn)行模塊化時，也需要關(guān)注集中式日志

應(yīng)用日志寫入應(yīng)用服務(wù)器的 SystemOut 或 SystemError 文件顯示不是最高效的辦法，但在生產(chǎn)環(huán)境中仍然常見，或如前所述，電子政務(wù)門戶的線程互相阻塞，共同爭奪一個 FileAppender 或者一個文件 I/O 。

最起碼，開發(fā)者應(yīng)該將有基于軟件包或完全限定類為已有的記錄器命名約定，并可能將不同的日志分類記錄到不同的 Appender 位置。

在生產(chǎn)過程中，應(yīng)該牢記日志級別應(yīng)該是 WARNING 或根據(jù)日志信息設(shè)為 INFO 級別。

一個有效的方法是在中央配置或常量類中，列舉出所有可能的日志，并只允許開發(fā)者使用這些日志。我們將在「設(shè)計(jì)高性能的智能日志」章節(jié)中進(jìn)行討論。

-?在集群環(huán)境和分布式環(huán)境中記錄日志

幾乎所有的服務(wù)器端應(yīng)用都必須采用集群和分布式環(huán)境，因?yàn)檫@兩種技術(shù)可以提供可擴(kuò)展性和可用性。在集群環(huán)境中，日志應(yīng)該反映出組件、模塊、子系統(tǒng)以及其過程實(shí)例。

在分布式和集群的環(huán)境采用集中的日志服務(wù)器，可以避免從多個目錄和機(jī)器上收集日志的繁瑣。同時，對于移動 I/O 到一個多帶帶的機(jī)器上也更加方便，而應(yīng)用性能可以不再受日志 I/O 的影響。

-?在厚分布式客戶端或嵌入式應(yīng)用中進(jìn)行日志記錄

在「缺少重要日志的案例分析」章節(jié)中的趣聞中也提道，在厚客戶端或嵌入式應(yīng)用的日志幾乎不會發(fā)送給到開發(fā)團(tuán)隊(duì)，也無從幫助他們進(jìn)行問題分析。遠(yuǎn)程傳輸日志的機(jī)制需要再深思熟慮，再適當(dāng)?shù)亓腥腠?xiàng)目計(jì)劃進(jìn)行開發(fā)。

-?使用映射診斷環(huán)境和嵌套診斷環(huán)境

Log4j 的映射診斷環(huán)境（ MDC ）和嵌套診斷環(huán)境（ NDC ）使用 ThreadLocal 儲存環(huán)境特定信息。它們可以存儲如用戶名、事務(wù) ID 這樣的信息，來識別特定用戶或事務(wù)所做的全部操作。這就不需要為了日志記錄，在類和方法中傳遞特定環(huán)境信息。利用 PatternLayout 的 %X 或 X { key } ，存儲的值將在日志中呈現(xiàn)。

-?規(guī)劃日志的生命周期和維護(hù)

這包括規(guī)劃日志滾動更新之前的日志文件大小和最大數(shù)量。為什么需要規(guī)劃呢？因?yàn)槿罩疚募３４蟮接梦谋揪庉嬈鞫即虿婚_！正如腳本會定期對數(shù)據(jù)庫進(jìn)行備份一樣，也應(yīng)該有腳本來備份和歸檔日志。當(dāng)超出磁盤空間限制時，壓縮日志文件也是不錯的想法，這樣遠(yuǎn)程傳輸起來會更加容易。

-?抵制實(shí)時記錄源位置信息的誘惑

獲取位置信息常常以昂貴的性能損失為代價，因?yàn)槿罩究蚣茉噲D確定當(dāng)前的線程堆棧，從而獲得該方法、文件名和行數(shù)。確切地說，日志信息本身就可以通過提供服務(wù)器、子系統(tǒng)、模塊、組件、線程等信息找出日志的來源。

-?避免重復(fù)使用長堆棧跟蹤來記錄錯誤

如果可能的話，日志中應(yīng)該有足夠的信息顯示錯誤發(fā)生的位置，并盡可能避免巨大的堆棧跟蹤。當(dāng)然，這不是一個像 NullPointerException 那樣的特例。但它可以為一些容易識別的特定應(yīng)用錯誤進(jìn)行記錄。此外，當(dāng)經(jīng)常性問題長期發(fā)生時，如與 Email 、短信或數(shù)據(jù)庫服務(wù)器的連接問題，日志記錄也會每隔5分鐘地記錄該問題，而不是每隔幾秒就用巨大的堆棧跟蹤填充日志。

-?不要盲目使用 AOP 注入記錄，尤其在生產(chǎn)過程中

對于新手來說，最基本的 AOP 教材案例就是日志。因?yàn)槿罩颈旧砭褪且粋€橫切關(guān)注點(diǎn)，新手可以在進(jìn)入方法之前或退出方法之后注入日志。在應(yīng)用于生產(chǎn)有價值的應(yīng)用之前，應(yīng)該嚴(yán)肅地考慮這個示例或觀點(diǎn)。對于以上已經(jīng)建立的示例，日志記錄可不是一件小事，它值得像大多數(shù)其他非功能性需求（ NFRs ）一樣進(jìn)行詳細(xì)布局規(guī)劃。

-?別把日志當(dāng)作其他監(jiān)控手段的替代品

最滑稽地使用日志記錄的典型案例之一就是「性能日志」，如下所示：

19 Sept 2010 10:20:30 PERF INFO Thread-25 OrderInsertAction.java Time taken in processing OrderInsertAction: 50ms

19 Sept 2010 10:20:33 PERF INFO Thread-8 OrderInsertDao.java Time taken in insert 30ms

筆者就曾犯過這樣的問題，卻沒意識到它增加 I/O 對性能產(chǎn)生的嚴(yán)重危害。

更明智的做法是捕獲 「 TimeStatistic 」 的總時間，并用計(jì)數(shù)器算出用 GUI 屏幕顯示同樣內(nèi)容的平均時間、最長時間、最短時間。

在這一節(jié)中主要討論的策略是將集中式日志包裝成記錄器，日志采用整數(shù)編碼而不是字符串。這項(xiàng)技術(shù)已經(jīng)由作者在導(dǎo)師的建議下成功地實(shí)現(xiàn)。

目前在網(wǎng)上有許多文章都介紹如何用 JMS 隊(duì)列和主題或 sockets 來構(gòu)建集中式日志記錄。集中式日志記錄能夠通過移動 I/O 活動到不同的機(jī)器上進(jìn)一步提高性能，雖然會對程序節(jié)點(diǎn)有輕微的開銷。

但是，這里的關(guān)鍵是結(jié)合代碼來記錄集中式日志，而非冗長的字符串?，F(xiàn)有框架 Log4J 或者 Commons Logging 鼓勵使用字符串來記錄信息，這樣的作法會對內(nèi)存、磁盤和網(wǎng)絡(luò)資源造成一定影響，而這些工作完全可以通過一段簡單的代碼搞定。

一個多帶帶的文件可以列出錯誤代碼和可識別字符串之間的映射。

如以下日志記錄：

[090822 16:02:48] TX WARNING (Tx-2-thread-1: 1163 transmitData): Server has not responded with an ACK, so trying again.

與下面的日志進(jìn)行對比

1300604499194,4,192168001002,20600,1001,2,500000

以上日志顯示了長時間戳、日志級別、生成日志的機(jī)器IP地址、處理的整數(shù)值、處理模塊、應(yīng)用的實(shí)例ID和一個完整的錯誤代碼，代碼翻譯過來也會傳達(dá)相同的含義。這種對象非常便于在網(wǎng)絡(luò)中以二進(jìn)制格式進(jìn)行傳輸。如果有上下文信息能進(jìn)一步限定日志中的信息，一個 Object[] 數(shù)組也可以被傳遞，而主錯誤代碼將轉(zhuǎn)化成為帶有 printf() 格式占位符的字符串。

使用短碼表示錯誤的做法，幾乎在所有的主流產(chǎn)品中都很常見，如 Oracle 、 WebSphere 、 Microsoft 。例如，在微軟的 Office 應(yīng)用出現(xiàn)錯誤時，所反饋的錯誤對話框就是一個難以讀懂的整數(shù)代碼，然后會發(fā)送給微軟用于診斷。

在查看錯誤時，可以將各種錯誤代碼翻譯成完整的字符串進(jìn)一步解讀。

這樣做的好處有如下幾點(diǎn)：

能節(jié)省磁盤空間，從而延長日志的保質(zhì)期和縮減文件大小

應(yīng)用內(nèi)部設(shè)計(jì)和執(zhí)行的一些安全措施不會被日志暴露。但在脫機(jī)查看時，日志可以通過使用翻譯機(jī)來翻譯全文。

避免構(gòu)造或傳輸長字符串，進(jìn)一步減少內(nèi)存使用。

網(wǎng)絡(luò)傳輸中日志是非常輕量的，所以在調(diào)試日志時也盡可能保持最小開銷。

防止日志隨機(jī)構(gòu)造

通過自定制工具更高效地搜索特定錯誤

此外，通過防止直接使用 Log4J 或其他類似的框架可以執(zhí)行日志記錄，或者在你最喜歡的日志框架上或自定制日志上編寫一個定制格式，比如：

public class LogClientFacade {

      public void log(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode);

      public void logWithContext(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Object[] contextInfo);

      public void logWithEx(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Throwable ex);

...

}

這樣的日志接口能確保開發(fā)者注意到在分布式環(huán)境下診斷日志的基本信息，比如子系統(tǒng)、部件或其他，不必在在實(shí)時操作中記錄源代碼的行號和文件名。

上圖顯示了一種解決方案的建議設(shè)計(jì)。其目的是通過在隊(duì)列和異步處理中收集信息，或在接收器線程中進(jìn)行轉(zhuǎn)移，盡量確保日志的處理過程不存在阻塞。這種方式在網(wǎng)絡(luò)傳輸過程中，以二進(jìn)制序列化格式進(jìn)行信息傳輸具有諸多優(yōu)勢，特別是完整的解決方案是同步地使用同一語言時。

當(dāng)他們倒進(jìn)服務(wù)器查看離線日志時，應(yīng)該有一個簡單的圖形用戶界面來觀看日志。然后用一個翻譯機(jī)將日志轉(zhuǎn)換為文本格式，而日志本身也會以二進(jìn)制格式寫入磁盤。需要注意的是，這種方法能和云環(huán)境很好地關(guān)聯(lián)，從而確保部署的知識產(chǎn)權(quán)的保密性。

擴(kuò)展現(xiàn)有框架也是一種好方法，如 Log4J 、 Commons Logging 、 SLF4J 。但是，這樣做的話，為了遵循框架內(nèi)部API的通用性，可能會犧牲一部分效率。例如， Log4J 會序列化日志消息，而堆棧跟蹤會作為字符串在 SocketAppender 和 JMSAppender 中進(jìn)行網(wǎng)絡(luò)傳遞。該框架相當(dāng)易于擴(kuò)展，而且能覆蓋所選擇框架的特定部分，如通過添加或擴(kuò)展新的 Appenders ，擴(kuò)展內(nèi)部的數(shù)據(jù)傳輸對象，如 LoggingEvent ，并進(jìn)行自定義序列化。再者，如果需要最大的靈活性，你可以僅用較短的時間來創(chuàng)建一個簡單的自定義日志框架。

另一個有趣的決定是在應(yīng)用運(yùn)行在服務(wù)器時是否使用 JMS ，或者通過使用一個獨(dú)立隊(duì)列，如 WebSphereMQ 、HornetQ 或 ActiveMQ 。如果選擇 JMS ，以下是作者的幾點(diǎn)建議：

使用寬松質(zhì)量屬性來避免增加事務(wù)、持續(xù)性并允許隊(duì)列重復(fù)。記住，嚴(yán)格可靠性會降低性能，對日志而言這是不必要的。

在一個 JVM 中，要么是在日志服務(wù)器或在客戶子系統(tǒng)，最好是使用輕量的 java.util.concurrent 隊(duì)列或 in-VM 隊(duì)列實(shí)現(xiàn)，從而避免系列化開銷。

建議使用消息代理或運(yùn)輸橋梁，而不是用一個集中式隊(duì)列，并做相同的遠(yuǎn)程調(diào)用。

本人的個人偏好是使用簡單的 socket。

在這篇文章中，我們已經(jīng)討論了最佳實(shí)踐和日志記錄中所發(fā)現(xiàn)的弊端。我們還提出了一種結(jié)合集中式日志和代碼的技術(shù)，從而取代字符串實(shí)現(xiàn)高性能的智能日志實(shí)踐。

作者將構(gòu)思高性能智能日志的設(shè)計(jì)歸功于她的導(dǎo)師 Akash Gupt 先生，是 InterGlobe 科技公司的解決方案架構(gòu)師（ http://in.linkedin.com/pub/akash-gupta/3/79/2b3 ），在他的指導(dǎo)下，作者成功地實(shí)施并觀察到這種技術(shù)的巨大性能優(yōu)勢。

8References

Pro Apache Log4J by Samudra Gupta

Log4J Source code

(編譯自：https://dzone.com/articles/high-performance-and-smarter)

OneAPM 為您提供端到端的 Java 應(yīng)用性能解決方案，我們支持所有常見的 Java 框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級部署，即刻體驗(yàn)，Java 監(jiān)控從來沒有如此簡單。想閱讀更多技術(shù)文章，請?jiān)L問 OneAPM 官方技術(shù)博客。

本文轉(zhuǎn)自 OneAPM 官方博客