前言

很多小伙伴看到标题，可能会有疑问，什么叫ARTS？，这里答疑一下：

这是来自于左耳朵耗子专栏的一个活动，详情请来到了解；

而ARTS实际意义是：

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

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

正文

这次的主题是，关于日志的那些事，其实上一篇已经有提及到日志相关的内容，这里再结合这个话题，一起再聊聊关于日志的那些事吧；

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

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

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

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

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

比如，用户反馈使用我们的产品提现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，如果非要做，格式可以用上面那样，只是服务器那里的脚本要单独处理下；

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

日志的安全

日志有了，那就需要考虑日志安全了，毕竟，如果日志明文了，别人获取到，就知道你的产品做了什么，提供了一种入侵的手段了；

一般来说，本地生成日志后，会把日志进行加密处理，然后回传给服务器，服务器再解密，至于加密算法，不同公司采用不同算法，这里只有一点忠告，尽可能是比较复杂的算法，提高被破解门槛；

如何体现日志的价值

现在我们所处大数据时代，记得一句话，数据本身没有意义，数据的意义，都是人赋予的；

如果不做数据分析，再多的数据也没有意义，那如何把日志的价值发挥的淋淋尽致？

那就是日志分析系统；

简单描述下，日志分析系统应该要有什么功能：

• 定时解密、解析日志，数据入库；
• 前端支持自定义查询，展示不同数据；
• 支持不同维度展示数据，如pv、uv、占比等；
• 后端支持把日志的重要问题反馈出来；
• 前端可以通过树状、曲线等方式来呈现问题严重性、趋势等；

既然有发现问题的渠道，那就需要有监控的渠道了；

监控告警就简单了，只需要制定好告警的策略，达到就报警（邮件、钉钉、微信等各种通知）；

一般告警的手段有两种：

• 关键字，比如出现闪退，崩溃，打不开，立马通知，毕竟是影响用户的路径；
• 统计，比如接口平均成功率低于90%；

当然，上面说的都是后端的，那前端呢？

前端也需要干点活，比如控制日志大小，加密，确保日志能百分比落地等，这里不细说，网上的轮子太多了。。

jb相信，肯定还有比上面更优的手段，欢迎大家补充，一起进步；

小结

感觉，这个话题到这里了，可能还会有补充，后续想到再补充，常规操作，来个小结；

本文主要是介绍了日志相关的信息，包括级别、类型、命名、格式、安全以及日志配套的东西，在这几个方面，小结几句话：

• 线上环境的日志不能无脑生成，过多的无效日志是一种累赘；
• 使用日志前，先想清楚，日志的作用是什么？属于哪种类型，不然牛头不对马嘴就不好了；
• 日志的命名，尽可能做到通俗易懂，做到小白一看就明白就最好了；
• 日志内容格式要注意，不能随心所欲，原则是排版清晰，一目了然；
• 日志尽可能加密，减少被篡改以及被黑的途径；
• 有了日志，就要有相关配套，或者就跟摩托车没油一样（如果非要推着走，也可以）

好啦，就这样吧，谢谢大家~