日志打印的碎碎念总结 - bmilk - 博客园

1、有意义的日志信息——为日志消息添加上下文 写这一行日志的时候思考下，生产出现异常的时候，这一行日志是否能提供有效的帮助去解决问题 这是最重要，也是最难做到的一个总结。在处理问题的时候，尤其是难以复现的问题，能协助处理问题的就只有日志文件，开发人员必须能从中了解到当时发生了什么！ 当开发人员看到日志时，通常会根据日志推断问题发生时的上下文消息，不幸的时候日志本身并没有这个上下文，因此需要开发者手动将这些信息补充到日志中，如果不能也可加入操作的目的或者结果，便于理解。 比如ERROR: save error - SQL Excepetion这条日志，当你排查问题的时候价值几乎为0，除了知道时SQL执行出错外，没有任何信息。更好，更有用的信息应该是这样ERROR: save error, data com.xxx.Cat(name = name, age=1) - SQL Excepetion,其中解释了Cat是一个类，并且记录了对应示例的相关内容，注意是相关内容，而不是全部，无用的信息应该被去除，避免一些无用信息混淆日志文件。 2、尽可能使用英文记录日志 英文可能没有中文读起来方便，但是英文依然是记录日志最好的语言，没有之一，原因如下： 无法预知日志消息的内容以及他将被归档在何地，以何种方式被打开。英文将以ASCII字符被记录，如果日志消息使用特殊字符集乃至UTF-8，当被阅读者打开的时候都有可能无法正确呈现。并且还可能存在用户的输入采用不同的字符集或者编码的问题 国际化。如果不确定程序的使用者是谁，那么英文会是最好的选择。 3、选择合适的记录工具 犹记得在我刚开始写代码的时候，为了记录日志信息使用了System.out.println()，尽管这个解决了问题，但是这是一个非常愚蠢的方式。缺点数不胜数。 尽管java生态种提供了诸如Log4j、JCL、slf4j 和 logback等诸多第三方日志框架，但请尽量使用slf4j的门面模式来记录，有利于维护和各个类的日志处理方式统一，并且可以在保证不修改代码的情况下，很方便的实现底层日志框架的更换。 4、不要写的太多但更不能太少 这句话听起来似乎很矛盾，但我们确实应该平衡日志的数量。试想在凌晨3点，你要在漫天日志中寻找问题的根源，如果被大量日志混乱你的思路这并不是一件好事。但如果日志太少，找不到问题根源，这更是一个问题。 到底多少合适，没有一个准确的数字，有一个解决思路是，前期可以多打日志，功能上线后，对日志进行分析，并根据问题的减少而减少日志，或者补上缺失的日志 5、在合适的地方记录日志 看这个标题，如果问我什么是合适的地方，我也不知道，但是如果从日志的用出来看，那将会有一些答案 远程调用或者第三方API开始与结束：众所周知，日志可以作为一个甩锅利器，当对方告诉你他做了什么而你认为没有或者不对的时候,日志就是最有力的证据 系统API开始与结束：这块就是自己系统的大门，谁来都得留下影子，别人说没给的时候，这里同样也是证据。另外在日志排错、性能分析、链路追踪方面很有帮助 异常块：所有捕获的异常军应该记录异常内容 应用的启动、停止日志 其他日志：可以根据业务需要，记录相应的日志，比如某些SQL查询的结果