最近在推上看到下面这张图，讲的是什么时候应该用什么log level，觉得还蛮有意思，于是想到结合自己过往的工作经验做一次解读

一般情况，在打日志这件事情上，并不严格区分Developer与System operator，事实上，在笔者的工作经历中，在怎么打、应该时候应该打日志这件事，基本上都是由开发自己去完成的。

日志分级

trace

Designates finer-grained informational events than the Debug.

对debug更精细的日志级别? 抱歉，我个人表示从来没有用到过这一级别

开发调试阶段会用到，比如在开发阶段可能会有打印请求body这类诉求，通常用的较少

常用日志级别，实际使用中，info是当debug用的，所以，基本上这两者区别不是特别大。比如某个操作成功打印一下，或者打印请求中的某些变量、当前操作用户等行为。

        logrus.Infof("this action sucess")
        logrus.Infof("current user is %s", userName)

处理http请求时，一般40x的日志级别是warn，或者是接口慢请求等

这一级通常需要接告警平台，把error内容通知给开发者的。比如服务panic了这类预期之外的错误，再比如金融服务中需要对账，如果一个人的账户余额跟流水对不上，这是大事，这可是大大的error，所以其实error是一个需要严肃对待日志级别

这个比error更严重了吧，生产环境没有用过，能想到的适用场景可能是服务启动时，做一些上下游依赖检查，如果没有通过，就不启动？

其实我在工作中经常发现这样几类打日志的坏习惯：

RESTful API的出参和入参全打出来，不管有用没有，有人认为要用的时候肯定用的着
打印一些没有上下文的一句话日志，比如前面提到的"this action sucess"，这种日志没太大意义搞清楚为什么要打印日志这件事情是非常重要的，从我的角度，日志当然是为了帮助开发者快速定位问题所在，出问题的地方是预期之外的，预期之内的笃定不会出错，可以按需要打辅助日志，无脑打日志是本人非常反对的。

我们的日志通常会写到日志文件中，日志文件可能会很大，这种时候最好做一下日志切割(比如lumberjack)，避免因写入日志磁盘占用过多而引起其它问题。

参考