在最近的時(shí)間里，我們已經(jīng)看到了許多工具可以幫助您理解日志。 諸如Scribe和LogStash之類的開(kāi)源項(xiàng)目，諸如Splunk之類的本地工具以及諸如SumoLogic和PaperTrail之類的托管服務(wù)。 這些都可以幫助您將大量日志數(shù)據(jù)減少為更有意義的內(nèi)容。

它們共有一個(gè)共同點(diǎn)。 它們都取決于您實(shí)際放入日志中的數(shù)據(jù)。 正確地獲取數(shù)據(jù)質(zhì)量和數(shù)量的任務(wù)就落在了您身上。 考慮到這一點(diǎn)，在記錄日志時(shí)，您應(yīng)該經(jīng)常注意以下五件事：

1.您好我的（線程）名稱是..

Thread name屬性是Java最被低估的方法之一，因?yàn)樗饕敲枋鲂缘摹?它發(fā)揮最大作用的地方是多線程日志記錄。 大多數(shù)日志記錄框架將自動(dòng)記錄當(dāng)前線程的名稱。 但是，它的外觀通常類似于“ http-nio-8080-exec-3”-由線程池或容器分配的名稱。

線程名稱在您的日志中是主要房地產(chǎn)，因此您需要確保正確使用它。 這意味著為它分配詳細(xì)的上下文，例如Servlet或立即完成的任務(wù)，以及一些動(dòng)態(tài)上下文，例如用戶或消息ID。

因此，代碼的入口應(yīng)以類似以下內(nèi)容的開(kāi)頭：

Thread.currentThread().setName(MyTask.class.getName() + “: “+ message.getID());

2.分布式標(biāo)識(shí)符

在SOA或消息驅(qū)動(dòng)的體系結(jié)構(gòu)中，任務(wù)或請(qǐng)求的執(zhí)行可能跨越多臺(tái)機(jī)器。 當(dāng)處理一個(gè)失敗時(shí)，連接機(jī)器之間的點(diǎn)及其狀態(tài)將是了解發(fā)生了什么的關(guān)鍵。

為了使日志分析器能夠在計(jì)算機(jī)上對(duì)相關(guān)日志消息進(jìn)行分組，您需要為它們提供唯一的ID，以此作為每個(gè)日志消息的一部分。 這意味著，系統(tǒng)中的每個(gè)入站操作都應(yīng)具有唯一的ID，該ID隨其一起運(yùn)行直到完成。

諸如用戶ID之類的永久性標(biāo)識(shí)符可能不是很好的工具，因?yàn)橐粋€(gè)用戶可能對(duì)他進(jìn)行了多項(xiàng)操作，這將使隔離更加困難。 UUID（盡管很長(zhǎng)）在這里是一個(gè)不錯(cuò)的選擇，也可以加載到線程名稱或?qū)Ｓ肨LS中。

不要記錄+循環(huán)。

通常，您會(huì)看到一段代碼在緊密的循環(huán)中運(yùn)行并執(zhí)行日志操作。 基本假設(shè)是該代碼將運(yùn)行有限的次數(shù)。

事情進(jìn)行得很好時(shí)，可能就是這種情況。 但是，當(dāng)代碼意外輸入時(shí)，循環(huán)可能不會(huì)中斷 。 在這種情況下，您不僅要處理無(wú)限循環(huán)，還要處理將無(wú)限數(shù)量的數(shù)據(jù)寫(xiě)入磁盤(pán)或網(wǎng)絡(luò)的代碼。

留給自己的設(shè)備，這可能會(huì)使服務(wù)器或整個(gè)群集停機(jī)。

如有可能，請(qǐng)勿在緊密循環(huán)中記錄。 捕獲錯(cuò)誤時(shí)尤其如此。

void readData {while (hasNext()) {try {readData();}catch (Exception e) {// this isn’t recommend - you can catch, but log outside the looplogger.error("error reading " X + " from " Y, e);}} }

4.空手

韋斯特羅斯（Westeros）將長(zhǎng)城作為其最后一道防線（可以幫助他們的肥胖食品）。 您有Thread.uncaughtExcceptionHandlers 。 因此，請(qǐng)確保使用它們。 如果您不安裝這樣的處理程序，則可能會(huì)冒著將上下文拋出異常的風(fēng)險(xiǎn)，而上下文卻很少，并且對(duì)是否以及在何處最終記錄它們的控制也很少。

請(qǐng)注意，即使在未捕獲的異常處理程序中，該處理程序也無(wú)法訪問(wèn)終止線程中的變量，您仍然可以獲得對(duì)Thread對(duì)象的引用。 如果您堅(jiān)持第1步，您仍然會(huì)獲得有意義的線索。 getName （）日志可為您提供更多上下文。

5.接聽(tīng)外部電話

每當(dāng)您進(jìn)行離開(kāi)JVM的API調(diào)用時(shí)，發(fā)生異常的機(jī)會(huì)都會(huì)大大增加。 這包括Web服務(wù)，Http，DB，文件，OS或任何其他JNI調(diào)用。 對(duì)待每個(gè)呼叫，就好像它會(huì)爆炸一樣（最有可能在某一時(shí)刻發(fā)生）。

在大多數(shù)情況下，API調(diào)用失敗的原因與您提供給他們的意外輸入有關(guān)。 在日志中為您提供這些值是解決此問(wèn)題的關(guān)鍵部分。

try {return s3client.generatePresignedUrl(request); } catch (Exception e) {String err = String.format("Error generating request: %s bucket: %s key: %s. method: %s", request, bucket, path, method);log.error(err, e); //you can also throw a nested exception here with err instead. }

使用Takipi進(jìn)行服務(wù)器調(diào)試

Takipi旨在通過(guò)使您的日志更智能，信息更豐富來(lái)使服務(wù)器調(diào)試更好。 以下3個(gè)功能可以在下次調(diào)試服務(wù)器時(shí)使您的生活更輕松：

服務(wù)器調(diào)試 。 當(dāng)Takipi在JVM中檢測(cè)到異常或錯(cuò)誤時(shí)，它將收集引起該異常的代碼和變量。 最終結(jié)果是，對(duì)于應(yīng)用程序中的每個(gè)錯(cuò)誤，您都可以直接跳入在該計(jì)算機(jī)上執(zhí)行的源代碼，并查看引起該錯(cuò)誤的所有變量值–當(dāng)前的局部變量，對(duì)象，數(shù)組和字符串錯(cuò)誤。

日志集成。 Takipi會(huì)為每個(gè)日志錯(cuò)誤自動(dòng)添加一個(gè)微小的調(diào)試超鏈接，因此您可以用來(lái)直接跳到引起該錯(cuò)誤的實(shí)際源代碼和變量值。

分布式調(diào)試 。 如果調(diào)用失敗的代碼是從另一臺(tái)運(yùn)行Takipi的計(jì)算機(jī)上進(jìn)行的，則您將在分布式調(diào)用鏈中看到源代碼和變量值。 因此，如果機(jī)器A調(diào)用B，而機(jī)器C調(diào)用失敗，則您將看到之間的整個(gè)鏈的代碼和變量。

單擊此處嘗試塔基皮

翻譯自: https://www.javacodegeeks.com/2014/03/5-techniques-to-improve-your-server-logging.html

總結(jié)

以上是生活随笔為你收集整理的5种改善服务器日志记录的技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。