JB的ARTS之旅-关于日志的那些事-CSDN博客

前言

很多小伙伴看到标题，可能会有疑问，什么叫ARTS？，这里答疑一下：
这是来自于左耳朵耗子专栏的一个活动，详情请来到某乎了解；

而ARTS实际意义是：

1.Algorithm：每周至少做一个 leetcode 的算法题
2.Review：阅读并点评至少一篇英文技术文章
3.Tip：学习至少一个技术技巧
4.Share：分享一篇有观点和思考的技术文章
复制代码

因精力有限，暂时只能挑一个完成，希望见谅；

正文

这次的主题是，关于日志的那些事，其实上一篇JB的测试之旅-关于线上问题的看法已经有提及到日志相关的内容，这里再结合这个话题，一起再聊聊关于日志的那些事吧；

首先说明，这里不会说，哪个日志有哪个日志模块，也不会说怎么手撸日志，这里只管讲一些对日志的看法跟思考，可能偏基础，望大神轻虐；

什么是日志？为什么需要日志？

日志日志，顾名思义，日就是每天的意思，志就是文章/笔记的意思，连起来，就是每天写笔记\文章；

好比学生写作文、写情书，工作写日报一样，主要的目的，就是用来记录信息，而对于计算机来说，本质是一致的；

为了确保程序是按照预想的路径执行，记录日志是必不可少的一步，一旦日志输出顺序不符合预期，则说明程序出错了，就可以很快的根据日志来跟进问题；

比如，用户反馈使用我们的产品提现1W块，但是一直没到账，要求赔偿；如果没有日志\记录，这问题怎么跟进？如果用户是特意骗钱的呢？

而在计算机里面，日志是用来记录程序的执行过程，但日志不是万能的，日志是强依赖开发者的水平，埋点埋的好，日志就有效，相反，也可能成为鸡肋，多余的日志反而会影响问题的分析；

日志的级别

既然日志是一个好东西，那，是不是每一行都把日志打上，这样是不是最稳妥了？日志在手，bug不走~

答案也是否定的，日志虽然重要，但是过多的日志会导致3个问题：

日志冗余
磁盘空间占用大
不利于快速分析问题

毕竟，服务器资源有限，无脑生成日志，最终的结果肯定是服务器炸了；

什么？扩容？多少都不够你用吧！
什么？定时删除？那你删啊，有问题没日志谁的锅！

既然不能无脑生成日志，那到底要按什么维度生成日志？

这里就截取了AS里面的截图，如图：

安卓log等级分几块：Verbose,Debug,Info,Warn,Error,Assert

级别	作用
Verbose	开发调试过程中一些详细信息，不应该编译进产品中，只在开发阶段使用
Debug	用于调试的信息，编译进产品，但可以在运行时关闭，一般是开发阶段使用
Info	运行时的状态信息，这些状态信息在出现问题的时候能提供帮助
Warn	警告系统出现了异常，即将出现错误
Error	系统已经出现了错误，一般会包含上下文信息
Assert	断言，一般是开发阶段使用

一般来说，Info、Warn、Error这三个等级的Log的警示作用依次提高，需要一直保留。因为这些日志在系统异常时能提供有价值的线索；

其他语言，应该来说，日志级别应该是类似的，比如ios的DDlogError、DDlogWarn、DDlogInfo、DDlogVerbose，看上去没有太多区别，也能理解，所以其他语言就不介绍了；

日志的类型

日志是个好东西，除了跟进问题，还有很多作用；

类型	意义
行为日志	记录用户每一步行为，便于后续产品等进行数据分析
错误日志	记录异常信息，便于问题排查
性能日志	记录不同性能的数据，比如启动速度、内存，用于性能监控及优化数据
操作日志	如果说行为日志是偏向用户侧，那操作日志就是偏向程序，记录具体操作的所有信息

日志的命名

在说命名之前，要先搞懂，日志的命名跟格式，到底是给谁看的？

这个问题也明显，明显是给人看，不同职能，比如运营、测试、研发、客服的技术水平都不一样，那日志的命名就很讲究了，要用一种通俗的方式让不同同学都能一眼辨别这个日志类型；

这里就不拐弯抹角，直接贴出老东家的样式，个人觉得蛮好的；

“产品名_版本号_流水号_机型_Android系统版本_时间戳_崩溃产生时间_产生场景(值为fg/bg)_
崩溃类型.log[.en|.jm]” 的格式
复制代码

名称	意义
产品名	产品名称
版本号	产品的版本号
流水号	产品打包的流水号，如APP打包的时间
机型	用户机型
系统版本	用户手机的系统版本
时间戳	日志生成的时间戳，单位ms
问题产生时间	具体时间，如20181119170213
产生场景(值为fg/bg)	fg代表前台，bg代表后台
问题类型	问题类型，自己定义
后缀	log、zip、jm等，自己定义

比如：

HJGT_3.3.0_181110155106_xiaomi-note3_8.1.0_1542618061000_20181119170101_fg_java.log 
复制代码

根据上面的日志名称，就能很容易的看出这个日志相关的信息；

这里可能会有同学有疑问，为什么要有产生场景，一般用哪个？
一般来说，都会用fg，因为大部分场景都是前台毕竟多，但是有些问题的确是出现在后台的时候，比如APP切换到后台，安卓内存不足，应用被系统杀掉了，从用户角度来说，会觉得你这个产品真烂，切换后台就需要重新打开APP了，此时就需要这个标记来区分日志；

又有同学可能会问，问题类型呢？
这里没有具体明确，内部自己定义，可以用Java表示Java层crash，也可以用novel来表示是小说业务出错了，也可以用news表示新闻业务出错了，内部定好这个规范就好，同时也可以叫jb；

日志的格式

既然，日志是给人看的，那优雅的排版，可能能让人看得赏心悦目，同理，错乱的排版，简直如同大海捞针，如果不是为了工作，谁愿意看；（本是同根生，相煎何太急）

并且，日志最终会上传到服务器，就算人不看，程序也会"看"，如果日志格式不好，程序"看"的也会很辛苦，变现提高工作量；

既然排版那么重要，那日志的排版怎么弄才好？

这里的话，在线上问题有提及到，采用的是公共及业务两个区块，如下：

********************************************
#此处公共模块信息
版本号：XXXX
子版本号：XXXXX
流水号：XXXX
时间：XXX
模块：小说\崩溃\anr等
********************************************
#具体业务日志内容
开始启动APP
启动成功，进入主界面，启动时长2S
点击搜索框
调起输入法
输入 电影推荐
删除输入框内容
等等...
********************************************
复制代码

当然，这只是推荐而已，这样做的好处是，清晰，给人一种一目了然的感觉；

Q:假如是行为日志，那怎么办？
A:行为日志的，建议使用key:value的形式；

Q:如果一份日志有多份内容呢？
A:其实不太建议这种做法，因为这对于服务端而言，需要做差异化处理，服务端的同学第一反应是no，如果非要做，格式可以用上面那样，只是服务器那里的脚本要单独处理下；

一般来说，考虑到服务器的容量，上传前都需要对原始日志压缩一下，尽可能减少日志的大小；