记录框架注意事项

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非常棒。我已经生成了数千个静态＆amp; “相当大的”动态日志（对于我的应用程序 - 这个术语可能会对您的应用程序进行不同的解释），尽管我执行的处理繁重（对于历史记录，我正在评估/模拟本地PC中的分布式P2P算法，所有这些都是尽管为模拟创建了数百个记录器实例，但仍然顺利进行。