日志记录最佳实践

译自Optimal Logging

by Anthony Vallone

Google Testing Blog

要找到一个系统问题的根本缘由，你须要多长时间？5分钟？仍是5天？若是你的答案接近5分钟，很大多是由于你的生产环境和测试环境使用了很是好的日志记录。更常见的状况是，诸如日志、异常处理、甚至测试这类非核心的工做，被看成一种出现问题后的补救方式。同异常处理和测试同样，日志记录真的也须要策略，不管是生产环境仍是测试环境。永远不要低估日志的做用。有了使用得当的日志，你甚至能够说debug不是必需的。下面是多年来对我很是有用的日志记录指导原则。

保持适度

切勿记录过多。大量的磁盘空间被日志占用说明你没有想过应该记录什么。若是记录了太多，你就还须要设计出复杂的方法来减小磁盘访问、保留历史记录、归档大量数据、以及在这些数据中查询。最关键的是，你将发如今这么多垃圾中找到有用信息是多么的困难。

惟一一个比记录过多日志还差的事是，记录的过少。日志一般有两个主要目的：定位问题和事件确认。若是你的日志不能明确一个bug的缘由，或者某个事务是否执行，你就记录的过少了。

适合记录的：

• 重要启动配置
• 错误
• 警告
• 持久性数据的更改
• 主要系统组件间的请求和响应
• 重要的状态变化
• 用户交互
• 有已知失败风险的调用
• 较长时间的等待
• 长期运行任务的周期性进度
• 重要的逻辑分支和导向分支的条件
• 从高层方法来汇总处理流程的步骤和事件——避免在底层方法中记录复杂流程的每一步骤

不适合记录的：

• 方法入口——不要记录方法入口，除非它很是重要或者是日志处于调试级别。
• 循环中的数据——避免在循环的屡次迭代中记录日志。若是是小循环，或者是间歇性的记录，倒也无妨。
• 大消息或者文件的内容——截断或者使用一些有利于调试的方式进行汇总。
• 良性错误——那些不是真正错误的错误会令日志的读者感到困惑。当异常处理是执行成功的一部分时，有时会遇到这种状况。
• 重复的错误——不要重复的记录相同或者类似的错误。这样可能会快速的填满日志，而且隐藏掉真正的问题。各类类型错误发生的频率最好有监视器（monitor）处理。日志只需捕获问题的详细信息。

多个日志级别

不要把全部信息都记录在同一个日志级别中。绝大多数的日志库都提供多个级别，系统启动时能够进行指定。这样能够很方便的控制日志详尽程度。

典型的级别有：

• 调试——最详细，可是只有在开发或者调试时适用。
• 信息——最经常使用的级别。
• 警告——奇怪的或者不在预期以内的一些状态，可是可接受。
• 错误——有错误发生，可是流程不受影响。
• 严重——流程没法继续，系统将关闭或者重启。

从实际使用来说，只须要两种级别的日志配置：

• 生产环境——除了调试级别，其余全开。若是生产环境发生了问题，日志应该可以指明缘由。
• 开发和调试——编写新代码或是尝试复现问题时，打开所有级别。

测试日志一样重要

日志的质量对于测试代码和产品代码一样重要。当一次测试运行失败时，日志应当明确的指出这个错误是来自测试自己仍是生产系统。若是作不到这一点，那么测试的日志是有问题的。

测试日志应该必需包括：

• 测试执行环境
• 初始状态
• 准备步骤
• 用例步骤
• 与系统的交互
• 指望的结果
• 实际的结果
• 清理步骤

利用临时日志队列实现条件性的详细信息控制

发生错误时，日志应当包含大量的详细信息。但不幸的是，当遇到一个错误时，致使这个错误发生的详细信息可能已经没法得到了。若是你遵从了“不要记录过多”的建议，在错误日志以前的那些日志可能没法提供足够的细节。解决这个问题的一个好的方式是，在内存中建立临时的日志队列。在事务的处理过程当中，将每一步的详尽信息追加到队列中。若是事务成功完成，丢弃这个队列，只记录一个汇总。若是发生了错误，就把错误和队列里的所有内容记录下来。这一方法对于系统交互的日志尤为有效。

问题是机遇

当生产环境出现问题时，你必将集中精力寻找而且修复问题，可是也不要忘记考虑一下日志。若是你费了很大力气才找到问题的缘由，这将是个很是好的机会来改善你的日志。修复问题前，先修复你的日志记录，使其能够清楚的指明问题缘由。若是这个问题又一次发生，将会很容易辨认。

若是没法复现问题，或者测试结果不肯定，改进日志以即可以在问题再次发生时将其记录下来。

在整个开发的生命周期内，都应该持续的利用问题来改进日志。写新代码时，试着少用debug，只使用日志。这些日志是否可以说明发生了什么？若是不能，日志就是不充分的。

最好也记录性能数据

记录时间数据能够用来帮助定位性能问题。例如，要找到一个大型系统的超时缘由是很困难的，除非你可以追踪每个重要处理步骤的耗时状况。这是很容易作到的，只需记录那些可能会比较耗时的调用的开始和结束时间便可：

• 重要的系统调用
• 网络请求
• CPU密集运算
• 链接设备的交互
• 事务

在多线程和多进程中追踪痕迹

在涉及到多线程或多进程的处理时，要为事务建立独一的标识。事务初始化时建立ID，将它传入每个为此事务工做的部分。当记录关于此事务的日志时，每个部分都应该记录下这个ID。这样，在多个事务并行执行时，追踪一个特定的事务会容易不少。

监控和日志相互完善

一个生产服务应该既有日志也有监控。监控提供了一种实时的对于系统状态的统计汇总。它能够提醒你，是否必定比例的某个类型请求失败了，是否系统正在经受不正常的流量访问，性能是否在降低，或者其余的一些异常。在某些状况下，只是这些信息就能够为找到问题缘由提供线索。不过，大多数状况下，监控警报只是为了简单的触发你的调查。监控将问题的症状展示给咱们。日志则针对各个事务提供了详细的信息和状态，这样你才能全面的理解问题的缘由。