一种基于访问日志的应用状态监控报警系统及方法与流程

本发明属于分布式发布订阅消息技术领域，特别是涉及到分布式订阅消息用于应用状态监控报警的技术。

背景技术：

目前移动互联技术高度发达，人们日常生活中的各种功能、事务都借助于网络服务来解决。另一方面，随着互联网用户的不断增加，大型的网站一般会采用多台相同角色的应用服务器，组成分布式网络系统，从而在用户访问网站时，各应用服务器能够较为均衡地接入用户，从而实现分布式网络系统的负载均衡。

在现有分布式网络系统中，为了保障网站的正常运行，需要对网站的可用性进行监控。网站的可用性包括各应用服务器系统层面的可用性以及应用服务器提供的网页页面应用内容的可用性，其中，对于系统层面的可用性，现有技术的监控比较完善，例如，可以针对负载、网络带宽、cpu、io、内存等基础数据提供完善的监控。而对于应用内容的可用性监控比较复杂，具体来说，一方面，应用内容错误并不一定导致系统层面的错误，另一方面，应用内容错误直接与用户获取信息的准确度相关，而应用内容的异常情况多种多样，例如，应用程序部分异常，会降低网页展示的应用内容的准确性，使得该网页页面展示的应用内容是错误的，或者是不全的。

为了及时处理应用服务器由于应用程序出现的应用内容错误，一些应用方案及其存在的技术问题如下所述。

1.应用监控报警技术。应用程序会自定义一个health_check的页面，来对应用的状态进行输出，如果应用服务出现服务异常，通过监控此health_check的方式来及时发现应用服务的故障问题，通过报警及时通知技术人员分析原因。应用的监控报警技术存在覆盖率不足的问题，覆盖率依赖于部署的监控的客户端和业务是否增加了报警的统一规则，一般只是代表监控客户端的物理情况、网络情况，并不能代表所有线上真实用户的访问情况，因此可能会遗漏部分场景，特别是对于集群环境下的监控，部署的监控节点的客户端存在路由覆盖不到的情况，部分集群内的机器业务的状态并不能被监控到。

2.http服务监控。http服务监控技术会定时请求访问的资源，通过定义返回的状态和返回的值来判断是否存在异常情况，如果存在异常状态，则通知用户报警。http服务监控一般是单独部署模拟的客户端模拟实际请求调用应用的服务，存在的主要缺陷是客户端有限，没法覆盖全部场景，因为ip的有限，也很难覆盖到集群服务下的所有业务的服务主机。由于现在的系统部署都采用高可用的集群部署方式，而覆盖率往往依赖于客户端的节点情况，比如如果节点ip被hash到同一台或者其中几台业务机器上，其他的机器的运行情况并不能被发现。还有种情况是各地运营商的情况不同，服务的响应可能也不一样。

3.应用日志监控。为了及时发现应用服务的错误，应用服务大部分会集成日志框架，比如log4j、logback等，日志框架会分别定义debug、info、warn、error等不同级别的日志级别，一般发系统级错误异常通过error的级别去输出，很多公司会基于对error日志的监控，来通过应用管理员及时发现和关注应用的服务日志。虽然这些应用利用日志方式针对自己的服务状态做了监控，但这仅仅是对自己的业务系统的事件或者日志进行监控和报警，而实际的很多场景是因为业务系统外部的因素导致服务不可用，比如网络不稳定、外部安全设备拦截等导致的问题，业务系统是感知不到的。另外，应用级别的监控技术只局限于业务的异常，对资源是否存在、url是否错误、超时类异常等都很难捕获，特别是静态资源、接口调用方面出现的概率比较大。

技术实现要素：

为解决现有技术中各类应用服务监控以及报警技术存在技术问题：1)应用级别的监控以及报警技术只局限于业务的异常，对资源是否存在、url是否错误、超时类异常等都很难捕获，特别是静态资源、接口调用方面出现的概率比较大；2)覆盖率不够，监控的覆盖率依赖的部署的监控的客户端，一般只是代表监控客户端的物理情况、网络情况，并不能代表所有线上真实用户的访问情况，会遗漏部分场景；3)并没有形成体系化，没法通过后端服务来进行数据统计以及分析，在此基础上做到对可用性的预估和优化度量。提出一种基于访问日志的应用状态监控报警方法，直接接入所有接入端的日志，能够分析所以访问日志的情况，能够触及到所有真实用户的情况。

为了实现该技术效果，本发明采用了如下的技术方案。

一种基于访问日志的应用状态监控报警系统，包括日志收集模块、日志订阅模块、过滤器链组件以及数据库模块，其中，

所述日志收集模块用于将来自日志源的应用日志文件进行处理和格式转换为数据流，将数据流按照主题作为应用日志消息进行存储和发布；

日志订阅模块用于根据主题订阅应用日志消息，并将应用日志消息推送给过滤器链组件，进行应用日志消息处理；

所述过滤器链组件还用于访问数据库模块，将应用日志消息及其处理结果进行存取、查询和更新；

其中，所述过滤器链组件中包括报警模块，用于根据应用日志消息的业务状态，以及应用与系统的关联规则，向系统关联负责人发送报警信息。

另外，所述日志收集模块按照集群方式进行存储和发布，所述集群包括多个服务器节点，每个服务器节点存储一主题应用日志消息的一个或多个分区；所述日志订阅模块采用拉取的方式获取应用日志消息，所述拉取的方式为每次按照预定偏移量拉取一定数量的应用日志消息。

另外，所述过滤器链组件还包括http状态分析器，所述http状态分析器模块通过分析http代码来确定应用日志消息是否属于报警业务规则内；所述http状态分析器还过滤静态资源，将与跟业务不相关的静态资源进行过滤；所述http状态分析器模块通过所述http代码分析以及静态资源过滤操作来确定应用日志消息的业务状态。

另外，所述过滤器链组件还包括用户分析器，所述用户分析器连接至报警模块，用于根据预设应用与系统之间的关联规则，确定系统关联负责人的联系信息，当所述应用日志消息的业务状态分析结果为需要报警时，将需要报警的数据及系统关联负责人的联系信息返回给报警模块，报警模块发送相关的报警信息。

另外，所述过滤器链组件还包括统计模块，所述统计模块用于对应用日志消息进行归类和统计分析，所述统计模块通过将应用日志消息按照登录应用、登录地址、登录代码等维度进行数据归类和统计，后期为分析提供基础数据。

另外，所述过滤器链组件还包括缓存管理器，所述对基础配置信息进行缓存和更新，以及将基础配置信息传递给数据库。

另外，所述过滤器组件还包括数据库管理器，所述数据库管理器用于使用jdbc连接关系数据库和在线分析数据库，为所述过滤器组件的其他业务模块提供快速数据库的查询和更新服务。

一种基于访问日志的应用状态监控报警方法，包括步骤：

a、将来自日志源的应用日志文件进行处理和格式转换为数据流，将数据流按照主题作为应用日志消息进行存储和发布；

b、根据主题订阅应用日志消息，并将应用日志消息推送给过滤器链组件，进行应用日志消息处理；

c、根据应用日志消息的业务状态，以及应用与系统的关联规则，向系统关联负责人发送报警信息；以及，

d、访问数据库模块，将应用日志消息及其处理结果进行存取、查询和更新。

另外，所述将数据流按照主题作为应用日志消息进行存储和发布包括：按照集群方式进行存储和发布，其中所述集群包括多个服务器节点，每个服务器节点存储一主题应用日志消息的一个或多个分区；且所述根据主题订阅应用日志消息的步骤包括：采用拉取的方式获取应用日志消息，所述拉取的方式为每次按照预定偏移量拉取一定数量的应用日志消息。

其中，所述进行应用日志消息处理的流程包括确定应用日志消息的业务状态，所述确定应用日志消息的业务状态具体包括：

b21、通过分析http代码来确定应用日志消息是否属于报警业务规则内；

b22、将与跟业务不相关的静态资源进行过滤。

附图说明

图1为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警系统的结构示意图。

图2为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警方法的流程图。

图3为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警系统中日志收集模块的结构示意图。

具体实施方式

下面结合附图，对本发明作详细说明。

以下公开详细的示范实施例。然而，此处公开的具体结构和功能细节仅仅是出于描述示范实施例的目的。

然而，应该理解，本发明不局限于公开的具体示范实施例，而是覆盖落入本公开范围内的所有修改、等同物和替换物。在对全部附图的描述中，相同的附图标记表示相同的元件。

参阅附图，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。同时，本说明书中所引用的位置限定用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

同时应该理解，如在此所用的术语“和/或”包括一个或多个相关的列出项的任意和所有组合。另外应该理解，当部件或单元被称为“连接”或“耦接”到另一部件或单元时，它可以直接连接或耦接到其他部件或单元，或者也可以存在中间部件或单元。此外，用来描述部件或单元之间关系的其他词语应该按照相同的方式理解(例如，“之间”对“直接之间”、“相邻”对“直接相邻”等)。

图1为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警系统的结构示意图。如图所示，本发明具体实施方式中公开了一种基于访问日志的应用状态监控报警系统，包括日志收集模块、日志订阅模块、过滤器链组件以及数据库模块，其中，

所述日志收集模块用于将来自日志源的应用日志文件进行处理和格式转换为数据流，将数据流按照主题作为应用日志消息进行存储和发布；

日志订阅模块用于根据主题订阅应用日志消息，并将应用日志消息推送给过滤器链组件，进行应用日志消息处理；

所述过滤器链组件还用于访问数据库模块，将应用日志消息及其处理结果进行存取、查询和更新；

其中，所述过滤器链组件中包括报警模块，用于根据应用日志消息的业务状态，以及应用与系统的关联规则，向系统关联负责人发送报警信息。

因此，本发明能够准实时掌握业务系统运行过程中，线上用户访问业务系统的情况，直接基于线上真实的访问情况，通过完整的日志定位和日志输出，帮助平台运营人员、技术人员快速发现问题并定位问题，从而提高整个业务系统的稳定性和服务质量。

图3为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警系统中日志收集模块的结构示意图。如图3所示，本发明具体实施方式中，所述日志收集模块按照集群方式进行存储和发布，所述集群包括多个服务器节点，每个服务器节点存储一主题应用日志消息的一个或多个分区；所述日志订阅模块采用拉取的方式获取应用日志消息，所述拉取的方式为每次按照预定偏移量拉取一定数量的应用日志消息。

典型地，日志源的信息来自于nginx服务器，所述nginx(enginex)是一个高性能的http和反向代理web服务器，同时也提供了imap/pop3/smtp服务，nginx作为负载均衡服务：nginx既可以在内部直接支持rails和php程序对外进行服务，也可以支持作为http代理服务对外进行服务。

nginx能够针对多个应用的状态和动作产生日志文件，可以服务于所有nginx后端的业务系统。接下来，将来自nginx服务器的日志文件，基于heka的功能，对日志文件进行提取、分析、格式转换等，然后将格式化后的文件转换为数据流，将数据流通过kafka组件，将格式化后的应用日志数据流发给kafka消息服务，进行数据存储。

kafka组件的典型特点是：消息被持久化到多个主题(topic)中。与点对点消息系统不同的是，消费者可以订阅一个或多个主题，消费者可以消费该主题中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。

如图3所示，针对某一主题的应用日志消息，配置了4个partition(分区)。第1分区有两个偏移量(offset)：0和1；第2分区有4个偏移量；第3分区有1个偏移量；第4分区有3个偏移量。

如果一个主题的副本数为4，那么kafka将在集群中为每个部分创建4个相同的副本。集群中的每个服务器节点(broker)存储一个或多个分区。多个发布者和消费者可同时生产和消费数据。

其中存储第一个副本的服务器节点被称为引领节点(leader)，后面的服务器节点被称为跟随节点(follower)。首先kafka会将接收到的消息进行分区，每个主题的消息有不同的分区。这样一方面消息的存储就不会受到单一服务器存储空间大小的限制，另一方面消息的处理也可以在多个服务器上并行。其次为了保证高可用，每个分区都会有一定数量的副本。这样如果有部分服务器不可用，副本所在的服务器就会接替上来，保证应用的持续性。为了保证较高的处理效率，消息的读写都是在固定的一个副本上完成。这个副本所在的节点就是所谓的引领节点，而其他副本所在的节点则是跟随节点。而跟随节点则会定期地到引领节点上同步数据。

因此，本发明中将来自多个应用的日志文件，按照不同主题存储在kafka集群上，并通过kafka集群进行发布，一方面保证了处理的效率，一方面还能保证系统的高可用性。

作为日志订阅模块的的kafka消费者通过订阅kafka的应用日志消息，将应用日志消息推送给日志处理组件核心的过滤器链组件，为了避免雪崩事件，消息的获取方式是通过拉的方式，每次通过预定偏移量拉取消息。所述预定偏移量能够动态配置，根据业务情况，例如在一个具体实施方式中，所述偏移量选择为10000条，过滤器链组件基本可以在10秒内处理完这些消息，实时性较好。

因此，本发明中有效地进行了削峰处理，所述削峰处理是指流量很大的时候(例如多个应用被用户大量访问，因此短时间内产生了大量的日志文件)，被了避免日志处理组件的性能瓶颈，产生雪崩效应，本发明具体实施方式中通过kafka的预定偏移量方式来处理，限定日志订阅模块能够拉取预定偏移量的应用日志消息，避免了数据量过大对日志处理组件产生冲击。

由于现有技术中的的系统部署都采用高可用的集群部署方式，而覆盖率往往依赖于client的节点情况，比如如果节点ip被hash到同一台或者其中几台业务机器上，其他的机器的运行情况并不能被发现。还有种情况是各地运营商的情况不同，服务的响应可能也不一样。针对此情况，本发明具体实施方式中，因为直接接入所有应用接入端的日志，能够分析所有访问日志的情况，能够触及到所有真实用户的情况，因此能够解决现有技术中存在的覆盖率偏低问题。

在本发明一具体实施方式中，所述过滤器链组件还包括http状态分析器，所述http状态分析器模块通过分析http代码来确定应用日志消息是否属于报警业务规则内；所述http状态分析器还过滤静态资源，将与跟业务不相关的静态资源进行过滤；所述http状态分析器模块通过所述http代码分析以及静态资源过滤操作来确定应用日志消息的业务状态。

所述http代码分析是根据统计结果确定需要报警的状态代码，去除掉不严重的故障状态代码，而保留对于业务系统可能造成严重影响的状态代码作为报警的基础，这样，一方面能够及时发现问题，另一方面是避免报警太多，导致失去报警的意义。

例如对于http状态代码，确定7个维度的日志报警规则：401(unauthorized，未授权)、403(forbidden，禁止)、409(conflict，冲突)、499(timeout，超时)、500(internalservererror，内部服务器错误)、502(badgateway，网关故障)、504(gatewaytimeout，网关超时)；对于一些其他的故障状代码，则不会触发报警，例如400(badrequest，请求错误)等。

但是这些可以引发报警的状态代码，也并非统一对待，例如其中针对401、403报警的时候需要分析报警源的ip、path等推送给系统管理员分析。499报警则需要分析spend_time，因为很多情况下浏览器如果被用户手动取消请求也会触发499，这种报警则需要避免。500、502、504要明确将nginx理由后的真实serverip告知到系统管理员。

所述静态资源过滤是指http状态分析器主动将一些跟业务不相关的静态资源进行过滤，比如爬虫的请求、ico的这种浏览器行为，避免对业务产生太多不需要关注的干扰。

因此，本发明具体实施方式中http状态分析器通过所述http代码分析以及静态资源过滤操作来确定应用日志消息的业务状态，通过分析logger来分析应用日志的来源和业务系统。

在本发明一具体实施方式中，所述过滤器链组件还包括用户分析器，所述用户分析器连接至报警模块，用于根据预设应用与系统之间的关联规则，确定系统关联负责人的联系信息，当所述应用日志消息的业务状态分析结果为需要报警时，将需要报警的数据及系统关联负责人的联系信息返回给报警模块，报警模块发送相关的报警信息。

现实状态中有多种应用，每种应用会产生大量不同主题的日志文件，因此本发明中首先应用与系统之间的关联规则，然后根据系统来追溯到系统关联负责人，所述系统关联负责人的联系信息可以是存储在mysql数据库中，例如采用域名与系统关联负责人建立联系的方式来实现。

所述报警模块包含了2类功能，一类是采用手机报警、一类是采用邮箱报警。所述报警模块通过提供2类报警服务，如果应用日志消息的分析结果是存在需要报警的需求，所述报警模块将通过其规则将报警发送给指定的系统关联负责人。

因此，本发明能够准实时掌握业务系统运行过程中，线上用户访问业务系统的情况，直接基于线上真实的访问情况，通过完整的日志定位和日志输出，帮助平台运营人员、技术人员快速发现问题并定位问题，从而提高整个业务系统的稳定性、服务质量。因为本发明具体实施方式中，直接接入所有接入端的应用日志，能够分析所有访问日志的情况，能够触及到所有外部的情况，能够解决现有技术中仅仅是对自己的业务系统的事件或者日志进行监控和报警，而实际的很多场景是因为业务系统外部的因素导致服务不可用，比如网络不稳定、外部安全设备拦截等导致的问题，现有技术的业务系统是感知不到的。另外，应用级别的监控技术只局限于业务的异常，对资源是否存在、url是否错误、超时类异常等都很难捕获，特别是静态资源、接口调用方面出现的概率比较大的技术问题。

另外，本发明具体实施方式中，所述过滤器链组件还包括统计模块，所述统计模块用于对应用日志消息进行归类和统计分析，所述统计模块通过将应用日志消息按照登录应用、登录地址、登录代码等维度进行数据归类和统计，后期为分析提供基础数据。

所述统计模块实现sla的数据分析，其中登录应用logger归类统计，可以分析应用维度；而登录地址ip：是分析报警的地区分布；而登录代码code是为了对报警进行分级，每种登录代码代表了不同的状态和错误level。

通过统计模块，进行数据分析，特别是按照登录应用、登录地址、登录代码等维度进行数据归类和统计，这样为了进一步调整和改善本发明具体实施方式中的基于访问日志的应用状态监控报警系统及方法，以及适用于更多的实施方式提供了数据指引，例如通过登录代码code的分析统计结果，可以将部分代码code加入需要报警的代码，而将部分原需要报警的代码进行去除。

例如来自某个地区的登录地址，频繁发生某个code的误报警，则本发明具体实施方式中，所述http状态分析器可以调整其代码分析策略(报警业务规则)，对于来自该地区的登录地址，将该code标记为无需报警。或者某个登录应用中频繁发生某个code的报警代码，则http状态分析器可以优先考虑对该应用扩大静态过滤范围，或者采取更灵活的方式，例如一段时间内将来自该登录应用的该代码code排除在报警范围之外，以避免系统的负荷过重，也避免系统关联负责人收到过于频繁的报警信息。

这样，通过统计模块的数据分析功能，能够灵活调整登录应用、登录地址、登录代码的对应关系，例如为http状态分析器和报警模块的报警决策提供灵活的调整方式，进一步改善了本发明具体实施方式的灵活性和高可靠性。

另外，本发明具体实施方式中，所述过滤器链组件还包括缓存管理器，所述对基础配置信息进行缓存和更新，以及将基础配置信息传递给数据库。

所述基础配置包括报警的配置关联、域名的配置等，缓存管理器为统计模块、http状态分析器和报警模块提供快速数据服务。特别是http状态分析器和报警模块需要快速处理大量的应用日志消息(例如10秒内处理10000条消息)，因此需要快速获取报警的配置关联、域名的配置、错误代码与报警的对应关系等，利用缓存管理器能够解决这一技术问题。

另外，本发明具体实施方式中，所述过滤器组件还包括数据库管理器，所述数据库管理器用于使用jdbc连接关系数据库和在线分析数据库，为所述过滤器组件的其他业务模块提供快速数据库的查询和更新服务。

在本发明具体实施方式中，所述数据库包括mysql关系数据库和tidb在线分析数据库，关系数据库是指包括相互联系的逻辑组织和存取这些数据的一套程序(数据库管理系统软件)。关系数据库管理系统就是管理关系数据库，并将数据逻辑组织的系统。而tidb在线分析数据库可以部署在本地和云平台上，支持公有云、私有云和混合云。用户可以根据实际场景或需求，选择相应的方式来部署tidb集群。

通过将数据分别部署在mysql关系数据库和tidb在线分析数据库，一方面方便过滤器组件的其他业务模块进行查询和更新，一方面能够保障大量的数据吞吐能力，利用云存储的方式来覆盖全部应用日志消息。

正因为本发明具体实施方式中，不限于处理单一的应用产生的日志文件，而是将来自nginx的全部应用日志文件进行订阅、分析处理和统计，因此能够分析所有应用日志的情况，能够触及到所有外部(相对于应用本身)的信息，为应用状态监控和报警提供真实有效的依据。

图2为根据本发明一具体实施方式中的基于访问日志的应用状态监控报警方法的流程图。如图2所示，与本发明具体实施方式中的基于访问日志的应用状态监控报系统相对应，本发明具体实施方式中，还包括一种基于访问日志的应用状态监控报警方法，包括步骤：

a、将来自日志源的应用日志文件进行处理和格式转换为数据流，将数据流按照主题作为应用日志消息进行存储和发布；

b、根据主题订阅应用日志消息，并将应用日志消息推送给过滤器链组件，进行应用日志消息处理；

c、根据应用日志消息的业务状态，以及应用与系统的关联规则，向系统关联负责人发送报警信息；以及，

d、访问数据库模块，将应用日志消息及其处理结果进行存取、查询和更新。

需要特别说明的是，尽管图2中将c/d步骤描绘为具有先后关系，但是实际上发送报警信息与访问数据库模块并无先后顺序，二者是在应用日志消息处理过程中随时发生的。

另外，本发明具体实施方式中，所述将数据流按照主题作为应用日志消息进行存储和发布包括：按照集群方式进行存储和发布，其中所述集群包括多个服务器节点，每个服务器节点存储一主题应用日志消息的一个或多个分区；且所述根据主题订阅应用日志消息的步骤包括：采用拉取的方式获取应用日志消息，所述拉取的方式为每次按照预定偏移量拉取一定数量的应用日志消息。

另外，本发明具体实施方式中，所述进行应用日志消息处理包括确定应用日志消息的业务状态，所述确定应用日志消息的业务状态具体包括：

b21、通过分析http代码来确定应用日志消息是否属于报警业务规则内；

b22、将与跟业务不相关的静态资源进行过滤。

上述说明示出并描述了本发明的若干优选实施例，应当理解本发明并非局限于本说明书所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本说明书所述发明构想范围内通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。