CN112068979A - 一种业务故障确定方法及装置 - Google Patents

Abstract

本发明公开了一种业务故障确定方法，包括：对集群中所有节点的日志进行监控；从集群中所有节点的日志中识别出错误日志，将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；将结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与模板日志的相关度评分；根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。根据打印的日志先进行一个是否为错误日志的判断，然后再进行一个故障类型的判断，通过这两次判断，初步定位故障模块，减少人工定位的工作量。

Description

一种业务故障确定方法及装置

技术领域

本发明涉及故障定位领域，具体涉及一种业务故障确定方法及装置。

背景技术

随着软件应用的不断发展，大量针对专业化业务场景的专属云系统纷纷出现，这些云系统一般都是通过私有的集群来提供云服务(如云存储集群)，对于使用者来说，云服务的底层信息是不可见的也无法控制的，在这种情况下，能够了解并利用海量的日志信息就显得尤为重要。

在企业级云存储软件应用中，往往使用大量的存储节点，多个节点意味着海量的日志，包括客户端日志、数据库日志、模块日志、中间件日志，传统的方式是当日志达到某种容量时进行一次压缩打包，存入备份日志中，这样只是简单的被动的处理大量产生的日志；还有一种办法是精简日志内容，这种方法如果碰到问题，往往难以通过日志来定位；在生产环境中，一般不同的日志输出到不同的日志文件中，如果需要查看某个功能或者某个业务的日志，需要在不同的日志文件中进行查找，当涉及的模块较多时、查找效率很低。由上可见，现有技术具有如下缺点：1、分布在系统不同应用程序、不同存储路径的日志，没有特定关键信息难以关联特定业务类型日志；2、每天产生日志量巨大，日志的管理和信息的提取较为困难；3、通过日志筛选业务请求中产生的故障、业务响应速度和模块的处理时间，耗费时间较大。为了解决管理海量日志、通过日志定位业务故障及性能瓶颈浪费的大量时间，有必要对现有的日志管理方式和通过日志定位问题的方式进行改进。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种业务故障确定方法及装置，用于解决现有技术的缺陷。

为实现上述目的及其他相关目的，本发明提供一种业务故障确定方法，包括：

对集群中所有节点的日志进行监控；

从集群中所有节点的日志中识别出错误日志，

将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

收集所述结构化日志流；

将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

可选地，在识别出错误日志时，开启打印详细日志；在判断错误日志中不存在故障日志时，关闭打印详细日志。

可选地，还包括：

将与故障类型信息匹配表匹配后的所述结构化日志流作为模板日志加入到所述故障类型信息匹配表中。

可选地，对非故障日志进行人工标记，判断所述非故障日志中是否存在故障日志，若存在，则将所述故障日志加入到故障日志信息匹配表中。

可选地，还包括：将所述备选模板日志的故障类型与故障信息处理表中的故障类型行对比，判断所述备选日志的修复类型，根据所述备选日志的修复类型完成对故障的修复。

可选地，所述将所述结构化日志流与故障类型信息匹配中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分，包括：

分别将所述结构化日志流和所述模板日志进行分词处理，得到若干相应的子词；

分别计算结构化日志流中的每个子词与模板日志中的每个子词的相关度；

对结构化日志流中的每个子词与模板日志中的每个子词的相关度进行加权求和，得到所述结构化日志流与每个模板日志的相关度评分。

可选地，所述结构化日志流与模板日志的相关度评分表示为：

其中，S(Q,d)表示结构化日志流与模板日志的相关度评分，W_i表示权重，R(q_i,d)是结构化日志流中子词q与模板日志d中子词的相关度评分。

可选地，所述备选模板日志为相关度评分超过设定阈值所对应的模板日志，或相关度评分排在前几位所对应的模板日志。

可选地，若在所述备选模板日志中，其中一个模板日志与结构化日志流的相关度评分远远超过其他模板日志与结构化日志流的相关度评分，则认为此时集群的故障类型为最高相关度评分对应的模板日志所对应的故障类型。

为实现上述目的及其他相关目的，本发明提供一种业务故障确定装置，包括：日志监控模块，用于对集群中所有节点的日志进行监控；

错误日志识别模块，用于从集群中所有节点的日志中识别出错误日志；

故障日志判断模块，用于将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

故障日志标记模块，用于对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

故障日志收集模块，用于收集所述结构化日志流；

故障日志解析模块，用于将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

故障类型匹配模块，用于根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

如上所述，本发明的一种业务故障确定方法及装置，具有以下有益效果：

本发明的一种业务故障确定方法，包括：对集群中所有节点的日志进行监控；从集群中所有节点的日志中识别出错误日志，将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；将结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与模板日志的相关度评分；根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。根据打印的日志先进行一个是否为错误日志的判断，然后再进行一个故障类型的判断，通过这两次判断，初步定位故障模块，减少人工定位的工作量。

附图说明

图1为本发明一实施例一种业务故障确定方法的流程图；

图2为本发明一实施例故障日志信息匹配表；

图3为本发明一实施例未匹配日志信息表；

图4为本发明一实施例故障类型信息匹配表；

图5为本发明一实施例故障处理信息表；

图6为本发明一实施例故障修复脚本信息表；

图7为本发明一实施例一种业务故障确定装置的硬件结构示意图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

如图1所示，一种业务故障确定方法，集成在集群中，可以用于软件内测阶段，包括自动化测试和手工测试过程中收集到的的数据，以及内测时的各种问题。随着测试版本的迭代，本发明会将保留大量的测试数据，成为一个可以应付生产环境的完善的故障修复。首先在测试环境集群中所有服务器上，安装本发明所述故障修复方法，安装统一的管理工具，控制所有节点统一的执行所有命令，来进行对日志的收集、汇总。配置控制机和被控机的配置文件，分别在/etc/salt/master和/etc/salt/minion。在上一步骤已安装完成的服务的前提下，安装本发明所述故障确定装置工具所依赖的组件，包括pgsql、zookeeper等。配置故障确定装置参数,将相关服务地址信息修改为相关依赖组件安装的地址信息，即pgsql、zookeeper等。

具体地，所述的故障确定方法，包括：

S11对集群中所有节点的日志进行监控；

S12从集群中所有节点的日志中识别出错误日志；

S13将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

S14对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

S15收集所述结构化日志流；

S16将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

S17根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

在步骤S11中，在集群所有节点上监控每个日志文件，通过日志的级别来判断是否需要开启打印详细日志，其中所述日志的级别包括INFO、WARN、ERROR。

从集群中所有节点的日志中识别出错误日志，具体为：根据日志的级别识别出集群中所有节点中的错误日志。比如，INFO、WARN对应非错误日志，ERROR对应错误日志。

当节点上的日志文件的级别为INFO、WARN，则不需要开启打印详细日志，当节点上的日志文件的级别为ERROR，则需要开启打印详细日志。

在开启打印详细日志后，收集集群中所有错误日志。具体收集错误日志的时间为，当日志量达到设定的条数时处理一次，或者在设定的时间段内无论日志数量多少就开始处理。

在本发明中可以根据实际业务情况动态开启、关闭打印详细日志，即日志文件的级别为INFO、WARN，则不需要开启打印详细日志，当节点上的日志文件的级别为ERROR，则需要开启打印详细日志。在保证在业务正常时，不会打印过多日志，占用存储资源。在异常时能够及时开启打印详细日志，方便定位。

在对完成对错误日志的识别后，需要基于所述错误日志得到故障日志。具体地，得到故障日志的方法为：

首先将这一批待处理的日志(即错误日志)进行分节点，分模块排序，然后过滤掉重复的日志，最后保留出来的日志开始逐条与故障日志信息匹配表log_match中日志的日志数据进行匹配，如果判断为故障，该日志即为故障日志，对故障日志进行标记，同时将此日志对应的数据流的下游日志(包含INFO、ERROR、WARN)采用同样的标识进行标记。如果全部判断为非故障，即不存在故障日志，则关闭打印详细日志。其中，标记的方法可以是采用同一标识ID进行标记。

对所述非故障日志进行人工标记，判断所述非故障日志中是否存在故障日志，若存在，则将所述故障日志加入到故障日志信息匹配表中，能够增强本发明的学习能力。

在完成对故障日志的标记后，收集所有带有标识ID的日志，集群中所有Slave节点将本节点产生的带有标识ID的日志，发送到Master节点，进行日志的汇总，然后对日志进行排序、去重后面收集全链路带有标识ID的日志先记录在数据库中。然后提取数据库中收集到的，带有标识ID的日志，提取日志中的关键信息，然后对其结构化处理，得到结构化日志流，如：RZ1->RZ2->RZ3>RZ4……。

在步骤S15中，将结构化日志流与故障类型信息匹配表module_match中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分。其中，所述日志流与所述模板日志的相关度评分的计算方法为：

将输入的结构化日志流和模板日志进行划分(分词)，然后分别计算结构化日志流中每个子部分(子词)与模板日志中每个子词的相关度，然后进行加权求和，得到所述结构化日志流与每个模板日志的相关度评分。评分公式如下：

上面公式中，S(Q,d)表示结构化日志流与每个模板日志的相关度评分，W_i表示权重，也就是IDF值。R(q_i,d)是结构化日志流中子词q与模板日志d中子词的相关度评分。

在经过匹配后，选择出多个最接近的目志作为备选模板日志，其中，最接近的是指相关度评分最高的几个备选模板日志。一般来说，可以选择5个最接近的备选模板日志，将这5个备选模板日志记为{L1、L2、L3、L4、L5}，标记出这些备选模板日志对应的故障类型{L1：a、L2：b、L3：c、L4：d、L5：e}，然后将结构化日志流和选出的备选模板日志存入故障类型信息匹配表module_match中，标记为：待确认；然后关闭详细日志打印。

在一实施例中，可以将与故障类型信息匹配表匹配后的所述结构化日志流作为模板日志加入到所述故障类型信息匹配表中，以完善本发明的匹配精度，增强本发明的学习能力。

需要说明的是，如果在这多个备选模板日志的其中一个相关度评分最高且远高于其他备选模板日志的评分，则会认定为是这个备选模板日志所对应的故障类型为整个集群的故障类型。

将此故障类型与故障处理信息表err_type中的的故障类型做对比，判断所述备选日志的修复类型，如果是可以自动修复的类型，就让其自动修复，如果是需要脚本干预的，则调用故障修复脚本信息表script_tool中的相关脚本对此类型的的故障进行修复；如果是不能修复的类型，则将此故障连同日志流一同通知给相关运维人员。

对于一些可以进行规避或者修复的故障类型，本发明会在脚本库中找到可以解决的工具，系统会进行规避或者修复，保证在无人工干预的情况下，自动修复；对于不能进行修复的情况，系统会及时告警，通知相关人员处理，达到一种从发现到解决(通知)的闭环。

在实际运用中，将此本发明所述的方法部署在集群中，在进行自动化测试和手工测试跑出的数据以及内测时的各种问题，都会维护在数据库中。一些常见问题的解决方法，也会以脚本的形式维护在本发明所包含的脚本库中，随着测试版本的迭代，本发明所述方法会完全继承测试周期内所保留大量的测试数据，成为一个可以应付生产环境的完善的故障修复方法。

由上述技术方案可见，本发明所提供的一种业务故障确定方法，通过实时监控，动态的开关打印详细日志，然后对日志进行逐条判断，对收集的全节点的日志进行结构化，最后对结构化日志进行故障匹配，实现一种在无人工干预的情况下从发现故障到定位问题。通过本发明的方法可以实现在生产环境下快速定位，甚至不需要人工干预的情况下解决一些线上问题。

在产品内测阶段，开始使用本发明，会在版本不断的迭代过程中形成一个包含各种错误类型的的库。在生产环境下，通过对新问题的再定位，可以使得本发明达到一种可以不断学习，不断增强匹配范围和准确性的效果。

如图7所示，一种业务故障确定装置，包括：

日志监控模块71，用于对集群中所有节点的日志进行监控；

错误日志识别模块72，用于从集群中所有节点的日志中识别出错误日志；

故障日志判断模块73，用于将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

故障日志标记模块74，用于对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

故障日志收集模块75，用于收集所述结构化日志流；

故障日志解析模块76，用于将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

故障类型匹配模块77，用于根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

由于装置实施例与方法实施例相对应，因此，装置实施例的具体实施例部分可以参考方法实施例，这里不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器((RAM,Random Access Memory)、电载波信号、电信信号以及软件分发介质等。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种业务故障确定方法，其特征在于，包括：

对集群中所有节点的日志进行监控；

从集群中所有节点的日志中识别出错误日志，

将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

收集所述结构化日志流；

将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

2.根据权利要求1所述的业务故障确定方法，其特征在于，在识别出错误日志时，开启打印详细日志；在判断错误日志中不存在故障日志时，关闭打印详细日志。

3.根据权利要求1所述的业务故障确定方法，其特征在于，还包括：

将与故障类型信息匹配表匹配后的所述结构化日志流作为模板日志加入到所述故障类型信息匹配表中。

4.根据权利要求1所述的业务故障确定方法，其特征在于，对非故障日志进行人工标记，判断所述非故障日志中是否存在故障日志，若存在，则将所述故障日志加入到故障日志信息匹配表中。

5.根据权利要求1所述的业务故障确定方法，其特征在于，还包括：将所述备选模板日志的故障类型与故障信息处理表中的故障类型行对比，判断所述备选日志的修复类型，根据所述备选日志的修复类型完成对故障的修复。

6.根据权利要求1所述的业务故障确定方法，其特征在于，所述将所述结构化日志流与故障类型信息匹配中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分，包括：

分别将所述结构化日志流和所述模板日志进行分词处理，得到若干相应的子词；

分别计算结构化日志流中的每个子词与模板日志中的每个子词的相关度；

对结构化日志流中的每个子词与模板日志中的每个子词的相关度进行加权求和，得到所述结构化日志流与每个模板日志的相关度评分。

7.根据权利要求6所述的一种业务故障确定方法，其特征在于，所述结构化日志流与模板日志的相关度评分表示为：

其中，S(Q,d)表示结构化日志流与模板日志的相关度评分，W_i表示权重，R(q_i,d)是结构化日志流中子词q与模板日志d中子词的相关度评分。

8.根据权利要求1所述的业务故障确定方法，其特征在于，所述备选模板日志为相关度评分超过设定阈值所对应的模板日志，或相关度评分排在前几位所对应的模板日志。

9.根据权利要求1或8所述的业务故障确定方法，其特征在于，若在所述备选模板日志中，其中一个模板日志与结构化日志流的相关度评分远远超过其他模板日志与结构化日志流的相关度评分，则认为此时集群的故障类型为最高相关度评分对应的模板日志所对应的故障类型。

10.一种业务故障确定装置，其特征在于，包括：

日志监控模块，用于对集群中所有节点的日志进行监控；

错误日志识别模块，用于从集群中所有节点的日志中识别出错误日志；

故障日志判断模块，用于将所述错误日志与故障日志信息匹配表中的日志数据进行匹配，识别出所述错误日志中的故障日志；

故障日志标记模块，用于对故障日志以及对应的下游日志采用同样的标记进行标记，并将标记后的故障日志进行结构化，得到结构化日志流；

故障日志收集模块，用于收集所述结构化日志流；

故障日志解析模块，用于将所述结构化日志流与故障类型信息匹配表中的模板日志进行匹配，得到所述日志流与所述模板日志的相关度评分；

故障类型匹配模块，用于根据所述相关度评分筛选出备选模板日志，并确定所述备选模板日志的故障类型。

Images