打日志的方法

• 日志级别 日志级别

  • error: 表示程序运行出现了错误，这种日志打出来以后，需要开发或运维人员进行处理的。特别的这里特指是自己写的程序出现错误，如果是别人传参传错了这种，不应该报error，记录下来就可以了。因为一来这不是程序本身出现了问题，二来着也会导致日志过多。可以试想一个场景，如果有error报出来，运维就需要去检查，那么这个问题本身应该给运维立刻去检查吗，这可以作为衡量的一个标准。
  • warn: 程序出现了错误，但是这个错误本身不影响正常运行。比如超时，网络原因，以及上面提到的参数错误。当warn很多的时候，就需要开发人员去检查。这里传参错误我也推荐打warn，如果大量出现这宗错误，那么开发人员就需要进行检查。
  • info: 其实应该理解到，info并不是重要的日志。它的作用不是告诉你程序运行出现了什么问题，而是告知你程序运行的信息，比如某个关键节点的成功，某些特殊数据。它是用来在出现问题时候进行辅助判断的日志，或者你可以用它来作为程序出现问题甩锅的依据。
  • debug: 开发时候需要打的各种信息，一般线上不会打这个级别的日志，我的debug日志基本上是开发的时候想怎么打怎么打，后续会大量删除，保留一部分关键的debug日志，当线上出现问题需要更进一步细节的话，可以尝试把debug打开看一看。
  • trace：跟踪程序的推进，我觉得可以不用打这个级别的日志，方法就是。。。忘记这个日志级别。。。

• 日志的可追溯性

  • 用logid追踪，logid可以是外部传过来的，如果不传，可以自己生成。做上下文关联用的，就是串联一次请求日志的唯一标志，timestamp其实就可以。在分布式环境下各个并发的日志混杂在一起，如果不达标记，日志可读性就比较差了。
  • 也有callid，remoteaddress等等。

• 日志的内容

  • 日志的内容要看能不能通过这条日志看出来这一步做了什么事情，包括但不限于：上下文日志的关系（是否可以追溯）logid，对应哪个请求，关键参数是什么，错误信息，关键结果的记录（可以打在info里面），程序运行成功失败的标记，运行状态：包括一些简单的计时记录。我们要认识到，将来分析日志的时候可能需要通过这些标记进行频率，正确率，tps，qps等数据的统计。
  • 性价比问题，日志如果某个信息方便打出来，信息量比较大，帮助比较大的话，就应该添加上去；相对的，比如说图片的base64，完整的request等等打出来就要慎重，因为它实在太大了，不适合放在日志里面
  • 日志格式的一致性，可读性。要注意到分析日志的时候在一大堆日志里面找需要的东西，很容易看花眼，所以格式要固定，要易读。另外应该为一些字段放置一些标志，这可以帮助在后期使用grep命令来分析。另外，大小写一致，还有我发现用[]来包围变量，可读性明显好一点。
  • 日志打在了哪个函数哪个文件时间等等，应该用日志模块自动生成。自己的经验来看，手动标记极其容易犯错。不可靠。

• 打日志的位置

  • 这里提一点，当函数出现错误的时候，错误日志其实可以打在里层也可以打在函数外层等等。可以以这个日志打在哪一层能够获取更多信息来决定打在哪里，有的时候日志打在外层能够获取到更多的环境信息，因为有些环境数据没法传递到下层函数当中去。 

• 日志校验

  • 内容：需要脱离代码来看日志，看看这个日提供的信息量是否足够，特别是在分布式环境下是不是有意义。
  • 格式：还是要脱离代码看日志，因为实际打印出来的日志和你通过代码阅读想象出来的样子可能完全就是不一样的。

• 其他的，需要经验和不断完善。很难在开发时候就完全把日志打好，有些要踩了坑才知道这个地方要打。我觉得除了一些注意点以外，也没有确定的法则，靠经验积累慢慢养成习惯和风格吧。

打日志的注意事项

原文：https://www.cnblogs.com/souther-blog/p/10427065.html