一种构建物联网工作流的交错日志分析方法

本发明属于计算机领域，特别涉及一种构建物联网工作流的交错日志分析方法。

背景技术：

目前，智能物联网系统架构变得越来越复杂，包括成千设备组件，并同时为多个用户提供服务。对于管理员来说，从日志中获取系统运行信息、了解系统运行状态是进行系统维护的重要途径。然而随着物联网系统规模和复杂性的增加，一天产生的日志数量已经达到tb级，手动处理这些日志将变得不可能。从系统日志中挖掘的工作流模型可以用于系统维护，帮助管理员了解系统运行状况并监视系统正确运行。然而，由于系统文件和规范的不完善，通常情况下无法获得系统完整的工作流。另外，由于物联网系统运行机制多变的特点，因此很难去建立一个有效、完整而自适应的工作流模型。

目前的系统都会将系统运行时的信息写入日志中，日志可以帮助管理人员了解系统运行状态、分析系统故障原因。下面的示例展示了一个典型的原始日志条目，包括时间戳、级别和原始日志内容。

2020-02-1020：38：31，5186infodfs.datanode$dataxceiver：receivingblockblk_-6853481264720481267src：/10.210.11.53：48251dest：/10.210.11.53：50754

原始日志内容可以通过日志解析成日志模板和参数，对于本示例而言，模板为“receivingblock*src：*dest：*”，参数用“*”进行标识。由于模板可以代表系统运行时的特定状态，所以被用来做工作流模型中的点。连接工作流模型中点的边表示状态转移，如图1中的工作流模型示例。

系统的并发和异步特点导致了日志交错现象，简单来说系统日志文件中日志序列杂乱无序。日志交错现象会带来上下文丢失和噪音的问题，这使得区分属于不同任务的日志很困难。但是原则上，要构建一个正确的工作流模型，需要先将隶属于不同任务的日志分离开来，然后进一步提取程序执行路径形成工作流模型。我们以图1为例，来说明分离交错日志并建立对应的工作流模型的困难。此处有两个日志序列，执行路径相互交错，即1→3→5→8→9→11和2→4→6→7→10→12。现有的一些方法假定每个日志条目都有唯一标识其所属执行的标识符。另外一些方法假定即使系统日志没有唯一标识，也可以通过日志中的信息协作识别这些日志。但是一些系统，例如openstack，它有超过三分之一的日志没有任何标识。因此，不能依赖这些信息去分离日志并建立工作流模型。对于这些系统，通过日志中的标识信息来区分隶属于不同任务的日志是无效的。

另外，系统的可变性和多态性带来了模型老化的问题，所以随着系统的运行离线建立的工作流模型会很快丧失效果。模型老化通常是不可逆的，热更新(应用重启)对其恢复或缓解的影响很小。因此，由于模型老化问题，如果不随时间进行调整更新，离线建立的静态工作流模型将会丧失效力。重构工作流模型会消耗很多资源，实时进行重构不是一个有效的解决方案。所以如何对离线建立的工作流模型进行在线更新也是一个亟待解决的问题。

技术实现要素：

本发明针对现有技术中存在的技术问题，提供一种构建物联网工作流的交错日志分析方法，在交错日志中构建工作流模型时避免了日志中标识信息的使用，具有广泛的适用性，同时解决了由日志交错带来的上下文丢失和噪声问题。另外，通过微迭代更新算法更新模型解决了模型老化的问题。

本发明采用的技术方案是：一种构建物联网工作流的交错日志分析方法，包括以下步骤：

步骤1：日志文件中，在每个日志条目后设置长度为n的窗口，窗口覆盖日志条目后方相邻的n个后继日志条目；窗口的n值人为确定；

步骤2：计算在前日志条目与其后窗口中的每个后继日志条目之间的依赖值；

步骤3：设定过滤阈值，若联合依赖值大于过滤阈值，则对应后继日志条目为在前日志条目的真实后继条目。其余为噪音后继条目。

作为优选，依赖值为后继日志条目在同一在前日志条目的所有窗口中的出现概率。

作为优选，为了应对前日志条目具有多个真实后继条目的情况，采用权重贪心算法对噪声进行过滤，具体为：步骤3中，按照后继日志条目的依赖值的数值由大到小排列，不断计算前m个依赖值之和，直至依赖值之和大于过滤阈值，则对应的后继日志条目全部为在前日志条目的真实后继条目；其中，m为自然数，其数值从1开始，每次递增1。其余日志条目均为噪音后继条目，对应的依赖值置零。m的数值从1开始，可以涵盖一个和多个真实后继条目的情况。

作为优选，在前日志条目及其后继日志条目构成日志条目依赖对；在前日志条目与其真实后继条目之间存在依赖关系；在前日志条目与其噪音后继条目之间不存在依赖关系。

作为优选，噪声日志条目对应依赖值的设定值为零，真实后继日志条目对应依赖值保持原值。

作为优选，微迭代调整：从日志文件中持续获取长度为l的日志文件片段，若实时的日志文件片段中存在日志条目依赖对，则依赖值增加μ，不存在则依赖值减小μ，

若依赖值超过上限值，则日志条目依赖对增加依赖关系，若依赖值低于下限值，日志条目依赖对删除依赖关系。

作为优选，重建：根据一段时间的交错日志重新建立一个工作流模型，避免系统运行模式发生大规模变化时的大量微迭代调整。

与现有技术相比，本发明所具有的有益效果是：

1.本发明设计窗口，在交错日志中覆盖日志条目的真正后继，窗口大小可调；使用基于变量窗口的方法进行依赖性计算，对抗上下文丢失问题；避免了日志中标识信息的使用，具有广泛的适用性。

2.本发明设计权重贪心算法过滤噪声，算法可以在窗口的候选对象中选择真正的后继者，然后删除噪声分支。

3.本发明提出一种微迭代调整算法，微调依赖值，进而更改依赖关系，以适应系统变化。该算法不仅可以产生实时的工作流模型，而且可以避免多次重新构造工作流时的大量资源消耗。

附图说明

图1为openstackvm启动的交错日志序列以及工作流模型；

图2为本发明实施例的流程示意图；

图3为本发明实施例的交错日志中相关的概率密度示意图；

图4为本发明实施例和logsed的precision/recall比较图；

图5为本发明实施例的不同窗口长度和过滤阈值的precision/recall的结果图。

具体实施方式

为使本领域技术人员更好的理解本发明的技术方案，下面结合附图和具体实施例对本发明作详细说明。

本发明的实施例提供了一种构建物联网工作流的交错日志分析方法，如图2所示，其包括以下步骤：

步骤1：日志文件中，在每个日志条目后设置长度为n＝3的窗口，窗口覆盖日志条目后方相邻的3个后继日志条目；

当使用窗口来查找当前模板的真正后继条目时，窗口中的其余条目与该当前模板无关。其余日志条目对在前日志条目而言就是噪声，尽管它们可能是其他的执行路径。

图3展示了交错日志中一个窗口的真实后继条目依赖值和噪声后继条目依赖值的概率密度。

在图3(a)中，随着窗口的增加，真实的依赖值变小，分布变得更加集中。但是在图3(b)中，随着窗口的增加，噪声依赖值变得更大，并且分布变得更加分散。因此，窗口设置越大，真正的后继发现能力的提升就越大，但是引入的噪声也会更多。适当的窗口长度可以确保后继发现能力，并尽可能减少引入的噪声。最佳窗口长度的计算是一个np难题，因此需要设置一个较优的窗口长度。在实际应用中，较优窗口长度设置可以从执行次数开始，直到最短任务的长度。

步骤2：计算在前日志条目与其后窗口中的每个后继日志条目之间的依赖值；

依赖关系值用于衡量日志模板之间的联系。如图2的依赖计算部分所示，首先需要计算计数向量(c_v)，其值是日志序列中当前模板之后的窗口内的模板出现计数。此处，我们介绍t2的c_v计算。如果检查t2的下3个条目，则可以得到一个出现次数字典{t0：1，t3：4，t4：1，t5：3，t6：2，t8：1}，自然地根据模板的下标转换为c_v。直观地讲，t3是t2的后继产品，因为t3在t2的c_v中具有最大的计数。但是t5是否也是t2的后继者尚不确定。此外，c_v的值可能会受到参考日志条目出现次数的很大影响。尽管系统日志是交错的，但模板条目的真实邻居将出现在附近。该日志条目的真实后继必将在一段时间后出现，而噪声日志条目将会随机出现。因此，参考模板的真实后继条目在窗口中出现概率会更高，并且该概率可以表示两个模板的依赖性。依赖向量(d_v)可以通过公式1来计算。

d_vi[j]＝c_vi[j]/sum(c_vi)(1)

其中d_vi和c_vi分别表示ti的依赖向量和计数向量。d_vi[j]为tj与ti之间的依赖值。

步骤3：噪声过滤采用权重贪心算法对噪声进行过滤，将多重依赖结合起来以形成一个新特征，共同进行噪声过滤。具体为：按照日志条目的依赖值的数值由大到小排列，不断计算前m个依赖值之和，尝试1联合，2联合，3联合，...m联合，直到联合增强的特征可以满足依赖性要求为止(依赖值之和大于过滤阈值θ)，则对应的日志条目全部为在前日志条目的真实后继条目；其余日志条目均为噪音后继条目，并将依赖值置零。

随着时间的推移，系统机制的状态迁移会产生变化，甚至完全转变为从未出现过的新运行模式。可以通过捕获系统日志中的变化来更新离线建立的工作流程模型，以适应系统机制的变化。工作流更新有两种情况，即实时工作流模型微调和周期性模型重建。工作流微调使用实时日志流来调整离线工作流模型中边的权重，并根据其变化动态添加或删除状态转换边缘。由于系统机制可能会完全转换为新的运行模型，因此还采用了周期性检查和重构来避免大量微调。

离线工作流模型由经过噪声过滤后的d_v构建，d_v中的非零依赖值代表两个模板之前存在转移边。在线微调阶段，微迭代调整算法会不断调整工作流模型中的依赖值(边的权重)。如果依赖性值达到上限或下限，则在线更新方法需要添加或删除转移边。具体步骤为：

在线模型被初始化为静态的离线工作流模型，并同时获得所有依赖值。从日志文件中持续获取长度为l的日志文件片段，若存在日志条目依赖对，则依赖值增加μ，不存在依赖值减小μ，若依赖值超过上限值，则日志条目依赖对增加依赖关系，若依赖值低于下限值，日志条目依赖对删除依赖关系。

微迭代调整算法适用于连续和轻微变化的情况，并且通过周期性检查和重构可以很好地处理系统机制的完全转移。

周期性模型重建：重新设定日志条目依赖对的依赖关系、依赖值和上限值、下限值。通过周期性检查和模型重建，当系统中发生巨大的突变时，可以避免大量的微调迭代。

迭代微调和定期重构的组合可以应用于绝大多数情况。

本实施例使用openstack中的nova计算服务作为交错实验的数据源。交错程度可以通过虚拟机(vm)的并发执行个数来控制。为了了解openstackvm运行周期的真实情况，我们手动检查源代码，并向系统提交单个请求以获得真实工作流。

我们收集了五组实验数据集以评估sysnif(本实施例)的工作流构建性能。这些实验测试了影响准确性和效率结果的潜在因素：任务同时执行数量。并发运行的任务越多，日志的交错复杂度就越高。并发任务数设置为2到6。每个任务代表一个可以自动执行虚拟机管理的执行。虚拟机周期从实例启动开始，到实例停止结束，我们实验中的每个任务依次执行20个周期。

在这一部分中，我们选择基于聚类logsed(t.jia，l.yang，p.chen，y.li，f.meng，andj.xu，“logsed：anomalydiagnosisthroughminingtime-weightedcontrolf1owgraphinlogs，”in2017ieee10thinternationalconferenceoncloudcomputing(cloud).ieee，2017，pp.447-455.)作为基准，比较指标为标准的precision/recall。precision是挖掘到的工作流模型中的边是真实的比例，recall是真实工作流模型中的边有多少比例被挖掘到了。

precision和recall比较实验结果如图4所示。logsed的precision很高，但是随着并发次数的增加，recall不能令人满意。openstackvm生命周期模型中的分支将导致依赖关系分散，logsed过滤掉一些真正的依赖关系(如噪声)。sysnif采用权重贪心算法过滤噪音来弥补这一不足并具有更好的性能。随着交错程度的提高，precision的结果会略有下降，但sysnif的precision和recall分别可以达到至少92.2％和93.1％。

依赖计算中的窗口大小和权值贪婪噪声滤波器中的过滤阈值对精度有很大影响。图5显示了sysnif并发任务数为5的数据集构建工作流模型的precision和recall。可以得出这样的判定，对于本数据集而言，需要将窗口大小设置为5，将过滤阈值设置为0.3，sysnif可获得更好的性能。这也验证了窗口越大，引入的噪声就越大，并且将真实前驱后继与噪声项区分开的难度就越大。

我们还进行了3k日志工作流直接构建和2k日志工作流构建+1k日志工作流微调的对比实验，其precision/recall结果分别为0.948/0.935和0.953/0.929。在该实验中，窗口长度被设置为5，并且微迭代步长μ被设置为0.008。上限值和下限值相对地设置为0.1和0.9。可以得出结论，构造+微迭代可以达到直接构造的精度水平。微迭代可在线工作，并在系统运行时输出实时工作流模型，从而避免了工作流重建的大量资源消耗。

sysnif的主要时间消耗可以分为两部分：原始日志预处理和结构化序列工作流构建。预处理是将非结构化原始日志数据解析为结构化日志模板序列。我们的工具采用了最新的日志解析算法drain(p.he，j.zhu，z.zheng，andm.r.lyu，“drain：anonlinelogparsingapproachwithfixeddepthtree，”in2017ieeeinternationalconferenceonwebservices(icws).ieee，2017，pp.33-40.)。在工作流构建阶段，sysnif基于很少迭代的统计计算。权重贪心噪声过滤算法中d_v计算和排序过程的时间复杂度分别为o(n)和o(nlog(n))，其中n是日志数，n是比n小得多的模板数。在i5-8300hcpu和8gb内存硬件环境中，sysnif处理10k日志的时间为3.95s。可以得出结论，sysnif可以达到每10k日志处理级别数秒级别。

以上通过实施例对本发明进行了详细说明，但所述内容仅为本发明的示例性实施例，不能被认为用于限定本发明的实施范围。本发明的保护范围由权利要求书限定。凡利用本发明所述的技术方案，或本领域的技术人员在本发明技术方案的启发下，在本发明的实质和保护范围内，设计出类似的技术方案而达到上述技术效果的，或者对申请范围所作的均等变化与改进等，均应仍归属于本发明的专利涵盖保护范围之内。