翻译:日志级别-错误的抽象

最近运维总向我们报怨,说项目中的日志太多太乱,日志级别分得不清晰,导致我们在定位线上问题的时候,日志的延迟很高,查询不方便,不能及时看到最新的日志等等一些问题。于是就想起很久之前看过的一篇文章,关于日志的抽象级别的一个很形象的描述,可以很直接的理解什么时候用什么日志级别。以下为我自己翻译后的正文:

好吧,你刚刚又写了一个try/catch块,然后又开始纠结:这个异常我该用ERROR还是WARN来记录日志呢?又或许你写了另一个“永远不会发生的”条件分支,然后你又开始疑惑了:这种“不可能”的分支,我要用哪种日志级别来记录呢?

其实,你问错问题了。

这些问题无助于你找出答案,因为它们是站在一个不正确的抽象级别的角度上来问的。而你必须应该从 这些日志语句将会被如何使用 的角度来看待这些问题。

在IG我们对日志级别做了如下的转换:

  • DEBUG: 一些在开发阶段有用的信息,通常比较随意的,不会在生产环境出现的。
  • INFO: 通常用来定位线上问题的信息
  • WARN: 有人会去调查到底发生了什么,但可以等到明天
  • ERROR: 完蛋了,赶紧报警,这个必须马上调查发生了什么

有了上面这些转换,那前面那些纠结该用哪种日志级别的问题,就变成了:“我想半夜起来调查这个问题么,或者这个能不能等到明天早上呢?”这种非常具体的,就算是你的业务经理或者产品老大都应该能够回答的问题了。

毫无毫无疑问这些转换肯定是要教给团队的新人的,并不断提醒有已有成员。为了不致于忘记这些映射,我们必须要在wikis、code reviews和邮件提醒中,不断的提醒大家。

在经过了几次code reviews以后,我问了几次这样的问题“这个异常为什么要在半夜把我叫起来”?于是,我决定把我们的日志接口从SLF4J换成内部试验版的“IGLOGGER”,大概是下面这样子:

现在结果就变得有趣了:

  • 当读到“WakeMeInTheMiddleOfTheNighgt”
  • 使用“WakeMeInTheMiddleOfTheNight”的时候要格外小心
  • 记录日志的时候,不需要人力思考了
  • 选择日志级别的时候更容易了
  • 不再需要教团队的新成员,也不需要时刻提醒老成员了
  • 根据需要在团队的其他项目中使用

最后,但并非最不重要是,我们得到了更多的睡眠:ERROR日志的数量减少到了0,并不是因为“wakeMeInTheMiddleOfTheNight”没有人可以打扰,而是因为这是一个非关键的离线服务,所以任何问题都可以等到第二天。

晚安,好梦!

英文原文链接:https://labs.ig.com/logging-level-wrong-abstraction