日志“最佳”实践

1、背景及意义

日志作为除DB外最重要的数据，如何组织和打印是需要在架构设计思考的问题。

• 意义/作用：
  1、排查bug，这也是日志的传统意义，线上出现问题以后，只有日志可以给你提供帮助，你要根据日志把异常精确的抓出来并以此为依据分析和解决问题；
  2、数据分析，近年来尤其是大数据兴起以来，数据组的同学绞尽脑汁的收集数据，除了DB数据(大多数是结果数据)外，日志也是数据同学迫切需要的。

2、常见问题

这里主要介绍笔者在工作中遇见的一些打印日志的问题（笔者虽然年纪不大，但是工作经历堪称丰富）

• 没有日志 ：测试环境靠system.out.print排查问题，测试通过把print删除（不删的话会影响业务性能，因为内部有锁），直接上。秉承着【测试环境没问题，正式环境必然也不会有问题】的良好心态。

这种情况不多做解释，出现线上和本地环境不一致、第三方接口抽风等情况，你只能寄希望于再试一遍能复现问题（偷偷把Exception捕获并隐藏这种行为不在本文讨论范围内）。

• 象征性的打印 ：项目里零星的存在几个log.info，可能是因为技术总监要求工程要打日志:)

这种情况其实和上述的“没有日志”差不多，甚至还不如没有日志。见过有些同学业务逻辑ok但是一条日志导致系统异常(常见于日志中打印了list.size()，而list是null…)，不多做解释:)

• 没有日志上下文关联 ：项目中每个方法基本都有日志，并且在业务关键节点特意加了日志。比如一个支付方法，在方法入口打印了“userid”，在支付成功后打印“支付成功”，支付失败后打印“支付失败”。

看起来无懈可击，支付失败后找到上面的userid就可以排查问题。可是在并发环境下多用户是交叉打印的，你无法确定“支付失败”的用户究竟是哪个用户。

• 只有value* ：项目中的日志很全面，方法的入参、出参、问题快照都记录的很清楚。在传统意义上，这种日志已经可以接受的。

这种情况的问题在于对数据组同学很不友好，因为不同方法的参数、顺序不同，导致数据组同学将日志导入hive等大数据环境前需要做进一步的转换，而且对不同的方法要和不同的开发同学沟通。更别提已有的方法发生变动，被大领导发现报表数据不对才发现问题，这种问题导致的锅，年终奖要扣谁的都不好说。
也许是笔者曾经身兼数据组和业务开发组，所以有些吹毛求疵。也有可能是因为笔者作为数据开发有些懒😃

---

说了这么多问题，接下来说解决方案，其实也是笔者在职业生涯中遇见的认为比较好的处理方式，给大家分享一下

3、待续(临时出bug)