互联网工程师应该用这种姿势打印日志

点击上方蓝色字关注我们~

在之前一篇关于Code Review的分享中 《互联网Code Review最佳实践分享》 ,也有涉及到日志打印的问题,并且每次评审的过程中,经常会见到日志打印的问题,所以我这边继续做些这方面的总结,希望对你有帮助。

日志就像系统里流动的“血液”,可以帮助排查问题、定位问题、解决问题、甚至预测问题,以至于保证业务逻辑的正确性。

日志组件选用

日志组件有很多,日志门面一般有: Sl4j、Apache Commons Logging等。

日志的实现有: log4j、logback、log4j2、jul等。

建议使用 Sl4j 作为日志门面, logbacklog4j2 作为日志实现。

关于具体为什么,可以自行网上搜索相关资料。

日志级别别乱用

日志级别一般包含: debug、trace、info、warn、error等。 在我们日常开发中,用的最多的是info、warn、error、debug(一般从多到小排名)。

有一些新手可能没能好好区分日志级别,或者在复制日志代码的时候没能好好的区别,也算是比较“粗心大意”吧。

还有可能有的公司会根据日志异常级别做监控,如果一定的error日志级别达到一定的频率就会触发告警,邮件或者短信通知相关负责人。

所以我们在日常打印日志时,一定要注意使用正确的日志级别。

入参要打全日志

有时候你会看到别人打印的日志看起来一头雾水,可能就打一半的意思或者只是单纯的打印业务日志,没有包含当前方法处理的入参,这在我们排查问题时非常苦恼,有时对应不上,或者不清楚具体的业务执行者是谁,这给我们带来非常大的麻烦,甚至我们认为这是打印无效并且毫无价值的“垃圾”日志”。

比如,简单的登录功能,方法入参: uid或userName。

你如果只是打印: “用户进行登录操作”。

这行日志,只能知道的业务功能就是记录用户进行登录的日志,并不能看到是谁进行登录。

正常的日志应该是: “用户 uid =123456或userName=程序员进行 登录 操作”。

虽说这问题很简单,但是还是会有不少同学会粗心的犯这种低级问题。

别打多余的日志

别打多余的日志,也就是不要打印重复的日志、无效的繁琐日志,能用一行日志打印的不要用两行日志分开重复打印。

要打异常堆栈日志

在我们处理业务时,异常总会有,有unchecked exception和checked exception两个大类别。

有时候异常堆栈对我们排查问题十分重要,此时应该要将异常对象使用日志打印出来,此时也包含了出现异常的堆栈信息。

在评审过程中,也发现不少同学要不漏打异常,要不不关注异常,这是非常“不科学”的做法。

重要逻辑要打日志

在我们进行联调测试的时候非常关键,可以根据日志进行逻辑的梳理,排查问题也十分方便,特别是一旦线上出问题,也能很好的辅助我们解决问题。

因为曾经我维护别人的功能,线上出了bug,此时要根据日志来定位问题,看了日志真的看不出啥,并且关键逻辑的日志一句也没有,这对于维护的人来说相当的痛苦,需要打开代码硬着头皮去理顺业务逻辑,这样发量真的会越来越少!

并且有时需要重现bug,由于缺乏相应的日志打印,可能都没办法排查,只能重新加上日志打印,重新构建、发版、线上验证,搞到这种地步实在是不该,因为每次改动代码都增加了很多不确定因素,不会随便让你更新代码发布上线。 生产环境发版管控非常严格,有时你基本上都不能这么操作。

所以关键日志打印是多么重要!

大对象不能全打

在针对大数据量的查询的时候,日志打印一定要注意不能全部打印大结果集,虽说日志要打的周全点,但是针对大数据量的日志我们不能打印,不仅增加了日志量也影响了磁盘IO,更重要的是我们查看日志时出现一整屏幕,并且意义不大的日志,对我们排查问题也增加了难度和让人疲劳。

正确的方式应该可以关注结果列表size,有时打印这个也可以辅助我们了解数据量。

或者使用debug的日志级别打印,有时在排查问题或者联调的时候我们可以调整日志级别,对结果进行验证。

机密信息要脱敏打印或不打

在我们的业务开发中,机密信息也是比较常见的,比如: 用户密码、卡密、身份证号码等等非常重要的信息。

如果一旦打印出来,这些秘密都会是明文展示,如果被黑客或者其它不怀好意的人员获取,可能会造成机密信息的泄露,对我们可能会造成非常重要的影响或者损失!

所以我们在打印日志的时候要非常重视这点,也要时常保持这种安全警觉。

针对这种机密信息,我们可以进行SHA-256加密、脱敏等安全手段进行处理,这样即使别人拿到我们的日志,我们也不用怕机密信息的泄露,也是我们开发人员或者公司对客户最大的信任保证。

日志要包含上下文

日志要包含上下文,其实跟上面的入参要打全日志这一项类似,也有包含的意思。

日志包含上下文,在我们跟踪业务逻辑的时候非常重要。

比如谁来操作这个方法,然后操作的结果是什么,“人物、行为、目的”,这三个基本要素都要有。 虽然现在有部分技术团队引入了调用链的方式,可以根据TraceID来获取整条调用链的调用情况,但是还有部分日志是没能走调用链,或者其它小团队没能引入这些技术。

所以,一行日志包含上下文是非常重要的,可以把我们的业务逻辑串起来,而不会造成一种困境迷惑我们。

日志要回滚切割

一般我们打印的日志都是在一个文件里,这样随着时间的流逝,文件越来越大,可能会造成磁盘空间不足,也容易造成我们的服务宕机。

所以我们应该定义日志的回滚策略,每天或定时回滚切割文件后压缩、归档,保留日志文件数等,这样就能减小日志文件的大小,例如logback等日志框架都有这些功能。

这对我们以后通过日志排查问题,磁盘容量监控和服务正常起到非常大的作用。

检查日志打印

如果你开发完成相关的业务需求,如果有时间或者花个几分钟 检查 一下日志打印是否 正确 或者需要 完善 ,相信对你一定有帮助的! Believe me,准没错!

日志不仅记录了业务相关的逻辑,也可能包含了用户的相关行为,能够帮助我们分析出有价值或者预测用户的行为习惯。

这样也能帮助我们的业务能够得到更好的改进或者做出用户更加喜欢的产品。

日志是一种宝贵的“资源”,我们时刻都要知道日志的作用,也要知道日志是有价值的,不然我们打印它干嘛,打印就是有用,没用的东西我们怎么要浪费时间与精力呢! 所以,在我们开发过程中,日志打印一定要好好对待,好的日志一定能帮助你达到事半功倍的效果。

希望上面的观点或建议,能够帮助到你!

如果你还有其它方面的建议,欢迎评论一起探讨,一起提升~

推荐阅读

-关注搬运工来架构,与优秀的你一同进步-

【版权声明】本着分享学习的目的,本公众号有部分文章来源于网络,版权归原作者所有!若您觉得侵权且要求删除,请您留言或者联系公众号小编,谢谢

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章