一点打log的个人经验

date

Jan 22, 2022

slug

一点打log的个人经验

status

Published

这里“对外”的定义，就是我们关心的对象跟外界交互的地方。至于粒度有多细，可以自己把握，可以是一个方法，也可以是一个服务。接口处的log可以帮助我们快速定位问题的范围。

这一点在团队大了以后尤其重要，排查跨服务的问题的时候，可以极大减少沟通成本。说的俗一点就是方便甩锅，当你没有证据的时候，想要别人相信不是你的问题，还是比较困难的。

比如：

也就是log应该告诉我们某件事发生了，而不是将要发生

因为在事情发生之前打log，某种程度上是一种噪音，即使我们看到了这些log，给我们的信息也是非常有限的。就上面的例子来看，我们如果想知道接口调用的具体结果，还是需要去找其他的log。

相对的，在事情发生之后打log就是很必要的，我们查log时可以有很明确的判断，如果能查到log，说明事情发生了，如果没查到，说明事情没发生。

描述性的信息，应该尽量做到清晰、简洁，另外应该带有某些关键词。这样对一个对项目不太熟悉的人在查问题的时候尤其友好，可以非常容易的知道发生了什么事，并且很容易通过搜索，找到具体的代码逻辑。

这个很好理解，描述性信息是帮助我们定位代码逻辑，各种key和参数是帮助我们定位数据，还原现场。尤其是在微服务越来越流行的今天，这个信息更加重要。

分开有两个好处。

首先，还是对不熟悉代码的人非常友好。设想，如果描述性信息和case相关的信息通过格式化混在一起的话，通过搜索，有可能是定位不到具体代码的。

其次，如果log需要后续处理，把case相关的信息，通过特别的格式输出，对自动化处理是非常有好处的。如果混杂在一起，后续要提取关键信息会很复杂。

比如：

都是用来告诉我们某件事发生了，但INFO是用于记录业务相关的信息，而DEBUG是用来记录代码相关的信息。

都是用来告诉我们，某种异常发生了。我倾向于用WARNING级别表示某种我们能见到的异常，而ERROR用来表示预期之外的异常。这个区别比较微妙，实际应用中还是要尽量跟团队保持一致更加重要，因为这个级别的log经常会跟监控和报警相关了。

比如：

鉴权失败，是正常业务之外的异常，但是属于我们能预期的异常。相应的，发生这种异常的时候，team可能有对应的预案。

其他异常属于我们预期之外的异常，可能我们没有对应的预案，对比WARNING级别，就要更严重一些，很有可能需要我们case by case的去处理。