日志框架注意事项

是否需要共享所有日志?我会使用任何日志机制是最好的每个阶段的逻辑(log4j或java的日志在java中，我想我不知道c++的日志库足够建议一个。)

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

如果你绝对需要它，你可以有一个外部的(非常低优先级)应用程序来获取日志并将它们发送回一个集中的日志服务器。

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

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

脱机处理日志可以是机器可读的格式(用于夜间报告)，也可以是人类可读的格式(用于调试)。为此，我将使用文件或数据库，或者两者兼而有之。文件可以更容易管理，特别是如果文件很大。数据库使构建报告更容易。

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

检查一下:http://logging.apache.org/log4j/1.2/manual.html

查看性能部分。它将解决您对应用程序中日志开销的担忧。

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

总的来说，根据我的经验，log4j非常出色。我已经产生了成千上万的静电&动态日志"相当大的规模"(对于我的应用程序-这个术语可能会对您的应用程序有不同的解释)没有任何问题，尽管我执行了繁重的处理(对于历史，我正在本地PC上评估/模拟分布式P2P算法，尽管为模拟创建了数百个日志记录器实例，但一切都很顺利)。