CN117527527A - 多源告警处理方法和系统 - Google Patents

Abstract

本发明涉及故障处理领域，公开了一种多源告警处理方法和系统，该方法包括：接收各来源平台的各待处理报警信息，根据各待处理报警信息的来源平台和各待处理报警信息，确定各待过滤报警信息；结合预设报警活动阈值进行过滤，得到标准报警信息；根据各标准报警信息，确定各报警组和每个报警组对应的目标故障根因；针对每个目标故障根因，若运维知识库中存在与目标故障根因对应的目标自愈脚本，则执行目标自愈脚本；若不存在，则根据目标故障根因对应的报警组的报警时间，将报警组和目标故障根因发送至与报警组对应的目标路由。本发明对各来源平台的报警信息进行统一，通过预设报警活动阈值和报警组抑制报警触发的频率，并通过自愈脚本进行处理。

Description

多源告警处理方法和系统

技术领域

本发明涉及故障处理领域，尤其涉及一种多源告警处理方法和系统。

背景技术

随着科技的进步，众多系统、平台都向智能化、微服务化和高可用转型，系统服务能力得到提升，但是也带来了新的挑战。面对越来越多的平台、子系统、服务器、数据库等设施，运维人员需要在系统异常时能快速定位、有效诊断问题及原因。

目前常见的监控工具种类繁多且各自为政，存在严重的数据孤岛现象，无法将监控数据关联起来，且监控指标有限，异常告警方式单一，无法及时有效地通知运维人员。同时，传统监控方式已无法满足系统运营的个性要求。

有鉴于此，特提出本发明。

发明内容

为了解决上述技术问题，本发明提供了一种多源告警处理方法和系统，实现对各来源平台的报警信息进行统一，通过设置预设报警活动阈值和报警组抑制报警触发的频率，进而，通过自愈脚本实现对报警信息所涉及的故障的自愈处理。

本发明实施例提供了一种多源告警处理方法，该方法包括：

接收各来源平台的各待处理报警信息，根据各所述待处理报警信息的来源平台以及各所述待处理报警信息，确定与各所述待处理报警信息对应的待过滤报警信息；

根据预设报警活动阈值对所述待过滤报警信息过滤，得到标准报警信息；其中，所述预设报警活动阈值基于运维知识库中的样本报警信息以及预设报警频率范围训练得到；所述样本报警信息基于预设周期内的各待过滤报警信息更新确定；

根据各标准报警信息，确定至少一个报警组以及与每个所述报警组对应的目标故障根因；

针对每一个目标故障根因，若所述运维知识库中存在与所述目标故障根因对应的目标自愈脚本，则执行所述目标自愈脚本；若所述运维知识库中不存在所述目标自愈脚本，则根据所述目标故障根因对应的报警组的报警时间，将所述报警组以及所述目标故障根因发送至与所述报警组对应的目标路由；其中，所述目标自愈脚本为所述运维知识库中已存储的运维脚本或者通过已存储的运维脚本自动编排生成的编排脚本。

本发明实施例提供了一种多源告警处理系统，该系统包括：多个来源平台、报警信息整合自愈模块、运维知识库以及多个目标路由；其中，

多个所述来源平台，与所述报警信息整合自愈模块相连接，用于将各待处理报警信息发送至所述报警信息整合自愈模块；

报警信息整合自愈模块，用于执行任一实施例所述的多源告警处理方法；

运维知识库，与各所述来源平台和所述报警信息整合自愈模块分别连接，用于存储所述报警信息整合自愈模块发送的样本报警信息以及预设报警活动阈值，以使所述系统根据所述样本报警信息，对所述预设报警活动阈值进行更新，并反馈至所述报警信息整合自愈模块；用于存储具有对应关系的故障快照、自愈脚本以及故障根因，所述故障快照包括多个所述来源平台中与所述故障根因对应的各报警信息从发生到结束的报警相关信息；用于存储各来源平台之间的平台调用链、各来源平台内部的内部调用链、样本报警组以及样本故障根因，以使所述系统根据各平台调用链、各内部调用链、所述样本报警组以及所述样本故障根因训练得到故障根因分析模型；所述故障根因分析模型用于确定报警组对应的至少一个目标故障根因；

多个目标路由，与所述报警信息整合自愈模块相连接，用于接收所述报警信息整合自愈模块发送的报警组以及目标故障根因，根据所述目标故障根因构建与目标故障根因对应的目标自愈脚本，并将所述目标自愈脚本发送至所述报警信息整合自愈模块。

本发明实施例具有以下技术效果：

通过接收各来源平台的各待处理报警信息，根据各待处理报警信息的来源平台以及各待处理报警信息，确定与各待处理报警信息对应的待过滤报警信息，以对各来源平台的报警信息进行统一处理，进而，根据预设报警活动阈值对待过滤报警信息过滤，得到标准报警信息，来对报警信息进行抑制处理，根据各标准报警信息，确定至少一个报警组以及与每个报警组对应的目标故障根因，以判断引发报警信息的根本故障，进一步的，针对每一个目标故障根因，若运维知识库中存在与目标故障根因对应的目标自愈脚本，则执行目标自愈脚本；若运维知识库中不存在目标自愈脚本，则根据目标故障根因对应的报警组的报警时间，将报警组以及目标故障根因发送至与报警组对应的目标路由，实现了对各来源平台的报警信息进行统一，通过设置预设报警活动阈值和报警组抑制报警触发的频率，进而，通过自愈脚本对报警信息所涉及的故障进行自愈处理的效果。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种多源告警处理方法的流程图；

图2是本发明实施例提供的一种多源告警处理系统的结构示意图；

图3是本发明实施例提供的一种多源告警处理系统的架构图；

图4是本发明实施例提供的一种模型训练的示意图；

图5是本发明实施例提供的另一种模型训练的示意图；

图6是本发明实施例提供的一种运维知识库构建和使用流程的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行清楚、完整的描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

本发明实施例提供的多源告警处理方法，主要适用于接收多个来源平台的报警信息进行标准化、分组以及故障分析处理，并对报警信息对应的故障进行自愈处理的情况。本发明实施例提供的多源告警处理方法可以由集成在多源告警处理系统内。

图1是本发明实施例提供的一种多源告警处理方法的流程图。参见图1，该多源告警处理方法具体包括：

S110、接收各来源平台的各待处理报警信息，根据各待处理报警信息的来源平台以及各待处理报警信息，确定与各待处理报警信息对应的待过滤报警信息。

其中，来源平台包括HPC集群、不同类型的公有云或私有云、AI智算平台和大数据平台等，这些来源平台的报警信息各不相同。待处理报警信息为对应的来源平台在发生故障时发出的信息，用于提醒人员处理。待过滤报警信息是通过标准格式对待处理报警信息进行标准化处理后的报警信息。

具体的，接收不同来源平台在发生故障时发出的报警信息，作为待处理报警信息。由于不同来源平台的报警信息的信息不一致，会导致后续分析和处理存在困难，因此，通过自定义的标准格式对各待处理报警信息进行标准化处理，得到待过滤报警信息。

需要说明的是，采集的各待处理报警信息可以根据报警来源、严重程度、报警类型、报警时间和报警信息之间的相关性进行智能分类。其中，会包含日志报警信息，数据库中结构化数据报警信息，主流监控系统的监控指标报警信息等。通过数据解析器将这些不同格式的待处理报警信息自动适配到不同的解析方式上，以便于后续通过统一的自定义格式输出。

在上述示例的基础上，可以通过下述方式来根据各待处理报警信息的来源平台以及各待处理报警信息，确定与各待处理报警信息对应的待过滤报警信息：

针对每个待处理报警信息，确定待处理报警信息的来源平台；

根据与来源平台对应的目标解析方法，确定待处理报警信息的各解析信息，根据各解析信息以及预设标准格式，确定与待处理报警信息对应的待过滤报警信息。

其中，目标解析方法是与来源平台对应的报警信息解析方法，不同的来源平台对应的报警信息解析方法不同。解析信息是用于待处理报警信息解析后得到的构建待过滤报警信息的部分信息。解析信息包括报警名、报警来源、报警类型、报警级别、报警时间以及报警和关联信息中的至少一种信息。预设标准格式是预先设定的构建待过滤报警信息的各字段以及各字段之间的连接方式。

具体的，针对每个待处理报警信息，可以确定待处理报警信息的来源平台，进而，根据来源平台确定针对该来源平台的报警信息进行解析的目标解析方法。通过确定出的目标解析方法对待处理报警信息进行解析，可以得到解析出的各字段信息，例如：报警名、报警来源、报警类型、报警级别、报警时间以及报警和关联信息等。进而，按照预设标准格式，将各解析信息进行重新整理，得到与待处理报警信息对应的待过滤报警信息。

示例性的，将在不同来源平台采集不同待处理报警信息，重新自定义统一的报警格式（预设标准格式），如：报警名-报警来源-报警类型-报警级别-报警时间-报警和关联信息。通过预设标准格式处理后的待过滤报警信息能够更容易实现不同来源平台以及各个系统层次之间的报警信息的共享和交流，才能够更高效快速的解析和处理这些报警信息，提高报警的响应速度。另外，统一的预设标准格式具有一致性和规范性，这样对于报警信息来说，更方便进行归纳和整理，便于后续准确无误的保存在运维知识库中，形成有序的知识体系。

S120、根据预设报警活动阈值对待过滤报警信息过滤，得到标准报警信息。

其中，预设报警活动阈值基于运维知识库中的样本报警信息以及预设报警频率训练得到，预设报警活动阈值用于对待过滤报警信息进行过滤，避免过高或过低的报警频率，即避免报警频繁或者不能及时报警的情况。预设报警活动阈值包括对待过滤报警信息的至少一个字段进行过滤的字段阈值。预设报警频率是预先设定的可接受的报警频率范围，可以根据用户使用需求设定。样本报警信息基于预设周期内的各待过滤报警信息更新确定，即将每个预设周期内的各待过滤报警信息添加至样本报警信息中，对样本报警信息进行扩充。预设周期是用于更新预设报警活动阈值的时间周期，可以根据需求设定。样本报警信息用于对预设报警活动阈值进行训练。运维知识库是用于存储各标准化处理后的报警信息以及针对这些报警信息的处理方式（运维脚本以及运维记录等）的知识库，其中还包含各来源平台基础数据、各来源平台内各层次运行状态数据、和调用链等信息。标准报警信息是后续进行自愈处理或者报警处理的待过滤报警信息，标准报警信息是通过预设报警活动阈值对待过滤报警信息进行过滤处理后剩余的部分待过滤报警信息。

具体的，通过运维知识库中的样本报警信息训练得到预设报警活动阈值，进而，通过预设报警活动阈值中针对各字段设置的字段阈值，对接收和处理后得到的各待过滤报警信息进行筛选和过滤，将保留下来的部分待过滤报警信息作为标准报警信息，以用于后续报警或自愈处理使用。

在上述示例的基础上，通过下述方式来根据预设报警活动阈值对待过滤报警信息过滤，得到标准报警信息：

针对每个待过滤报警信息，根据预设报警活动阈值内的各字段活动阈值以及待过滤报警信息，判断是否针对待过滤报警信息进行处理；

在针对待过滤报警信息进行处理的情况下，将待过滤报警信息确定为标准报警信息。

其中，字段活动阈值是预设报警活动阈值中针对待过滤报警信息的各字段信息进行过滤的阈值信息。

具体的，将各解析信息按照预设标准格式进行整理，得到与待处理报警信息对应的待过滤报警信息。进一步的，通过预设报警活动阈值内的各字段活动阈值，对每个待过滤报警信息内各字段信息进行分析，进而进行过滤处理。由于预设报警活动阈值包括针对一个或者多个待过滤报警信息中字段进行过滤的字段阈值，即限制规则，因此，需要对待过滤报警信息中的每个字段都进行分析。通过预设报警活动阈值内的各字段活动阈值可以判断待过滤报警信息是否符合预设报警活动阈值，若符合，则需要继续进行报警或自愈解决，若不符合，则无需进行报警和处理。在针对待过滤报警信息进行处理的情况下，表明该待过滤报警信息应当保留以便于进行后续的分析、报警和解决，因此，将待过滤报警信息确定为标准报警信息。在针对待处理报警信息不进行处理的情况下，表明该待过滤报警信息属于影响较小的信息，无需进行处理，因此，将待过滤报警信息存储至运维知识库中即可。当然，也需要将标准报警信息存储至运维知识库中，以用于后续更新预设报警活动阈值。

在上述示例的基础上，预设报警活动阈值通过下述方式确定：

将当前预设周期内的各待过滤报警信息存储至运维知识库的样本报警信息中，并将当前预设周期内的预设报警活动阈值确定为初始报警阈值；

根据添加后的样本报警信息以及初始报警阈值，确定当前报警频率；

若当前报警频率不在预设报警频率范围内，则更新初始报警阈值，并返回执行根据添加后的样本报警信息以及初始报警阈值，确定当前报警频率的操作；

若当前报警频率在预设报警频率范围内，则将初始报警阈值作为下一预设周期内的预设报警活动阈值。

其中，样本报警信息是用于训练模型得到预设报警活动阈值的待过滤报警信息，样本报警信息包括各预设周期内各来源平台的各待处理报警信息对应的待过滤报警信息。初始报警阈值是待进行更新和处理的各字段阈值，是训练模型过程中尝试的各字段阈值。当前报警频率是当前初始报警阈值对样本报警信息进行过滤处理后的报警频率。

具体的，将当前预设周期内的各待过滤报警信息存储至运维知识库的样本报警信息中，以对运维知识库内的样本报警信息进行扩充。进而，并将当前预设周期内的预设报警活动阈值确定为初始报警阈值，以便于判断是否需要进行调整，以及在需要调整的情况下，进行模型训练来调整处理。通过初始报警阈值对运维知识库中的添加当前预设周期内的各待过滤报警信息后的样本报警信息进行过滤处理，得到过滤留下的部分样本报警信息，并通过这些样本报警信息的报警时间，确定这些样本报警信息的当前报警频率。进而，若当前报警频率不在预设报警频率范围内，则表明当前报警频率过高或者过低，即存在报警频繁或者不能够及时报警的问题，因此，更新初始报警阈值，并返回执行根据添加后的样本报警信息以及初始报警阈值，确定当前报警频率的操作，来重新得到新的初始报警阈值，并判断新的初始报警阈值对应的当前报警频率与预设报警频率范围之间的关系。若当前报警频率在预设报警频率范围内，则表明当前报警频率不会过高或者过低，处于用户比较容易接受的状态，因此，可以将初始报警阈值作为下一预设周期内的预设报警活动阈值，用于在下一预设周期内对接收和处理得到的新的各待过滤报警信息进行过滤。

需要说明的是，在持续接收各来源平台的各待处理报警信息，将各待处理报警信息标准化处理为待过滤报警信息的过程中，将这些待过滤报警信息按照预设周期存储在运维知识库中，以丰富运维知识库，通过更多的样本来不断更新预设报警活动阈值，使得报警频率处于合适的频率范围（预设报警频率范围）。

示例性的，通过适当的机器学习算法（如决策树、支持向量机、神经网络等），并使用运维知识库中数据（如样本报警信息）训练模型。根据模型预测的结果和实际需求设定预设报警活动阈值，将该预设报警活动阈值应用于实际生产环境中，运行一段时间后如果预设报警活动阈值存在不理想的情况，例如报警频繁或者是不能及时报警，然后，可以尝试优化模型参数或者更换其他模型，直到找到最优的预设报警活动阈值。

可以理解的是，可以通过上述方式将预设报警活动阈值内的各字段阈值作为整体进行训练，也可以将预设报警活动阈值内的各字段阈值分别构建模型进行训练。若针对各字段阈值分别构建模型进行训练，则确定预设报警频率范围包括各字段分别对应的字段预设报警频率范围。

示例性的，针对每个字段，选择对应的机器学习算法，使用运维知识库中当前的样本报警信息对这些模型（字段过滤模型）进行训练。针对每个字段对应的字段过滤模型，基于字段过滤模型对样本报警信息进行过滤处理后，确定过滤处理后的该字段对应的当前字段报警频率。若当前字段报警频率在与该字段对应的字段预设报警频率范围内，则确定字段过滤模型训练完成，确定该字段过滤训练模型对应的字段阈值。若当前字段报警频率在与该字段对应的字段预设报警频率范围外，则采用调整模型参数或者更换模型等方式，得到新的字段过滤训练模型，重新确定当前字段报警频率和判断。在各字段对应的字段过滤模型均训练完成时，得到各字段阈值，将这些字段阈值组合确定为与预设报警活动阈值。

S130、根据各标准报警信息，确定至少一个报警组以及与每个报警组对应的目标故障根因。

其中，报警组是通过各种预先设定的分组规则对标准报警信息进行分组后的组。目标故障根因是报警组内的各标准报警信息中的故障根因，可以理解的是，由于平台的某一部分出现故障会导致下游多个平台的多个部分继而出现故障，此种情况下，目标故障根因是导致各标准报警信息出现的最上游的故障。

具体的，按照预先设定的分组规则将各标准报警信息进行分组，得到至少一个报警组。例如：将满足第一分组规则的报警组作为第一报警组，将满足第二分组规则的报警组作为第二报警组，以此类推。进而，针对每个报警组进行根因分析，得到与每个报警组对应的目标故障根因。

在上述示例的基础上，可以通过下述方式来根据各标准报警信息，确定至少一个报警组以及与每个报警组对应的目标故障根因：

根据预设分组规则，对各标准报警信息进行分组处理，得到至少一个报警组；

针对每个报警组，根据报警组内的各标准报警信息、各来源平台之间的平台调用链以及各来源平台内部的内部调用链进行根因分析，得到与报警组对应的至少一个目标故障根因。

其中，预设分组规则包括基于报警时间的分组规则、基于报警来源的分组规则、基于触发条件的分组规则和基于报警级别的分组规则中的至少一种。可以理解的是，各预设分组规则可以是相互存在交叉条件的分组规则，也可以是条件相互排斥的分组规则。平台调用链是各来源平台之间的在实现各功能时的调用关系。内部调用链是各来源平台内部各层次各部件实现各功能时的调用关系。

具体的，按照各种预设分组规则，对各标准报警信息进行分组处理，可以得到与每个预设分组规则对应的一个报警组，此时的报警组可能为空。进一步的将空的报警组删除，得到后续需要进行分析的至少一个报警组。针对每个报警组，都需要进行分析，以减少报警信息的发送和处理，具体是根据该报警组内的各标准报警信息、各来源平台之间的平台调用链以及各来源平台内部的内部调用链进行根因分析，判断这些标准报警信息的故障源头，据此可以得到至少一个目标故障根因。

在上述示例的基础上，在确定与每个报警组对应的目标故障根因之后，还可以进一步的对目标故障根因进行归并处理，以降低故障处理频率以及报警频率。

具体的，将各报警组对应的目标故障根因进行分析比较，判断各目标故障根因是否存在关联；若存在关联，则将存在关联的至少两个目标故障根因进行合并。判断是否存在重复的目标故障根因；若存在，则将重复的至少两个目标故障根因进行去重处理。

示例性的，将各标准报警信息按照设置的预设分组规则归并到一起，并这些标准报警信息并将报警聚合和去重。通过报警抑制规则（预设分组规则）进行分组，得到报警组，通过设置报警组的触发等待时间、报警发送时间间隔、报警发送路由等规则来抑制大规模报警造成的报警轰炸。触发等待时间表示，同一个报警组的数据会在定义的等待时间统一触发，报警发送时间间隔表示，触发之后一段时间内不会再次发送报警。还可以设置多个报警发送路由，每个路由包含多个子路由，在各层级路由上面还可以设置各自的路由抑制规则，这属于报警发送路由的抑制规则。对于大规模的报警，可能是由于一个或几个上游系统的故障造成的，此时，可以根据运维知识库中保存的故障运维记录、调用链等过滤出目标故障根因。通过上述各种规则的设置，能够达到报警抑制的效果。

S140、针对每一个目标故障根因，若运维知识库中存在与目标故障根因对应的目标自愈脚本，则执行目标自愈脚本；若运维知识库中不存在目标自愈脚本，则根据目标故障根因对应的报警组的报警时间，将报警组以及目标故障根因发送至与报警组对应的目标路由。

其中，目标自愈脚本为运维知识库中已存储的运维脚本或者通过已存储的运维脚本自动编排生成的编排脚本。可以理解的是，目标自愈脚本可以是原先编排的或者之前处理过的故障处理脚本（运维脚本），也可以是根据已存储的故障处理脚本自动化编排得到的脚本（编排脚本）。报警时间是针对各报警组设置的用于报警的时间，可以通过预设的报警时间间隔确定，并可以设置报警休息时段。示例性的，针对每个报警组，在报警休息时段之外，每隔报警时间间隔确定一个报警时间。目标路由是预先设置的每个报警组对应的路由，即处理该报警组对应的故障的用户所在的路由。

具体的，针对每一个目标故障根因，先判断在运维知识库内是否存在与该目标故障根因对应的目标自愈脚本，例如：是否存在历史运维记录，若存在，历史运维记录中的故障处理脚本就是目标自愈脚本；若不存在，则通过机器学习算法、历史运维记录中的各故障处理脚本、当前系统状态等，进行自动编排，生成编排脚本，作为目标自愈脚本。在获取目标故障根因对应的目标自愈脚本后，执行目标自愈脚本，以完成故障自愈。若无法获取与目标故障根因对应的目标自愈脚本，则需要通知用户进行故障处理，例如构建目标自愈脚本，因此，先确定针对目标故障根因对应的报警组的报警时间和目标路由，在报警时间将该报警组以及对应的目标故障根因发送到目标路由，以使目标路由的用户进行处理，例如：用户通过可视化运维编排的方式构建目标自愈脚本，

在上述示例的基础上，在根据目标故障根因对应的报警组的报警时间，将报警组以及目标故障根因发送至与报警组对应的目标路由之后，还可以通过可视化运维编排的方式构建目标自愈脚本，具体可以是：

接收目标路由构建和发送的与目标故障根因对应的目标自愈脚本，并执行目标自愈脚本；

将目标自愈脚本与目标故障根因对应存储至运维知识库中。

其中，目标路由构建和发送的与目标故障根因对应的目标自愈脚本为目标路由接收从可视化编排库中确定出的与目标故障根因对应的至少两个操作节点以及连接线，并接收对至少两个操作节点以及连接线的编排操作后所得到的与所述目标故障根因对应的目标自愈脚本；操作节点包括元操作节点以及逻辑操作节点；元操作节点包括功能描述以及输入输出参数格式；逻辑操作节点用于判断下一节点走向以及传递上一节点的输出参数；连接线用于表示各操作节点的执行顺序。可视化编排库中包括多个预先加载的元操作节点、逻辑操作节点以及连接线。

具体的，用户根据故障处理逻辑，基于目标路由在可视化编排库选择所需的操作节点以及连接线，并通过对操作节点和连接线进行连接编排，得到与故障处理逻辑对应的目标环图，该目标环图中的处理流程就是故障处理的流程，因此，可以将目标环图确定为目标自愈脚本。因此，接收目标路由构建和发送的与目标故障根因对应的目标自愈脚本，并执行该目标自愈脚本，可以实现对目标故障根因的故障处理。为了后续对该目标故障根因进行自愈处理，避免再次通过人工可视化编排的方式重复工作，将目标自愈脚本与目标故障根因对应存储至运维知识库中，以便于后续根据目标故障根因确定出该目标自愈脚本。

示例性的，在运维知识库中可以保存和下发各运维元操作脚本至目标路由，运维元操作脚本仅是单一的运维操作功能的实现。每个运维元操作脚本可以作为一个元操作节点。剧本编排的整个流程主要包含元操作节点、逻辑操作节点和连接线，元操作节点包含功能的描述、输入输出参数格式，具体的实现细节不需要在编排过程中展示；逻辑操作节点用来判断运维操作的下一步走向，并且传递上一步执行结果输出参数；连接线是有方向的，表示操作节点（元操作节点和逻辑操作节点）之间的执行顺序。编排的过程是在目标页面（如web页面等）上以拖拽的方式，将所有选定的元素（元操作节点、逻辑操作节点和连接线）编排成一个DAG图（无回路有向图）。编排完成之后的操作流程会以工作流的形式（即目标自愈脚本）保存在运维知识库中，并可以绑定到特定报警信息（目标故障根因）上面。在报警发生的时候，确定出该目标故障根因，就可以直接调用对应的这个工作流（目标自愈脚本）。

可以理解的是，目标自愈脚本也是机器学习模型的有效数据，通过模型的训练能够将其他报警（目标故障根因）的自愈脚本也整合在一起，最终形成一个庞大的、完整的故障自动处理解决流程。

在上述示例的基础上，可以通过下述方式来将目标自愈脚本与目标故障根因对应存储至运维知识库中：

若在目标故障根因对应的等待时间内，仍存在与目标故障根因相关的标准报警信息，则将目标自愈脚本以及目标故障根因发送至目标路由，以通过目标路由对目标自愈脚本进行修正；接收目标路由发送的修正后的目标自愈脚本，并返回执行目标自愈脚本的操作，直至在目标故障根因对应的等待时间内，不存在与目标故障根因相关的标准报警信息；

若在目标故障根因对应的等待时间内，不存在与目标故障根因相关的标准报警信息，则将目标自愈脚本与目标故障根因对应存储至运维知识库中。

其中，等待时间可以是根据目标故障根因所对应的报警组中设置的报警时间确定的时间，可以通过预设的报警时间间隔确定，也可以大于或等于报警时间。等待时间是用于等待判断目标故障根因是否解决的时间。

具体的，确定每个目标故障根因对应的等待时间，以在等待时间内监测目标故障根因是否被解决。若在目标故障根因对应的等待时间内，仍存在与目标故障根因相关的标准报警信息，则表明通过执行当前的目标自愈脚本无法解决目标故障根因，仍存在一些由于该目标故障根因引发的标准报警信息，因此，将目标自愈脚本以及目标故障根因发送至目标路由，以便于用户通过目标路由对目标自愈脚本进行修正。进一步的，接收目标路由发送的修正后的目标自愈脚本，并返回执行目标自愈脚本的操作，直至在目标故障根因对应的等待时间内，不存在与目标故障根因相关的标准报警信息，表明目标故障根因已经被解决。若在目标故障根因对应的等待时间内，不存在与目标故障根因相关的标准报警信息，则表明该目标故障根因可以通过该目标自愈脚本处理，因此，将目标自愈脚本与目标故障根因对应存储至运维知识库中，以便于下次出现目标故障根因时直接调取执行。

在上述示例的基础上，可以通过下述方式来将目标自愈脚本与目标故障根因对应存储至运维知识库中：

根据目标故障根因对应的标准报警信息，生成目标故障快照；

将目标故障快照、目标自愈脚本以及目标故障根因对应存储至运维知识库中。

其中，目标故障快照目标故障根因对应的多个标准报警信息发生前至解决后各个来源平台以及各来源平台内各层次之间的调用关系。

具体的，根据目标故障根因，可以确定出与目标故障根因对应的各标准报警信息，进而，将这些标准报警信息发生前至通过目标自愈脚本解决目标故障根因后的一段时间内的各个来源平台以及各来源平台内各层次之间的调用关系，生成目标故障快照。将目标故障快照、目标自愈脚本以及目标故障根因对应存储至运维知识库中，以便于下次出现相同或相似的报警信息时直接能够调取进行分析和执行。

本实施例具有以下技术效果：通过接收各来源平台的各待处理报警信息，根据各待处理报警信息的来源平台以及各待处理报警信息，确定与各待处理报警信息对应的待过滤报警信息，以对各来源平台的报警信息进行统一处理，进而，根据预设报警活动阈值对待过滤报警信息过滤，得到标准报警信息，来对报警信息进行抑制处理，根据各标准报警信息，确定至少一个报警组以及与每个报警组对应的目标故障根因，以判断引发报警信息的根本故障，进一步的，针对每一个目标故障根因，若运维知识库中存在与目标故障根因对应的目标自愈脚本，则执行目标自愈脚本；若运维知识库中不存在目标自愈脚本，则根据目标故障根因对应的报警组的报警时间，将报警组以及目标故障根因发送至与报警组对应的目标路由，实现了对各来源平台的报警信息进行统一，通过设置预设报警活动阈值和报警组抑制报警触发的频率，进而，通过自愈脚本对报警信息所涉及的故障进行自愈处理的效果。

图2是本发明实施例提供的一种多源告警处理系统的结构示意图。参见图2，该多源告警处理方法具体包括：多个来源平台210、报警信息整合自愈模块220、运维知识库230以及多个目标路由240。

其中，多个来源平台210，与报警信息整合自愈模块220相连接，用于将各待处理报警信息发送至报警信息整合自愈模块220；报警信息整合自愈模块220，用于执行如上述任一实施例的多源告警处理方法；运维知识库230，与各来源平台210和报警信息整合自愈模块220分别连接，用于存储报警信息整合自愈模块220发送的样本报警信息以及预设报警活动阈值，以使系统根据样本报警信息，对预设报警活动阈值进行更新，并反馈至报警信息整合自愈模块220；用于存储具有对应关系的故障快照、自愈脚本以及故障根因，故障快照包括多个来源平台210中与故障根因对应的各报警信息从发生到结束的报警相关信息；用于存储各来源平台210之间的平台调用链、各来源平台210内部的内部调用链、样本报警组以及样本故障根因，以使系统根据各平台调用链、各内部调用链、样本报警组以及样本故障根因训练得到故障根因分析模型；故障根因分析模型用于确定报警组对应的至少一个目标故障根因；多个目标路由240，与报警信息整合自愈模块220相连接，用于接收报警信息整合自愈模块220发送的报警组以及目标故障根因，根据目标故障根因构建与目标故障根因对应的目标自愈脚本，并将目标自愈脚本发送至报警信息整合自愈模块220。

在上述示例的基础上，目标路由240包括剧本编排模块以及可视化编排库。

其中，剧本编排模块，与可视化编排库相连接，用于接收从可视化编排库中确定出的与目标故障根因对应的至少两个操作节点以及连接线，并接收对至少两个操作节点以及连接线的编排操作后所得到的与目标故障根因对应的目标自愈脚本，并将目标自愈脚本发送至报警信息整合自愈模块220；可视化编排库，包括：多个预先加载的操作节点以及连接线；其中，操作节点包括元操作节点以及逻辑操作节点；元操作节点包括功能描述以及输入输出参数格式；逻辑操作节点用于判断下一节点走向以及传递上一节点的输出参数；连接线用于表示各操作节点的执行顺序。

本实施例具有以下技术效果：通过多个来源平台、报警信息整合自愈模块、运维知识库以及多个目标路由构建的多源告警处理系统，对各来源平台的各待处理报警信息进行标准化处理，并通过报警信息整合自愈模块对各待处理报警信息进行抑制、分组、分析和自愈处理，在无法自愈的情况下，通过对应的目标路由人工编排脚本进行故障的解决，并且，通过运维知识库对上述各种信息进行存储以便于训练机器学习模型，以通过训练完成的机器学习模型来更新预设报警活动阈值和通过已存储的运维脚本自动编排生成的编排脚本，实现了对各来源平台的报警信息进行统一，通过设置预设报警活动阈值和报警组抑制报警触发的频率，进而，通过自愈脚本对报警信息所涉及的故障进行自愈处理的效果。

示例性的，图3是本发明实施例提供的一种多源告警处理系统的架构图。如图3所述，该系统支持如下功能：

1）跨平台多数据源告警数据采集：

该系统能够支持大规模的几十万节点的HPC集群、不同类型的公有元或私有元、AI智算平台和大数据平台等多种计算平台的报警信息的统一采集。采集的报警信息能够根据报警来源、严重程度、报警类型、报警时间和报警信息之间的相关性进行智能分类。其中，会包含日志报警信息，数据库中的数据结构化报警信息，主流监控系统的监控指标报警信息等。通过数据解析器将这些不同格式的报警谢谢自动适配到不同的解析方式上，以统一的自定义格式输出，供该系统构建运维知识库。通过上述方式使得运维知识库中保存的报警信息是统一的，而不同来源平台的数据源可以按照自己的方式返回报警信息即可。由于融合了所有来源平台的数据源，才能够真正做到将事件告警关联多指标和日志数据等报警信息，在整个系统架构层面智能分析出可能的故障点，直观展示该故障点所处的位置，准确定位故障根因。

2）统一报警信息格式：

该系统能够跨多个来源平台采集不同数据源的报警信息，这些信息的格式是不一致的，导致在分析故障根因的时候比较困难。因此，该系统能够将在不同来源平台采集不同报警信息，重新自定义统一的报警格式（预设标准格式），如：报警名-报警来源-报警类型-报警级别-报警时间-报警和关联信息。统一的报警信息的格式能够更容易实现不同来源平台中各个系统层次之间的报警信息的共享和交流，该系统才能够更高效快速的解析和处理这些报警信息，提高报警的响应速度。另外，统一的报警格式具有一致性和规范性，这样的信息方便进行归纳和整理，准确无误的保存在运维知识库中，形成有序的知识体系。

3）智能化的报警运维系统：

运维知识库包含平台基础数据、平台各层次运行状态数据、统一报警信息、运维脚本、运维记录和调用链等信息。并使用运维知识库中数据（如样本报警信息）训练模型，如图4和图5所示的模型训练示意图。根据模型预测的结果和实际需求设定预设报警活动阈值，将该预设报警活动阈值应用于实际生产环境中，运行一段时间后如果预设报警活动阈值存在不理想的情况，例如报警频繁或者是不能及时报警，然后，可以尝试优化模型参数或者更换其他模型，直到找到最优的预设报警活动阈值。当报警触发的时候，首先判断运维知识库中是否存在定义好的匹配规则或者历史运维记录，如果存在直接执行运维脚本（目标自愈脚本）；如果不存在则通过训练好的模型，根据当前系统状态、报警信息等相关特征数据、运维脚本元操作和历史运维记录智能编排自愈脚本，即生成新的运维脚本（目标自愈脚本）。然后，根据实际运维效果不断优化模型参数和结构，以提高自愈脚本匹配的准确性和效率。当达到理想的运维效果之后，报警信息（待过滤报警信息）、报警阈值（预设报警活动阈值）和自愈脚本关联关系都要沉淀到运维知识库。

4）多级告警归并和告警抑制：

由于同时采集多个来源平台的待处理报警信息，各来源平台的节点规模也是比较大的，所有采集的数据规模和报警数量的规模也是很大的。所以要在数据采集、报警触发、报警信息格式统一、报警信息发送和报警处理等流程上进行告警的归并和抑制。

首先，将不同来源平台上面的数据进行归并整合，在不同的来运平台部署不同的数据采集agent（代理），用来采集各来源平台的运行状态数据。数据采集引擎可以通过主动或者被动的方式获取采集待处理报警信息，主动的方式是指数据采集引擎定时的去各个来源平台的agent上面拉取数据，被动的方式就是各来源平台直接将数据推送给数据采集引擎。报警触发引擎可以设置报警来源、分组、触发条件、评估时间、级别等报警规则。报警触发要根据报警阈值判断当前各来源平台各层次运行状态数据是否正常，如果不正常将这些待处理报警信息按照设置报警规则归并到一起。报警格式化引擎对所有触发的待处理报警信息会进行格式化处理，以统一的自定义格式输出报警发送引擎。报警发送引擎会接收这些待过滤报警信息并进行聚合和去重，并且，可以设置报警组触发等待时间、报警发送时间间隔，报警抑制规则，报警发送路由等规则来抑制大规模报警造成的报警轰炸。同一个报警组的数据会在定义的等待时间统一触发，触发之后一段时间内不会再次发送报警。对于大规模的报警，可能是由于一个或几个来源平台的故障造成的，此时，可以根据运维知识库中保存的故障运维记录、调用链等过滤出这几个目标故障根因，并且，可以通过设置对应的报警抑制规则，达到报警抑制的效果。同时，还可以设置多个报警发送路由，每个路由包含多个子路由，在各层级路由上面还可以设置各自的路由抑制规则。最终，通过各级路由配置的报警接收器，将报警发送到报警处理引擎。报警处理引擎会将报警信息持久化存储起来，根据报警时间、报警级别来判断这些报警是否应该推送。

5）支持工作流方式的可视化运维编排：

在运维知识库中保存运维元操作脚本，运维元操作脚本仅是单一的运维操作功能的实现。若无法通过智能编排自愈脚本完成故障自愈，则需要人工编排脚本，脚本编排的整个流程主要包含元操作节点、逻辑操作节点和连接线，元操作包含功能的描述、输入输出参数格式，具体的实现细节不需要在编排过程中展示；逻辑操作节点用来判断运维操作的下一步走向，并且传递上一步执行结果输出参数；连接线是有方向的，表示操作节点之间的执行顺序。编排的过程是在web页面以拖拽的方式，将所有选定的元素编排成一个DAG环图。编排完成之后的操作流程会以工作流的形式保存在运维知识库中，可以绑定到特定报警信息上面，报警发生的时候直接调用这个自愈脚本。也是机器学习模型的有效数据，通过模型的训练能够将其他报警的工作流也整合在一起，最终形成一个庞大的、完整的报警自动处理解决流程。

6）针对多维度告警的运维知识库：

该系统会创建一个持久化多维度告警的运维知识库，涉及到报警发生到结束的整个流程，如图6所示的运维知识库构建和使用流程。该系统能够采集硬件层、系统层、平台层、网络层和业务层各个层次的信息数据，包括平台基础设施的数据信息、操作系统的运行状态数据、平台的运行状态数据、网络数据传输状态、业务系统的运行状态数据。将这些数据统一在运维知识库中进行管理，同时运维知识库中还会保存各层次之间的调用链关系、所有待过滤报警信息、运维记录信息和运维脚本（自愈脚本）。运维知识库涉及报警发生到结束的整个生命周期，当报警发生的时候，系统会保存报警发生前后各个来源平台的层次的状态和各层次之间的调用关系，做成一个快照（目标故障快照）。如果故障是自动恢复的，同时会将运维记录也保存起来。如果故障没有自动恢复，就需要人为干预解决系统故障，并将运维过程形成运维脚本，继续沉淀到运维知识库。机器学习模型会使用运维知识库中信息持续训练，将故障发生的根本原因分析出来，推算出应该执行的运维操作（目标故障自愈脚本）。当故障再次发生的时候，系统会根据运维知识库中保存信息，自动查询各层次状态，执行针对性的故障恢复策略。

本发明主要针对多来源平台、大规模报警信息，构建针对多维度告警的运维知识库，通过不断训练机器学习模型、持续丰富运维知识库。在运维知识库和机器学习的协助下，实现多平台多源报警的格式化统一，并在报警触发的过程中经过多级的告警归并和抑制、智能预测设置报警阈值达到精准快速定位的效果。在报警发生之后，首先通过智能匹配运维脚本解决故障，如果不能及时恢复报警，可以通过可视化运维剧本编排，人为将故障处理流程分解成处理单元，形成一个故障处理工作流，保存到运维知识库中。通过优化机器学习模型，来自动运维，当故障发生的时候针对各个层次问题的处理办法重新编排运维脚本。通过不断地迭代运维知识、优化运维模型实现多平台的故障自愈。

需要说明的是，本发明所用术语仅为了描述特定实施例，而非限制本申请范围。如本发明说明书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者设备中还存在另外的相同要素。

还需说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。除非另有明确的规定和限定，术语“安装”、“相连”、“连接”等应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案。

Claims (10)

1.一种多源告警处理方法，其特征在于，包括：

接收各来源平台的各待处理报警信息，根据各所述待处理报警信息的来源平台以及各所述待处理报警信息，确定与各所述待处理报警信息对应的待过滤报警信息；

根据预设报警活动阈值对所述待过滤报警信息过滤，得到标准报警信息；其中，所述预设报警活动阈值基于运维知识库中的样本报警信息以及预设报警频率范围训练得到；所述样本报警信息基于预设周期内的各待过滤报警信息更新确定；

根据各标准报警信息，确定至少一个报警组以及与每个所述报警组对应的目标故障根因；

针对每一个目标故障根因，若所述运维知识库中存在与所述目标故障根因对应的目标自愈脚本，则执行所述目标自愈脚本；若所述运维知识库中不存在所述目标自愈脚本，则根据所述目标故障根因对应的报警组的报警时间，将所述报警组以及所述目标故障根因发送至与所述报警组对应的目标路由；其中，所述目标自愈脚本为所述运维知识库中已存储的运维脚本或者通过已存储的运维脚本自动编排生成的编排脚本。

2.根据权利要求1所述的方法，其特征在于，所述根据各所述待处理报警信息的来源平台以及各所述待处理报警信息，确定与各所述待处理报警信息对应的待过滤报警信息，包括：

针对每个待处理报警信息，确定所述待处理报警信息的来源平台；

根据与所述来源平台对应的目标解析方法，确定所述待处理报警信息的各解析信息，根据各所述解析信息以及预设标准格式，确定与所述待处理报警信息对应的待过滤报警信息；其中，解析信息包括报警名、报警来源、报警类型、报警级别、报警时间以及报警和关联信息中的至少一种信息。

3.根据权利要求1所述的方法，其特征在于，所述根据预设报警活动阈值对所述待过滤报警信息过滤，得到标准报警信息，包括：

针对每个待过滤报警信息，根据预设报警活动阈值内的各字段活动阈值以及所述待过滤报警信息，判断是否针对所述待过滤报警信息进行处理；

在针对所述待过滤报警信息进行处理的情况下，将所述待过滤报警信息确定为标准报警信息。

4.根据权利要求3所述的方法，其特征在于，所述预设报警活动阈值通过下述方式确定：

将当前预设周期内的各待过滤报警信息存储至所述运维知识库的样本报警信息中，并将所述当前预设周期内的预设报警活动阈值确定为初始报警阈值；

根据添加后的样本报警信息以及初始报警阈值，确定当前报警频率；

若所述当前报警频率不在预设报警频率范围内，则更新所述初始报警阈值，并返回执行所述根据添加后的样本报警信息以及初始报警阈值，确定当前报警频率的操作；

若所述当前报警频率在预设报警频率范围内，则将所述初始报警阈值作为下一预设周期内的预设报警活动阈值。

5.根据权利要求1所述的方法，其特征在于，所述根据各标准报警信息，确定至少一个报警组以及与每个所述报警组对应的目标故障根因，包括：

根据预设分组规则，对各标准报警信息进行分组处理，得到至少一个报警组；其中，所述预设分组规则包括基于报警时间的分组规则、基于报警来源的分组规则、基于触发条件的分组规则和基于报警级别的分组规则中的至少一种；

针对每个报警组，根据所述报警组内的各标准报警信息、各来源平台之间的平台调用链以及各来源平台内部的内部调用链进行根因分析，得到与所述报警组对应的至少一个目标故障根因。

6.根据权利要求1所述的方法，其特征在于，在所述根据所述目标故障根因对应的报警组的报警时间，将所述报警组以及目标故障根因发送至与所述报警组对应的目标路由之后，还包括：

接收目标路由构建和发送的与所述目标故障根因对应的目标自愈脚本，并执行所述目标自愈脚本；其中，所述目标路由构建和发送的与所述目标故障根因对应的目标自愈脚本为所述目标路由接收从可视化编排库中确定出的与所述目标故障根因对应的至少两个操作节点以及连接线，并接收对至少两个操作节点以及连接线的编排操作后所得到的与所述目标故障根因对应的目标自愈脚本；所述操作节点包括元操作节点以及逻辑操作节点；所述元操作节点包括功能描述以及输入输出参数格式；所述逻辑操作节点用于判断下一节点走向以及传递上一节点的输出参数；所述连接线用于表示各操作节点的执行顺序；

将所述目标自愈脚本与所述目标故障根因对应存储至运维知识库中。

7.根据权利要求6所述的方法，其特征在于，所述将所述目标自愈脚本与所述目标故障根因对应存储至运维知识库中，包括：

若在所述目标故障根因对应的等待时间内，仍存在与所述目标故障根因相关的标准报警信息，则将所述目标自愈脚本以及所述目标故障根因发送至所述目标路由，以通过所述目标路由对所述目标自愈脚本进行修正；接收所述目标路由发送的修正后的目标自愈脚本，并返回执行所述目标自愈脚本的操作，直至在所述目标故障根因对应的等待时间内，不存在与所述目标故障根因相关的标准报警信息；

若在所述目标故障根因对应的等待时间内，不存在与所述目标故障根因相关的标准报警信息，则将所述目标自愈脚本与所述目标故障根因对应存储至运维知识库中。

8.根据权利要求6所述的方法，其特征在于，所述将所述目标自愈脚本与所述目标故障根因对应存储至运维知识库中，包括：

根据所述目标故障根因对应的标准报警信息，生成目标故障快照；

将所述目标故障快照、所述目标自愈脚本以及所述目标故障根因对应存储至运维知识库中。

9.一种多源告警处理系统，其特征在于，包括：多个来源平台、报警信息整合自愈模块、运维知识库以及多个目标路由；其中，

多个所述来源平台，与所述报警信息整合自愈模块相连接，用于将各待处理报警信息发送至所述报警信息整合自愈模块；

报警信息整合自愈模块，用于执行如权利要求1-8任一项所述的多源告警处理方法；

运维知识库，与各所述来源平台和所述报警信息整合自愈模块分别连接，用于存储所述报警信息整合自愈模块发送的样本报警信息以及预设报警活动阈值，以使所述系统根据所述样本报警信息，对所述预设报警活动阈值进行更新，并反馈至所述报警信息整合自愈模块；用于存储具有对应关系的故障快照、自愈脚本以及故障根因，所述故障快照包括多个所述来源平台中与所述故障根因对应的各报警信息从发生到结束的报警相关信息；用于存储各来源平台之间的平台调用链、各来源平台内部的内部调用链、样本报警组以及样本故障根因，以使所述系统根据各平台调用链、各内部调用链、所述样本报警组以及所述样本故障根因训练得到故障根因分析模型；所述故障根因分析模型用于确定报警组对应的至少一个目标故障根因；

多个目标路由，与所述报警信息整合自愈模块相连接，用于接收所述报警信息整合自愈模块发送的报警组以及目标故障根因，根据所述目标故障根因构建与目标故障根因对应的目标自愈脚本，并将所述目标自愈脚本发送至所述报警信息整合自愈模块。

10.根据权利要求9所述的系统，其特征在于，所述目标路由包括剧本编排模块以及可视化编排库；其中，

所述剧本编排模块，与所述可视化编排库相连接，用于接收从可视化编排库中确定出的与所述目标故障根因对应的至少两个操作节点以及连接线，并接收对至少两个操作节点以及连接线的编排操作后所得到的与所述目标故障根因对应的目标自愈脚本，并将所述目标自愈脚本发送至所述报警信息整合自愈模块；

所述可视化编排库，包括：多个预先加载的操作节点以及连接线；其中，所述操作节点包括元操作节点以及逻辑操作节点；所述元操作节点包括功能描述以及输入输出参数格式；所述逻辑操作节点用于判断下一节点走向以及传递上一节点的输出参数；所述连接线用于表示各所述操作节点的执行顺序。