[发明专利]业务日志的处理方法及系统

说明书

本申请公开了一种业务日志的处理方法及系统。该方法包括：从分布式订阅发布消息系统中采集业务日志，其中，分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对业务日志进行解析，得到结构化日志对象，其中，目标日志模型是按照业务日志的日志格式创建的模型；按照时间窗口对结构化日志对象进行聚合处理，得到聚合后的日志数据；基于聚合后的日志数据确定是否触发告警信息。通过本申请，解决了相关技术中解决关于业务日志的监控需求的效果较差的问题。

技术领域

本申请涉及信息处理技术领域，具体而言，涉及一种业务日志的处理方法及系统。

背景技术

在生产环境中，各种应用系统会被部署在众多的服务器(或容器，后统称“服务器”)上，这些系统在运行过程中，会输出各种日志，来反映系统状态、反馈业务执行情况等，采集和分析这些日志信息，可以做到对一个应用系统从业务层面上的数据分析与监控告警。随着公司业务的升级和拓展、业务类型愈发丰富，越来越多的应用系统被引入和部署，而一套可靠的监控告警系统是这些业务可靠性的根本保障。

目前，市场上有许多商业或开源的产品旨在解决监控告警需求，并在工业界被广泛地应用，但目前这些产品都无法支持或者无法很好地解决关于业务日志的监控需求。这些系统通常对定期采集的常规时序数据有很好的支持，比如业界中最常用的Prometheus，通过定期拉取各服务的指标接口或相应的Exporter来周期性采集数据，进行监控告警。这种模型对于系统组件、系统状态的监控需求有很好的支持，但对于数据驱动型的业务日志监控无法原生支持。本系统的设计旨在解决业务日志实时分析、监控告警和原文反查的整套监控和运维协助系统的有机结合。

实时日志聚合分析和告警系统在输入数据、聚合分析方式、监控告警策略等方面和现有的监控告警系统有较大的区别，其各方面特征可以做如下表述。

(1)输入数据的特征

数据流入情况不确定、高并发高吞吐量：基于业务日志的监控数据不同于传统的周期采集类型时序数据，业务日志输入的情况大多数情况下取决于该业务系统的多种因素：当前时间段的访问量、系统错误发生率、网络抖动等。既可能出现十万QPS的波峰，也可能出现几小时只有一笔数据的波谷。因此本系统不仅要有高吞吐、低延迟的IO要求，还需要支持对于一些波动大的数据流支持动态计算资源调节，高流量时密集计算降低延迟、低流量时缩容节约计算资源。

半结构化数据：与统一结构的周期采集指标数据不同，本系统的输入是业务日志，这些日志由不同应用系统打印，其格式无法如采集指标一样遵循同一个规范。即使是同一种业务日志，也会因为系统的实例不同，而产生多种类型(典型例子如同一个应用系统的不同版本的实例)。本系统需要构建一个模型仓库，以支持对异构数据的处理和分析，即便是同一个数据源亦同；并且需要识别、尝试处理、重定向异常结构的日志的能力。

(2)实时聚合分析的特征

基于时间窗口的统计：周期采集的指标数据往往支持对瞬时值进行监控，其典型的案例是进程是否存活。而基于日志的监控分析往往是需要以一段时间的聚合统计数据来作为监控指标的，典型案例如：最近5分钟返回码为500的登录请求量、最近半小时Nginx上游无存活发生次数等。这是因为日志指标的产生是完全数据驱动，基于数据本身的时间进行聚合统计并产生时序数据的，在时间序列上体现为一系列离散的点；而采集指标是系统状态的一种反馈，它通常是一条充满时间序列的曲线。这种特性是大部分现有的监控系统无法支持日志类分析监控的原因之一。

延迟到达和提前到达：由于业务日志完全由上游业务系统输出，通过消息队列削峰后到达本系统，在生产环境中可能出现数据延迟或提前到达的情况。数据延迟指的是要处理的日志数据在时间窗口之后才到达日志分析系统，由于网络通讯等原因，这种情况在生产环境是非常常见的，该情况需要系统支持延迟数据的补回，以保证数据统计的准确性；数据提前是一种比较罕见的情况，表现在日志中包含的业务时间戳比日志处理系统更早，这种情况下通常是业务方出现了错误的输出，需要监控系统重定向这些日志到某个错误信息库所并发出告警。