日志记录框架注意事项

Question

我正在设计一个用于日志记录的服务器。这个应用程序的业务逻辑是用多种语言编写的(目前是C++和Java，但以后可能会添加其他语言。

我正在考虑让它成为一个独立的服务器，有一个定义良好的接口，以确保我以后不需要将它移植到其他语言。为了提高可伸缩性，主应用程序能够在负载均衡器支持的多台机器上运行多个实例。

设计的一个重要考虑因素(与通常的日志级别不同)是性能和对多个日志目标的支持(平面文件、控制台、数据库(？)等)。

如何确保记录器不会影响应用程序的性能？使用套接字进行通信有意义吗？有没有更好的方法来做这件事？

Answer 1

是否需要共享您所有的日志？我会为逻辑的每个阶段使用任何最好的日志记录机制(log4j或java中的日志记录，我猜我对C++的日志记录库了解得还不够多，无法提出一个建议)。

在大多数情况下，日志应该只用于调试和应用程序外的解析。我不建议将日志记录作为业务逻辑的一部分。如果您确实需要日志中的数据，那么您最好进行直接通信，而不是将日志吐出来让另一个应用程序窃取它。

如果您确实需要它，您可以有一个外部的(优先级很低的)应用程序，它提供日志并将它们发送回一个集中的日志服务器。

Answer 2

有些数据需要近乎实时地查看，有些数据需要记录下来以便离线处理。它们有不同的要求。

实时数据需要是机器可读的格式，并且通常被定向到使用它的地方。中央记录器可以在此路径上，前提是它不会导致无法接受的实时信息延迟。为此，我将使用套接字(或JMS)而不是缓冲文件。

离线处理日志可以是机器可读的格式(用于夜间报告)，也可以是人类可读的(用于调试)，为此，我将使用文件或数据库，或者两者都使用。文件可以更容易管理，特别是当文件很大的时候。数据库使构建报告变得更容易。

在任何一种情况下，我都会将需要通过套接字发送或写入文件的信息传递给另一个线程，这样系统中的任何随机延迟都不会影响生成日志的代码。事实上，我会考虑延迟发送任何日志，直到关键过程完成。也就是说，你首先处理所有需要做的事情，然后记录所有感兴趣的事情。

Answer 3

检查这个：http://logging.apache.org/log4j/1.2/manual.html

看一看性能部分。它将解决您关心的应用程序中的日志开销问题。

就支持多个日志目标而言，这很容易通过log4j实现，但您需要深入研究一些细节(请参阅我发布给您的网址)。

总的来说，根据我的经验，log4j是非常优秀的。我已经生成了数千个“相当大的大小”的静态和动态日志(对于我的应用程序-这个术语可能对您的应用程序有不同的解释)，尽管我执行了大量的处理(对于历史记录，我正在评估/模拟本地PC中的分布式P2P算法，尽管为模拟创建了数百个记录器实例，但一切都很顺利)。