CN111526060A - 业务日志的处理方法及系统 - Google Patents

Abstract

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

Description

业务日志的处理方法及系统

技术领域

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

背景技术

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

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

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

(1)输入数据的特征

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

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

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

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

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

动态更新分析策略：实时日志分析过程中可能会动态地变更部分分析策略，比如增加某些日志文件或字段的过滤器，增加要监听的关键字等。

(3)监控告警策略的特征

以周期和双周期聚合告警为主：基于业务数据驱动的特性，业务日志实时分析计算得出的指标数据通常是经过周期聚合之后才对接告警系统的。

可溯源的日志原文：有别于采集指标只是系统状态的反馈，告警发生后没有“发生现场”可循。日志分析系统所触发的监控是由日志数据分析得到的，当业务日志指标发生告警后，运维人员很大可能需要登录到服务器上查阅日志，并需要通过繁琐的手段去重新定位到触发告警的日志原文及其上下文。

以上关于日志分析告警的各方面特征，现有的开源解决方案还尚未解决或未能完全覆盖。

针对相关技术中解决关于业务日志的监控需求的效果较差的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种业务日志的处理方法及系统，以解决相关技术中解决关于业务日志的监控需求的效果较差的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种业务日志的处理方法。该方法包括：从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据；基于所述聚合后的日志数据确定是否触发告警信息。

进一步地，所述方法还包括：若检测到所述目标日志模型对所述业务日志中的数据解析失败，确定所述业务日志中存在无法解析的日志字符串；将无法解析的日志字符串输出到预设配置的数据库。

进一步地，按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据包括：对所述时间窗口进行允许延迟数据的优化处理，得到优化后的时间窗口，其中，所述延迟数据分两种情况：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据；采用优化后的时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据。

进一步地，基于所述聚合后的日志数据确定是否触发告警信息包括：将所述聚合后的日志数据输入时序数据库中；通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；若所述告警条件被触发，触发告警信息。

进一步地，若所述告警条件被触发，触发告警信息之后，所述方法还包括：生成反查凭据ID的超链接，将所述告警信息和所述反查凭据ID的超链接发送给目标终端，其中，所述反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

进一步地，采用目标日志模型对所述业务日志进行解析，得到结构化日志对象之后，所述方法还包括：采用用户自定义函数对所述结构化日志对象进行处理，得到处理后的结构化日志对象。

为了实现上述目的，根据本申请的另一方面，提供了一种业务日志的处理系统，包括：日志分析模块，其中，所述日志分析模块用于通过第一数据源抽象链接器从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数；通过第二数据源抽象链接器将所述聚合后的日志数据输出至时序数据库中；告警模块，用于通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；若所述告警条件被触发，触发告警信息。

为了实现上述目的，根据本申请的另一方面，提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序执行上述任意一项所述的业务日志的处理方法。

为了实现上述目的，根据本申请的另一方面，提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述任意一项所述的业务日志的处理方法。

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

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例提供的业务日志的处理方法的流程图；

图2是根据本申请实施例提供的业务日志的处理方法中延时处理的示意图；以及

图3是本申请实施例提供的可选的业务日志的处理系统的架构图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

模型仓库：业务日志模型管理系统，此系统存储所有需要接入实时分析告警系统的业务日志分析模型，模型包含了该类日志的数据结构。

规则中心：整套系统的中心管理模块，维护每种日志模型所涉及的实时分析聚合策略、统计方式、监控告警规则以及日志反查凭证。

根据本申请的实施例，提供了一种业务日志的处理方法。

图1是根据本申请实施例的业务日志的处理方法的流程图。如图1所示，该方法包括以下步骤：

步骤S101，从分布式订阅发布消息系统中采集业务日志，其中，分布式订阅发布消息系统用于获取应用系统产生的业务日志。

本申请实施例的业务日志的数据来源于消息中间件Kafka(分布式订阅发布消息系统)队列，所有应用系统所产生的业务日志被采集器(例如，File Beat)收集到Kafka中。

步骤S102，采用目标日志模型对业务日志进行解析，得到结构化日志对象，其中，目标日志模型是按照业务日志的日志格式创建的模型。

采用目标日志模型对业务日志进行解析，得到结构化日志对象是在日志分析模块中执行的，本申请实施例中通过数据源抽象连接器从分布式订阅发布消息系统中采集业务日志，也即将上游应用系统输出的日志读入日志分析模块。日志分析模块支持从多个数据源同时消费数据进入同一个计算任务，如处理复数个消息中间件(例如，同一个业务的日志、海内外业务独立Kafka的情况)时可以支持。

上述的目标日志模型是根据采集到的业务日志在运维管理模块的模型仓库中创建对应的模型。本申请实施例中使用目标日志模型初始化一个解析引擎，用于解析每一笔流入的日志字符串数据，并输出处理好的结构化日志对象。解析引擎会根据模型中定义的文法，使用递归下降算法解析一条日志事件。输入的字符串日志原文被解析的结果是一个包含了Tag和Field两个字典的结构化日志对象，其中Tag字典包含了要输出的数据标签，Field字典包含了要参与计算的数据项。例如，对于游戏登录日志，如果要计算一段时间内去重复登录数，那么游戏标识符“gameid”是一个Tag，用户唯一标识符“udid”是一个Field。

可选地，在本申请实施例提供的业务日志的处理方法中，该方法还包括：若检测到目标日志模型对业务日志中的数据解析失败，确定业务日志中存在无法解析的日志字符串；将无法解析的日志字符串输出到预设配置的数据库。

也即，对于解析引擎无法解析的日志字符串，这部分的脏数据被称为“SideOutput”，流向数据汇抽象层最终输出到用户指定的数据汇(对应上述的预设配置的数据库)。

可选地，在采用目标日志模型对业务日志进行解析，得到结构化日志对象之后，该方法还包括：采用用户自定义函数对结构化日志对象进行处理，得到处理后的结构化日志对象。

用户自定义函数(User define function，简称UDF)，对解析后的结构化日志对象进行进一步处理，输入一个结构化日志对象，输出一个用户自定义逻辑处理过完毕的结构化日志对象。此处的UDF函数可以为插件化设计，支持用户以插件的形式实现UDF。在日志分析模块中，将采用反射机制动态构建UDF实例来处理结构化事件。典型的例子是，使用一个UDF来提取某个URL格式的Tag中get模式下的参数和值并导入到结果Tag中。

步骤S103，按照时间窗口对结构化日志对象进行聚合处理，得到聚合后的日志数据。

上述步骤是按照时间窗口来分组聚合输入的结构化日志对象。时间窗口指统计的周期，分组指的是Tag字典中的内容，相当于SQL的Group By操作。以“5分钟内各游戏登录量”为例，“5分钟”是时间窗口，“各游戏”指需要按游戏进行分组，因此解析引擎输出的Tag字典将包含一个代表游戏标识符的“gameid”字段供分组。聚合引擎每五分钟(对齐到现实时钟)就会聚合统计一次登录请求的计数，并输出数量为分组数的多个时序统计量。

由于生产环境上的数据通常会因为网络延迟不可能总是准时到达，为确保数据的准确性，可选地，在本申请实施例提供的业务日志的处理方法中，按照时间窗口对结构化日志对象进行聚合处理，得到聚合后的日志数据包括：对时间窗口进行允许延迟数据的优化处理，得到优化后的时间窗口，其中，延迟数据分两种情况：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据；采用优化后的时间窗口对结构化日志对象进行聚合处理，得到聚合后的日志数据。

通过上述方案，对时间窗口做了允许延迟数据的优化处理。此处将延迟数据分为两种：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据，如图2所示，图2展示了时间窗口为1分钟，延迟阈值为1分钟下的情况。

对于假延迟数据，认为是因为网络延迟而只有些许迟到的数据，这部分数据会被纳入属于它的时间窗口中计算；对于真延迟数据，认为是已经不再需要关心的过时数据，它将被作为“Side Output”输出到数据汇抽象连接器，并最终导出到用户指定的延迟数据存放数据汇。

聚合后的日志数据中至少包括：聚合得到的日志时序统计量、目标日志模型解析失败的业务日志数据、真延迟数据，通过数据汇抽象连接器对外输出。

步骤S104，基于聚合后的日志数据确定是否触发告警信息。

可选地，在本申请实施例提供的业务日志的处理方法中，基于聚合后的日志数据确定是否触发告警信息包括：将聚合后的日志数据输入时序数据库中；通过告警引擎按照配置好的规则扫描时序数据库，计算告警条件是否被触发；若告警条件被触发，触发告警信息。

可选地，在本申请实施例提供的业务日志的处理方法中，若告警条件被触发，触发告警信息之后，该方法还包括：生成反查凭据ID的超链接，将告警信息和反查凭据ID的超链接发送给目标终端，其中，反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

上述步骤可以在告警模块中执行，本申请可以选择Prometheus作为告警模块的告警引擎，并使告警被触发时产生一个反查凭据并写入反查凭据库中，附带了反查凭据ID的超链接会随同告警信息发送给目标终端，以传达给运维人员。当运维人员收到日志监控告警而需要反查日志原文时，此超链接将引导其到运维管理模块的告警反查界面，查阅相应日志原文及上下文。

超链接中附带的反查凭证ID能唯一定位反查凭证库中的一个凭证，凭证中包含了要反查的日志原文路径、原文文件指针偏移量、最早一条日志时间戳、最晚一条日志时间戳、条件谓词。其中，条件谓词是向日志原文数据库发起查询的关键字键值对，这些键值从告警内容中提取得到，例如：“最近5分钟Nginx访问日志中，访问A接口、返回码200的请求一共有100次”，对应有<接口，A>和<返回码，200>这两个谓词。这些谓词会被用于构造反查原文的条件，只有同样满足这些谓词的日志原文才会被过滤出来，再附加文件信息和时间范围，反查模块就可以精准地得到触发此条告警的所有原文。

通过本申请实施例提供的业务日志的处理方法，在功能方面可以实现：基于应用系统的日志，做到业务维度下的微观分析与告警。模型仓库和规则中心的引入，满足任意格式的业务日志实时分析需求。任何业务日志只需要定义好日志结构模型即可接入分析监控体系，无需对线上业务做任何的注入或变更，数据的处理独立于线上业务系统，做到了业务零影响零变更接入；规则中心支持运维人员灵活配置日志分析和处理逻辑、插件式UDF以及动态配置数据上下游。告警反查日志原文及其上下文，极大方便了运维人员查找和定位问题。在性能、可维护性、可拓展性上可以实现：高可用、可伸缩的框架，支持快速便捷的扩容或缩容。高性能，在生产环境集群中，5台服务器以75万QPS峰值实时处理日志。低延迟，在生产环境集群中，线上日志从采集到被分析完毕的平均时延小于10秒，其中实时分析模块在解析每条事件的平均时延在99.9％的情况下不超过1ms。

也即，本申请实施例提供的业务日志的处理方法可以描述绝大多数场景下的业务日志数据结构，并提示实时日志分析模块应该使用和忽略哪些日志属性，它是实时日志分析模块的作业上下文，指导如何分析特定输入的日志数据。所有日志模型被管理在模型仓库中，由系统SRE负责运维。文法模型以树的结构来组织，一个日志模型的文法结构可以这样叙述：

上级字段名(from)：当前节点要解析的内容在上级文法节点解析输出的哪个字段中，如果是文法根节点则该字段内容固定为“__RAW__”(即完整的日志原文)；

解析类型(type)：用何种方式看待日志的这部分字符串。如“Json”方式会将整个字符串作为Json解析，“RE”方式会作为正则表达式解析。

输出模式(pattern)和计算字段(field)：一个向量，描述使用指定解析类型解析日志的指定部分字符串后应该析出的内容。例如Json模式下填入“gameid”和“channel”，将会把字符串以Json对象的形式解析后，析出对应key为“gameid”和“channel”，值为对应键值的字典到结果中。输出模式和计算字段的区别在于，输出模式中的字段会作为最终实时分析结果时序数据的tag(标签)，计算字段会作为field(聚合字段)，关于标签和聚合字段的定义与传统时序数据库并无明显差异，此处不做赘述。

过滤器(filter)：给定一系列的谓词，使满足此谓词的日志数据才继续进入下一步分析过程，例如错误日志的关键字白名单过滤等应用场景。

文法子节点向量(next)：一个向量，向量中的每个元素是一个如上述所示的文法节点，这些文法节点作为当前文法节点的子节点，可以使用当前文法节点析出的字段作为输入，进行下一步匹配。例如，上级节点析出了字段名为body的字符串，它又可以被子级节点通过“from”获取，随后以Json解析出其中对应的url字段(嵌套关系表现为：body.url)。

本申请实施例提供的业务日志的处理方法还可以用于描述实时日志处理模块的工作模式，如聚合时间窗口、Group By分组情况、上游数据源、下游数据汇、解析失败行为等。所有处理过程模型被管理在规则中心，由系统SRE负责运维。文法模型以树的结构来组织，一个日志模型的文法结构可以这样叙述：

作业名称(name)、类型(type)、环境(env)：用于标识实时分析作业的基本信息；

数据源(source)：一个向量，包含了日志分析模块的输入数据源信息，包括链接建立方式、取数视图、隔离级别等。所有的数据源最终会汇聚成同一条输入流被处理；

数据汇(sink)：一个向量，包含了日志分析模块的输入数据汇信息，包括链接建立方式、写数方式等。与数据源不同，数据汇有“标签”的概念，一个实时分析作业中产生的各种输出会被分发到属于自己标签的数据汇中，这部分内容将在第四章详述；

实时计算方式(operator)和配置(properties)：指定以何种方式来实时分析日志、产生时序数据。支持的方式包括：计数(count)、关键字匹配(like)、最大最小平均算术计算(arithmetic)、去重(distinct)等；

日志模型(parser)：日志分析模块对输入的数据用何种日志模型进行解析。

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

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供了一种业务日志的处理系统，需要说明的是，本申请实施例的业务日志的处理系统可以用于执行本申请实施例所提供的用于业务日志的处理方法。以下对本申请实施例提供的业务日志的处理系统进行介绍。

根据本申请实施例的业务日志的处理系统，该系统包括：日志分析模块，其中，日志分析模块用于通过第一数据源抽象链接器从分布式订阅发布消息系统中采集业务日志，其中，分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对业务日志进行解析，得到结构化日志对象，其中，目标日志模型是按照业务日志的日志格式创建的模型；按照时间窗口对结构化日志对象进行聚合处理，得到聚合后的日志数；通过第二数据源抽象链接器将聚合后的日志数据输出至时序数据库中；告警模块，用于通过告警引擎按照配置好的规则扫描时序数据库，计算告警条件是否被触发；若告警条件被触发，触发告警信息。

通过根据本申请实施例的业务日志的处理系统，解决了相关技术中解决关于业务日志的监控需求的效果较差的问题，通过对业务日志进行实时分析处理，基于处理后的日志数据触发告警信息，进而达到了提升对业务日志的监控效果。

可选地，在本申请实施例提供的业务日志的处理系统中，告警模块还用于生成反查凭据ID的超链接，将告警信息和反查凭据ID的超链接发送给目标终端，其中，反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

可选地，在本申请实施例提供的业务日志的处理系统中，该系统还包括：运维模块，用于接收反查请求，基于反查请求在告警反查接口与界面上通过反查凭据ID的超链接跳转至触发告警信息的原文及上下文。

本申请可以选择Prometheus作为告警模块的告警引擎，并使告警被触发时产生一个反查凭据并写入反查凭据库中，附带了反查凭据ID的超链接会随同告警信息发送给目标终端，以通知运维人员。当运维人员收到日志监控告警而需要反查日志原文时，此超链接将引导到运维模块的告警反查界面，查阅相应日志原文及上下文。

上述的运维模块还包括日志模型仓库，其中，日志模型仓库保存了历史解析处理的日志模型，日志模型仓库中按照业务日志的日志格式创建目标日志模型。

如图3所示，图3是本申请实施例提供的可选的业务日志的处理系统的架构图。本系统的输入来源于消息中间件Kafka(分布式订阅发布消息系统)队列，所有应用系统所产生的业务日志被采集器收集到Kafka中。本系统的对外输出一共有2种数据：时序数据和告警信息，具体地，时序数据由实时分析模块产生，是日志数据通过日志模型解析、按照处理规则计算和聚合后得到的统计时序数据，一个典型的例子是“最近1分钟A游戏在x渠道的登录量”。这些数据通常会写入一个外部的时序数据库，供后续告警系统使用。告警信息由告警引擎产生，发送给运维人员的通知。告警引擎会按照配置好的规则扫描时序数据库，计算告警条件是否被触发，并将发生的告警及其原文反查凭证发送给运维人员。

实时分析模块包括两个数据源抽象链接器，例如为第一数据源抽象链接器和第二数据源抽象链接器，第一数据源抽象链接器将上游应用系统输出的日志读入分析模块，第二数据源抽象链接器将实时分析模块的输出传送至时序数据库中。

实时分析模块还包括：解析引擎，UDF处理引擎和聚合引擎，其中，实时分析模块使用目标日志模型初始化一个解析引擎，用于解析每一笔流入的日志字符串数据，并输出处理好的结构化日志对象。UDF(User define function，用户自定义函数)处理引擎用于对解析完毕的结构化日志对象进行进一步处理，输入一个结构化日志对象，输出一个用户自定义逻辑处理过完毕的结构化日志对象。聚合引擎会按照时间窗口来分组聚合输入的结构化日志对象。

也即，本申请实施例提供的业务日志的处理系统，提供了一个高性能、高可用、可伸缩的日志分析模块。基于上文所分析的数据特征、系统功能性和非功能性需求，选择使用开源流式计算框架Flink作为实时日志分析模块的底层架构，搭建一个接受给定的日志实时处理过程模型，实时消费业务日志数据并分析产生指标。选择Flink作为日志分析模块的底层框架是因其原生的高性能、分布式、易伸缩的优秀特性，并且对于实时数据的计算有Exactly-Once语义的保证和中间状态的保存与恢复机制，这些基础设施可以增强系统的可靠性和灵活性。该模块从消息中间件Kafka数据源中读取来自各个业务或系统的日志数据，通过模型仓库中的日志文法解析对应日志数据，随后根据规则中心配置的实时计算规则输出到目标数据汇，通常是时序数据库或Kafka中间件。日志分析模块的核心是一个解析引擎，在模块启动时，它将按照给定的日志模型初始化并生成对应的解析引擎实例，在随后的运行过程，每一笔日志数据都通过此解析引擎处理转化为结构化数据供后续计算任务进行处理和聚合。解析引擎使用递归下降算法实现，并尽可能减少Json反序列化次数和正则匹配器的构造次数，使日志分析模块拥有高吞吐量。

运维人员可以通过运维管理模块与系统交互。运维管理模块包括日志模型仓库的运维、规则中心的运维、日志原文反查接口及界面。日志模型仓库保存了所有可以解析处理的日志结构模型，规则中心保存了需要进行实时处理和计算的过程描述模型，日志原文查询界面和接口用于承接告警信息附带的反查链接的跳转，并展示触发告警的原文及上下文。其中，超链接中附带的反查凭证ID能唯一定位反查凭证库中的一个凭证，凭证中包含了要反查的日志原文路径、原文文件指针偏移量、最早一条日志时间戳、最晚一条日志时间戳、条件谓词。其中条件谓词是向日志原文数据库发起查询的关键字键值对，这些键值从告警内容中提取得到，例如：“最近5分钟Nginx访问日志中，访问A接口、返回码200的请求一共有100次”，对应有<接口，A>和<返回码，200>这两个谓词。这些谓词会被用于构造反查原文的条件，只有同样满足这些谓词的日志原文才会被过滤出来，再附加文件信息和时间范围，反查模块就可以精准地得到触发此条告警的所有原文。

也即，本申请实施例提供的业务日志的处理系统，提供了一个可支持原文反查的告警体系。由于本系统是完全数据驱动的，因此所输出的时序监控数据均来源于日志分析的结果，即存在日志原文可以被反向溯源，而这些原始日志及其上下文是运维人员理解告警、定位问题的关键，而通常运维人员需要人工登录到应用系统的服务器上查找和分析日志，时间成本很高。本系统在告警模块上增加了一种反查凭证，反查凭证随告警发送到运维人员，运维人员通过此凭证可以直接查阅到产生此告警的相关日志原文，极大地简化了运维人员定位问题的时间成本。反查凭证的本质是一个元组，包含了产生告警的日志原文文件路径、文件指针偏移量、条件谓词、原始日志的最早和最晚时间戳等。该元组可以唯一确定一个日志数据子集，该子集对应触发告警的全部原始日志，即已经过滤掉无关信息的，运维人员需要关注的原始日志。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来处理业务日志。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本发明实施例提供了一种计算机可读的存储介质，其上存储有程序，该程序被处理器执行时实现所述业务日志的处理方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述业务日志的处理方法。

本发明实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据；基于所述聚合后的日志数据确定是否触发告警信息。

处理器执行程序时还可以实现以下步骤：所述方法还包括：若检测到所述目标日志模型对所述业务日志中的数据解析失败，确定所述业务日志中存在无法解析的日志字符串；将无法解析的日志字符串输出到预设配置的数据库。

处理器执行程序时还可以实现以下步骤：按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据包括：对所述时间窗口进行允许延迟数据的优化处理，得到优化后的时间窗口，其中，所述延迟数据分两种情况：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据；采用优化后的时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据。

处理器执行程序时还可以实现以下步骤：基于所述聚合后的日志数据确定是否触发告警信息包括：将所述聚合后的日志数据输入时序数据库中；通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；若所述告警条件被触发，触发告警信息。

处理器执行程序时还可以实现以下步骤：若所述告警条件被触发，触发告警信息之后，所述方法还包括：生成反查凭据ID的超链接，将所述告警信息和所述反查凭据ID的超链接发送给目标终端，其中，所述反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据；基于所述聚合后的日志数据确定是否触发告警信息。

当在数据处理设备上执行时，还可以适于执行初始化有如下方法步骤的程序：所述方法还包括：若检测到所述目标日志模型对所述业务日志中的数据解析失败，确定所述业务日志中存在无法解析的日志字符串；将无法解析的日志字符串输出到预设配置的数据库。

当在数据处理设备上执行时，还可以适于执行初始化有如下方法步骤的程序：按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据包括：对所述时间窗口进行允许延迟数据的优化处理，得到优化后的时间窗口，其中，所述延迟数据分两种情况：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据；采用优化后的时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据。

当在数据处理设备上执行时，还可以适于执行初始化有如下方法步骤的程序：基于所述聚合后的日志数据确定是否触发告警信息包括：将所述聚合后的日志数据输入时序数据库中；通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；若所述告警条件被触发，触发告警信息。

当在数据处理设备上执行时，还可以适于执行初始化有如下方法步骤的程序：若所述告警条件被触发，触发告警信息之后，所述方法还包括：生成反查凭据ID的超链接，将所述告警信息和所述反查凭据ID的超链接发送给目标终端，其中，所述反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

当在数据处理设备上执行时，还可以适于执行初始化有如下方法步骤的程序：采用目标日志模型对所述业务日志进行解析，得到结构化日志对象之后，所述方法还包括：采用用户自定义函数对所述结构化日志对象进行处理，得到处理后的结构化日志对象。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种业务日志的处理方法，其特征在于，包括：

从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；

采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；

按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据；基于所述聚合后的日志数据确定是否触发告警信息。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若检测到所述目标日志模型对所述业务日志中的数据解析失败，确定所述业务日志中存在无法解析的日志字符串；

将无法解析的日志字符串输出到预设配置的数据库。

3.根据权利要求1所述的方法，其特征在于，按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据包括：

对所述时间窗口进行允许延迟数据的优化处理，得到优化后的时间窗口，其中，所述延迟数据分两种情况：在预设时间段内延迟到达的假延迟数据和超过预设时间段的真延迟数据；

采用优化后的时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数据。

4.根据权利要求1所述的方法，其特征在于，基于所述聚合后的日志数据确定是否触发告警信息包括：

将所述聚合后的日志数据输入时序数据库中；

通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；

若所述告警条件被触发，触发告警信息。

5.根据权利要求4所述的方法，其特征在于，若所述告警条件被触发，触发告警信息之后，所述方法还包括：

生成反查凭据ID的超链接，将所述告警信息和所述反查凭据ID的超链接发送给目标终端，其中，所述反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

6.根据权利要求1所述的方法，其特征在于，采用目标日志模型对所述业务日志进行解析，得到结构化日志对象之后，所述方法还包括：

采用用户自定义函数对所述结构化日志对象进行处理，得到处理后的结构化日志对象。

7.一种业务日志的处理系统，其特征在于，包括：

日志分析模块，其中，所述日志分析模块用于通过第一数据源抽象链接器从分布式订阅发布消息系统中采集业务日志，其中，所述分布式订阅发布消息系统用于获取应用系统产生的业务日志；采用目标日志模型对所述业务日志进行解析，得到结构化日志对象，其中，所述目标日志模型是按照所述业务日志的日志格式创建的模型；按照时间窗口对所述结构化日志对象进行聚合处理，得到聚合后的日志数；通过第二数据源抽象链接器将所述聚合后的日志数据输出至时序数据库中；

告警模块，用于通过告警引擎按照配置好的规则扫描所述时序数据库，计算告警条件是否被触发；若所述告警条件被触发，触发告警信息。

8.根据权利要求7所述的系统，其特征在于，所述告警模块还用于生成反查凭据ID的超链接，将所述告警信息和所述反查凭据ID的超链接发送给目标终端，其中，所述反查凭据ID的超链接用于跳转至触发告警信息的原文及上下文。

9.一种计算机可读的存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序执行权利要求1至6中任意一项所述的业务日志的处理方法。

10.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至6中任意一项所述的业务日志的处理方法。

Images