日志收集的 “DNA”

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

关于日志收集的文章，xjjdog已经写了不少了，比如下面这八篇文章。今天主要介绍一下关于日志的划分。工具虽然有力，落地才能有效。

[1] 这么多监控组件，总有一款适合你

[2] elkb实践经验，再赠送一套复杂的配置文件

[3] 昔日教人类用火的prometheus，如今在努力报警

[4] 你的野花，朕的kibana

[5] 2w字长文，让你瞬间拥有「调用链」开发经验

[6] 这一轮，skywalking胜出

[7] 冷门instrument包，功能d炸天

[8] 微服务不是全部，只是特定领域的子集

日志收集是每一家公司都需要的基础组件，尤其是已经步入正轨的公司。但是，日志收集要收集哪些内容呢？我们要对这些信息一视同仁么？

日志种类划分

一般说到日志，想到的都是后端日志。但是后端日志根据不同的需要和日志级别，最终的流向和处理方式也是不一样的。

iURjuaU.png!web

普通业务日志。你要知道，在这个世界中，线上开着DEBUG日志级别跑的程序员，到处都是。那些像撒尿一样的流水账，是没必要收集的。也就是说，业务日志中，大多数都是没用的东西。对待这种数据，我们只要有个地方进行统一存储就可以了。

检索型业务日志。检索的业务日志，是有业务属性的。比如你的系统和第三方支付进行对接所产生的 报文交互 数据。它们比普通业务日志有用，但又没有存放到数据库的必要，我们一般的处理方式就是收集到ES这种大容量的存储中。

并不是说你收集到ES，挂个 kibana 就完事了。这些信息我们还需要检索，也就是字段要有具体的意义。这时候， 普通字符串 就没什么用了，需要转化成 json 一类的规格数据，这样就可以根据某个条件进行搜索统计。

ES和mongo对此支持也都不错。

检索型业务日志是建设的重点，需要对日志输出组件进行二次开发和定制，配合完成。

vmUvMbz.png!web

以下是一个可能的外观接口。

//输出携带参数的日志，参数为偶数，将会对其进行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");

//手工组装参数(参数非常多时，建议此方式)
Map<String, Object> param = new HashMap<>();
param.put("vendorid", 5);
param.put("madetime", new Date());
param.put("orderno", 21731310830180019L);
LogMe.out("test map","remarkaa", param);

//error堆栈+参数，以上两个方法都可以追加异常栈
LogMe.out("error","remark error", new Exception("error"), "vendorid", "5", "storecode", "1011");

异常日志。异常日志又是一种流向。对待这一类信息，我们希望得到两个效果。第一、异常日志能够及时的被业务人员发现；第二、异常日志能够被统计和事后分析。所以，一个触发式的日志处理链，以及检索型的上下文查询，都是必要的。

APM这个和前端，终端综合起来，可以进行调用链追踪，行为分析等，一般是垮端的整体性分析。市面上有很多这样的产品，包括收费的和开源的。

再向上，就是一些终端的日志。终端包括Android、IOS，以及其他手持设备。它和WEB端是类似的，只是工具链不同。

行为日志。你在使用一些App的时候，都会默认勾选上一个叫做 匿名发送使用数据-帮助我们提高 的选项。最详细的行为数据记录，用户的每一次点击事件，都会产生一条日志，这些日志会传送到服务端进行分析。这种日志的数据一般是非常庞大的，需要专门处理，使用 TSDB 等超大容量的存储进行存放。

终端异常日志终端的异常日志一般是个技术活。除了收集应用正常运行中产生的异常，还需要获得应用异常退出时候的异常信息。

可以看到，每一种日志都有它自己的使用场景，后端使用的技术栈也不尽相同。