【发布时间】：2018-04-19 02:09:03
【问题描述】：
日志记录会很快变得复杂。考虑到您有一些代码，如何向其中添加日志记录？您使用什么库？
有哪些好的代码技术可以最大限度地利用日志记录语句，同时对应用程序的影响最小？
【问题讨论】：
标签： logging
【发布时间】：2018-04-19 02:09:03
【问题描述】：
库：Log4J 和 Log4Net（分别用于 Java 和 .NET）
来自 Log4J 网站：
在代码中插入日志语句是一种低技术的调试方法。这也可能是唯一的方法，因为调试器并不总是可用或适用的。这通常是分布式应用程序的情况。
另一方面，有些人认为日志语句会污染源代码并降低可读性。 （我们认为情况正好相反）。在没有预处理器的 Java 语言中，日志语句会增加代码的大小并降低其速度，即使关闭了日志记录也是如此。鉴于一个合理大小的应用程序可能包含数千条日志语句，因此速度尤为重要。
使用 log4j 可以在运行时启用日志记录，而无需修改应用程序二进制文件。 log4j 包的设计使这些语句可以保留在交付的代码中，而不会产生沉重的性能成本。可以通过编辑配置文件来控制日志记录行为，而无需接触应用程序二进制文件。
日志记录为开发人员提供了应用程序故障的详细上下文。另一方面，测试为应用程序提供了质量保证和信心。不应混淆日志记录和测试。它们是互补的。如果明智地使用日志记录，它可以证明是必不可少的工具。
【讨论】：
在其他问题中对此进行了相当多的讨论。如果您是 C# 人，请查看 What is the best logging solution for a c# net 3.5 project 或 What’s your logging philosophy?
搜索 Logging，您会发现更多。 :)
【讨论】：
查看Log4X日志的工具：ChainSaw
【讨论】：
我想补充一些关于日志记录实践的方面。
- 将功能日志记录与开发日志记录分开成为一种惯例。在生产环境中，功能日志记录可能涉及 DBMS 或其他一些资源。我们可以通过在实际记录器上编写包装器来实现这一点。
- 在多用户环境中，日志语句变得难以阅读，具有唯一的用户会话 ID 并在开发阶段记录它。然后一个简单的 perl 脚本可以过滤掉这些部分，使调试更简单。使用如上所述的包装类很容易
- 包装类还可以让您免于被绑定到一个特定的日志记录 API。
- 尽可能尝试面向方面的日志记录方法，这基本上是使用切点完成的（方法入口/出口点可以很容易地覆盖）。清理代码会更容易。
【讨论】：
当您决定日志记录理念以使其具有性能意识时，几乎没有什么需要考虑的事情。首先让我们分解日志记录所花费的资源。
- 在附加或组装特定日志行和垃圾收集上花费的 CPU 时间
- 用于附加或组合特定日志行的工作内存
- 写入目标 (I/O) 所花费的 CPU 时间，可以是文件、控制台、网络等。
- 在共享资源或共享目标上等待或战斗所花费的时间。这可能是磁盘上的文件或日志框架内的同步方法。
- 为持久化日志文件而占用的磁盘空间或任何其他存储空间
以下是您可以采取的措施来尽量减少上述情况。
- 控制日志记录。具有适当的日志级别，因此只能在生产中使用 INFO、WARN、ERROR，而在开发中只能使用 DEBUG、TRACE。最重要的是，级别不应该控制将日志写入目标，但它也应该控制组装日志行。为此，请使用参数化日志记录 (https://www.slf4j.org/faq.html#logging_performance) 或在组装日志行之前简单地检查日志级别是否已启用。使用 lambda 也是一种替代方法。
- 避免昂贵的格式化。如果需要漂亮的打印，请编写一个日志提取工具，将原始日志行转换为漂亮的日志行，这将离线和按需进行。如果将日志转发到 Splunk 或 ElasticSearch 之类的工具，则可以轻松完成许多有用的事情。
- 最小化日志大小。使用速记代码最小化日志行的大小，同时保持可读性。
- 最小化日志频率。在决定记录某些内容时，粗略估计多少日志大小/事务或多少日志行/事务。如果超过 1:100，那么记录太多了，这取决于。
- 尝试异步日志记录。换句话说，不要在事务线程中写入目标 (I/O)，而是将其添加到缓冲区并在后台处理它。 RandomAccessFileAppender 就是 Log4J 提供的这样的工具
- 分而治之。将日志分段。稍后在生产中，这可用于通过为不同的日志设置不同的目标（文件）来分散目标（I/O）上的负载
【讨论】：