日志框架注意事项

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中，尽管为模拟创建了数百个记录器实例，但一切都进展顺利）。