工作中遇到用户反馈问题,通常最直接有效的办法就是获取用户日志,根据日志来排查问题。稍微大一点的项目,一天的log大概有上万行甚至上百万行。如何在短时间内排查问题呢?
提取关键信息
假设需要根据一个一百万行的log文件查某个问题,那往往只需要用户出现问题的那个时间点附近的log,另外,也只需要自己所关心的业务相关的log,其他业务的不需要关注。
一般来说,根据打印log的规范,其前缀都会包含业务相关的信息,比如业务相关的类名、函数名等等。我们只需要过滤出这些特定的log,就能很轻松的看到用户的点击流,以及到底走到了哪些异常的分支。
看log推荐用VSCode,有很多比较好用的插件,另外在打开和预览大文件时的性能也很棒。Filter Line是VSCode的一个插件,提供了根据关键字过滤log的功能。具体使用方法可以查看该插件的README。
前几天总监反馈了一个问题,说用户的某个公众号在同一时间收到了多条完全一样的消息。然后我拿到log之后,打开之后是这样的:
90w+的log,即使知道用户是在哪个时间点出现的bug,也很难快速查出具体原因。
但是,这么多log,和自己业务相关的,以及和用户反馈的bug相关的,其实很少:
90w+的log,在几秒钟时间提取了30条有效信息,立刻就判定后台确实在同一时间下发了重复的消息,然后拉后台同学排查即可。
对Filter Line的吐槽
上面介绍了使用Filter Line过滤log的例子,绝对是提升效率的神器。想想你用比别人更短的时间解决了问题,多刺激。先感谢这个插件的作者的付出。
但是让我很不习惯的是,对大文件的支持不太好,如果log文件比较大,需要使用所谓的“large file mode”,这不扯么,完全可以发现文件比较大时,自动切换策略,不需要使用者去做额外的工作。而且,亲测我把log文件删的只剩5k行,依然被当成large file。
顺便说说log相关的几点建议
根据log查问题,首先你的log要稍微全一些,如果平时写需求都不打log,那就很难查问题了。
打log时尽量上下文能串起来,打log不能走形式,而是为了后面出了问题容易反查,比如,用户某一次点击流的n行log,要能对应的上,要能看出来这个用户的关键信息和操作。
查问题时,尽量快,最明显的,同一个问题,你需要十分钟,别人需要一个小时,虽然最后都解决了,但是综合效果肯定差别很大。
log里不要包含敏感信息,比如用户余额,聊天记录等等。
题图:傍晚的深圳湾一号。