【PaperReading】System Log Analysis for Anomaly Detection
Experience Report: System Log Analysis for Anomaly Detection
2016 IEEE 27th International Symposium on Software Reliability Engineering
经验报告: 系统日志分析以检测异常
Shilin He, Jieming Zhu, Pinjia He, and Michael R. Lyu
Department of Computer Science and Engineering, The Chinese University of *, *
Shenzhen Research Institute, The Chinese University of *, Shenzhen, China
{slhe, jmzhu, pjhe, lyu}@cse.cuhk.edu.hk
摘要——异常检测在现代大型分布式系统的管理中起着重要的作用。日志记录系统运行时信息，广泛用于异常检测。传统上，开发人员(或操作人员)经常使用关键字搜索和规则匹配手动检查日志。然而，现代系统的规模和复杂性的不断增加，使得日志的数量激增，这使得手工检查变得不可行。为了减少人工的工作量，提出了许多基于自动日志分析的异常检测方法。但是，由于缺乏对这些异常检测方法的回顾和比较，开发人员可能仍然不知道应该采用哪种异常检测方法。此外，即使开发人员决定使用异常检测方法，重新实现也需要付出不小的努力。为了解决这些问题，我们提供了六种最先进的基于日志的异常检测方法的详细审查和评估，其中包括三种监督方法和三种非监督方法，并发布了一个开源工具包，允许重用。这些方法已经在两个公开可用的生产日志数据集中进行了评估，共有15,923,592条日志消息和365,298个异常实例。我们相信，我们的工作，连同评估结果和相应的结果，可以为采用这些方法提供指导，并为今后的发展提供参考。
1.引言
现代系统正在向大规模发展，可以扩展到构建在数千台普通机器(如Hadoop[1]、Spark[2])上的分布式系统，也可以扩展到使用数千台处理器的超级计算机(如Blue Gene/L[36])进行高性能计算。这些系统正在成为IT行业的核心部分，支持各种在线服务(如搜索引擎、社交网络和电子商务)和智能应用(如天气预报、商业智能和生物医学工程)。由于这些系统大多设计为全天候运行，为全球数百万在线用户提供服务，因此必须具备高可用性和可靠性。这些系统的任何事故，包括服务中断和服务质量下降，都将导致应用程序崩溃，并导致严重的收入损失。
异常检测是为了及时发现系统异常行为，在大型系统的事件管理中发挥着重要作用。及时的异常检测允许系统开发人员(或操作人员)及时地定位问题并立即解决它们，从而减少系统停机时间。系统通常生成日志，日志记录系统运行期间的详细运行时信息。这些广泛可用的日志作为系统异常检测的主要数据源。基于日志的异常检测(如[27]、[38]、[47])已成为学术界和工业界具有实际意义的研究课题。对于传统的独立系统，开发人员可以手动检查系统日志或编写规则，根据他们的领域知识检测异常，还可以使用关键字搜索(例如,"fail"、"exception")或正则表达式匹配。但是，这种严重依赖手工检查日志的异常检测方法不适用于大型系统，原因如下:
- 现代系统的大规模和并行性使得系统行为过于复杂，以至于单个开发人员无法理解，他们通常只负责子组件。例如，许多开源系统(如Hadoop、Spark)是由数百名开发人员实现的。开发人员可能对整个系统行为只有不完整的理解，因此从大量日志中识别问题是一个很大的挑战。
- 现代系统正在生成大量的日志，例如，以每小时50 gb(大约120~2亿行)的速度生成[32]。即使使用搜索和grep等实用工具，单凭这些日志的数量就很难(如果不是不可行的话)从噪声数据中手工识别关键信息来进行异常检测。
- 大型系统通常使用不同的容错机制构建。系统有时运行具有冗余的相同任务，甚至主动终止投机任务以提高性能。在这种情况下，使用关键字搜索的传统方法在提取这些系统中的可疑日志消息时变得无效，这可能导致许多误报，实际上这些日志消息与实际故障[27]无关。这将大大增加手工检查的工作量。
因此，迫切需要用于异常检测的自动化日志分析方法。近几十年来，基于日志的异常检测得到了广泛的研究。然而，我们发现在学术界的研究和工业界的实践之间存在着差距。一方面，开发人员在许多情况下并不了解最先进的异常检测方法，因为目前对这一主题缺乏全面的审查。他们必须查阅大量的文献才能全面了解目前的异常检测方法。这是一项繁重的任务，但不能保证找到最合适的方法，因为每项研究工作通常都特别侧重于向目标系统报告详细的方法。如果开发人员事先没有了解这些方法所需的机器学习背景知识，那么这种困难可能会加剧。另一方面，据我们所知，目前还没有基于日志的开源工具可以用于异常检测。现有的异常检测方法也缺乏比较。对于开发人员来说，他们很难知道解决手头实际问题的最佳方法是什么。为了比较所有的候选方法，他们需要用自己的实现来尝试每一个方法。复制这些方法通常需要付出巨大的努力，因为没有测试预言可以保证底层机器学习算法的正确实现。
为了弥补这一缺陷，本文对基于日志的异常检测进行了详细的回顾和评估，并发布了一个用于异常检测的开源工具包(https://github.com/logpai/loglizer)。我们的目标不是要改进任何特定的方法，而是要全面地描述当前用于异常检测的日志分析的研究现状。我们认为我们的工作可以使研究者和实践者在两个方面受益：综述可以帮助他们快速了解当前的异常检测方法；而开源工具包允许他们轻松地重用现有的方法，并进行进一步的定制或改进。这有助于避免重新实现所做的耗时但冗余的工作。
异常检测的日志分析过程包括四个主要步骤:日志收集、日志解析、特征提取和异常检测。在我们的上一篇文章[24]中，我们回顾并评估了自动日志解析方法，其中公开发布了四个开源日志解析器。在这项工作中，我们将主要集中在特征提取和异常检测的机器学习模型方面。根据所涉及的数据类型和使用的机器学习技术，异常检测方法可以分为两大类：监督异常检测和非监督异常检测。监督方法需要标注训练数据，并对正常实例和异常实例有明确的说明。然后利用分类技术学习模型，最大限度地区分正常和异常实例。然而，无监督方法根本不需要标签。它们的工作基于这样的观察：异常实例通常表现为与其他实例距离较远的异常点。因此，可以应用无监督学习技术，如集群。
更具体地说，我们回顾并实施了最近文献中报道的六种有代表性的异常检测方法，其中包括三种监督方法(即， Logistic回归[12]，决策树[15]，SVM[26]，三种无监督方法(即日志聚类[27]，PCA[47]，Invariant Mining[28])。我们进一步对两个公开可用的日志数据集(共15,923,592条日志消息和365,298个异常实例)对这些方法进行了系统的评估。评估结果报告的精度(根据报告的正确异常的百分比)、查全率(根据检测到的实际异常的百分比)和效率(根据不同日志大小的运行时间)。虽然数据有限，但我们相信，这些结果，以及所揭示的结果，可为采用这些方法提供指导，并可作为今后发展的基准。
综上所述，本文的贡献如下:
- 详细回顾基于自动日志分析的常用异常检测方法;
- 由六种代表性异常检测方法组成的开源工具包;
- 对当前异常检测方法的有效性和效率进行系统评估。
本文的其余部分组织如下。第二部分描述了基于日志的异常检测的总体框架。第三部分综述了六种具有代表性的异常检测方法。我们在第四部分报告了评价结果，在第五部分进行了一些讨论。第六部分介绍了相关工作，最后第七部分对本文进行了总结。
2.总体框架
图1说明了基于日志的异常检测的总体框架。异常检测框架主要包括日志采集、日志解析、特征提取和异常检测四个步骤。
日志收集：大型系统通常生成日志来记录系统状态和运行时信息，每个日志包含一个时间戳和一个日志消息，指示发生了什么。这些有价值的信息可以用于多种目的(例如，异常检测)，因此首先收集日志以供进一步使用。例如，图1描述了从Amazon EC2平台[47]上的HDFS日志中提取的8条日志行，为了便于表示，这里省略了一些字段。
日志解析：日志是非结构化的，其中包含*格式的文本。日志解析的目的是提取一组事件模板，从而可以对原始日志进行结构化。更具体地说，可以将每个日志消息解析为带有一些特定参数(变量部分)的事件模板(常量部分)。如图1所示，第4条日志消息(日志4)被解析为“Event 2”，并带有一个事件模板“Received block * of size * from *”。
特征提取：将日志解析为单独的事件后，需要将日志进一步编码为数值特征向量，从而应用机器学习模型。为此，我们首先使用不同的分组技术(包括固定窗口、滑动窗口和会话窗口)将原始日志分割成一组日志序列。然后，对于每个日志序列，我们生成一个特征向量(事件计数向量)，它表示每个事件的发生次数。所有的特征向量可以组合成一个特征矩阵，即事件计数矩阵。
异常检测：最后将特征矩阵输入机器学习模型进行训练，生成异常检测模型。所构造的模型可用于识别新的输入日志序列是否异常。
3.方法
在本节中，我们将详细介绍不同阶段的方法：日志解析、特征提取和异常检测。简要介绍了日志解析的基本思想，并介绍了几种典型的日志解析器。然后，讨论了三种特征提取技术，并将其应用于已解析的日志事件生成特征向量。在得到特征向量后，重点研究了六种具有代表性的异常检测方法，其中三种是监督方法，另外三种是非监督方法。
A.日志解析
日志是由常量部分和变量部分组成的纯文本，在不同的情况下可能会有所不同。例如，给定日志" Connection from 10.10.34.12 closed"和"Connection from 10.10.34.13 closed"，"Connection"、"from"和"close"这三个词被认为是常量部分，因为它们总是保持不变，而其余部分由于不是固定的，所以称为可变部分。常量部分由开发人员在源代码中预定义，变量部分通常是动态生成的(例如端口号、IP地址)，不能很好地用于异常检测。日志解析的目的是将常量部分与变量部分分离，并形成一个良好的日志事件(即，“Connection from * closed”在本例中)。
有两种类型的日志解析方法：基于集群的(如LKE[20]、LogSig[44])和基于启发式的(如iPLoM [29]， SLCT[45])。在基于集群的日志解析器中，首先计算日志之间的距离，然后使用集群技术将日志分组到不同的集群中。最后，从每个集群生成事件模板。对于基于启发式的方法，计算每个单词在每个日志位置上出现的次数。其次，选取频繁词作为事件候选词进行组合。最后，选择一些候选项作为日志事件。我们在之前的工作[24]中实现并比较了四个日志解析器。此外，我们还在网上发布了一个开源的日志解析工具包（https://github.com/logpai/logparser），用于在本文中将原始行日志解析为日志事件。
B.特征提取
这一步的主要目的是从日志事件中提取有价值的特征，这些特征可以被输入到异常检测模型中。特征提取的输入为日志解析步骤中生成的日志事件，输出为事件计数矩阵。为了提取特征，我们首先需要将日志数据分成不同的组，其中每个组表示一个日志序列。为此，应用窗口将日志数据集划分为有限块[5]。如图1所示，我们使用三种不同类型的窗口：固定窗口、滑动窗口和会话窗口。
固定窗口:固定窗口和滑动窗口都基于时间戳，它记录每个日志的发生时间。每个固定窗口都有其大小，这意味着时间跨度或时间持续时间。如图1所示,Δt表示窗口大小,这是一个恒定值,如一个小时或一天。因此，固定窗口的数量取决于预定义的窗口大小。发生在同一窗口中的日志被视为日志序列。
滑动窗口:与固定窗口不同，滑动窗口由两个属性组成：窗口大小和步长。例如，每小时的窗口每五分钟就会滑动一次。一般来说，步长小于窗口大小，因此会造成不同窗口的重叠。图1显示窗口大小ΔT,步长是向前的距离。滑动窗的数量通常大于固定窗的数量，主要取决于窗口大小和步长。发生在同一个滑动窗口中的日志也被分组为一个日志序列，尽管由于重叠，日志可能在多个滑动窗口中重复。
会话窗口:与上面两种窗口类型相比，会话窗口基于标识符而不是时间戳。标识符用于在某些日志数据中标记不同的执行路径。例如，带有block_id的HDFS日志记录特定块的分配、写入、复制和删除。因此，我们可以根据标识符对日志进行分组，其中每个会话窗口都有一个惟一的标识符。
利用窗口技术构造日志序列后，生成事件计数矩阵X。在每个日志序列中，我们计算每个日志事件的发生次数，以形成事件计数向量。例如，如果事件计数向量是[0,0,2,3,0,1,0]，则表示在这个日志序列中，事件3发生了两次，事件4发生了三次。最后，将大量事件计数向量构造为事件计数矩阵X，其中条目Xi,j记录了事件j在第i个日志序列中发生的次数。
C.基于监督的异常检测
监督学习(如决策树)被定义为一种机器学习任务，从标记的训练数据中得到一个模型。标记训练数据是监督异常检测的前提，它通过标记来表示正常或异常状态。标记的训练数据越多，模型就越精确。下面我们将介绍三种有代表性的监督方法:逻辑回归、决策树和支持向量机。
1）逻辑回归
Logistic回归是一种被广泛应用于分类的统计模型。为了确定一个实例的状态，逻辑回归估计所有可能状态(正常或异常)的概率p。概率p由一个基于标签训练数据的logistic函数计算。当一个新的实例出现时，logistic函数可以计算概率p(0)，得到概率后，概率最大的状态为分类输出。
为了检测异常，将每个日志序列构造一个事件计数向量，并将每个事件计数向量及其标签称为一个实例。首先，我们使用训练实例来建立logistic回归模型，这实际上是一个logistic函数。得到模型后，我们将一个测试实例X输入logistic函数，计算其异常概率p，当p≥0.5时，X的标号为异常，否则为正常。
2）决策树
决策树是一个树结构图，它使用分支来说明每个实例的预测状态。该决策树采用自顶向下的方式使用训练数据构造。每个树节点使用当前的“best”属性创建，该属性由属性的信息增益[23]选择。例如，图2中的根节点显示数据集中总共有20个实例。在分割根节点时，将事件2的出现次数视为“best”属性。因此，根据该属性的值将整个20个训练实例划分为两个子集，其中一个包含12个实例，另一个包含8个实例。
在[15]中，决策树首次应用于web请求日志系统的故障诊断。利用事件计数向量及其在III-B节中描述的标签构建决策树。为了检测新实例的状态，它根据每个遍历树节点的谓词遍历决策树。在遍历结束时，实例将到达其中一个叶子，它反映了这个实例的状态。
3）SVM
支持向量机(SVM)是一种用于分类的监督学习方法。在支持向量机中，构造一个超平面来分离高维空间中的各类实例。寻找超平面是一个优化问题，它使超平面与不同类中最近的数据点之间的距离最大。
在[26]中，Liang等人使用SVM来检测故障，并将其与其他方法进行比较。与逻辑回归和决策树类似，训练实例是事件计数向量及其标签。在SVM异常检测中，如果一个新实例位于超平面之上，则将其作为异常报告，反之则标记为正常。支持向量机有两种，即线性支持向量机和非线性支持向量机。在本文中，我们只讨论线性支持向量机，因为在我们的大多数实验中，线性支持向量机都优于非线性支持向量机。
D.基于无监督的异常检测
与监督方法不同，无监督学习是另一种常见的机器学习任务，但它的训练数据没有标记。由于缺少标签，非监督方法在实际生产环境中更适用。常用的无监督方法包括各种聚类方法、关联规则挖掘、PCA等。
1）日志聚类
在[27]中，Lin等人设计了一种基于集群的方法LogCluster来识别在线系统问题。LogCluster需要两个培训阶段，即知识库初始化阶段和在线学习阶段。因此，这两个阶段的培训实例分别分为两部分。
知识库初始化阶段包括三个步骤:日志向量化、日志聚类、代表性向量提取。首先将日志序列矢量化为事件计数向量，再通过逆文档频率(IDF)[41]和归一化对其进行修正。其次，使用凝聚层次聚类方法对正常事件和异常事件分别进行聚类向量计数，生成两组向量聚类(即，正常集群和异常集群)作为知识库。最后，通过计算每个簇的质心，为每个簇选择一个有代表性的向量。
在线学习阶段用于进一步调整知识库初始化阶段构建的集群。在在线学习阶段，将事件计数向量逐一添加到知识库中。给定一个事件计数向量，计算它与现有代表性向量之间的距离。如果最小距离小于阈值，则将该事件计数向量添加到最近的集群中，并更新该集群的代表向量。否则，LogCluster将使用这个事件计数向量创建一个新的集群。
在构建知识库并完成在线学习过程后，可以使用LogCluster进行异常检测。具体地说，为了确定一个新的对数序列的状态，我们计算它到知识库中表示向量的距离。如果最小距离大于阈值，则将日志序列报告为异常。否则，如果最近的集群是正常/异常集群，则日志序列报告为正常/异常。
2）PCA
主成分分析(PCA)是一种广泛用于降维的统计方法。PCA的基本思想是将高维数据(如高维点)投影到由k个主分量(如，其中k被设置为小于原始维度。主成分分析通过寻找主成分(即轴心)来计算k个主成分，并在高维数据中获得最大方差。因此，被PCA转换的低维数据可以保留原始高维数据的主要特征(例如两点之间的相似性)。例如，在图3中，PCA试图将二维点转换为一维点。之所以选择Sn作为主成分，是因为点与点之间的距离可以通过映射到Sn得到最好的描述。
3）Invariants Mining
程序不变量是线性关系，即使在不同的输入和不同的工作负载下，系统运行时也总是保持这种关系。在[28]中，不变量挖掘首次应用于基于对数的异常检测。具有相同会话id的日志(例如，HDFS中的块id)通常表示该会话的程序执行流。图4显示了一个简化的程序执行流程。
在这个执行流程中，系统在从A到G的每一个阶段都会生成一条日志消息。假设系统中运行着大量的实例，并且它们遵循图4中的程序执行流程，则公式如下:
其中n(*)表示属于相应事件类型*的日志数量。
不变量挖掘，它的目的是找到不变量(即线性关系)，包含三个步骤。不变量挖掘的输入是一个由日志序列生成的事件计数矩阵，其中每一行是一个事件计数向量。首先，利用奇异值分解对不变空间进行估计，确定下一步需要挖掘的不变量的数量r。其次，该方法通过蛮力搜索算法求出不变量。最后，通过将每个挖掘出的不变量候选项的支持度与阈值(例如，98%的事件计数向量支持)进行比较来验证每个挖掘出的不变量候选项。这个步骤将继续，直到得到r独立不变量。
在基于不变量的异常检测中，当一个新的日志序列到达时，我们检查它是否服从不变量。如果至少有一个不变量被破坏，日志序列将被报告为异常。
E.方法比较
为了加强对以上六种异常检测方法的理解，帮助开发人员更好地选择要使用的异常检测方法，我们在本部分讨论了不同方法的优缺点。
对于监督方法，异常检测需要标签。决策树比其他两种方法更具解释性，因为开发人员可以用有意义的解释(即，树节点中的谓词)。逻辑回归不能解决线性不可分问题，而支持向量机可以用核函数来解决。但是SVM的参数很难调优(如罚参数)，建立模型往往需要大量的手工工作。
由于无监督方法缺少标签，因此更加实用和有意义。日志聚类使用在线学习的思想。因此，它适用于处理大量的日志数据。不变量挖掘不仅可以高精度地检测异常，而且可以为每一个检测到的异常提供有意义和直观的解释。然而，不变量挖掘过程是费时的。PCA不容易理解，对数据很敏感。因此，它的异常检测精度在不同的数据集上是不同的。
F.工具实现
我们用Python实现了六种异常检测方法，代码超过4000行，并将它们打包成一个工具包。对于监督方法，我们使用一个广泛使用的机器学习包，scikit-learn[39]来实现逻辑回归、决策树和SVM的学习模型。SVM和logistic回归中有大量的参数，我们在训练过程中对这些参数进行手动调整，以达到最佳效果。对于SVM，我们逐一尝试了不同的核函数和相关参数，发现线性核函数支持向量机的异常检测精度优于其他核函数支持向量机。对于逻辑回归，还研究了不同的参数，并对它们进行了仔细的调优，以获得最佳性能。
然而，实现非监督方法并不简单。对于日志聚类，我们不能直接使用来自scikit-learn的聚类API，因为它不是为大规模数据集设计的，在这种情况下，我们的数据无法装入内存。我们将聚类算法实现为一个在线版本，其中每个数据实例被一个接一个地分组到一个簇中。有多个阈值需要调优。我们也付出了很大的努力来实现不变量挖掘方法，因为我们建立了一个可能不变量的搜索空间，并提出了多种方法来删除所有不必要的不变量。测试不同的阈值组合非常耗时。最后利用scikit-learn中的一个API，根据原始参考文献实现了PCA方法。PCA只有两个参数，而且很容易调优。
4.评价研究
在本节中，我们将首先介绍使用的数据集和用于评估的实验设置。然后，我们分别给出了监督和非监督异常检测方法的评估结果，因为这两种方法通常适用于不同的环境。最后，对这些方法的有效性进行了评价。
A.试验设计
日志数据集：公开可用的生产日志是稀缺的数据，因为由于机密问题，公司很少发布它们。幸运的是，通过查阅大量的文献，并与相应的作者进行深入的联系，我们成功地获得了两个日志数据集，HDFS数据[47]和BGL数据[36]，这两个数据集适用于评估现有的异常检测方法。这两个数据集都是从生产系统收集的，共有15,923,592条日志消息和365,298个异常样本，由原始领域专家手工标记。因此，我们将这些标签(异常与否)作为准确评估的依据。更多的数据集的统计信息如表I所示。
HDFS数据包含11,175,629条日志消息，这些消息是从Amazon EC2平台[47]收集的。HDFS日志为每个块操作(如分配、写入、复制和删除)记录一个惟一的块ID。因此，会话窗口可以更自然地捕获日志中的操作(如III-B中介绍的)，因为可以使用每个惟一的块ID将日志分割成一组日志序列。然后从这些日志序列中提取特征向量，生成575,061个事件计数向量。其中，有16838个样本被标记为异常。
BGL数据包含4747963条日志消息，由劳伦斯利弗莫尔国家实验室(LLNL)[36]的BlueGene/L超级计算机系统记录。与HDFS数据不同，BGL日志没有为每个作业执行记录标识符。因此，我们必须使用固定窗口或滑动窗口将日志分割为日志序列，然后提取相应的事件计数向量。但是窗口的数量取决于所选择的窗口大小(和步骤大小)。在BGL数据中，348,460条日志消息被标记为故障，如果该序列中存在任何故障日志，则将日志序列标记为异常。
实验环境：我们在一台Linux服务器上运行所有实验，该服务器使用Intel Xeon E5-2670v2 CPU和128GB DDR3 1600 RAM，运行64位Ubuntu 14.04.2和Linux内核3.16.0。除非另有说明，每个实验进行五次，并报告平均结果。我们使用最常用的度量方法precision、recall和F-measure来评估异常检测方法的准确性，因为我们已经知道了这两个数据集的ground truth(是否异常)。如下所示，精度度量报告的异常正确的百分比，召回度量实际检测到的异常的百分比，F-measure表示精度和召回的调和平均值。
对于这三种监督方法，我们选择前80%的数据作为训练数据，其余20%作为测试数据，因为只有以前发生的事件才会导致后续异常。默认情况下，我们将固定窗口的窗口大小设置为1小时，将滑动窗口的窗口大小和步长分别设置为6小时和1小时。
B.有监督模型的准确性
为了探索监督方法的准确性，我们使用它们来检测HDFS数据和BGL数据上的异常。我们使用会话窗口对HDFS数据进行切片，然后生成事件计数矩阵，而固定窗口和滑动窗口分别应用于BGL数据。为了检验三种监督方法(Logistic回归、决策树、SVM)的有效性，我们首先对训练数据进行模型训练，然后将模型应用于测试数据。我们报告了不同设置下的训练精度和测试精度，如图7~9所示。我们可以看到，所有的监督方法都达到了很高的训练精度(超过0.95)，这意味着使用我们的特征表示可以很好地分离正常实例和异常实例。然而，它们对测试数据的准确性因方法和数据集的不同而不同。无论是固定窗口还是滑动窗口，HDFS数据的总体精度都高于BGL数据的精度。这主要是因为HDFS系统记录相对简单的操作，只有29个事件类型，这比BGL数据中的385少得多。此外，HDFS数据按会话窗口进行分组，从而在每个日志序列中的事件之间产生更高的相关性。因此，在HDFS上的异常检测方法优于在BGL上的异常检测方法。
特别是图5显示了对HDFS数据异常检测的准确性，三种方法对测试数据都有很好的性能，F-measure接近1。在对固定窗口的BGL测试数据应用监督方法时，虽然训练数据表现良好，但并没有达到很高的精度。如图6所示，固定窗口BGL上的三种方法召回率都只有0.57，但检测精度较高，为0.95。我们发现，由于固定窗口大小仅为1小时，因此可能导致异常分布不均。例如，当前窗口中发生的一些异常实际上可能与前一个时间窗口中的事件有关，并且它们被错误地划分了。因此，固定窗口时间为1小时的异常检测方法对BGL数据的检测效果不佳。
发现1:监督异常检测方法实现了较高的精度，而召回率随着不同的数据集和窗口设置而变化。
针对固定窗口性能较差的问题，采用滑动窗口对窗口大小为6h、步长为1h的BGL数据进行切片。结果如图7所示。与固定窗相比，基于滑动窗的异常检测对检测数据的精度有了很大的提高。其原因是，通过使用滑动窗口，我们不仅可以获得与固定窗口一样多的窗口(事件计数向量)，而且可以避免由于窗口大小较大而导致的分布不均问题。在监督方法中，我们观察到SVM的总体精度最好，F-measure为0.85。此外，基于滑动窗口的决策树和逻辑回归方法的召回率分别比固定窗口提高了10.5%和31.6%。
为了进一步研究不同窗口大小和不同步长对异常检测精度的影响，我们在保持一个参数不变的情况下，通过改变一个参数进行实验。根据图8中的图a)，我们保持步长大小为1小时，同时改变窗口大小，如表2所示。超过12小时的窗口大小不被考虑，因为它们在实际应用中不实用。我们可以看到，SVM的F度量随着窗口大小的增大而略有减小，而logistic回归的精度先缓慢增加，当窗口大小增加到9小时时急剧下降，然后保持稳定。显然，当窗口大小为6小时时，logistic回归的精度最高。决策树精度的变化趋势与logistic回归相反，在12小时时达到最高。因此，logistic回归对窗口大小敏感，而决策树和SVM保持稳定。
发现2:滑动窗异常检测比固定窗检测精度高。
与窗口大小相比，步长对异常检测精度的影响较大。表II说明，如果我们在将窗口大小保持在6小时的同时减小步骤大小，那么滑动窗口(数据实例)的数量将显著增加。这三种方法都显示出相同的趋势，精度先略有提高，然后在3小时左右下降。这可能是由于在使用较大的步长时，例如在3小时时，数据实例的数量会急剧减少。一个例外发生在6小时的步长:窗口大小等于步长，因此滑动窗口与固定窗口相同。在这种情况下，消除了一些重叠引起的噪声，使得检测精度有了小幅提高。
C.无监督模型的准确性
虽然监督方法可以达到很高的精度，特别是对HDFS数据，但这些方法不一定适用于实际的设置，因为数据标签通常是不可用的。针对这一问题，提出了无监督异常检测方法。为了探讨无监督方法的异常检测精度，我们对HDFS数据和BGL数据进行了评价。如上一节所示，滑动窗口可以使异常检测更加准确。因此，我们只报告BGL数据上滑动窗口的结果。
由于对50万个实例的HDFS数据进行日志集群非常耗时，调优参数变得不切实际，因此我们选择在合理的时间内能够处理的最大日志大小来表示HDFS数据。
从图9中可以看出，所有的无监督方法对HDFS数据的精度都很好，但对BGL数据的精度相对较低。在三种方法中，不变量挖掘相对于其他非监督异常检测方法在两种数据上都取得了较好的性能(F-measure为0.91)。不变量挖掘自动构造线性相关模式来检测异常，该模式与自然BGL数据非常吻合，通过一些关键事件来标记故障。日志聚类和PCA对BGL数据的检测精度不高。日志聚类性能差是由于事件计数矩阵的高维稀疏特性造成的。因此，日志聚类很难将异常和正常实例分开，这通常会导致大量的误报。
我们深入研究，进一步了解为什么PCA对BGL数据不能达到较高的精度。PCA检测异常的准则是与正常空间的距离(平方预测误差)。如图10所示，当距离大于特定阈值(红色虚线表示当前阈值)时，将一个实例标识为异常。但是，通过使用ground truth标签来绘制距离分布，如图10所示，我们发现这两个类(normal和abnormal)不能被任何单个阈值自然地分隔开。因此，PCA在BGL数据上表现不佳。
发现3:非监督方法的性能一般低于监督方法。不变量挖掘是一种很有前途的方法，具有稳定、高效的特点。
和监督方法一样，我们也对不同的窗口大小和步长设置进行实验，以探索它们对准确性的影响。如图11所示，我们有一个有趣的观察，随着窗口尺寸的增大，精度稳步上升，而步长变化对精度影响不大。这个观察结果与我们对监督方法的发现相反。如表Ⅱ所示，随着窗口大小的增加，窗口数量大幅度减少。在较大的窗口大小下，可以覆盖更多的信息，同时也可以添加更多的噪声，但是无监督方法可以发现更精确的异常检测模式。
结果4:窗口大小和步长设置对监督方法和非监督方法有不同的影响。
D.异常检测方法的有效性
在图12中，所有这些异常检测方法的效率都是在具有不同日志大小的两个数据集上进行评估的。如图所示，监督方法可以在很短的时间内(不到1分钟)检测到异常，而非监督方法则要花费更多的时间(PCA除外)。我们可以看到，所有异常检测方法都是随着日志大小的增加而线性伸缩的，除了日志聚类，其时间复杂度为O(n2)。注意，水平轴和垂直轴都不是线性的。此外，日志聚类不能在可接受的时间内处理大规模数据集;因此，日志聚类的运行时结果并没有完全绘制出来。值得注意的是，不变量挖掘在BGL数据上的运行时间大于在HDFS数据上的日志聚类，因为BGL数据中的事件类型多于HDFS数据，这增加了不变量挖掘的时间。此外，还应该注意，当BGL数据的日志大小为125 mb时，不变量挖掘的运行时间略有减少。这是因为我们设置了停止条件来控制它在大型数据集上的蛮力搜索过程，这可以避免不必要的高维关联搜索。
发现5:大多数异常检测方法都与日志大小成线性关系，但是日志聚类和不变量挖掘方法需要进一步优化以加快速度。
5.讨论
在这一部分中，我们讨论了我们工作的一些局限性，并进一步为未来的研究提供了一些潜在的方向。
数据集的多样性。生产系统记录的日志对于评估异常检测方法非常有用。然而，公开可用的日志数据集是稀缺的资源，因为公司通常不愿意打开他们的日志数据由于保密问题。这就是评估变得困难的地方。在[36]和[47]作者的支持下，我们获得了两个生产日志数据集，它们支持我们的工作。数据集表示来自两种不同类型系统的日志，但是评估结果和结果可能仍然受到数据集多样性的限制。显然，更多日志数据集的可用性将允许我们概括我们的发现，并大力支持相关研究。我们未来的计划是从开放平台收集更多的日志数据集。
特征表示。通常，不同的系统通常有非常不同的日志，如HDFS和BGL数据集中所示。为了推广我们对不同异常检测方法的实现，我们主要关注一个由事件计数矩阵表示的特征空间，这在现有的大部分工作(如[28]、[47])中都得到了应用。还需要进一步研究其他一些特性，比如日志消息的时间戳，这样就可以提取两个连续事件的时间持续时间和日志序列的顺序信息。然而，正如[28]中所报道的，现代分布式系统生成的日志通常由不同的进程交错。因此，从这些日志中提取可靠的时间特性成为一个巨大的挑战。
其他可用的方法。我们回顾并实现了大多数常用的、有代表性的异常检测日志分析方法。然而，还有其他一些使用不同模型的方法，如频繁序列挖掘[22]、有限状态机[20]、形式概念分析[18]和信息检索[30]。我们还认为，由于日志分析的实际重要性，将会有更多的研究出来。实现和维护一组更全面的开源工具是我们正在进行的工作。
开源日志分析工具。目前，缺乏可直接用于异常检测的公开可用的日志分析工具。我们还注意到，一些新公司(如[3]、[4])正在提供日志分析工具作为它们的产品。但它们都像一个黑匣子一样工作。这将导致重复研究的难度增加，并减缓整个创新过程。我们希望我们的工作为使源代码公开迈出第一步，并且我们提倡在这方面作出更多的努力。
潜在的方向。1)方法的可解释性。目前基于日志的异常检测方法大多建立在机器学习模型(如PCA)的基础上。但这些模型中的大多数都是作为“黑匣子”工作的。也就是说，它们很难解释以提供直观的洞见，而且开发人员常常无法找出异常是什么。目前迫切需要能够反映异常性质的方法。2)实时日志分析。当前的系统和平台常常实时生成大量日志。因此，实时处理大日志数据成为一个很大的挑战。大数据平台上的日志分析工具的开发和实时异常检测功能的实现是迫切需要的。
6.相关工作
日志分析。日志分析在异常检测[10]、[28]、[47]、故障诊断[17]、[31]、[38]、程序验证[11]、[42]、性能预测[16]等方面被广泛应用于提高软件系统的可靠性。这些日志分析方法大多由日志解析和日志挖掘两个步骤组成，近年来得到了广泛的研究。He等人[24]评估了四种离线日志解析方法的有效性，SLCT[45]、IPLOM[29]、LogSig[44]和LKE[20]，它们不需要系统源代码。Nagappan等人提出了一种具有线性运行时间和空间的离线日志解析方法。Xu等人设计了一种基于系统源代码的在线日志解析方法。对于日志挖掘，Xu等人[47]使用PCA检测异常，PCA的输入是由日志生成的矩阵。Beschastnikh等人的[11]使用系统日志来生成有限状态机，它描述了系统运行时的行为。不同于以往用对数分析来解决不同问题的论文，本文主要研究基于对数分析的异常检测方法。
异常检测。异常检测的目的是发现异常行为，并将异常行为报告给开发人员进行手工检查和调试。Bovenzi等人提出了一种操作系统级异常检测方法，该方法对关键任务系统是有效的。Venkatakrishnan et al[46]在攻击危及系统之前检测安全异常以防止攻击。本文针对大型系统中常规异常检测方法的有效性进行了评价。Babenko等人设计了一种利用异常检测到的故障自动生成解释的技术。Alonso等人使用不同的分类器来检测异常。Farshchi等人采用基于回归分析的技术来检测云应用操作的异常。Azevedo等人使用聚类算法来检测卫星中的异常。这些方法利用不同系统收集的性能指标数据，可以对本文所评估的基于日志的异常检测方法进行补充。基于日志的异常检测方法被广泛研究于[19]、[20]、[28]、[31]、[43]、[47]。本文对六种基于对数分析的异常检测方法——[12]、[15]、[26]、[27]、[28]、[47]——进行了回顾和评价，认为它们具有创新性和代表性。
实证研究。近年来出现了许多关于软件可靠性的实证研究，因为实证研究通常可以为研究人员和开发人员提供有用和实用的见解。Yuan等人研究了开源系统的日志记录实践，并为开发人员提供了改进建议。Fu等人[21]、[49]对工业界日志实践进行了实证研究。Pecchia等人研究工业项目中影响日志分析的日志目标和问题。Amorim等人的[7]评估了使用决策树算法识别代码气味的有效性。Lanzaro等人的[25]分析了库代码中的软件错误如何表现为接口错误。Saha等人从五个不同的角度研究了长期存在的Bugs。Milenkoski等人对[33]进行了调查，并将计算机入侵检测系统评估中的常见实践系统化。Chandola等人的[14]调查异常检测方法在不同的类别中使用机器学习技术，但本文的目的是回顾和基准的现有工作，将日志分析技术应用于系统异常检测。
7.总结
在现代大规模分布式系统中，log被广泛应用于异常检测。然而，由于日志大小的急剧增加，传统的异常检测方法严重依赖于手工日志检查，已不可能实现。为了减少人工劳动，近年来，自动日志分析和异常检测方法得到了广泛的研究。但是，由于对现有的异常检测方法缺乏全面的回顾和比较，开发人员对现有的异常检测方法还不了解，往往需要自己重新设计一种新的异常检测方法。本文通过对六种最先进的异常检测方法进行详细的回顾和评价，填补了这一空白。我们还比较了两种典型的生产日志数据集的准确性和效率。此外，为了便于重用和进一步研究，我们还发布了一个包含这些异常检测方法的开源工具包。