日志记录最佳实践

译自Optimal Logging

by Anthony Vallone

Google Testing Blog

要找到一个系统问题的根本原因,你需要多长时间?5分钟?还是5天?如果你的答案接近5分钟,很大可能是因为你的生产环境和测试环境使用了非常好的日志记录。更常见的情况是,诸如日志、异常处理、甚至测试这类非核心的工作,被当作一种出现问题后的补救方式。同异常处理和测试一样,日志记录真的也需要策略,无论是生产环境还是测试环境。永远不要低估日志的作用。有了使用得当的日志,你甚至可以说debug不是必需的。下面是多年来对我非常有用的日志记录指导原则。

保持适度

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

唯一一个比记录过多日志还差的事是,记录的过少。日志通常有两个主要目的:定位问题和事件确认。如果你的日志不能明确一个bug的原因,或者某个事务是否执行,你就记录的过少了。

适合记录的:

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

不适合记录的:

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

多个日志级别

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

典型的级别有:

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

从实际使用来讲,只需要两种级别的日志配置:

  • 生产环境——除了调试级别,其他全开。如果生产环境发生了问题,日志应该能够指明原因。
  • 开发和调试——编写新代码或是尝试复现问题时,打开全部级别。

测试日志同样重要

日志的质量对于测试代码和产品代码同样重要。当一次测试运行失败时,日志应当明确的指出这个错误是来自测试本身还是生产系统。如果做不到这一点,那么测试的日志是有问题的。

测试日志应该必需包括:

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

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

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

问题是机遇

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

如果无法复现问题,或者测试结果不确定,改进日志以便可以在问题再次发生时将其记录下来。

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

最好也记录性能数据

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

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

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

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

监控和日志相互完善

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

posted @ 2013-07-10 08:57  CaliforniaDream  阅读(...)  评论(...编辑  收藏