解析 Java 程序如何正确地打日志

2018年5月15日，周二晚上8点30分，在 Java 行业深耕多年，有着诸多开发和架构实战经验的R哥带来了主题为《Java 程序如何正确地打日志》的交流。以下是主持人天怡整理的问答实录，记录了作者和读者间问答的精彩时刻。

---

内容提要：

• 是否可以举例说明哪些位置应该打印日志，以及建议打印哪些参数？
• 是否可以针对自己日常对日志文件的处理进行拓展，比如说分布式集群如何处理日志？异步事件的日志如何处理？错误接口的栈信息如何处理？
• 在查询生产问题的角度，常常需要对一个流程作全流程的日志监控，这个时候要怎样把整个流程的日志串连起来？
• slf4j 对应的 logback，如果要自定义一些功能，是自己实现一套 slf4j，还是能在 logback 这种线程的日志框架上面去修改？
• 请问一般框架自带的 debug 日志太多，有什么办法只打印自己的 debug 吗？
• 请问良好的打印日志习惯，除了第三方接口，还有哪里需要打印日志？
• 现在除了 elk 还有什么日志方案？
• 抛异常和打印错误日志，有时分不清？什么样的情况下抛异常，什么样的情况下打印错误日志？

---

问：是否可以举例说明哪些位置应该打印日志，以及建议打印哪些参数？

答：这个问题比较大，举个例子，我们要请求第三方的接口，首先要用 info 打出请求的参数，也可以用 debug 打出网络信息，请求过程出错要抓取异常并记录完整堆栈信息到 error 日志里面，请求成功的话用 info 打出响应状态码和返回信息。请求第三方注意设置超时，并对不同异常记录不同的日志。

---

问：是否可以针对自己日常对日志文件的处理进行拓展，比如说分布式集群如何处理日志？异步事件的日志如何处理？错误接口的栈信息如何处理？

答：每个日志实现框架都是可以自定义实现拓展的，如 FileAppender 接口。分布式日志目前最流行的是使用 ELK 方案，异步事件可以正常处理，错误接口一般应该由接口的提供错误码，而不是捕捉异常，超时的除外。

---

问：在查询生产问题的角度，常常需要对一个流程作全流程的日志监控，这个时候要怎样把整个流程的日志串连起来？

答：这个一般是对每个线程使用一个全局唯一的类似 trace id 的东西来对整个日志链记录，根据这个 id 就能串起来。

---

问：slf4j 对应的 logback，如果要自定义一些功能，是自己实现一套 slf4j，还是能在 logback 这种线程的日志框架上面去修改？

答： logback 是基于 slf4j 实现的，slf4j 只是门面接口，接口不用改，要自定义功能改日志实现框架 logback 即可。

---

问：请问一般框架自带的 debug 日志太多，有什么办法只打印自己的 debug 吗？

答：一般可以禁用开源框架中的日志输出功能，或者调整日志级别。如 log4j.logger.org.spring......web.level=OFF，OFF 可以改为 info warn 等。

---

问：请问良好的打印日志习惯，除了第三方接口，还有哪里需要打印日志？

答：你可以 review 你的代码，在代码任何一处发生异常是否可以通过日志定位到问题。也可以多观察下开源框架中的日志输出，很详细的，多学习借鉴开源框架中的思想。

---

问：现在除了 elk 还有什么日志方案？

答： ELK+Filebeat 完美最优方案，其他方案无非可以替换其中的组件，现在也没有其他更优秀的组件。

---

问：抛异常和打印错误日志，有时分不清？什么样的情况下抛异常，什么样的情况下打印错误日志？

答：这个可以规范起来，如工具类中不要抛出异常统一捕获异常并输出错误日志。提供出去的接口就不要抛异常，自己记录错误日志并使用错误码返回给对方，也可以可以统一抛出异常，如参数错误、认证失败由全局异常处理机制处理等。