打日志的注意事项

打日志的方法

• 日志级别 日志级别

  • 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命令来分析。另外，大小写一致，还有我发现用[]来包围变量，可读性明显好一点。
  • 日志打在了哪一个函数哪一个文件时间等等，应该用日志模块自动生成。本身的经验来看，手动标记极其容易犯错。不可靠。

• 打日志的位置

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

• 日志校验

  • 内容：须要脱离代码来看日志，看看这个日提供的信息量是否足够，特别是在分布式环境下是否是有意义。
  • 格式：仍是要脱离代码看日志，由于实际打印出来的日志和你经过代码阅读想象出来的样子可能彻底就是不同的。

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