原文鏈接：5 Techniques to Improve Your Server Logging

以下為譯文

---

最近涌現(xiàn)出各種各樣能幫助你理解日志的新工具，有類似 Scribe、Logstash 這樣的開源項(xiàng)目，也有類似 Splunk 的預(yù)付費(fèi)工具，還有托管服務(wù)如 SumoLogic 和 PaperTrail。這些工具的共同點(diǎn)是對(duì)日志數(shù)據(jù)進(jìn)行清洗，在大量日志中提取一些更有價(jià)值的文件。

但有一件事這些工具卻愛莫能助，因?yàn)樗鼈兺耆蕾嚹銓?shí)際投入的日志數(shù)據(jù)，而如何保證數(shù)據(jù)的質(zhì)量和數(shù)量則需要用戶自行完成。因此，在關(guān)鍵時(shí)刻，如果你需要基于部分或者遺漏日志做代碼調(diào)試時(shí)，事情可能會(huì)變得非常棘手。

為了減少這種情況發(fā)生，在這里分享五個(gè)建議，在你記錄日志時(shí)最好能銘記于心：

1. 你好，我的（線程）名字是

正如 Ringo，線程名稱這個(gè)屬性是 Java 中最被低估的方法之一。其原因是線程名稱大部分是描述性的。然而問題同樣出現(xiàn)在這里，類似人們自己，起名時(shí)通常會(huì)被賦予一定的意義。而在多線程日志中，線程名同樣揮著關(guān)鍵作用。通常情況下，大多數(shù)日志框架會(huì)記錄當(dāng)前所調(diào)用的線程名稱。可悲的是，我們通常會(huì)看到 http-nio-8080-exec-3 這種名字，簡單地由線程池或容器進(jìn)行分配。

出于某種原因，我們曾不止一次地聽過這種誤解——線程名稱是不可變的。與之相反，在日志中，線程名稱占據(jù)基本主要地位，你應(yīng)該確保能正確使用。比如將它與具體情境結(jié)合起來，例如 Servlet 的名字、任務(wù)相關(guān)，或者一些動(dòng)態(tài)語境如用戶或消息 ID。

這樣的話，代碼接口應(yīng)該是這樣：

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

更先進(jìn)的版本將被加載到當(dāng)前線程的線程局部變量，配置 log appender，并自動(dòng)將其添加到日志條目。

當(dāng)多個(gè)線程寫入服務(wù)器日志，但你需要集中在單一線程上時(shí)，這將會(huì)非常有用。如果你在一個(gè)分布式 /SOA 環(huán)境下運(yùn)行，更能看到它得天獨(dú)厚的優(yōu)勢。

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

在 SOA 或消息驅(qū)動(dòng)的架構(gòu)，任務(wù)執(zhí)行很可能跨多臺(tái)機(jī)器。當(dāng)處理這種環(huán)境下的故障時(shí)，連接相關(guān)機(jī)器和它們的狀態(tài)將是了解具體情況的關(guān)鍵。大多數(shù)日志分析器會(huì)將這些日志信息分組，假設(shè)你為它們提供了唯一標(biāo)識(shí)，它們便可以作為實(shí)際日志消息的一部分。

從設(shè)計(jì)的角度出發(fā)，這意味著，從進(jìn)入系統(tǒng)到操作完成，每一個(gè)入站操作應(yīng)該有其唯一的 ID 對(duì)應(yīng)。請(qǐng)注意，一個(gè)持久的標(biāo)識(shí)符，如用戶 ID 可能不是一個(gè)好容器。在記錄日志文件的過程中，用戶可能有多個(gè)操作，這將使得隔離特定流更加困難。UUIDs 可能是個(gè)不錯(cuò)的選擇。它的值可以被加載到實(shí)際線程名稱或者作為 TLS-thread 的局部儲(chǔ)存器。

3. 不要使用文本+驅(qū)動(dòng)器，不要日志+循環(huán)

很多時(shí)候，你會(huì)看到一段代碼在緊密的循環(huán)中運(yùn)行，并執(zhí)行相應(yīng)的日志操作?；炯僭O(shè)是，該代碼運(yùn)行的次數(shù)是有限的。

很可能運(yùn)行情況非常良好。但是當(dāng)代碼得到意外輸入時(shí)，循環(huán)可能并不會(huì)中斷。在這種情況下，你不只是處理一個(gè)無限循環(huán)「雖然這樣已經(jīng)很糟糕了」，你正在處理的代碼正將無限量的數(shù)據(jù)寫到磁盤或網(wǎng)絡(luò)。

在單機(jī)場景中它可能會(huì)造成一臺(tái)服務(wù)器崩潰，而在分布式場景中，被影響的則是整個(gè)集群。因此如果可能，不要在緊密循環(huán)中記錄日志。捕獲錯(cuò)誤時(shí)，這一點(diǎn)尤其如此。

下面這個(gè)例子，記錄了一個(gè) while 循環(huán)中的異常：

void read() { while (hasNext()) { try { readData(); } catch {Exception e) { // this isn’t recommend logger.error(“error reading data“, e); } } }

如果 readData 拋出異常，而 hasNext 返回值為 true，這里將會(huì)寫入無限量的日志數(shù)據(jù)。要解決這個(gè)問題的方法是確保不會(huì)記錄這一切：

void read() { int exceptionsThrown = 0; while (hasNext()) { try { readData(); } catch {Exception e) { if (exceptionsThrown < THRESHOLD) { logger.error(“error reading data", e); exceptionsThrown++; } else { // Now the error won’t choke the system. } } } }

另一種方法是從循環(huán)中移除日志記錄，并保存第一/最后一個(gè)異常對(duì)象并在其它地方記錄。

4. 未捕獲的處理程序

Westeros 有最后一道防御墻，而你有 Thread.uncaughtExceptionHandler。因此，盡量使用它們。如果沒有安裝這些處理程序，在異常拋出時(shí)，你只能獲得很少有價(jià)值的上下文，同時(shí)你也無法控制在結(jié)束之前你已經(jīng)將其記錄，并確定記錄的位置。

請(qǐng)注意，即使在未捕獲的異常處理程序，看起來你沒有任何辦法訪問線程中（已終止）的任何變量，你仍然可以獲得實(shí)際線程對(duì)象的引用。如果你堅(jiān)持# 1步，你仍然會(huì)得到一個(gè)有意義的thread.getName()值可記錄。

5. 捕獲外部調(diào)用

每當(dāng)調(diào)用一個(gè)外部的 API， JVM 異常的幾率將大大增加。這包括 Web 服務(wù)、 HTTP、 DB、 文件系統(tǒng)、操作系統(tǒng)和任何其他 JNI 調(diào)用。認(rèn)真對(duì)待每個(gè)調(diào)用，因?yàn)樗S時(shí)會(huì)爆炸 「它很有可能發(fā)生在同樣的點(diǎn)」。

大多數(shù)情況下，外部 API 故障的原因是意外輸入，日志中對(duì)其記錄是修復(fù)代碼的關(guān)鍵。

在這一點(diǎn)上，你可以選擇不記錄錯(cuò)誤，只是拋出異常也可以。在這種情況下，只要收集到調(diào)用的相關(guān)參數(shù)，并將其解析為異常錯(cuò)誤信息。

只要確保異常被捕獲并記錄在更高級(jí)別的堆棧調(diào)用即可。

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. }

原文鏈接：5 Techniques to Improve Your Server Logging

本文系 OneAPM 工程師編譯整理。想技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方博客。

總結(jié)

以上是生活随笔為你收集整理的[译] 提高日志质量的 5 大技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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