日誌框架注意事項

Question

我正在設計一個記錄服務器。這個應用程序的商業邏輯是用多種語言編寫的（現在是C++ & Java，但其他語言可能會在後期添加到混合中）。

我正在考慮將這個單獨的服務器與一個定義良好的接口爲確保可擴展性，主應用程序可以在負載均衡器支持的多臺機器上運行多個實例。

設計的其中一個重要考慮事項（其他比通常的日誌記錄級別更好）是性能和支持多個日誌記錄目標（平面文件，控制檯，DB（？）等）。如何確保記錄器不影響應用程序的性能？使用套接字進行通信是否合理？有一個更好的方法嗎？

Answer 1

是否需要共享所有日誌？我會使用任何日誌機制最適合邏輯的每個階段（log4j或java在java中的日誌記錄，我想我不知道C++的日誌記錄庫足以提供一個。）

對於大多數情況，日誌應該僅用於調試和外部應用程序解析。我不建議將日誌記錄集成爲業務邏輯的一部分。如果您真的需要日誌中的數據，那麼直接溝通會比通過其他應用程序唾棄日誌來得好。

如果您絕對需要它，您可以擁有一個外部（非常低優先級）的應用程序，該應用程序提供日誌並將它們發送回中央日誌記錄服務器。

Answer 2

您需要近實時查看數據以及需要記錄的離線處理數據。他們有不同的要求。

實時數據需要採用機器可讀的格式，通常指向使用它的地方。中央記錄器可以在此路徑上，只要它不會不可接受地延遲實時信息。爲此，我將使用套接字（或JMS）而不是緩衝文件。

脫機處理日誌可以是機器可讀的格式（用於過夜報告）或者是人類可讀的（用於調試）爲此，我將使用文件或數據庫或兩者。文件可以更簡單地管理，尤其是如果它很大的話。數據庫使建築報告更容易。

在任何一種情況下，我都會將需要通過套接字發送或寫入文件的信息傳遞給另一個線程，以便系統中的任何隨機延遲不會影響生成日誌的代碼。事實上，我會考慮推遲發送任何日誌，直到關鍵過程完成。即，您先處理需要先完成的所有事情，然後再記錄下所有感興趣的事情。

Answer 3

檢查： http://logging.apache.org/log4j/1.2/manual.html

看看性能部分。就應用程序中的日誌開銷而言，它將解決您的擔憂。

就支持多個日誌記錄目標而言，這很容易通過log4j實現，但您需要深入研究一些細節（請參閱我發佈的URL）。

一般來說，從我的經驗來看，log4j非常好。我已經生成了數千個「相當大的」靜態&動態日誌（對於我的應用程序 - 這個術語的解釋可能與您的應用程序有所不同），儘管執行了大量的處理（對於歷史記錄，我正在評估/模擬分佈式P2P算法在本地PC中，儘管爲模擬創建了數百個記錄器實例，但一切都進展順利）。