记录应用程序的一些好技术是什么?

我想添加一些关于日志记录实践的方面。

1. 将功能日志和开发日志分开是一种实践。在生产环境中,功能日志记录可能涉及DBMS或其他资源。我们可以通过在实际的记录器上写一个包装器来实现这一点。
2. 在多用户环境中,日志语句变得难以读取,具有唯一的用户会话ID,并在开发阶段将其记录下来。然后,一个简单的Perl脚本可以过滤掉这些部分,使调试变得更简单。使用上面描述的包装类很容易
3. 包装类还使您免于绑定到一个特定的日志API。
4. 尽可能尝试面向方面的日志记录方法,这基本上是通过点切割来完成的(方法入口/出口点很容易被覆盖)。清理代码会更容易。

图书馆: Log4J 和 Log4Net (分别用于Java和.NET)

从log4j站点:

在代码中插入日志语句是调试它的一种低技术方法。它也可能是唯一的方法,因为调试程序并不总是可用或适用的。对于分布式应用程序,通常是这样。

另一方面,一些人认为日志语句会污染源代码并降低可读性。(我们认为事实恰恰相反)。在预处理器不可用的Java语言中,即使关闭日志,日志语句也会增加代码的大小并降低其速度。考虑到合理大小的应用程序可能包含数千条日志语句,速度尤为重要。

使用log4j,可以在运行时启用日志记录而不修改应用程序二进制文件。log4j包的设计使得这些语句可以保留在已发货的代码中,而不会产生很高的性能成本。可以通过编辑配置文件来控制日志记录行为,而无需触摸应用程序二进制文件。

日志记录为开发人员提供了应用程序失败的详细上下文。另一方面,测试提供了对应用程序的质量保证和信心。日志记录和测试不应该混淆。它们是互补的。当测井被明智地使用时,它可以被证明是一个必不可少的工具。

在其他问题上也有很多关于这个的讨论。如果你是个骗子,看看 What is the best logging solution for a c# net 3.5 project 或 What’s your logging philosophy?

搜索日志,你会发现更多。:)

查看log4x日志的工具: ChainSaw

当您决定日志哲学以使其具有性能意识时,几乎没有要考虑的事情。首先,让我们分析一下用于日志记录的资源。

• 附加或组装特定日志行和垃圾收集所花费的CPU时间
• 用于附加或组装特定日志行的工作内存
• 写入目标(I/O)所花费的CPU时间可以是文件、控制台、网络等。
• 在共享资源或共享目标上等待或战斗所花费的时间。这可以是磁盘上的文件,也可以是日志框架内的同步方法。
• 为保留日志文件而占用的磁盘空间或任何其他存储空间

下面是您可以做的事情,以最小化上面的内容。

• 控制日志记录。具有适当的日志级别,因此只能在生产中使用信息、警告、错误,以及在开发中使用调试和跟踪。最重要的是,级别不应该控制将日志写入目的地,但它也应该控制组装日志行。要实现这一点,请使用参数化日志记录( https://www.slf4j.org/faq.html#logging_performance )或者在组装日志行之前简单地检查日志级别是否已启用。使用lambda也是一种选择。
• 避免昂贵的格式设置。如果需要漂亮的打印,请编写一个日志提取工具,将原始日志行转换为漂亮的日志行,这将在脱机时按需进行。如果将日志转发给splunk或elasticsearch等工具,那么可以轻松完成许多有用的事情。
• 最小化日志大小。在保持可读性的同时,使用速记代码最小化日志行的大小。
• 最小化日志频率。当决定记录一些东西时,大致估计一下日志大小/事务或多少日志行/事务。如果超过1:100,那就说明伐木太多了,这要看情况而定。
• 尝试异步日志记录。换句话说,不要写入事务线程中的目标(I/O),而是将其添加到缓冲区并在后台处理它。RandomAccessFileAppender是由log4j提供的工具
• 分而治之。把圆木分段。在后期的生产中,可以通过为不同的日志设置不同的目标(文件),将负载分散到目标(I/O)上。