一种基于日志的故障根因分析方法、设备及存储介质与流程

1.本技术涉及云计算技术领域，尤其涉及一种基于日志的故障根因分析方法、设备及存储介质。


背景技术：

2.边缘一体机是边缘计算常见的硬件形态之一，其通常部署在边缘环境中。
3.为了满足云边协同的需求，导致边缘一体机中存在大量复杂的长链路计算，涉及到硬件、网络、系统、应用等多个层面和多个工作团队，因此，边缘一体机的运维复杂度很高。目前，边缘一体机的运维工作依然需依赖开发人员来进行人工运维，运维效率不足。


技术实现要素：

4.本技术的多个方面提供一种基于日志的故障根因分析方法、设备及存储介质，用以提高故障根因分析的效率。
5.本技术实施例提供一种基于日志的故障根因分析方法，包括：
6.接收根因分析请求，所述根因分析请求中包含运维对象对应的日志数据以及为所述运维对象所指定的目标问题类型；
7.在所述目标问题类型下预先打标出的日志事件中，查找与所述日志数据匹配的目标日志事件；
8.按照所述目标问题类型下预置的根因定位逻辑，定位所述目标日志事件在所述根因定位逻辑中触发的约束条件所关联的故障根因；其中，所述根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序。
9.本技术实施例还提供一种计算设备，包括存储器、处理器和通信组件；
10.所述存储器用于存储一条或多条计算机指令；
11.所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：
12.通过所述通信组件接收根因分析请求，所述根因分析请求中包含运维对象对应的日志数据以及为所述运维对象所指定的目标问题类型；
13.在所述目标问题类型下预先打标出的日志事件中，查找与所述日志数据匹配的目标日志事件；
14.按照所述目标问题类型下预置的根因定位逻辑，定位所述目标日志事件在所述根因定位逻辑中触发的约束条件所关联的故障根因；其中，所述根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序。
15.本技术实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的基于日志的故障根因分析方法。
16.在本技术实施例中，在运维过程中可能遇到的各类问题下预先打标出日志事件并
预置基于日志事件的根因定位逻辑，这样，可在各类问题下持续沉淀专家经验；在此基础上，在日常运维过程中，仅需提供运维对象对应的日志数据并为运维对象指定目标问题类型，即可自动化地识别运维对象所匹配的目标日志事件，并可将识别出的目标日志事件带入运维对象所适用的根因定位逻辑中，即可按照根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序，定位出目标日志事件所触发的约束条件关联的故障根因。这可实现一键自动化根因分析，无需再依赖人工分析，有效提高根因分析效率。
附图说明
17.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
18.图1为本技术一示例性实施例提供的基于日志的故障根因分析方法的流程示意图；
19.图2为本技术一示例性实施例提供的一种基于日志的故障根因分析方案的逻辑示意图；
20.图3为本技术一示例性实施例提供的一种基于日志的故障根因分析方案的可选实现方案的逻辑示意图；
21.图4为本技术另一示例性实施例提供的一种计算设备的结构示意图。
具体实施方式
22.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
23.目前，针对边缘一体机的运维工作依然主要依赖人工完成，效率不佳。为此，本技术的一些实施例中：在运维过程中可能遇到的各类问题下预先打标出日志事件并预置基于日志事件的根因定位逻辑，这样，可在各类问题下持续沉淀专家经验；在此基础上，在日常运维过程中，仅需提供运维对象对应的日志数据并为运维对象指定目标问题类型，即可自动化地识别运维对象所匹配的目标日志事件，并可将识别出的目标日志事件带入运维对象所适用的根因定位逻辑中，即可按照根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序，定位出目标日志事件所触发的约束条件关联的故障根因。在此基础上，可根据定位出的故障根因，输出运维对象的故障根因结论。这可实现一键自动化根因分析，无需再依赖人工分析，有效提高根因分析效率。
24.以下结合附图，详细说明本技术各实施例提供的技术方案。
25.图1为本技术一示例性实施例提供的基于日志的故障根因分析方法的流程示意图。该方法可由故障根因分析装置执行，该故障根因分析装置可实现为软件和/或硬件的结合，该故障根因分析装置可集成在计算设备中。
26.本实施例提供的故障根因分析方案可应用于各种运维场景中，尤其可适用于哪些比较难以远程获取日志、运维经验需要依赖专家、日志量较大、日志内容过多等特点的运维
场景，包括但不限于边缘一体机的运维场景、专有云中的软硬一体设备的运维场景等。针对这些应用场景，本实施例提出了基于日志进行故障根因分析的技术构思。在不同的应用场景中，本实施例所适用的运维对象可以是多样的，本实施例中的运维对象可包括但不限于边缘一体机、专有云中的软硬一体设备等等。
27.图2为本技术一示例性实施例提供的一种基于日志的故障根因分析方案的逻辑示意图。参考图2，本实施例中的根因分析方案可主要包含两大模块：日志事件识别模块和根因定位模块。其中，日志事件识别模块主要用于承担与日志事件相关的处理工作，包括但不限于日志事件打标工作、识别工作等，根因定位模块主要用于承担根因定位相关的处理工作，包括但不限于根因定位逻辑构建工作、故障根因预测工作等。
28.基于此，参考图1，本实施例提供的基于日志的故障根因分析方法，可包括：
29.步骤100、接收根因分析请求，根因分析请求中包含运维对象对应的日志数据以及为运维对象所指定的目标问题类型；
30.步骤101、在目标问题类型下预先打标出的日志事件中，查找与日志数据匹配的目标日志事件；
31.步骤102、按照目标问题类型下预置的根因定位逻辑，定位目标日志事件在根因定位逻辑中触发的约束条件所关联的故障根因；其中，根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序。
32.参考图1和图2，在步骤100中，用户可发起针对运维对象的根因分析请求，并在根因分析请求中携带运维对象对应的日志数据以及为运维对象指定目标问题类型。其中，运维对象对应的日志数据可以是从运维对象中拷贝或提取出的符合目标问题类型要求的指定时段、指定类型或指定系统层面所发生的日志数据。为此，本实施例中，可预先为不同类型的问题指定日志数据的采集范围，现场运维人员只需要按照运维对象对应的目标问题类型的要求采集相关日志数据携带在根因分析请求中即可。另外，本实施例中，一种为运维对象指定目标问题类型的方式可以是：确定运维对象上所发生的故障现象，根据各类问题所能覆盖到的故障现象来寻找可适用于运维对象上故障现象的问题类型作为目标问题类型。其中，单种类型的问题可覆盖多种故障现象。示例性的，本实施例中的问题类型可包括但不限于离线类问题、视频推流失败类问题、丢包类问题等等，本实施例对此不做限定，可根据应用场景的实际需求来定义问题类型。为运维对象指定目标问题类型的工作可有人工完成，也可通过在根因分析请求中携带运维对象上发生的故障现象信息的方式而间接地指定出目标问题类型。
33.参考图1和图2，在步骤101中，可在目标问题类型下预先打标出的日志事件中，查找与日志数据匹配的目标日志事件。
34.参考图2，本实施例中，可预先为各类问题打标出日志事件，其中日志事件可以是为一类日志数据总结出的日志模板，日志事件的背后实质是关联到日志数据中的一项或多项日志文件的，我们将这一项或多项日志文件作为同类事件，从日志事件的维度来进行故障根因定位工作，从而在故障根因定位的过程中，无需再分析日志数据中包含的具体内容，不再负累于日志数据中复杂多样的内容理解，这使得故障根因定位环节中的处理逻辑更加的轻量化。在各类问题下的日志事件打标工作是依赖专家经验的，因此，可有效沉淀日志事件识别工作的专家经验。
35.本实施例中，以目标问题类型为例，为目标问题类型打标日志事件的一种示例性方案可以是：在目标问题类型下，收集相关的日志样本；对日志样本进行聚类，以产生多个日志事件，日志事件作为描述聚类组中日志数据的模板；基于专家经验，在聚类出的多个日志事件中选择对目标问题类型下的根因定位结果存在影响的部分日志事件进行打标，以产生在目标问题类型下预先打标出的日志事件。
36.在该示例性方案中，可由专家收集与目标问题类型相关的各种日常错误日志、关键日志或者所有日志作为日志样本。在此基础上，可对日志样本进行聚类，以确定出目标问题类型下存在多少种聚类组，并可在每种日志聚类组提炼出日志模板，作为日志事件，这里的多个日志事件是根据自然聚类而产生的。此后可引入专家经验，由专家从聚类产生的多个日志事件中选择目标问题类型下的根因定位结果存在影响的部分日志事件进行打标。打标信息可包括但不限于事件描述信息、异常等级信息或事件所属的系统层级信息中的一种或多种。另外，还可为每个日志事件分配唯一的标识id，以在根因定位逻辑中指代日志事件。打标信息可更加清楚、全面地描述日志事件，这可为后续构建根因定位逻辑的过程提供更加直接的提示，为专家提供便利。
37.图3为本技术一示例性实施例提供的一种基于日志的故障根因分析方案的可选实现方案的逻辑示意图。参考图3，可选地，在该示例性方案中，可采用drain(a fixed depth tree based online log parsing method，基于固定深度树的在线日志解析)技术来总结日志事件。基于此，在该示例性实施例中，可将日志样本输入目标问题类型专用的训练态drain解析树中，以聚类出多个日志事件。在该示例性方案中，在drain技术的基础上，还加入了本实施例中额外提出的技术逻辑，对现有drain技术进行了改进：增加了上述的日志事件打标功能；并创新性地提出将drain解析树分为训练态和推理态。其中，训练态drain解析树中承载了根据drain技术为目标问题类型的日志样本聚类出的所有日志事件，且专家对部分日志事件打标出的打标信息也承载在训练态drain解析树中。我们可以将训练态drain解析树存储至为目标问题类型准备的事件库中，对目标问题类型的日志事件的经验沉淀工作是长久持续的，在后续的沉淀工作中，可从事件库中加载训练态drain解析树作为基础，而非从0开始重新沉淀，这样，可充分利用起历史沉淀工作成果，提高沉淀效率；而且，久而久之，目标问题类型下的训练态drain解析树中可以包含目标问题类型相关的所有日志事件以及专家对部分日志事件的打标信息。其中，推理态drain解析树将在后文中使用到，在该示例性方案中，可从目标问题类型专用的训练态drain解析树中裁剪出打标出的日志事件所在的解析路径，以构建出目标问题类型专用的推理态drain解析树。可知，推理台drain解析树相较于训练态drain解析树更加轻量。
38.在此基础上，在步骤101中，可通过查找目标问题类型专用的推理态drain解析树来确定与运维对象对应的日志数据匹配的目标日志事件。
39.当然，本实施例中，除drain技术外，还可采用其它方案来为各类问题总结出日志事件，本实施例并不限于此。例如，对日志数据进行向量化，并按照向量距离进行聚类等方式，在此不做详述。
40.参考图3，本实施例中，可支持非结构化/半结构化的日志数据作为故障根因的分析依据，例如，日志数据(对应图中的源数据)可以是oss压缩包或者是运维对象的贝蒂日志文件等，本实施例对日志数据的数据格式不做限定。为此，本实施例中，可为不同类型的问
题预置日志预处理逻辑，参考图2，本实施例中的根因分析方案还可包含第三个模块：日志预处理模块。其中，日志预处理逻辑可包括但不限于扫描路径、日志行扫描顺序、日志过滤条件、是否需要补充/修正时间信息、是否需要增加指定字段或采样频率等。通过日志预处理操作，可支持非结构化/半结构化的日志数据；将日志数据处理成符合drain解析树输入要求的数据格式；可提取出目标问题类型所关注的关键信息；可通过过滤的方式压缩日志数据的量级；还可剔除对日志事件识别的准确性有消极影响的部分信息，以保证日志事件识别的准确性；还可解决应用场景内其它特有问题，在此不再穷举。
41.这样，在步骤101中，可按照目标问题类型下预置的日志预处理逻辑，对日志数据进行预处理，以获得预处理后日志数据；针对预处理后日志数据中包含的每项日志文件，分别在目标问题类型下预先打标出的日志事件中查找是否存在匹配的日志事件；将目标问题类型下预先打标出的日志事件中因预处理后的日志数据而被命中的日志事件，作为目标日志事件。承接上述采用drain技术沉淀日志事件的示例性方案，这里，可将预处理后日志数据中的每项日志文件分别带入目标问题类型专用的推理态drain解析树中，以搜索是否存在匹配的日志事件，从而确定出运维对象在目标问题类型下的目标日志事件。
42.在此基础上，参考图1和图2，在步骤102中，可按照目标问题类型下预置的根因定位逻辑，定位目标日志事件在根因定位逻辑中触发的约束条件所关联的故障根因。
43.本实施例中，可为不同类型的问题分别预置根因定位逻辑。这里创新性地提出基于日志事件来构建根因定位逻辑的构思。也即是，在故障根因定位的过程中，可专注于日志事件层面的分析工作，而无需再分析日志数据中包含的具体内容，不再负累于日志数据中复杂多样的内容理解，这使得故障根因定位环节中的处理逻辑更加的轻量化。
44.在根因定位逻辑的构建过程中，引入了专家经验，根据专家经验确定了目标问题类型下所需进行的诊断环节、诊断环节之间的顺序、从前述在目标问题类型下打标出的日志事件中确定每个诊断环节所需关注的日志事件以及对其所关注日志事件的约束条件等，从而构建其目标问题类型下的根因定位逻辑。其中，诊断环节中的约束条件可包括其所关注的日志事件是否出现以及出现的时序等维度的约束。示例性的，约束条件可包括但不限于存在指定日志事件、不存在指定日志事件、存在指定的多个日志事件中的任意一个或多个、同时存在指定的多个日志事件、指定日志事件出现后的指定时间内出现其它指定日志事件、或者指定的多个无序的日志事件均出现且相互间隔指定时间中的一种或多种条件组合。
45.一些示例性的约束条件可定义为：
46.a.定义'&'表示步骤与步骤的连接符，步骤与步骤之间存在时间先后约束
47.b.'《a》'表示检测事件a是否存在,存在为true，不存在为false
48.c.'^《a》'事件a存在为false，不存在为true
49.d.'(《a》|《b》)'表示事件a或b存在则为true,无时间先后顺序约束
50.e.'(《a》-《b》)'表示事件a和b都存在则为true，且事件a与b没有时间先后约束
51.f.'(《a》&《b》)_5m'表示事件a出现后，5分钟时间内出现了b事件，时间维度可以有天(d),小时(h)，秒(s),
52.g.'(《a》-《b》)_^5m'表示无序事件中，a和b均出现，但必须间隔5分钟以上。
53.基于此，在步骤102中，可按照根因定位逻辑中诊断环节之间的顺序，依次在各诊
断环节下判断目标日志事件是否满足相应的约束条件；在约束条件已被目标日志事件所触发了的诊断环节下，分别输入各自关联的故障根因。
54.其中，诊断环节之间的顺序可采用在根因定位逻辑对应的逻辑表达式中的出现顺序，当然，也可为各个诊断环节分配优先级，这样，诊断环节之间的顺序可采用优先级顺序。另外，通常情况下，可在根据定位逻辑中包含的各个诊断环节下分别判断其约束条件是否被目标日志事件所触发，而在一些特殊情况下，可指定部分特定诊断环节，当特定诊断环节下的约束条件被触发后，可不再执行后续的其它诊断环节，而直接将被触发的特定诊断环节关联的故障根因作为定位结果。
55.另外，在一些故障根因分析工作比较简单的场景中，我们可以为根因定位逻辑中的各个约束条件直接关联故障根因，但是对于故障根因分析工作比较复杂的场景来说，可能无法满足这类场景中的分析精度要求，为此，本实施例中，还可在根因定位逻辑的基础上，进一步提供基于机器学习技术的根因定位提升功能。
56.基于此，在本技术实施例中，若根因定位逻辑中的约束条件并未关联故障根因而是关联隐藏事件，则获取目标日志事件在根因定位逻辑中触发的约束条件所关联的隐藏事件，其中，隐藏事件是基于对应的约束条件中指定的日志事件所预测出的；将目标日志事件和隐藏事件作为根因分析模型的输入；在根因分析模型中提取目标日志事件和隐藏事件对应的事件特征，并基于事件特征与故障根因之间的映射关系，预测出故障根因。其中，根因分析模型可采用xgboost、decision tree或随机森林的机器学习模型。另外，本实施例中可采用有监督的训练方式来对根因分析模型进行训练，在训练过程中可进一步引入专家经验，对事件特征对应的故障根因进行打标，从而产生根因分析模型的训练样本，将训练样本提供给根因分析模型后，可促使根因分析模型学习到事件特征与故障根因之间的映射关系。
57.另外，本实施例中，在根因定位的依据除了可以是上述的日志事件外，还可从除日志外的其它途径获取与运维对象相关的参考事件，参考事件可包括但不限于sls(log service，日志服务)事件、ots(object transaction service，对象事务服务)事件等，当然，这些仅是示例性的，本实施例中还可引入其它对根因定位有参考意义的参考对象。同样，本实施例中可对这些参考对象分配唯一的标识id，以指代参考事件。在此基础上，上述的根因定位逻辑中的诊断环节还可关注参考事件，并将参考事件和日志事件作为平等的事件来配置约束条件，也即是，单个诊断环节中可将参考事件和日志事件进行混合，并定义约束条件。对于根因分析模型，则可将参考事件也作为根因分析模型的输入并参与根据分析模型中的根因预测过程。
58.这样，通过引入参考事件，可更加全面、更加准确地定位出运维对象对应的故障根因。
59.在此基础上，可根据定位出的故障根因，输出运维对象的故障根因结论。这里，可根据定位出的故障根因所出自的诊断环节对应的优先级、所相关的日志事件所属的系统层级等来对故障根因进行排序、筛选等处理，以确定出最终的故障根因并输出，作为运维对象的故障根因结论。
60.正如前文提及的，本实施例中在目标问题类型下预先打标出了日志事件。基于此，本实施例中，还可接收针对运维对象的日志事件识别请求；输出目标日志事件对应的打标
信息，以响应日志事件识别请求。也即是，在某些情况下，可基于在各类问题下预先打标出的日志事件来支持对运维对象的日志事件识别请求，输出运维对象所命中的的日志事件。而由于，日志事件的打标信息可包括但不限于事件描述信息、异常等级信息或事件所属的系统层级信息中的一种或多种。因此，通过日志事件识别请求，可向用户提供运维对象所命中的日志事件对应的打标信息，为用户提供运维参考。
61.综上，本实施例中，可在运维过程中可能遇到的各类问题下预先打标出日志事件并预置基于日志事件的根因定位逻辑，这样，可在各类问题下持续沉淀专家经验；在此基础上，在日常运维过程中，仅需提供运维对象对应的日志数据并为运维对象指定目标问题类型，即可自动化地识别运维对象所匹配的目标日志事件，并可将识别出的目标日志事件带入运维对象所适用的根因定位逻辑中，即可按照根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序，定位出目标日志事件所触发的约束条件关联的故障根因。这可实现一键自动化根因分析，无需再依赖人工分析，有效提高根因分析效率。
62.以下将提供一种实际的应用场景，以更加清楚地说明本实施例提供的基于日志的故障根因分析方案。
63.在该应用场景中，本实施例提供的故障根因分析方案的运行环境可采用python3.8，外部依赖k8s、minio或oss存储、ots存储等云原生加持，因此，本实施例提供的故障根因分析方案可完全运行在云端。但是，应当理解的是，这些仅是示例性的，本实施例提供的故障根因分析方案并不强依赖于任何一种云产品，其可适配应用场景所使用的任意类型的云产品而搭建运行环境。
64.本实施例中，可为不同类型的问题分别定义问题单，问题单用于定义针对指定类型的问题所需采用的解决方案。问题单中可用于承载本实施例中的日志预处理逻辑和根因定位逻辑。这样，可将为各类问题预置的日志预处理逻辑和根因定位逻辑承载在各自的问题单中。我们对问题单的定义语言不做限定。示例性地，问题单可采用yaml语言来进行编写。一种yaml语言编写的示例性的问题单可以是：
[0065][0066][0067]
可采用dsl(领域专用语言)来编排上述问题单中diagnosis_flow字段中的根因定位逻辑。一种示例性的根因定位逻辑可以编排为：
[0068]
'《a》&(《b》&(《c》|《d》))_5m&(《e》-《f》)'
[0069]
相应的诊断过程为：第一个诊断环节中判断是否出现了a事件；第二个诊断环节中判断a事件之后，是否出现b事件，且b事件出现的五分钟内，出现了c或d事件；第三个诊断环节中判断第二诊断环节中结束后是否出现了e和f事件。其中，a、b、c、d、e、f分别为日志事件的标识id。
[0070]
在此基础上，当运维对象的故障现象适用于上述问题单时，工作人员可按照问题
单中指定的path，筛选出问题单中指定所需的日志数据，并存储在问题单中指定的路径位置上即可。之后，可按照问题单中的日志预处理逻辑对日志数据进行预处理，并将预处理后日志数据输入到为该问题单预先构建的推理态drain解析树中，以查找与运维对象匹配的目标日志事件。
[0071]
将查找到的目标日志事件带入上述的根因定位逻辑中，判断各个诊断环节中的约束条件是否被触发，并提取被触发的诊断环节关联的故障根因。还可对提取出的故障根因进行排序、筛选等处理，以输出运维对象对应的根因分析结论。另外，还可按照时间区间、所属系统层面、异常等级等维度对根因分析结论中的故障根因进行分类、统计等，形成所需的根因分析报告。
[0072]
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤100至步骤103的执行主体可以为设备a；又比如，步骤100和102的执行主体可以为设备a，步骤103的执行主体可以为设备b；等等。
[0073]
另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如801、802等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。
[0074]
图4为本技术另一示例性实施例提供的一种计算设备的结构示意图。如图4所示，该计算设备包括：存储器40、处理器41以及通信组件42。
[0075]
处理器41，与存储器40耦合，用于执行存储器40中的计算机程序，以用于：
[0076]
接收根因分析请求，根因分析请求中包含运维对象对应的日志数据以及为运维对象所指定的目标问题类型；
[0077]
在目标问题类型下预先打标出的日志事件中，查找与日志数据匹配的目标日志事件；
[0078]
按照目标问题类型下预置的根因定位逻辑，定位目标日志事件在根因定位逻辑中触发的约束条件所关联的故障根因；其中，根因定位逻辑中包含每个诊断环节中对其所关注日志事件的约束条件以及诊断环节之间的顺序。
[0079]
在一可选实施例中，处理器41在目标问题类型下预先打标出的日志事件中，查找与日志数据匹配的目标日志事件的过程中，可用于：
[0080]
按照目标问题类型下预置的日志预处理逻辑，对日志数据进行预处理，以获得预处理后日志数据；
[0081]
针对预处理后日志数据中包含的每项日志文件，分别在目标问题类型下预先打标出的日志事件中查找是否存在匹配的日志事件；
[0082]
将目标问题类型下预先打标出的日志事件中因预处理后的日志数据而被命中的日志事件，作为目标日志事件。
[0083]
在一可选实施例中，目标问题类型下预先打标出的日志事件承载于目标问题类型专用的推理态drain解析树中，处理器41在针对预处理后日志数据中包含的每项日志文件，分别在目标问题类型下预先打标出的日志事件中查找是否存在匹配的日志事件的过程中，可用于：
[0084]
将预处理后日志数据中的每项日志文件分别带入目标问题类型专用的推理态drain解析树中，以搜索是否存在匹配的日志事件。
[0085]
在一可选实施例中，日志预处理逻辑包括扫描路径、日志行扫描顺序、日志过滤条件、是否需要补充/修正时间信息、是否需要增加指定字段或采样频率中的一种或多种。
[0086]
在一可选实施例中，处理器41还可用于：
[0087]
在目标问题类型下，收集相关的日志样本；
[0088]
对日志样本进行聚类，以产生多个日志事件，日志事件作为描述聚类组中日志数据的模板；
[0089]
基于专家经验，在聚类出的多个日志事件中选择对目标问题类型下的根因定位结果存在影响的部分日志事件进行打标，以产生在目标问题类型下预先打标出的日志事件。
[0090]
在一可选实施例中，处理器41在对日志样本进行聚类，以产生多个日志事件的过程中，可用于：
[0091]
将日志样本输入目标问题类型专用的训练态drain解析树中，以产生多个日志事件，其中，打标出的日志事件也承载在训练态drain解析树中；
[0092]
处理器41还可用于：
[0093]
从目标问题类型专用的训练态drain解析树中裁剪出打标出的日志事件所在的解析路径，以构建出目标问题类型专用的推理态drain解析树，在响应根因分析请求的过程中使用推理态drain解析树查找与输入的日志数据匹配的日志事件。
[0094]
在一可选实施例中，处理器41在按照目标问题类型下预置的根因定位逻辑，定位目标日志事件在根因定位逻辑中触发的约束条件所关联的故障根因的过程中，可用于：
[0095]
按照根因定位逻辑中诊断环节之间的顺序，依次在各诊断环节下判断目标日志事件是否满足相应的约束条件；
[0096]
在约束条件已被目标日志事件所触发了的诊断环节下，分别输入各自关联的故障根因。
[0097]
在一可选实施例中，约束条件包括：存在指定日志事件、不存在指定日志事件、存在指定的多个日志事件中的任意一个或多个、同时存在指定的多个日志事件、指定日志事件出现后的指定时间内出现其它指定日志事件、或者指定的多个无序的日志事件均出现且相互间隔指定时间中的一种或多种条件组合。
[0098]
在一可选实施例中，处理器41还可用于：
[0099]
若根因定位逻辑中的约束条件并未关联故障根因而是关联隐藏事件，则获取目标日志事件在根因定位逻辑中触发的约束条件所关联的隐藏事件，其中，隐藏事件是基于对应的约束条件中指定的日志事件所预测出的；
[0100]
将目标日志事件和隐藏事件作为根因分析模型的输入；
[0101]
在根因分析模型中提取目标日志事件和隐藏事件对应的事件特征，并基于事件特征与故障根因之间的映射关系，预测出故障根因。
[0102]
在一可选实施例中，处理器41还可用于：
[0103]
从除日志外的其它途径获取与运维对象相关的参考事件；
[0104]
将参考事件也作为根因分析模型的输入并参与根据分析模型中的根因预测过程。
[0105]
在一可选实施例中，处理器41还可用于：
[0106]
接收针对运维对象的日志事件识别请求；
[0107]
输出目标日志事件对应的打标信息，以响应日志事件识别请求；
[0108]
其中，打标信息包括事件描述信息、异常等级信息或事件所属的系统层级信息中的一种或多种。
[0109]
在一可选实施例中，运维对象包括边缘一体机或专有云中的软硬一体设备。
[0110]
进一步，如图4所示，该计算设备还包括：电源组件43等其它组件。图4中仅示意性给出部分组件，并不意味着计算设备只包括图4所示组件。
[0111]
值得说明的是，上述关于计算设备各实施例中的技术细节，可参考前述的方法实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本技术保护范围的损失。
[0112]
相应地，本技术实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由计算设备执行的各步骤。
[0113]
上述图4中的存储器，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
[0114]
上述图4中的通信组件，被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如wifi，2g、3g、4g/lte、5g等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
[0115]
上述图4中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
[0116]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0117]
本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0118]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特
定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0119]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0120]
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
[0121]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0122]
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0123]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0124]
以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。