云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！
日志收集是每一家公司都需要的基础组件，尤其是已经步入正轨的公司。但是，日志收集要收集哪些内容呢？我们要对这些信息一视同仁么？
日志种类划分
一般说到日志，想到的都是后端日志。但是后端日志根据不同的需要和日志级别，最终的流向和处理方式也是不一样的。
普通业务日志。 你要知道，在这个世界中，线上开着DEBUG日志级别跑的程序员，到处都是。那些像撒尿一样的流水账，是没必要收集的。也就是说，业务日志中，大多数都是没用的东西。对待这种数据，我们只要有个地方进行统一存储就可以了。
检索型业务日志。 检索的业务日志，是有业务属性的。比如你的系统和第三方支付进行对接所产生的报文交互数据。它们比普通业务日志有用，但又没有存放到数据库的必要，我们一般的处理方式就是收集到ES这种大容量的存储中。
并不是说你收集到ES，挂个kibana就完事了。这些信息我们还需要检索，也就是字段要有具体的意义。这时候，普通字符串就没什么用了，需要转化成json一类的规格数据，这样就可以根据某个条件进行搜索统计。
ES和mongo对此支持也都不错。
检索型业务日志是建设的重点，需要对日志输出组件进行二次开发和定制，配合完成。
以下是一个可能的外观接口。
//输出携带参数的日志，参数为偶数，将会对其进行key，value配对。
LogMe.out("title","remark aa", "vendorid", 5, "storecode", "1011", "poscode", "POS1111", "version", "7.0.0.16");
//参数为奇数，放入_all字段，无法根据内容查找（要尽量避免此情况）
LogMe.out("test _all title","remark aa", "vendorid", 5, "storecode", "1011", "poscode", "POS1111", "version");
//error堆栈+参数，以上两个方法都可以追加异常栈
LogMe.out("error","remark error", new Exception("error"), "vendorid", "5", "storecode", "1011");
异常日志。 异常日志又是一种流向。对待这一类信息，我们希望得到两个效果。第一、异常日志能够及时的被业务人员发现；第二、异常日志能够被统计和事后分析。所以，一个触发式的日志处理链，以及检索型的上下文查询，都是必要的。
APM 这个和前端，终端综合起来，可以进行调用链追踪，行为分析等，一般是垮端的整体性分析。市面上有很多这样的产品，包括收费的和开源的。
再向上，就是一些终端的日志。终端包括Android、IOS，以及其他手持设备。它和WEB端是类似的，只是工具链不同。
行为日志。 你在使用一些App的时候，都会默认勾选上一个叫做匿名发送使用数据-帮助我们提高的选项。最详细的行为数据记录，用户的每一次点击事件，都会产生一条日志，这些日志会传送到服务端进行分析。这种日志的数据一般是非常庞大的，需要专门处理，使用TSDB等超大容量的存储进行存放。
终端异常日志 终端的异常日志一般是个技术活。除了收集应用正常运行中产生的异常，还需要获得应用异常退出时候的异常信息。
可以看到，每一种日志都有它自己的使用场景，后端使用的技术栈也不尽相同。
干什么用？
后端日志收集之后，大多数是为了辅助开发或者运维进行问题定位，减少分析问题的时间。
我们着重说一下客户端日志收集。
除了偷偷使用你的硬件进行挖矿的无良App，还有类似支付宝这种偷偷拍你的照，录你的音的大厂软件（自行搜索，我姑且认为这是真的）。目的都是为了采集用户数据，搞一些类似大数据杀熟的勾当。像iphone本身等也有类似的功能，比较缺德的是默认是打勾的。
大多用户对自己的行为数据无感知，但当大量的数据聚合起来，厂商会觉得很香，很带感。做技术当然是去实现就好，不用去谴责自己的良心，天塌下来还有公关部那群炮灰顶着呢。
和APM这种用来用来改善调用关系、性能的工具不同，客户端收集的数据更加零散，业务模型也更加多样化。
用户的数据即然这么宝贵，那么都收集些什么呢？又是怎么收集呢？当然不是通过收集调查问卷。用户的每个点击，甚至页面的停留时间，都可能会成为被分析的对象。
由于用户安装了你的软件，其硬件环境的信息也能够获取，包括调用硬件的设备采取的包括用户隐私、截图、音频、视频等数据等。所以收集的数据是多种多样的。
1、硬件信息
这个在Android设备上体现的比较明显。收集这些数据用来分析app与设备、设备版本、语言等之间的关系。可以将工作重点转向市场占用率高的设备和版本上。你可能还会收集设备的CPU、内存、显卡等信息，以便对你的产品进行专项优化。
2、软件环境
收集自有软件的信息
软件版本。通过分析用户安装的每个软件版本的数量，你可以决定那些版本可以不在维护，哪些版本发生的bug多等，是你很多决策的依据。
收集其他软件的信息
3、功能监控
对一些灰度的，或者重要的功能进行监控。比如你新上线了一个idea，到底行不行，还得需要线上数据来验证。通过分析日志，就能判断出哪些产品经理的主意是非常差劲的。
4、LBS
用户位置数据是非常敏感的。LBS曾经成就了陌陌，对于大部分应用来说，位置数据可以分析产品在某个区域、省份、国家的受欢迎程度和差异化。
当你发布了一个新的产品需求，就应该考虑到后期的数据追踪，以便评估你的需求效果。包括在发布期间用户的装机、卸载量。这都是有数据支撑的，而不是拍脑袋决定的。
5、行为数据
前几年还是比较火的推荐功能，现在加上深度学习的加持，分析更为准确。机器会在后台默默的记录你的喜好，并产生相应的输出，投你所好。
End
综上所述，设计一个比较全面的日志系统，还是有一番挑战的。不同类型的业务日志，有着不同的分析处理方式，数据的最终流向也不尽相同。xjjdog后续会尝试从日志规范方面，将这个体系进行整体的归纳。
【云栖号在线课堂】每天都有产品技术专家分享！
课程地址：https://yqh.aliyun.com/zhibo立即加入社群，与专家面对面，及时了解课程最新动态！
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
原文发布时间：2020-04-13
本文作者：小姐姐味道
本文来自：“掘金”，了解相关信息可以关注“掘金”
