CN112699005A - 服务器硬件故障监控的方法、电子设备及存储介质 - Google Patents
服务器硬件故障监控的方法、电子设备及存储介质 Download PDFInfo
- Publication number
- CN112699005A CN112699005A CN202011613848.3A CN202011613848A CN112699005A CN 112699005 A CN112699005 A CN 112699005A CN 202011613848 A CN202011613848 A CN 202011613848A CN 112699005 A CN112699005 A CN 112699005A
- Authority
- CN
- China
- Prior art keywords
- alarm
- items
- item
- kernel
- fault
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000012544 monitoring process Methods 0.000 title claims abstract description 46
- 230000001364 causal effect Effects 0.000 claims abstract description 28
- 238000012545 processing Methods 0.000 claims abstract description 20
- 238000007781 pre-processing Methods 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 5
- 230000000694 effects Effects 0.000 claims 1
- 230000000875 corresponding effect Effects 0.000 description 57
- 238000012549 training Methods 0.000 description 12
- 230000000295 complement effect Effects 0.000 description 9
- 238000004458 analytical method Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000001186 cumulative effect Effects 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000002596 correlated effect Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000012098 association analyses Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000010219 correlation analysis Methods 0.000 description 1
- 230000002068 genetic effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明实施例涉及计算机技术领域，公开了一种服务器硬件故障监控的方法、电子设备及存储介质。本发明中服务器硬件故障监控的方法，包括：获取至少两条待分析的告警项，告警项包括用于表征待分析内核日志中告警内容的标识信息；针对每个告警项进行如下处理：根据标识信息关联告警项与其他告警项，将满足预设关联规则的告警项及关联的其他告警项作为相关项对；获取相关项对中告警项之间的因果关系；根据因果关系对相关项对中的告警项进行分类，获得分类结果；根据分类结果，获取服务器硬件故障的故障原因。采用本实施例中的方法，能够监控海量的服务器，准确获取服务器硬件故障的故障原因。
Description
技术领域
本发明实施例涉及计算机技术领域，特别涉及一种服务器硬件故障监控的方法、电子设备及存储介质。
背景技术
硬件安全是服务器底层的安全，做好各项硬件监控，及时处理硬件故障是保证系统服务正常运行的基础。通常内核日志是进行机器硬件故障诊断的重要依据，内核日志记录了服务器在运行过程中，内核自身、以及所运行模块、进程等性能状况的信息；对内核日志进行分析，从中挖掘出与硬件状态相关的信息，确定出硬件的状态。
目前对内核日志的分析过程中，为了便于发现不同类别的故障问题，通常会根据内容的相似度对内容日志进行归类；然而，海量的服务器产生的内核日志的数据量大且数据复杂，若基于内容的相似度进行日志分类的方式，容易忽略内容不同而实际反映同一类问题的日志，或者忽略内容不同而实际相互关联的日志，导致对日志的分类不准确，对硬件的状态分析不准确，影响对服务器的硬件故障的监控。
发明内容
本发明实施方式的目的在于提供一种服务器硬件故障监控的方法、电子设备及存储介质，能够监控海量的服务器的硬件故障，准确获取服务器硬件故障的故障原因。
为解决上述技术问题，本发明的实施方式提供了一种服务器硬件故障监控的方法，包括：获取至少两条待分析的告警项，所述告警项包括用于表征待分析内核日志中告警内容的标识信息；针对每个所述告警项进行如下处理：根据所述标识信息关联所述告警项与其他告警项，将满足预设关联规则的所述告警项及关联的其他告警项作为相关项对，其中，所述预设关联规则包括：所述告警项与关联的其他告警项之间的支持度、置信度以及提升度均超过各自对应的阈值；获取所述相关项对中所述告警项之间的因果关系；根据所述因果关系对所述相关项对中的所述告警项进行分类，获得分类结果；根据所述分类结果，获取服务器硬件故障的故障原因。
本发明的实施方式还提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的服务器硬件故障监控的方法。
本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时实现上述的服务器硬件故障监控的方法。
本申请实施例中的服务器硬件故障监控的方法，针对每个告警项进行关联处理，获取满足预设关联规则的告警项及其关联的其他告警项，通过告警项与关联的其他告警项之间的支持度、置信度以及提升度选取出符合预设关联规则的相关项对，可以挖掘出具有强因果关系的告警项及其关联的其他告警项；通过相关项对中的告警项之间的因果关系对告警项进行分类，可以准确地将导致同一故障结果的告警项划分为一类，从而可以避免通过告警内容的文本相似度进行归类而导致忽略文本内容不同但相互关联的告警内容或忽略文本内容不相似而实际属于相同类别的告警内容，提高了对告警项归类的准确度，每个类别中的告警项更加全面，可以确定出准确的故障原因；同时告警项包括用于表征待分析内核日志对应的告警内容的标识信息，基于该标识信息关联告警项与其它告警项，而不是直接获取待分析内核日志进行归类和故障定位，减小了待归类和分析的数据量，使得针对海量的服务器的待分析内核日志时，无需对日志的所有内容进行分类和分析，减少了处理的数据量，提高了确定故障原因的速度和效率，扩大了监控的服务器的数量。
另外，在获取所述相关项对中所述告警项之间的因果关系之前，所述方法还包括：针对每个相关项对进行如下处理：检测是否存在与相关项对的因果关系相反的相关项对，若是存在，则判断相关项对的置信度是否大于相反的相关项对的置信度，若是，则保留相关项对，否则，删除相关项对，保留相反的相关项对。若检测到存在对应关系互为相反的相关项对，保留置信度高的相关项对，进一步减少分析的数据量，同时，保留置信度高的相关项对，提高待分析的相关项对的准确度。
另外，相关项对包括：被标记为先导项的告警项以及被标记为后继项的告警项，所述先导项用于表征故障因素，所述后继项用于表征与所述故障因素对应的故障结果；根据所述因果关系对相关项对中的所述告警项进行分类，获得分类结果，包括：查询具有相同后继项的相关项对；根据相关项对中所述先导项与所述后继项之间的因果关系，将查询到的相关项对中对应同一个后继项的先导项划分为同一类别，将其他相关项对中的先导项各自作为一个类别。通过先导项和后继项可以表征相关项对中告警项之间的因果关系，将具有相同故障原因的先导项划分为同一类别，使得被划分为同一类别的先导项可以引发该故障结果；进而基于故障结果，可以确定出故障原因，该分类方式中，是将导致同一故障结果的告警项划分为一类，避免因告警内容的文本不同而忽略告警项之间的关联关系的问题，提高对故障原因的准确定位。
另外，根据所述分类结果，确定服务器硬件故障的故障原因，包括：获取每个所述类别对应的后继项；根据所述后继项以及预设的后继项与故障原因的对应关系，确定每个所述类别的故障原因；输出每个类别以及对应的所述故障原因。后继项表征了故障结果，直接输出故障结果不利于工作人员对服务器的维护，通过后继项与故障原因之间的对应关系，确定每个类别的故障原因后，便于工作人员对服务器进行维护。
另外，获取至少两条待分析的告警项之后，所述方法还包括：获取每个所述告警项对应的宕机率，所述宕机率用于表征所述告警项出现的情况下同时服务器发生宕机的概率；查询小于预设的宕机率阈值的所述宕机率；删除查询到的所述宕机率对应的告警项。结合宕机率，可以进一步筛选出具有关联性的告警项，过滤出与故障结果不相关的数据，提高对故障原因分析的准确度。
另外，获取每个所述告警项对应的宕机率，包括：获取用于表征所述告警项出现次数的第一数据以及获取用于表征所述告警项对应出现宕机次数的第二数据；将所述第二数据与所述第一数据的比值作为所述告警项对应的宕机率。通过告警项以及宕机次数，快速获取宕机率。
另外，获取至少两条待分析的告警项，包括：获取监控范围内服务器的日志数据，所述日志数据包括至少两条内核日志；对所述日志数据进行预处理，获得待分析内核日志，所述预处理包括：删除无效内核日志的操作或删除重复内核日志的操作；根据所述待分析内核日志中的告警内容以及预设的与所述告警内容匹配的标识信息，生成至少两条待分析的告警项。对获取的日志数据进行预处理，减少处理的数据量以及提高后续故障原因确定的准确性。
另外，删除重复内核日志的操作包括：将每条所述内核日志中的日志时间转化为具有相同格式的时间戳；按照所述时间戳指示的从早至晚的顺序，依次对每条所述内核日志进行如下处理：将所述内核日志与其他内核日志进行模糊匹配，获取相似度超过预设阈值的内核日志作为相似内核日志；从所述内核日志以及所述相似内核日志中获取时间戳指示最早的内核日志作为待分析内核日志。模糊匹配的方式，可以从海量的日志数据中快速筛选出重复的数据，进一步减少后续待分析的数据量。
另外，预处理还包括：针对每条所述内核日志进行如下处理：判断所述内核日志中的告警内容是否与预设的白名单中的告警内容匹配，若匹配，则根据所述匹配的告警内容生成所述待分析告的告警项；若匹配失败，则执行所述删除重复内核日志的操作。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。
图1是根据本发明第一实施方式提供的一种服务器硬件故障监控的方法的流程图；
图2是根据本发明第二实施方式提供的一种服务器硬件故障监控的方法的流程图；
图3是根据本发明第三实施方式提供的一种服务器硬件故障监控的方法的流程图；
图4是根据本发明第三实施方式提供的一种服务器硬件故障监控的方法中的一种数据表；
图5是根据本发明第三实施方式提供的一种服务器硬件故障监控的方法中的汇总告警项形成的数据表；
图6是根据本发明第四实施方式提供的一种服务器硬件故障监控的方法中的一种数据表；
图7是根据本发明第五实施方式提供的一种电子设备的结构框图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。
以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
本发明的第一实施方式涉及一种服务器硬件故障监控的方法。应用于电子设备，如用于故障监控的服务器等，其流程如图1所示：
步骤101：获取至少两条待分析的告警项，告警项包括用于表征待分析内核日志中告警内容的标识信息。
步骤102：针对每个告警项进行如下处理：根据标识信息关联告警项与其他告警项，将满足预设关联规则的告警项及关联的其他告警项作为相关项对，其中，预设关联规则包括：告警项与关联的其他告警项之间的支持度、置信度以及提升度均超过各自对应的阈值。
步骤103：获取相关项对中告警项之间的因果关系；
步骤104：根据因果关系对相关项对中的告警项进行分类，获得分类结果。
步骤105：根据分类结果，获取服务器硬件故障的故障原因。
本申请实施例中的服务器硬件故障监控的方法，针对每个告警项进行关联处理，获取满足预设关联规则的告警项及其关联的其他告警项，通过告警项与关联的其他告警项之间的支持度、置信度以及提升度选取出符合预设关联规则的相关项对，可以挖掘出具有强因果关系的告警项及其关联的其他告警项；通过相关项对中的告警项之间的因果关系对告警项进行分类，可以准确地将导致同一故障结果的告警项划分为一类，从而可以避免通过告警内容的文本相似度进行归类而导致忽略文本内容不同但相互关联的告警内容或忽略文本内容不相似而实际属于相同类别的告警内容，提高了对告警项归类的准确度，每个类别中的告警项更加全面，可以确定出准确的故障原因；同时告警项包括用于表征待分析内核日志对应的告警内容的标识信息，基于该标识信息关联告警项与其它告警项，而不是直接获取待分析内核日志进行归类和故障定位，减小了待归类和分析的数据量，使得针对海量的服务器的待分析内核日志时，无需对日志的所有内容进行分类和分析，减少了处理的数据量，提高了确定故障原因的速度和效率，扩大了监控的服务器的数量。
本发明的第二实施方式涉及一种服务器硬件故障监控的方法。第二实施方式是对第一实施方式的详细介绍，其流程如图2所示：
步骤201：获取至少两条待分析的告警项，告警项包括用于表征待分析内核日志中告警内容的标识信息。
具体地，本示例中应用于电子设备，该电子设备可以用于监控海量的服务器硬件故障；确定服务器硬件故障的故障原因。该电子设备可以包括服务器。
可以从数据平台直接获取待分析的告警项，该告警项包括用于表征待分析内核日志对应的告警内容的标识信息，标识信息可以为日志中的告警内容的关键词，也可以由电子设备基于获取的待分析内核日志以及预设的告警项规则，生成待分析的告警项。告警项的形式可以根据需要设置，例如，本示例中可以将该标识信息“cpu_temperature”作为一条告警项，用于表征CPU温度异常。
本示例中由于告警项包括表征告警内容的标识信息，而标识信息通常较为简短，生成的告警项的数量小于待分析内核日志的数据量，从而可以压缩待分析内核日志中的信息，减少后续分析的数据量。
可以理解的是，由于是对大量的服务器的监控，故获取的告警项的数据量通常较大，例如：10000条、20000条等。
步骤202：针对每个告警项进行如下处理：根据标识信息关联告警项与其他告警项，将满足预设关联规则的告警项及关联的其他告警项作为相关项对。
具体地，如果两个告警项在所有服务器中同时出现、或某个告警项的出现伴随另一个告警项的出现的概率很高的话，表征这两个告警项之间是存在关联的关系。基于此，本示例中采用关联分析算法对告警项进行关联。本示例中可以根据实际的需要设置关联规则，关联规则包括：告警项与关联的其他告警项之间的支持度超过支持度阈值、告警项与关联的其他告警项之间的置信度超过置信度阈值以及告警项与关联的其他告警项之间的提升度超过提升度阈值的告警项对。下面将详细介绍关联规则以及基于关联规则，获取相互关联的告警，形成相关项对的过程：
可以根据待分析的告警项，构建训练样本集。
具体地，针对每个服务器进行如下处理：将该服务器的告警项合并为一条记录，将该记录作为一个样本。若有N台服务器，可以得到包含N条记录的训练样本集，N为大于1的整数。在关联算法中，可以将每个告警项称为事务，本示例中以“item”表征事务，即告警项，关联可以基于该告警项中的标识信息进行关联。支持度表征在该训练样本集中，项集(X，Y)同时出现的概率，可以用公式(1)表示：
Surpport(X->Y)＝训练样本集中同时出现X,Y的样本数/总样本数，公式(1)；
其中，X表示关联规则中用于表征故障因素的先导项，Y表示关联规则中用于表征与故障因素对应的故障结果的后继项。
置信度表征在训练样本集中X出现的条件下Y出现的概率，可以用公式(2)表示为：
Confidence(X->Y)＝训练样本集中同时出现X,Y的样本数/练样本集中出现X的样本数，公式(2)；
提升度表征训练样本集中X出现的条件下Y出现的概率与训练样本集中Y出现的概率的比值，即可以理解为在Y自身出现可能性的基础上，X的出现对Y出现概率的提升程度，可以用公式(3)表示为：
Lift(X->Y)＝Confidence(X->Y)/样本集中Y出现的概率，公式(3)；
可以根据实际应用，预先设置关联规则X->Y，例如，本示例中预设关联规则表示关联关系中各项指标超过预设定的阈值，通常支持度阈值、置信度阈值以及提升度阈值设定越高，表示Y的出现与X的出现相关性越强。
需要说明的是，支持度阈值可以根据设置的支持样本数据计算获得，支持样本数可以为同时出现X和Y的样本的数目；例如，本示例中告警项多，可以将支持样本数设置为30，那么支持度阈值＝30/训练样本集中的样本数。支持样本数小表明在训练集合中同时出现X和Y的覆盖范围小，可能为偶然发生的事件，故支持样本数不能设置太小，例如，包含10000条告警项的训练样本集，支持样本数不能设置为1。
本示例中，将支持样本数设置为30，置信度阈值设置0.8，提升度阈值设置为1.2。在关联规则设置完成之后，可以选择关联分析中FPGROWTH算法，查找满足该关联规则的关联关系。本示例中，相关项对可以包括：被标记为先导项的告警项以及被标记为后继项的告警项，先导项用于表征故障因素，后继项用于表征与故障因素对应的故障结果。在实际应用中，相关项对中的先导项可以包含至少1个告警项，后继项中也可以包含至少1个告警项。即一个告警项可能同时关联多个告警项，也可能同时被多个项关联，或者是相互关联。为了简化后续对相关项对中告警项的分类，本示例中获取先导项包含1个告警项且后继项包含1个告警项的相关项对，得到如表1所示的相关项对，表1中还包括了每个置信度以及出现该先导项和后继项的样本数。
| 先导项 | 后继项 | 置信度 | 样本数 |
| processor-apic | cpu-machine-check-exception | 0.99 | 450 |
| cpu-machine-check-exception | processor-apic | 0.98 | 450 |
| processor-apic | tsc-error | 0.89 | 405 |
| tsc-error | processor-apic | 0.99 | 405 |
| cpu-machine-check-exception | tsc-error | 0.88 | 404 |
| tsc-error | cpu-machine-check-exception | 0.98 | 404 |
| cpu_error | processor-apic | 0.84 | 277 |
| cpu_error | cpu-machine-check-exception | 0.84 | 277 |
| HW_err_generic | cpu_error | 1.00 | 56 |
| HW_err_generic | tsc-error | 0.86 | 48 |
表1
需要说明的是，本示例中也可以通过设置最终后继项的方式，获取相关项对；即若某个告警项除了相互关联的告警项之外，没有其他后继项则为最终后继项。其中，各先导项的最终后继项可以通过递归方式查找。
值得一提的是，在执行步骤202之后，可以针对每个相关项对进行如下处理：检测是否存在与相关项对的因果关系相反的相关项对，若是存在，则判断相关项对的置信度是否大于相反的相关项对的置信度，若是，则保留相关项对，否则，删除相关项对，保留相反的相关项对。
下面以一个具体的例子进行说明，例如，相关项对“processor-apic——>cpu-machine-check-exception”,其中，位于“——>”左侧的为先导项，右侧为后继项；该相关项对中因果关系即为：故障因素“processor-apic”对应的故障结果为“cpu-machine-check-exception”；若检测到与该相关项对“processor-apic——>cpu-machine-check-exception”相反的相关项对“cpu-machine-check-exception——>processor-apic”；那么获取该相关项对的置信度以及相反的相关项对的置信度；保留置信度高的相关项对。如表1所示，“processor-apic——>cpu-machine-check-exception”的置信度为0.99，相反的相关项对的置信度为0.98，那么保留相关项对“processor-apic——>cpu-machine-check-exception”；删除相反的相关项对“cpu-machine-check-exception——>processor-apic”。
值得一提的是，通过检测是否存在相反的相关项对，保留置信度高的相关项对，可以进一步减少重复的数据，同时保证保留的相关项的准确性。
步骤203：获取相关项对中告警项之间的因果关系；
具体地，由于在相关项对中，后继项表征了故障因素对应的故障结果，先导项用于表征故障因素，即相关相对中的因果关系即为该相关项对中先导项与后继项之间的对应关系。
步骤204：查询具有相同后继项的相关项对。
步骤205：根据相关项对中先导项与后继项之间的因果关系，将查询到的相关项对中对应同一个后继项的先导项划分为同一类别，将其他相关项对中的先导项各自作为一个类别。
由于在相关项对中，后继项表征了故障因素对应的故障结果，先导项用于表征故障因素，故可以通过先导项和后继项之间的因果关系，将导致同一结果的原因划为一类。
下面以一个具体的例子说明，例如，查询到的相关项对如表2所示，
表2
如表2所示，查找到的相关项对包括：第2个、第3个、第4个至第8个；由于第2个和第3个具有相同的后继项，第4个至第8个具有相同的后继项，那么可以将第2个和第3个的先导项划分为同一个类别，即将“cpu-machine-check-exception、processor-apic”划分为一个类别，该类别对应同一个后继项“tsc-error”；将第4至第8个的相关项对中的先导项划为同一个类别，即，将“cpu_error、processor-apic、HW_err_generic、processor-apic、tsc-error”归为一个类别，该类别对应的后继项均为“cpu-machine-check-exception”；而第1个相关项对中的后继项与其他相关相对中的后继项均不相同，则将第1个的先导项单独作为一个类别。
得到如表3所示的类别与其对应的后继项。
表3
需要说明的是，步骤204至步骤205是对第一实施方式中步骤104的具体说明。
步骤206：获取每个类别对应的后继项。
步骤207：根据后继项以及预设的后继项与故障原因的对应关系，确定每个类别的故障原因。
为了便于理解后继项表征的故障结果，可以是人工预先设置后继项与故障原因的对应关系，也可以是设备预先对故障原因进行分析后获得该对应关系，以确定出每个类别的故障原因。例如，如表4中所示，“cpu_error,HW_err_generic,processor-apic,rip-inexact,tsc-error,cpu-machine-check-exception”该类别对应的后继项为“cpu-machine-check-exception”，可以根据该故障因素，确定出该硬件故障的故障原因为cpu_error，因此，可以将该cpu_error作为该类别的故障原因。
表4
步骤208：输出每个类别以及对应的故障原因。
具体地，可以显示每个类别包含的告警项以及每个类别对应的故障原因。
以下为日志告警项与故障原因的对应关系表：
表5
步骤206至步骤207是对第一实施方式中步骤105的详细说明。
本实施方式中，通过关联规则，可以快速获取具有强关联关系的告警项，即使得确定的相关相对中的因果关系强；对具有强关联的相关项对进行分析，避免对关联关系弱的告警项的分析，减少干扰。
本发明的第三实施方式涉及一种服务器硬件故障监控的方法。本实施方式是对第二实施方式或第一实施方式的进一步改进，主要改进之处在于：本实施方式中结合宕机率对告警项进行处理，进一步减少了无用的数据。其流程如图3所示：
步骤301：获取至少两条待分析的告警项，告警项包括用于表征待分析内核日志中告警内容的标识信息。
步骤302：获取每个告警项对应的宕机率，宕机率用于表征告警项出现的情况下同时服务器发生宕机的概率。
具体地，本示例中为了进一步减少干扰数据，可以通过服务器的宕机数据，获取每个告警项对应的宕机率；并结合告警项对应的宕机率，删除与故障原因无关的告警项。
可以同时获取所有服务器的宕机数据；获取宕机数据的方式多有种，例如，可以使用kdump工具获取数据；还可以用其他工具获取数据；也可以结合多种工具获取的数据，将结合后的数据作为获取的宕机数据。本示例中结合多种工具获取的数据作为宕机数据。
例如，kdump是一个用于在机器的系统宕机时进行重启和记录宕机信息的工具和服务。安装kdump工具后，该机器的系统若因崩溃、内存耗尽、内核异常等原因导致宕机时，会自动重启机器并在本地生成记录文件，可在重新开机时查看文件内容并定位宕机原因。将宕机原因用指定命令发送到监控的设备，该监控设备获取监控范围内服务器的kdump宕机信息。但是，kdump工具无法采集因系统盘或阵列卡问题导致的宕机，部分硬件故障也无法通过kdump工具进行启动。
为了弥补kdump工具采集的宕机数据不完整的问题，本示例中通过另一宕机采集工具采集数据；该宕机采集工具定时检查机器状态，记录宕机与失连的机器信息，定时的时长可以为1分钟。该宕机采集工具无法采集发生宕机且在1分钟内重启成功的机器的数据。
本示例中还可以在每次机器重启时，提取系统日志中本次开机内核启动前一段的日志，识别日志中是否存在各项系统服务正常停止的日志记录，从而判断上次关机是否为正常重启。
结合上述三种方式获取的数据，生成基于宕机数据，记录发生宕机的机器及机器对应的宕机时间。
在一个例子中，获取用于表征告警项出现次数的第一数据以及获取用于表征告警项对应出现宕机次数的第二数据；将第二数据与第一数据的比值作为告警项对应的宕机率。
具体地，为了获取宕机次数与告警项之间的关系，本示例中还获取监控范围服务器的内核日志；将获取的内核日志与宕机数据进行合并；例如，以日期粒度，对某一个ip的数据进行合并，形成如图4所示的数据表，图4中items为告警项，为了进一步便于统计发生宕机的事件，可以将图4中的数据中每个告警项进行汇总，形成如图5所示的数据表；图5中每个告警项对应的宕机次数表示该告警项出现后是否发生宕机的累计值，告警项x1在图4中总共出现了3次，第一次出现在1号，截止统计时间，在1号及1号之后发生过宕机，则累计值记为1，第二次出现在3号，截止统计时间，在3号及3号之后发生过宕机，则累计值加1，同理，第三次出现在5号，截止统计时间，在5号及5号之后发生过宕机，则累计值加1；故该告警项x1出现后发生宕机的累计值为3。
获取用于指示每个告警项出现次数的第一数据，以及获取表征该告警项对应出现宕机次数的第二数据。
下面以图4和图5介绍告警项x1对应的宕机率：
x1对应的宕机率＝x1出现后同时出现宕机的次数/x1出现的次数×100％
＝3/3×100％
＝100％；
其中，x1出现后同时出现宕机的次数即为该告警项x1对应出现宕机次数。
本示例中获取各告警项对应的宕机率，其部分结果可以如表6所示：
| 告警项 | 第一数据 | 第二数据 | 宕机率 |
| bug-bad-page-state | 1853 | 302 | 16.3％ |
| cpu-core-power-limit | 268 | 13 | 4.85％ |
| cpu_err | 385 | 367 | 95.32％ |
| cpu-machine-check-exception | 463 | 461 | 99.57％ |
| cpu-package-power-limit | 39 | 0 | 0％ |
| cpu-pid-tainted | 1280 | 641 | 50.08％ |
表6
步骤303：查询小于预设的宕机率阈值的宕机率。
具体地，宕机率阈值可以有多种方式进行设置，例如，采用四分位数法，也可以有根据实际的应用确定宕机率阈值。
步骤304：删除查询到的宕机率对应的告警项。
查询宕机率小于该宕机率阈值的宕机率；宕机率小于宕机率阈值，表明该宕机率对应的告警项不是导致故障的因素，故删除该宕机率对应的告警项。例如，告警项x5对应的宕机率为0；小于宕机率阈值3％，那么删除该告警项x5。
步骤305：针对每个告警项进行如下处理：根据标识信息关联告警项与其他告警项，将满足预设关联规则的告警项及关联的其他告警项作为相关项对。
步骤306：获取相关项对中告警项之间的因果关系。
步骤307：根据因果关系对相关项对中的告警项进行分类，获得分类结果。
步骤308：根据分类结果，获取服务器硬件故障的故障原因。
步骤305至步骤307可以如第二实施方式中步骤202至步骤205，此处将不再赘述。
在一个例子中，若故障根因在于磁盘硬件损坏，可以输出更换磁盘的建议。若故障原因在为文件系统损坏，可以输出修复文件系统的建议。
需要说明的是，本示例中增加了宕机率，结合宕机率可以进一步过滤出不重要的告警项，减少数据的数量，提高故障原因确定的准确率。
本发明的第四实施方式涉及一种服务器硬件故障监控的方法。本实施方式是对上述实施方式中获取告警项的另一种实现方式的详细介绍。该获取至少两条待分析的告警项的流程如图6所示：
步骤401：获取监控范围内服务器的日志数据，日志数据包括至少两条内核日志。
具体地，可以通过netconsole工具采集线上服务器日志数据，该日志数据为服务器的内核日志。本示例中，监控范围内的服务器的数量至少2台，同样本示例中可以监控海量的服务器，例如，1000台、10000台等。
步骤402：对日志数据进行预处理，获得待分析内核日志，预处理包括：删除无效内核日志的操作和/或删除重复内核日志的操作。
具体地，日志数据中包含信息多且杂，需要对日志数据进行预处理，压缩日志数据的内容，同时尽可能保留更多的有效信息。预处理的方式有多种，如，删除无效内核日志的操作和/或删除重复内核日志的操作。下面将详细介绍删除无效内核日志的操作和删除重复内核日志的操作。
删除无效内核日志的操作：可以预先设置属于无效日志的种类，查找日志数据中的属于无效的内核日志，并删除查找到的内核日志。无效内核日志的种类可以是用于汇报机器启动的信息、模块清单，或用于表征报告的上下文的信息。可以通过关键词进行匹配的方式识别属于无效的原始内核日志。
在另一个例子中，删除无效内核日志的操作还可以包括：预先设置次级删除列表，该次级删除列表用于存储每个待删除告警信息的出现的次数的阈值；若告警内容出现的次数超过该阈值，则删除所有具有该告警内容的原始日志。
在一个例子中，删除重复内核日志的操作包括：将每条内核日志中的日志时间转化为具有相同格式的时间戳；按照时间戳指示的从早至晚的顺序，依次对每条内核日志进行如下处理：将内核日志与其他内核日志进行模糊匹配，获取相似度超过预设阈值的内核日志作为相似内核日志；从内核日志以及相似内核日志中获取时间戳指示最早的内核日志作为待分析内核日志。
具体地，模糊匹配可以采用单词粒度进行，下面具体介绍模糊匹配的过程：
步骤S1：选取待比较的两个字符串，分别记为A和B。
分别以空格分隔字符并进行去重，形成两个单词集合，记为set(A)和set(B)。
步骤S2：获取两个集合的交集C、A对B的补集，记为A.diff(B)以及获取B对A的补集，记为B.diff(A)，按照字母顺序排序后用空格连接为新的字符串，具体操作如下：
sortedC＝“.join(C.sorted())；
sortedAtoB＝“.join(A.diff(B))；
sortedBtoA＝“.join(B.diff(A))；
combineAtoB＝sortedC+sortedAtoB；
combineBtoA＝sortedC+sortedBtoA；
其中，sortedC为对交集C按照字母顺序排序后用空格连接，形成为新的字符串，同理，sortedAtoB表示将A对B的补集按照字母顺序排序后用空格连接，形成新的字符串；sortedBtoA表示将B对A的补集按照字母顺序排序后用空格连接，形成新的字符串。combineAtoB表示将sortedC sortedAtoB进行合并，生成新的字符串；combineBtoA表示将sortedC和sortedBtoA进行合并，生成新的字符串。
经过上述处理，得到多个新的字符串，
步骤S3：分别计算sortedC与combineAtoB、combineAtoB与combineBtoA以及sortedC与combineBtoA中最长连续子序列，并取三者的最大值，记为两个序列A和B的相似度。
若相似度超过相似度阈值，则可以将字符串B对应的日志作为相似日志；若字符串A对应的日志的日期早于该字符串B对应的日志的日期，那么删除字符串B对应的日志。
值得一提的是，通过模糊匹配的方式可以去除重复的日志，进而减少数据量。
在另一个例子中，预处理还包括：针对每条内核日志进行如下处理：判断内核日志中的告警内容是否与预设的白名单中的告警内容匹配，若匹配，则根据匹配的告警内容生成待分析告的告警项；若匹配失败，则执行删除重复内核日志的操作。
具体地，还设置白名单，白名单用于存储会导致硬件故障的告警内容的关键信息，如关键词；可以针对每条内核日志进行处理，判断该告警内容与白名单中的告警内容是否匹配，若匹配，将该内核日志作为待分析内核日志；若不匹配，则继续执行删除重复内核日志的操作。
值得一提的是，经过白名单的匹配操作，可以快速确定待分析内核日志，减少后续删除重复内核日志的操作的数据量。
需要说明的是，预处理中包括多个操作，本示例中，可以先执行删除无效内核日志的操作；其次，进行白名单的匹配处理，最后执行删除重复内核日志的操作。
步骤403：根据待分析内核日志中的告警内容以及预设的与告警内容匹配的标识信息，生成至少两条待分析的告警项。
为了减少待分析的数据量，可以预设告警内容与匹配的标识信息之间的对应关系；根据该预设的对应关系，即可生成告警项，其中，标识信息可以是简短的字符，例如，标识信息为“cpu-machine-check-exception”。若告警内容没有对应的告警项，则将该告警内容作为告警项的标识信息。
可以理解的是，为了便于获知告警项相关的信息，还可以获取该告警项的IP地址、时间、数据来源等信息。
本发明第五实施方式涉及一种电子设备，其结构框图如图7所示，包括：至少一个处理器501；以及，与所述至少一个处理器501通信连接的存储器502；其中，存储器502存储有可被至少一个处理器501执行的指令，指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的服务器硬件故障监控的方法。
其中，存储器和处理器采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器和存储器的各种电路链接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器。
处理器负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器可以被用于存储处理器在执行操作时所使用的数据。
本发明第六实施方式涉及一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时实现上述的服务器硬件故障监控的方法。
本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
Claims (11)
1.一种服务器硬件故障监控的方法，其特征在于，包括：
获取至少两条待分析的告警项，所述告警项包括用于表征待分析内核日志中告警内容的标识信息；
针对每个所述告警项进行如下处理：根据所述标识信息关联所述告警项与其他告警项，将满足预设关联规则的所述告警项及关联的其他告警项作为相关项对，其中，所述预设关联规则包括：所述告警项与关联的其他告警项之间的支持度、置信度以及提升度均超过各自对应的阈值；
获取所述相关项对中所述告警项之间的因果关系；
根据所述因果关系对所述相关项对中的所述告警项进行分类，获得分类结果；
根据所述分类结果，获取服务器硬件故障的故障原因。
2.根据权利要求1所述的服务器硬件故障监控的方法，其特征在于，在所述获取所述相关项对中所述告警项之间的因果关系之前，所述方法还包括：
针对每个所述相关项对进行如下处理：检测是否存在与所述相关项对的因果关系相反的相关项对，若是存在，则判断所述相关项对的置信度是否大于所述相反的相关项对的置信度，若是，则保留所述相关项对，否则，删除所述相关项对，保留所述相反的相关项对。
3.根据权利要求1或2所述的服务器硬件故障监控的方法，其特征在于，所述相关项对包括：被标记为先导项的告警项以及被标记为后继项的告警项，所述先导项用于表征故障因素，所述后继项用于表征与所述故障因素对应的故障结果；
所述根据所述因果关系对所述相关项对中的所述告警项进行分类，获得分类结果，包括：
查询具有相同后继项的所述相关项对；
根据相关项对中所述先导项与所述后继项之间的因果关系，将查询到的所述相关项对中对应同一个后继项的所述先导项划分为同一类别，将其他所述相关项对中的先导项各自作为一个类别。
4.根据权利要求3所述的服务器硬件故障监控的方法，其特征在于，所述根据所述分类结果，确定服务器硬件故障的故障原因，包括：
获取每个所述类别对应的后继项；
根据所述后继项以及预设的后继项与故障原因的对应关系，确定每个所述类别的故障原因；
输出每个类别以及对应的所述故障原因。
5.根据权利要求2所述的服务器硬件故障监控的方法，其特征在于，所述获取至少两条待分析的告警项之后，所述方法还包括：
获取每个所述告警项对应的宕机率，所述宕机率用于表征所述告警项出现的情况下同时服务器发生宕机的概率；
查询小于预设的宕机率阈值的所述宕机率；
删除查询到的所述宕机率对应的告警项。
6.根据权利要求5所述的服务器硬件故障监控的方法，其特征在于，所述获取每个所述告警项对应的宕机率，包括：
获取用于表征所述告警项出现次数的第一数据以及获取用于表征所述告警项对应出现宕机次数的第二数据；
将所述第二数据与所述第一数据的比值作为所述告警项对应的宕机率。
7.根据权利要求1所述的服务器硬件故障监控的方法，其特征在于，所述获取至少两条待分析的告警项，包括：
获取监控范围内服务器的日志数据，所述日志数据包括至少两条所述内核日志；
对所述日志数据进行预处理，获得待分析内核日志，所述预处理包括：删除无效内核日志的操作和/或删除重复内核日志的操作；
根据所述待分析内核日志中的告警内容以及预设的与所述告警内容匹配的所述标识信息，生成至少两条待分析的告警项。
8.根据权利要求7所述的服务器硬件故障监控的方法，其特征在于，所述删除重复内核日志的操作包括：
将每条所述内核日志中的日志时间转化为具有相同格式的时间戳；
按照所述时间戳指示的从早至晚的顺序，依次对每条所述内核日志进行如下处理：
将所述内核日志与其他内核日志进行模糊匹配，获取相似度超过预设阈值的内核日志作为相似内核日志；
从所述内核日志以及所述相似内核日志中获取时间戳指示最早的内核日志作为待分析内核日志。
9.根据权利要求7所述的服务器硬件故障监控的方法，其特征在于，所述预处理还包括：
针对每条所述内核日志进行如下处理：判断所述内核日志中的告警内容是否与预设的白名单中的告警内容匹配，若匹配，则根据所述匹配的告警内容生成所述待分析告的告警项；若匹配失败，则执行所述删除重复内核日志的操作。
10.一种电子设备，其特征在于，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-9任一所述的服务器硬件故障监控的方法。
11.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至9中任一项所述的服务器硬件故障监控的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011613848.3A CN112699005A (zh) | 2020-12-30 | 2020-12-30 | 服务器硬件故障监控的方法、电子设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011613848.3A CN112699005A (zh) | 2020-12-30 | 2020-12-30 | 服务器硬件故障监控的方法、电子设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112699005A true CN112699005A (zh) | 2021-04-23 |
Family
ID=75512724
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011613848.3A Pending CN112699005A (zh) | 2020-12-30 | 2020-12-30 | 服务器硬件故障监控的方法、电子设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112699005A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113886125A (zh) * | 2021-09-30 | 2022-01-04 | 苏州浪潮智能科技有限公司 | 系统异常启动修复方法、装置、服务器及存储介质 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140129536A1 (en) * | 2012-11-08 | 2014-05-08 | International Business Machines Corporation | Diagnosing incidents for information technology service management |
| CN104239437A (zh) * | 2014-08-28 | 2014-12-24 | 国家电网公司 | 一种面向电网调度的智能告警分析方法 |
| WO2015051638A1 (zh) * | 2013-10-08 | 2015-04-16 | 华为技术有限公司 | 一种故障定位方法及装置 |
| CN109358602A (zh) * | 2018-10-23 | 2019-02-19 | 山东中创软件商用中间件股份有限公司 | 一种故障分析方法、装置及相关设备 |
| CN109412867A (zh) * | 2018-12-06 | 2019-03-01 | 国家电网有限公司信息通信分公司 | 一种告警关联合并方法、装置、系统、设备和存储介质 |
| CN111726248A (zh) * | 2020-05-29 | 2020-09-29 | 北京宝兰德软件股份有限公司 | 一种告警根因定位方法及装置 |
| CN112052151A (zh) * | 2020-10-09 | 2020-12-08 | 腾讯科技（深圳）有限公司 | 故障根因分析方法、装置、设备及存储介质 |
-
2020
- 2020-12-30 CN CN202011613848.3A patent/CN112699005A/zh active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140129536A1 (en) * | 2012-11-08 | 2014-05-08 | International Business Machines Corporation | Diagnosing incidents for information technology service management |
| WO2015051638A1 (zh) * | 2013-10-08 | 2015-04-16 | 华为技术有限公司 | 一种故障定位方法及装置 |
| CN104239437A (zh) * | 2014-08-28 | 2014-12-24 | 国家电网公司 | 一种面向电网调度的智能告警分析方法 |
| CN109358602A (zh) * | 2018-10-23 | 2019-02-19 | 山东中创软件商用中间件股份有限公司 | 一种故障分析方法、装置及相关设备 |
| CN109412867A (zh) * | 2018-12-06 | 2019-03-01 | 国家电网有限公司信息通信分公司 | 一种告警关联合并方法、装置、系统、设备和存储介质 |
| CN111726248A (zh) * | 2020-05-29 | 2020-09-29 | 北京宝兰德软件股份有限公司 | 一种告警根因定位方法及装置 |
| CN112052151A (zh) * | 2020-10-09 | 2020-12-08 | 腾讯科技（深圳）有限公司 | 故障根因分析方法、装置、设备及存储介质 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113886125A (zh) * | 2021-09-30 | 2022-01-04 | 苏州浪潮智能科技有限公司 | 系统异常启动修复方法、装置、服务器及存储介质 |
| CN113886125B (zh) * | 2021-09-30 | 2023-07-14 | 苏州浪潮智能科技有限公司 | 系统异常启动修复方法、装置、服务器及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113282461B (zh) | 传输网的告警识别方法和装置 | |
| US10248517B2 (en) | Computer-implemented method, information processing device, and recording medium | |
| CN103761173A (zh) | 一种基于日志的计算机系统故障诊断方法及装置 | |
| US20040103121A1 (en) | Method, system and computer product for integrating case based reasoning data and failure modes, effects and corrective action data | |
| US20110035094A1 (en) | System and method for automatic fault detection of a machine | |
| CN106844139A (zh) | 一种日志文件分析方法及装置 | |
| US20190171644A1 (en) | Efficient event searching | |
| AU2019275633B2 (en) | System and method of automated fault correction in a network environment | |
| US20240264890A1 (en) | Method and system for analyzing cloud platform logs, device and medium | |
| CN113553210A (zh) | 告警数据的处理方法、装置、设备及存储介质 | |
| US20240272975A1 (en) | Method and system for upgrading cpe firmware | |
| US11025478B2 (en) | Method and apparatus for analysing performance of a network by managing network data relating to operation of the network | |
| US11822578B2 (en) | Matching machine generated data entries to pattern clusters | |
| CN112699005A (zh) | 服务器硬件故障监控的方法、电子设备及存储介质 | |
| CN111400435B (zh) | 邮件告警收敛方法、装置、计算机设备及存储介质 | |
| CN111460268B (zh) | 数据库查询请求的确定方法、装置和计算机设备 | |
| CN111475643A (zh) | 数据中心交换机异常日志的处理方法、装置及存储介质 | |
| CN113535458B (zh) | 异常误报的处理方法及装置、存储介质、终端 | |
| CN115186001A (zh) | 一种补丁处理方法和装置 | |
| CN113343051B (zh) | 一种异常sql检测模型构建方法及检测方法 | |
| JP5623950B2 (ja) | Ｉｔ障害予兆検知装置及びプログラム | |
| CN114936139A (zh) | 数据中心网络内的日志处理方法、装置、设备及存储介质 | |
| CN115310011A (zh) | 页面展示方法、系统以及可读存储介质 | |
| CN113781068A (zh) | 线上问题解决方法、装置、电子设备和存储介质 | |
| CN115408244A (zh) | 网页性能测试方法、装置、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |