第三点，发现如果日志的格式没有一定约束的话，会很容易产生非常多的无效日志，不能保证数据质量，因此我们对日志的格式也应该有一定的约束性和一定的强制性；

第四点，整个系统出现异常的情况下，怎么样能够快速地或者自动地去检测到这个异常，所以需要一个异常检测的模块；

最后一点，现在越来越多的系统已经不能满足批处理和离线的方式，在我们的日志平台中间也需要引入实时流处理的模块，使得日志能够更快地让用户查询或者进行一些数据聚合操作。

下面分别介绍一下每个方向的工作。

模块检测

首先，模块故障的监控，这个是比较直接的，对于日志系统中间的每个模块需要保证正确性和可靠性。比如进程的监测，进程是否活着，对于 CPU 和内存的使用量。因为日志系统有数据的输出和输入，对比数据的输出和输入帮助我们发现系统的故障。很多时候，比如对 Airbnb 网站来说，数据是有季节性的，比如说每周一、每周二我们平台的数据量会上升，到了周末数据量会下降，因此对数据会有一个季节性的对比，把这周一的数据和上周一的数据对比看有没有差别，如果差别很大看系统是不是有一定的错误。有了这些基本的模块级别指标之后就可以建立预警机制，发生错误的时候可以告知，检查系统错误。

端到端审核

除了模块级别的监测之外我们还要考虑端到端的审核制度。首先，我们监测每个模块不足以保证整个系统的可靠性，比如有些错误是未知的，没有看到过所以目前的监测手段会失效，因为我们不知道监测怎么样的指标去发现错误。第二个，需要量化整个系统的可靠性。第三个，在发生错误的时候要尽快定位到错误发生的模块。第四个，需要除了应用系统本身的指标去监测系统之外，还希望有一些第三方的数据或者带外的形式，和日志系统的指标进行对比，发现系统的错误。

基于这几点我们主要提供了心跳日志和数据库更新日志。心跳日志就是一种虚假的或者人工的日志，能够定期向不同的服务发送，按照一定的速率，通过在后端数据库里面聚合这些心跳日志，就知道整个平台是不是产生了数据丢失，这个方法非常简单、有效、可靠。另外，我们可以通过一些数据库的更新日志，比如订单日志，每次订单产生都会对数据库产生一次更新，更新的次数会被统计出来，根据更新的次数对比在后台数据操作中订单日志的差别，我们可以发现整个系统日志平台是不是可靠，数据库的更新日志提供一种带外的方式检查整个平台的可靠性。

对于整个平台端到端的日志审核，主要是在日志中添加一些辅助的信息，比如日志 ID（唯一识别的 ID）、主机名称、进程号、序列号、时间戳等等，有了这些辅助信息之后就可以量化数据平台的可靠性。同时可以计算，日志在整个系统平台中间每一跳的可靠性。

这是一个简单的例子，在每个日志中间需要添加这些信息，比如数据的类型、数据唯一的标识，数据在整个流程中会经过节点，每个节点会有一些类型、主机号、IP 地址、时间戳、序列号等等。

日志格式

有了端到端的保证和模块级别监控之后，依然不能保证整个系统的可靠性，是因为日志的格式还没有得到保证，会产生一些错误的日志格式。