有哪些好的技术可以记录您的应用程序？

Question

日志记录可能很快变得复杂。考虑到你有一些代码，你如何添加日志？你用的是哪些图书馆？

有什么好的代码技术可以充分利用您的日志记录语句，同时对您的应用程序产生最小的影响？

Answer 1

库：Log4J和Log4Net（分别用于Java和.NET）

来自Log4J网站：

  

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

     

另一方面，有些人认为日志语句会污染源代码并降低可读性。 （我们认为恰恰相反）。在预处理器不可用的Java语言中，即使关闭日志记录，日志语句也会增加代码的大小并降低其速度。鉴于合理大小的应用程序可能包含数千个日志语句，速度特别重要。

     

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

     

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

Answer 2

在其他问题上对此进行了相当多的讨论。如果你是C＃男人，请查看What is the best logging solution for a c# net 3.5 project或What’s your logging philosophy?

搜索记录，你会发现更多。 ：）

Answer 3

查看Log4X日志的工具：ChainSaw

Answer 4

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

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

Answer 5

There are few things to consider when you decide your logging philosophy to make it performance conscious. First let us breakdown the resources spent on logging.

• CPU time spent on appending or assembling a particular log line & garbage collection
• Working memory spent on appending or assembling a particular log line
• CPU time spent on writing to the destination (I/O), can be file, console, network etc.
• Wall time spent on waiting or fighting on a shared resource or shared destination. This may be a file on disk or a synchronous method inside the logging framework.
• Disk space or any other storage occupied to persist the log file

Following are the things that you can do to minimize the above.

• Have controls over logging. Have proper log levels so can only INFO,WARN,ERROR will be used in production, and DEBUG, TRACE will be used in development. Most importantly levels should not control writing the logs to the destination, but it should also control assembling log lines as well. To achieve this, use parameterized logging ( https://www.slf4j.org/faq.html#logging_performance ) or simply check the log level is enabled before assembling the log line. Using a lambda is an alternative as well.
• Avoid costly formatting. If pretty printing is needed write a log extraction tool convert raw log lines to pretty log lines, which will happen offline, and on demand. There are lot of useful things that can be easily done if the logs are forwarded a tool like Splunk or ElasticSearch.
• Minimize log size. Use shorthand codes to minimize the size of a log lines while preserving the readability.
• Minimize log frequency. When deciding to log something, roughly estimate on how much log size/transaction or how many log lines/ transaction. If it is more than 1:100, then that is too much logging, well it depends.
• Try asynchronous logging. In other words do not write to the destination (I/O) in the transaction thread, rather add it to a buffer and tackle it in the background. RandomAccessFileAppender is such facility provided by Log4J
• Divide and conquer. Have the logs segmented. Later in production, this can be used to spread the load on destinations (I/O) by having different destinations (files) for different logs