當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

服务器日志记录_5种改善服务器日志记录的技术

發布時間：2023/12/3 编程问答 52 豆豆

生活随笔收集整理的這篇文章主要介紹了服务器日志记录_5种改善服务器日志记录的技术小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

服務器日志記錄

在最近的時間里，我們已經看到了許多工具可以幫助您理解日志。開源項目（例如Scribe和LogStash），內部部署工具（例如Splunk）以及托管服務（例如SumoLogic和PaperTrail）。這些都可以幫助您將大量日志數據減少為更有意義的內容。

它們共有一個共同點。它們都取決于您實際放入日志中的數據。正確地獲取數據質量和數量的任務就落在了您身上。考慮到這一點，在記錄日志時，您應該經常注意以下五件事：

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

Thread name屬性是Java最被低估的方法之一，因為它主要是描述性的。它發揮最大作用的地方是多線程日志記錄。大多數日志記錄框架將自動記錄當前線程的名稱。但是，這通常看起來像“ http-nio-8080-exec-3”-由線程池或容器分配的名稱。

線程名稱在您的日志中是主要房地產，因此您需要確保正確使用它。這意味著為它分配詳細的上下文，例如Servlet或立即完成的任務，以及一些動態上下文，例如用戶或消息ID。

因此，代碼的入口應以以下內容開頭：

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

2.分布式標識符

在SOA或消息驅動的體系結構中，任務或請求的執行可能跨越多臺機器。當處理失敗時，連接機器之間的點及其狀態將是了解發生了什么的關鍵。

為了使日志分析器在計算機之間對相關日志消息進行分組，您需要為它們提供唯一的ID，作為每個日志消息的一部分，通過它們它們可以執行此操作。這意味著，系統中的每個入站操作都應具有唯一的ID，該ID隨其一起運行直到完成。

諸如用戶ID之類的永久性標識符可能不是很好的工具，因為一個用戶可能對他進行了多項操作，這將使隔離更加困難。 UUID（盡管很長）在這里是一個不錯的選擇，也可以加載到線程名稱或專用TLS中。

不要記錄+循環。

通常，您會看到一段緊縮的代碼運行并執行日志操作。基本假設是該代碼將運行有限的次數。

事情進行得很好時，可能就是這種情況。但是，當代碼意外輸入時，循環可能不會中斷。在那種情況下，您不僅要處理無限循環，還要處理將無限數量的數據寫入磁盤或網絡的代碼。

留給自己的設備，這可能會使服務器或整個群集停機。

如果可能，請勿在緊密循環中記錄。捕獲錯誤時尤其如此。

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）將長城作為其最后一道防線（可以幫助他們的胖子）。您有Thread.uncaughtExcceptionHandlers 。因此，請確保使用它們。如果您沒有安裝這樣的處理程序，則可能會冒著將上下文扔到以太程序中的風險，而上下文卻很少，而且對是否以及在何處最終記錄日志的控制也很少。

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

5.接聽外部電話

每當您進行離開JVM的API調用時，發生異常的機會都會大大增加。這包括Web服務，Http，DB，文件，OS或任何其他JNI調用。將每個呼叫視為爆炸（最有可能在某一時刻發生）。

在大多數情況下，API調用失敗的原因與您提供給他們的意外輸入有關。在日志中為您提供這些值是解決問題的關鍵部分。

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進行服務器調試

Takipi旨在通過使您的日志更智能，信息更豐富來使服務器調試更好。以下3個功能可以在下次調試服務器時使您的生活更輕松：

服務器調試。當Takipi在JVM中檢測到異常或錯誤時，它將收集引起該異常的代碼和變量。最終結果是，對于應用程序中的每個錯誤，您都可以直接跳入在該計算機上執行的源代碼，并查看引起該錯誤的所有變量值–當前的局部變量，對象，數組和字符串錯誤。

日志集成。 Takipi會為每個日志錯誤自動添加一個微小的調試超鏈接，因此您可以使用它直接跳轉到導致該錯誤的實際源代碼和變量值中。

分布式調試。如果調用失敗的代碼是從另一臺運行Takipi的計算機上進行的，則您將在分布式調用鏈中看到源代碼和變量值。因此，如果機器A調用B，而機器C調用失敗，則您將看到之間的整個鏈的代碼和變量。

單擊此處嘗試塔基皮

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