【2024】A Large-Scale Evaluation for Log Parsing Techniques：How Far Are We?

道之衍

已于 2024-08-15 18:51:48 修改

阅读量718

点赞数 15

文章标签：软件工程 github

于 2024-08-12 19:46:57 首次发布

本文链接：https://blog.csdn.net/qq_20211875/article/details/141126595

版权

论文：《A Large-Scale Evaluation for Log Parsing Techniques: How Far Are We?》

归纳总结：此论文提出了两个日志解析器生成日志模板准确度的评估标准

下载地址：[2308.10828] A Large-Scale Evaluation for Log Parsing Techniques: How Far Are We? (arxiv.org)

github：logpai/loghub-2.0: A Large-scale Evaluation for Log Parsing Techniques: How Far are We? [ISSTA'24] (github.com)

摘要

Log data have facilitated various tasks of software development and maintenance, such as testing, debugging and diagnosing. Due to the unstructured nature of logs, log parsing is typically required to transform log messages into structured data for automated log analysis. Given the abundance of log parsers that employ various techniques, evaluating these tools to comprehend their characteristics and performance becomes imperative. Loghub serves as a commonly used dataset for benchmarking log parsers, but it suffers from limited scale and representativeness, posing significant challenges for studies to comprehensively evaluate existing log parsers or develop new methods. This limitation is particularly pronounced when assessing these log parsers for production use. To address these limitations, we provide a new collection of annotated log datasets, denoted Loghub-2.0, which can better reflect the characteristics of log data in real-world software systems. Loghub2.0 comprises 14 datasets with an average of 3.6 million log lines in each dataset. Based on Loghub-2.0, we conduct a thorough reevaluation of 15 state-of-the-art log parsers in a more rigorous and practical setting. Particularly, we introduce a new evaluation metric to mitigate the sensitivity of existing metrics to imbalanced data distributions. We are also the first to investigate the granular performance of log parsers on logs that represent rare system events, offering in-depth details for software diagnosis. Accurately parsing such logs is essential, yet it remains a challenge. We believe this work could shed light on the evaluation and design of log parsers in practical settings, thereby facilitating their deployment in production systems.

日志数据为软件开发和维护的各种任务提供了便利，例如测试、调试和诊断。由于日志的非结构化特性，通常需要进行日志解析才能将日志消息转换为结构化数据，以便进行自动化日志分析。考虑到大量使用各种技术的日志解析器，评估这些工具以理解它们的特征和性能变得势在必行。Loghub是对日志解析器进行基准测试的常用数据集，但它的规模和代表性有限，这给全面评估现有日志解析器或开发新方法的研究带来了重大挑战。在评估这些日志解析器用于生产时，这种限制尤其明显。为了解决这些限制，我们提供了一个新的带注释的日志数据集集合，标记为Loghub-2.0，它可以更好地反映真实软件系统中日志数据的特征。Loghub2.0包含14个数据集，每个数据集平均有360万条日志行。基于Loghub-2.0，我们在更严格和实用的设置中对15个最先进的日志解析器进行了彻底的重新评估。特别是，我们引入了一个新的评估指标，以减轻现有指标对不平衡数据分布的敏感性。我们也是第一个研究日志解析器在表示罕见系统事件的日志上的粒度性能的人，为软件诊断提供了深入的细节。准确解析这类日志至关重要，但这仍然是一个挑战。我们相信这项工作可以在实际设置中阐明日志解析器的评估和设计，从而促进它们在生产系统中的部署。

一、绪论

日志数据记录了软件运行时的信息，这对于开发人员理解软件系统的行为是必不可少的。日志数据中封装的丰富信息使开发人员和维护人员能够测试程序[4,7,8,41]，识别错误[3,6,14,59]和诊断软件[44-46]。一般来说，日志消息是半结构化的文本数据，由开发人员在源代码中编写的日志语句生成，例如Java中的' logger.info(" connected to host: {} "， hostIp) '[29,30,33,61]。在运行时，变量hostIp可能在不同的执行中发生变化，这可能导致一系列日志消息，如“连接到主机:172.16.254.1”和“连接到主机:172.16.254.2”。日志解析的目的是将这种半结构化的日志消息转换为结构化的事件，这通常是许多日志分析任务的第一步，也是最重要的一步[18,27,32,37,60]。具体来说，日志解析从日志消息中提取恒定部分(即日志模板)和可变部分(即日志参数)。在上面的示例中，日志模板为“connected to host: <*>”，log参数为主机的具体IP地址，如“172.16.254.1”。

传统方法通过将原始日志消息与源代码中各自的日志语句相匹配来解析日志[5,47,48,50]。然而，这种方法通常是不切实际的，因为软件源代码可能并不总是可用的，例如，商业软件。因此，人们在数据驱动的方法上付出了巨大的努力[17,21,23,58]。这些解析器直接处理原始日志消息，而无需访问源代码。考虑到使用不同技术的日志解析器的多样性，评估这些工具以理解它们的特征和性能是至关重要的，这为在工业生产中采用这些工具提供指导。为此，Zhu等人[62]发布了Loghub，其中包含了各种系统生成的日志数据集的广泛集合。然而，Loghub仅为从每个系统随机抽样的2,000行日志(记为Loghub-2k)提供带注释的解析基础事实，它已被广泛用于评估现有的日志解析器[25,63]和开发新的日志解析器[9,10,31,55]。

考虑到使用不同技术的日志解析器的多样性，评估这些工具以理解它们的特征和性能是至关重要的，这为在工业生产中采用这些工具提供指导。为此，Zhu等人[62]发布了Loghub，其中包含了各种系统生成的日志数据集的广泛集合。然而，Loghub仅为从每个系统随机抽样的2,000行日志(记为Loghub-2k)提供带注释的解析基础事实，它已被广泛用于评估现有的日志解析器[25,63]和开发新的日志解析器[9,10,31,55]。

尽管现有的日志解析器，如Drain[17]、Logram[9]和LogPPT[28]，已经在Loghub-2k数据集上报告了最先进的结果，但我们观察到，当这些工具被集成到现实世界的软件系统中时，解析性能会受到损害[15,49]。根据我们在生产环境中部署自动日志解析的经验，我们发现现有的解析器很难识别两种类型的日志模板，即，不频繁的日志模板(不经常出现的)和参数密集的日志模板(涉及许多参数的)。前者通常包括具有严重日志级别(例如，错误或致命)的日志，由于其潜在影响，通常需要更多的关注。后者通常记录系统运行时状态和相关值。这两种类型的日志模板对于下游分析任务至关重要，例如异常检测和调试。因此，必须确保这些日志模板的解析准确性。然而，以往研究报告的研究结果[25,63]不一定适用于实际生产环境，特别是这两种类型的日志数据。

这种性能差异主要源于现有基准研究的三个固有局限性。首先，广泛使用的Loghub-2k规模有限。它在每个数据集中只包含2000行日志消息，而实际数据通常包含数百万行日志消息[55,56,63]。因此，Loghub-2k可能无法充分表示从生产系统获得的日志数据的复杂特征，特别是在日志模板的频率和参数计数方面。其次，现有基准中使用的评估指标(例如，组精度，GA[63])通常是消息级的(即，根据日志消息的数量计算)，因此可能产生误导性的高精度结果。这是因为日志模板出现的分布在生产系统中通常是高度不平衡的[25,55]。评估结果可能受到大多数日志模板类别的支配(即，那些包含许多日志消息的日志模板)。因此，这些指标对于具有不同模板分布的数据集可能不够健壮。第三，现有的研究经常报告日志解析器在处理整个数据集时的性能。在处理上述两种类型的日志模板时，它们是如何执行的还不清楚。缺乏细粒度的评估可能导致对日志解析器在实践中如何处理这些特定情况的理解有限。

为了解决这些限制，我们提出了一个新的日志解析基准，以在更严格和实际的设置中评估日志解析器。具体来说，(1)在原始Loghub日志[20]的基础上，我们构建了一个用于日志解析的大规模注释日志数据集的新版本，称为Loghub-2.0。注释遵循严格的框架进行，通过日志分组和模板匹配，可以显著减少人工工作量。Loghub-2.0旨在反映在真实场景中观察到的日志数据的规模和分布。详细地说，Loghub-2.0包含来自不同软件系统的14个数据集。每个数据集平均包含360万行日志消息。每条日志行都手工标注了相应的日志模板和参数。(2)我们提出了一个更全面的基准测试协议来评估现有的日志解析器。该协议包括一个新的模板级度量，即组精度(FGA)的f1分数，以减轻消息级度量(例如GA)对不平衡数据的敏感性。此外，我们第一步研究了日志解析器在不同频率和参数计数的日志模板上的性能，为它们在生产环境中的性能提供了重要参考。(3)我们在Loghub-2.0上使用提议的基准测试协议对15个日志解析器(包括13个基于统计的和2个基于语义的日志解析器)进行了广泛的重新评估。我们的研究为研究人员和实践者提供了一个更实用的视角来理解这些解析器的特征。我们将评估的主要发现总结如下。

关键的发现。(1)与Loghub-2k相比，Loghub-2.0具有更真实的数据特征，特别是在日志模板频率和参数数量方面。(2)与Loghub-2k相比，所有现有的解析器在Loghub-2.0上表现出明显的性能下降，差异程度更大。这表明我们提出的数据集和基准测试协议可以揭示日志解析器在更复杂和多样化条件下的性能。(3)在整个数据集上实现高的整体性能并不一定保证对不频繁和参数密集的日志进行有效的解析，这在系统维护中往往需要更多的关注。因此，综合评估应考虑不同类型的日志，以确保在实践中性能的鲁棒性和可靠性。(4) 15个解析器中有9个无法在合理的时间范围内处理Loghub-2.0中的所有数据集，这突出了提高解析效率的重要性，特别是对于生产部署。

本文的主要贡献总结如下:

•我们提出了一个新的用于评估日志解析技术的大规模数据集集合，称为Loghub-2.0。该集合包括14个数据集，每个数据集平均有360万条日志行。通过严格的标注框架对日志消息的解析标签进行手工标注，保证了标注过程的高效性和准确性。这是对现有的广泛使用的Loghub-2k的重要扩展，后者每个数据集只包含2000行日志消息。

•我们为日志解析器提出了一个更全面的基准测试协议，该协议强调评估具有不同特征的日志的解析准确性。此外，提出了一种新的模板级度量，即FGA，以解决现有度量对不平衡数据的敏感性。

•我们通过基准测试协议重新评估了15个最先进的日志解析器，并得出了7个有趣的发现，这些发现可以在更实际的环境中阐明日志解析器的设计和评估。为了有利于未来的研究，我们公开了数据集、源代码和实验结果[1]。

二、背景和动机

在本节中，我们首先简要介绍文献中现有的日志解析器。然后，我们讨论促使我们重新审视现有日志解析研究的观察结果。

2.1、现有的日志解析技术

文献中提出了许多日志解析方法，主要分为以下四类。

基于频率的解析方法。这种类型的方法[9,43,53,54]是基于这样一种直觉，即经常出现在特定日志数据集中的令牌通常表示这些日志的静态元素。因此，频率模式的提取为自动日志解析提供了一种直接的方法。详细地说，这些日志解析器首先遍历所提供的日志数据集以构造频率项集。随后，利用这些项集派生日志消息的相应日志模板。

基于相似度的解析方法。这些日志解析器[13,16,42,51,52]将日志解析定义为将日志按照相似度聚类为不同的集群，并且每个集群中的日志共享相同的日志模板。各种方法采用不同的聚类算法(例如，层次聚类，基于密度的聚类)和相似度定义。在集群过程之后，可以通过从每个集群中的日志中提取通用标记来派生日志模板。

基于启发式的解析。另一类日志解析器[11,17,24,39,40,58]采用各种启发式算法或数据结构，如基于最长公共子序列的方法、解析树、进化算法等。这些日志解析器旨在利用日志数据的独特特征来区分日志消息中的模板和参数。

基于语义的解析。近年来，许多解析器[21,28,31,35]使用深度神经网络来理解日志的语义，从而提高解析精度。具体来说，这些日志解析器采用监督式方法，利用双向长短期记忆或预训练语言模型等模型来学习日志消息的语义信息，从而通过完成分类任务来区分日志模板和参数。

2.2、动机

鉴于日志解析的研究成果丰硕，综合评价现有的日志解析器对于了解其特点和指导实践中选择合适的方法至关重要。Zhu等[63]通过收集来自不同类型系统(包括分布式系统、超级计算机系统等)的多个日志数据集，提出了第一个包含13个日志解析器的基准测试。特别是，他们为每个数据集随机抽样了2,000条日志消息，并为这些日志的模板手动注释。这就产生了广泛使用的日志解析数据集集合，即Loghub-2k。许多新的日志解析方法[9,28,55]也在Loghub-2k上评估了它们的性能，并展示了有希望的结果。

尽管数据集有优势，我们仍然观察到与之相关的一些固有局限性。首先，最近的一项研究[25]指出了注释模板中的多个错误，这可能会影响日志解析器的评估。因此，他们提出了几个启发式规则，例如正则表达式，来修复Loghub-2k中的错误模板。其次，我们发现这些日志解析器在生产部署中的有效性和效率受到了损害。这突显了以前基准研究的局限性，因为它们没有完全捕捉到日志解析器的综合性能，特别是在实际环境中。为了理解上述局限性，我们进行了彻底的调查，并确定了三个主要原因：

•Loghub-2k规模较小，每个数据集仅包含2000行日志消息。考虑到现实世界的系统经常产生大量的日志数据(例如，每小时数十gb [19,36,55])， Loghub-2k可能无法反映生产环境中观察到的日志数据的多样性和复杂性特征。考虑到大多数现有日志解析器的数据驱动性质，它们的性能可能会受到Loghub-2k有限规模的影响，并且可能无法很好地推广到具有更大、更多样化日志数据集的实际场景。此外，Loghub-2k的注释过程没有遵循严格和标准化的方法，导致在注释的模板中出现潜在的错误和不一致。

•现有的研究往往缺乏一套全面的评价指标。其中大多数只采用消息级指标，如组精度[63]和解析精度[9]。从理论上讲，这些指标倾向于支持频繁出现的日志模板。例如，如果一个简单的模板包含大量的日志消息，那么成功解析该模板将产生良好的性能，而不考虑使用频率较低的模板的结果。在实际场景中，日志数据可能高度不平衡。例如，一些系统定期打印日志消息来记录日常信息，例如系统心跳(“system uptime: 30 hours”)。系统操作人员可能对此类日志不感兴趣。然而，它们可能会影响整体性能，掩盖了在处理不频繁的模板时可能出现的错误。

•当前对日志解析器的评估主要报告整个数据集的整体性能。但是，这种方法缺乏对具有不同特征的日志解析性能的细粒度分析。我们已经确定了两种关键类型的日志，它们在生产系统维护中发挥着重要作用。其中包括不常见的日志模板，它表示需要特别注意的罕见系统事件，以及参数密集型日志模板，它提供有关系统状态和相关实体的详细信息。研究这些日志的性能有助于理解日志解析器在实际应用程序中的实际有效性。

为了解决这些限制，我们建议在更严格和实用的设置中对现有日志解析器进行新的基准研究。这需要创建更多样化的日志解析数据集集合，这些数据集的规模要大得多，还需要设计更全面的基准测试协议。

三、数据集建设

3.1、综述

为了构建数据集，我们在Loghub[20]中选择了14个日志数据集，这些数据集跨越了不同类型的系统，包括分布式系统、超级计算机和操作系统。尽管这些数据集是从各种类型的系统中大规模收集的，但它们缺乏用于日志解析评估的基本标签。因此，我们研究的一个必要的初步步骤是对这些数据集进行注释。

注释过程由五名熟练的数据注释员组成的团队执行。这个团队由三名博士生组成，他们至少有两年的系统维护研究经验，还有两名行业工程师，他们都至少有五年的软件开发和管理经验。考虑到每个数据集的巨大规模(例如，数百万条日志消息)，手动标记每个日志消息是不可行的。因此，我们设计了严格的标注框架来辅助标注过程，通过日志分组和模板匹配来保证标注效率和准确性。

图1 数据注释的总体框架

图1显示了注释框架的概述，其中包括五个步骤:预处理、日志分组、模板注释、日志模板匹配和模板细化。首先，我们对原始日志进行预处理以获得有意义的日志内容。然后，我们通过层次聚类的方法将日志粗划分为不同的组。共享相同模板的日志很可能被划分到同一组中，从而促进了高效的注释过程。在每个组中，所有注释人员都仔细识别所有日志模板。在此过程中，我们按照字典顺序排列每组中的日志消息，以便将相似的日志消息放在一起，这使我们能够快速注释所有日志模板，而不是标记每个日志消息。在注释之后，我们使用正则表达式来构建日志消息与标记的日志模板之间的匹配。如果任何日志消息仍然不匹配，我们检查并纠正模板，随后重复匹配过程，直到所有日志消息都匹配。最后，我们对所有标注器的结果进行模板细化，以确保在所有标注器和数据集上标注的准确性和一致性。每个步骤的详细说明如下。

3.2、预处理

根据之前的工作[17,55,63]，我们首先应用预定义的正则表达式来提取日志消息的不同字段。典型的字段包括时间戳、日志级别、组件和内容。然后，我们对日志进行了清理。此过程专门针对内容不包含任何字母字符的日志，例如仅由数字数字或标点符号组成的日志。这些日志由于缺乏可解析的内容而被清除。我们还临时删除了包含重复内容的日志行，以减少以下步骤中的手工工作。

3.3、日志聚类

在预处理阶段之后，我们仍然面临着大量的日志消息(例如，HDFS数据集中有数百万条日志消息)，这使得手动注释每条消息变得不可行的。受[34]的启发，我们通过层次聚类的方法将日志消息粗略划分为多个组。我们的目标是将共享相同模板的日志消息划分在一起，这使我们能够一次标记它们的模板。为此，我们首先根据日志级别和组件名称对日志进行聚类，并在预处理步骤中提取日志。这两个属性提供了一种简单的方法来初始识别属于同一模板的日志[34]。其次，我们使用更高级的信息对日志进行分组，即日志消息中最频繁出现的令牌。具体来说，我们使用分隔符(如空格和标点符号)将每个日志消息标记为多个标记，并计算每个标记在数据集中出现的频率。对于每条日志消息，我们计算K个最频繁的令牌，然后将那些共享常见的前K个频繁令牌的日志消息分组在一起。其基本原理是日志消息的模板部分保持稳定，而参数部分可以在运行时动态更改。因此，日志消息中最常见的K个令牌可以有效地作为确定它们属于同一组的可靠证据。根据每个数据集的特征确定K的值，取值范围从1到3。特别是，我们维护了一个停止词的集合，将其排除在前k个频繁标记之外，以确保这些常用词不会干扰分组过程。除了Scipy库[2]提供的停止词外，我们还手动将某些词添加到集合中，如root、true等。最后，我们获得多个粗粒度的日志消息组，其中每个组中的日志消息共享相同的日志级别、组件和top-K令牌。

3.4、模板注释

模板注释的目标是通过手动注释来派生每个组的真实日志模板。为了加速手动注释过程，我们将每个组内的日志消息按字典顺序排序，以将相似的日志消息放在一起。然后，注释者可以快速识别基于它们的结构和相似性的日志模板。

因此，注释者只需要注释真实日志模板，消除了对每个日志消息进行顺序标记的需要。这种方法基于这样的观察：潜在的日志模板数量通常比日志消息的总数小几个数量级[25, 55, 63]，这使得手动标记成为一个可行的任务。具体来说，所有注释者独立进行手动注释过程，他们的个人结果将被整合以生成最终结果（将在第3.6节中详细说明）。

为确保注释的准确性和一致性，我们遵循Li等人[31]提出的参数类别来确定一个标记是否为参数。我们还要求注释者应用Khan等人[25]提出的相同启发式规则，以确保模板格式更加一致，例如，将双倍空格替换为单倍空格。如果一个标记被识别为参数，我们将用"<*>"替换它，静态部分保持不变，以形成相应的模板。由于相似的日志消息已经被分组并排序在一起，我们可以高效地绕过每个组中明显共享相同模板的众多日志消息，并且只记录已识别的模板。最后，在极少数不同组仍然共享相同模板的情况下，我们比较不同组派生的模板，消除重复的模板，并在必要时合并一些模板。这个过程可以消除日志分组步骤中的潜在错误，从而确保注释的准确性。

3.5、日志模板匹配

当我们在手动注释步骤中生成日志模板时，我们不记录每个日志消息与其相应模板之间的显式匹配。这是为了避免使注释过程复杂化，并且在以后可能的重复数据删除和合并过程中，它可能导致关系不明确，并在保持清晰度和准确性方面带来挑战。相反，我们使用正则表达式技术来自动构建日志和模板之间的匹配。

具体来说，我们通过用“(.*)”替换“<*>”将每个模板转换为正则表达式，这使得每个参数位置能够匹配任何长度的字符串。随后，对于每个日志消息，我们尝试将其与每个日志模板进行匹配，当找到匹配时停止。尽管此步骤需要在大量日志消息和日志模板之间进行配对匹配，但由于日志模板的数量通常远小于日志消息的总数(如表1所示)，因此可以在合理的时间内完成此步骤。我们还通过并行方式实现该匹配过程，从而进一步加快了此匹配过程。

此外，在此匹配过程中，一条日志消息可以匹配多个模板。例如，两个模板𝑇1:"auth failure;logname=<*> uid=<*> ruser=<*>" 和 𝑇2: "auth failure;Logname =<*> uid=<*>"可以存在于同一数据集中。从模板𝑇1生成的所有日志消息都可以与𝑇2匹配，因为最后一个<*>允许匹配多个令牌。为了解决这个问题，当日志消息匹配多个正则表达式时，我们优先考虑具有较长静态部分的模板进行注释。直觉是，当两个不同的模板能够匹配相同的日志消息时，能够匹配更多非“<*>”字符的模板表明该日志消息属于该特定模板的可能性更高。在很少的情况下，两者是相同的，我们选择“<*>”较少的模板，以生成更紧凑和简单的模板。通过应用此规则，𝑇1的日志消息将与𝑇1正确匹配。

在特定日志消息无法匹配任何正则表达式的情况下，我们将返回到模板注释步骤，仔细检查这些日志消息，进行必要的模板更正，然后重复匹配过程。最终，每个日志消息都应该成功匹配与其注释模板对应的一个正则表达式。

3.6、模板加密

最后一步是模板优化，其目的是整合所有五个注释器的结果并纠正潜在的错误。在仔细比较了五个注释者的模板后，我们确定了以下最常见的不一致情况。通过讨论解决所有差异，以确保注释的准确和统一。

•一个注释者可能比其他人产生更多的模板。在这种情况下，他的一些带注释的模板可能太具体了。例如，一些变量(例如，root/true/temp)被错误地识别为常量。然后，我们将这些情况作为如下[25]的参数。

•相同的模板可能有不同的格式，例如，““1165 bytes (1.13 KB) sent”可能被标记为“<*> bytes (<*> KB) sent”或" <*> bytes <*> sent "。在本例中，我们选择前者来保留日志消息的原始格式。

此外，我们定量评估了五个注释者的注释一致性。这是通过确定五个注释者的注释相同的模板的比例来衡量的。所有数据集的平均一致性得分达到0.926，表明标注步骤的一致性很高。最终，所有五个注释者就所有注释模板达成了共识，然后将其作为最终注释采用。

3.7、注释结果

表1 Loghub-2.0统计信息

数据注释过程最终生成来自不同系统的大型日志裁剪数据集集合，称为Loghub 2.0。Loghub 2.0的详细统计信息如表1所示。与Loghub-2k相比，带注释的日志消息的平均数量大幅增加，从2,000增加到3,601,187，增加了1875倍。此外，带注释的日志模板的平均数量增加了204.2%，从81.9个增加到249.1个，包含了更广泛的模板。大规模的新数据集集Loghub-2.0支持对日志解析技术进行详细的评估，有可能在更现实和大规模的场景中展示它们的性能。

四、研究方案设计

在本节中，我们将介绍日志解析器基准研究的设计。基于Loghub-2.0的大规模和多样性，我们的目标是更深入地了解日志解析器对实际应用程序的有效性和适用性。为此，我们首先设计了三个研究问题来指导研究。然后，我们为综合性能评估选择一组新的度量标准，其中包括我们设计的新的模板级度量标准和现有的流行度量标准。最后，我们详细说明了所选择的日志解析器的评估和实验设置。

4.1、研究课题

问题1: Loghub-2.0和Loghub2k之间有什么区别?在本问题中，我们的目标是探讨Loghub-2.0和Loghub-2k的特性是否存在显著差异，这些差异可能会影响日志解析器的性能。具体来说，我们将重点检查两个重要特征:日志模板的频率和日志模板中的参数计数。

问题2:与Loghub-2k相比，应用于Loghub-2.0的日志解析器的性能有何不同?在本问题中，我们的重点是对使用Loghub-2.0的日志解析器进行全面的重新评估，包括有效性和效率两个方面。我们还探讨了与广泛使用的Loghub-2k相关的任何潜在限制。为此，我们仔细比较了Loghub-2.0和Loghub-2k的评估结果，得出了深刻的结论。

问题3:日志解析器处理具有不同特征的日志时的性能如何?受第2.2节观察的启发，我们研究了日志解析器在不同模板频率和参数计数的日志上的性能。这是至关重要的，因为某些具有独特特征的日志在生产环境中可能非常重要。特别是，由于Loghub-2.0的大规模和多样性，只有使用标记的数据集才能进行这种评估。

4.2、评测指标

我们使用两类指标，即消息级和模板级指标来评估日志解析器。消息级度量说明属于每个模板的消息数量，因此支持日志消息量较大的模板。另一方面，模板级度量平均地考虑每个模板，而不管每个模板对应的日志消息的数量。在我们的基准协议中，我们采用了两个消息级指标，即Group Accuracy (GA)和Parsing Accuracy (PA)，以及两个模板级指标，即Group Accuracy (FGA)的F1-score和Template Accuracy (FTA)的F1-score[25]。其中，我们提出的FGA是GA的模板级版本。下面，我们将详细说明我们研究中使用的指标。

4.2.1消息级度量。

根据现有的研究，我们利用两个流行的消息级度量，即GA和PA。

组精度(Group Accuracy，GA)。GA首先由Zhu等人[63]使用，它评估了正确分组属于同一模板的日志消息的能力。它被定义为正确分组的日志消息与日志消息总数的比例。当且仅当日志消息的模板对应于与基本事实相同的日志消息集时，日志消息才被视为正确分组。

解析精度(Parsing Accuracy，PA)。Dai等人[9]使用的PA评估了正确提取每个日志消息的模板部分和参数部分的能力，这对于各种日志分析任务至关重要，例如使用参数值进行异常检测[12,22,26]。它被定义为正确解析的日志消息与日志消息总数的比率，其中当且仅当静态模板和动态变量的所有令牌都被正确识别时，才认为日志消息被正确解析。

4.2.2模板级指标。

尽管广泛使用消息级指标[31,57,58]，但它们考虑的是日志消息的数量，因此对模板不平衡很敏感。例如，在95%的日志消息只属于1%模板的数据集中，日志解析器可以通过对这1%的模板进行准确分组或解析来实现0.95的GA或PA，而不考虑其余99%模板的任何解析错误。在实践中，某些不经常出现的模板(如错误级别的日志消息)可能具有至关重要的意义，而经常出现的模板(如心跳消息)可能不那么重要。因此，不考虑每个模板的日志消息数量的模板级指标也应该被纳入，以全面评估日志解析器的性能。

组精度F1评分（F1-score of Group Accuracy，FGA）。我们提出FGA，它侧重于正确分组模板的比例，而不是日志消息。因此，它可以被认为是标准的计算GA的算法。具体来说，FGA是PGA (Precision of Group Accuracy)和RGA (Recall of Group Accuracy)的调和平均值（harmonic mean）。设预置 $N_{p}$ 为日志解析器生成的模板数量，预置 $N_{c}$ 为日志解析器正确解析的模板数量。这里的正确性与GA中的定义相同，即，当且仅当属于该模板的日志消息集与基本真理中指示的日志消息集匹配时，才认为日志模板被正确解析。在基本事实中，二进制操作的实际正确数目为:基于这些表示法，我们可以将PGA定义为: $\frac{N_{c}}{N_{p}}$ ，将RGA定义为: $\frac{N_{c}}{N_{g}}$ 。然后,我们可以计算FGA调和平均数,即 $\frac{2\times \textit{PGA} \times \textit{RGA}}{\textit{PGA} + \textit{RGA}}$ 。

模板精度F1评分(F1-score of Template Accuracy, FTA)。FTA是Khan等人[25]提出的RTA (Recall of Template Accuracy)和PTA (Precision of Template Accuracy)的调和平均值。FTA对“正确识别”的定义与FGA不同，并且我们定义了一个新的标记符 $\hat{N_{c}}$ 来表示被日志解析器正确识别的模板的数量。对于FTA，当且仅当以下两个条件成立时，一个模板被认为是正确识别的：（1）被解析模板对应的日志消息集共享相同的实际模板；（2）模板的所有令牌与基真模板的令牌相同。然后,我们可以定义PTA： $\hat{\frac{N_{c}}{N_{p}}}$ 和RTA： $\hat{\frac{N_{c}}{N_{g}}}$ 。和FTA可以计算调和平均数,即 $\frac{2\times \textit{PTA} \times \textit{RTA}}{\textit{PTA} + \textit{RTA}}$ 。与FGA相比，FTA更侧重于识别特定日志消息的具体常量和参数部分的能力。

4.3、评价设置

为了进行评估，我们从文献中仔细选择了15个最先进的日志解析器。Khan等人曾对其中13个进行过评估[25]。与他们的工作不同，我们将LKE[13]排除在我们的评估之外，这涉及到成对距离的计算，使得它在大规模场景中不切实际。这些日志解析器都是基于统计的，使用基于频率(即LFA[43]、LogCluster[54]、loggram[9]、SLCT[53])、相似性(即LenMa[51]、LogMine[16]、LogSig[52])和启发式(即AEL[24]、Drain[17]、IPLoM[39]、MoLFI[40]、SHISO[42]、Spell[11])的技术。在实现上，我们直接重用前人工作发布的源代码[25,63]。此外，我们还将两个基于语义的日志解析器UniParser[35]和LogPPT[28]纳入了我们的基准测试研究。我们按照相应论文中提供的细节实现了UniParser模型，并重用了LogPPT的源代码。

在我们的评估中，我们应用相同的预处理规则(例如，正则表达式)，并通过多次运行每个日志解析器来微调参数设置。对于由于固有随机性而在解析结果中表现出可变性的日志解析器，例如MoLFI和LogPPT，我们执行五次评估。通过报告中位数结果，我们的目标是减轻由这种随机性引起的潜在偏差，并对其性能进行更可靠的评估。所有实验都是在一台服务器上进行的，该服务器配备了英特尔(R) Xeon(R) Gold 6226R CPU @ 2.90GHz, 256GB RAM和NVIDIA GeForce GTX3090，运行Ubuntu 16.04.7 LTS。

五、实验结果

5.1、问题1: Loghub-2.0和Loghub-2k的区别

在本问题中，我们的目标是研究Loghub-2.0和Loghub-2k之间数据特征的差异。如表1所示，在日志消息和模板的大小方面，Loghub-2.0明显超过了Loghub-2k，平均消息多1900倍，模板多3倍。这一显著的增长可能意味着这两个数据集集合的特征分布存在显著差异。

正如第2.2节所讨论的，日志数据集有两个固有的关键特征:模板的频率和模板的参数计数。具体来说，日志模板的出现频率是指属于该日志模板的日志消息的数量。日志模板的参数计数是每个日志模板中不同动态部分的个数，即日志模板中“<*>”符号的个数。我们在Loghub-2k和Loghub2.0中计算了每个数据集这两个特征的分布，并绘制了相应的累积分布函数图。由于篇幅限制，我们在Loghub-2.0中只展示了三个代表性的数据集，即Spark、Linux和OpenSSH。所有14个数据集的图表都可以在我们的存储库中找到[1]。

图2 Loghub-2.0和Loghub-2k中模板频率和参数个数的分布比较

模板频率的分布。图2左侧的图描述了模板频率在三个数据集上的分布。一方面，Loghub-2.0的模板频率范围较宽，例如，在Loghub-2.0的Spark中，模板频率范围在1到 $10^{6}$ 以上，而在Loghub-2k中，模板频率范围较窄，范围在1到 $10^{3}$ 左右。另一方面，Loghub-2.0的长尾分布比Loghub-2k更明显，说明模板频率更不平衡。例如，在Loghub2.0的Spark数据集中，只有10%的模板频率超过104，但这几个模板构成了大部分日志。

模板参数计数的分布。图2右侧的三个图给出了模板参数个数的分布情况。我们可以观察到，Loghub-2.0涵盖了更广泛的模板，与Loghub-2k中的模板相比，每个模板都有更多的参数。例如，在Loghub-2k中，Spark的日志模板的最大参数数为3。然而，在Loghub-2.0的情况下，这个数字上升到24。在Linux和OpenSSH中也可以观察到类似的趋势，这表明Loghub-2.0具有更复杂的日志模板。这种复杂性对日志解析器在准确识别增加的参数数量方面提出了更大的挑战。

发现1。Loghub-2k和Loghub-2.0中日志模板频率和参数个数的分布存在显著差异。特别是，Loghub-2.0在模板频率方面表现出更明显的不平衡。此外，Loghub-2.0包含更多的模板，并且与Loghub-2k中的模板相比，每个模板平均具有更大的参数计数。

5.2、问题2：日志解析器在Loghub-2.0和Loghub-2k上的性能差异

考虑到在问题1中观察到的Loghub2k和Loghub-2.0之间的特征差异，这些差异对日志解析器性能的潜在影响仍然不清楚。为了解决这个问题，我们将选定的15个日志解析器应用于Loghub-2.0，并将其性能与Loghub-2k[25,63]在有效性和效率方面进行比较。具体来说，我们将第4.3节中描述的相同实验设置(例如，预处理和参数调优)应用于所有评估的日志解析器。为了评估其有效性，我们报告了Loghub-2.0和Loghub-2k的GA、PA、FGA和FTA等指标。此外，我们记录每个解析器的解析时间，这是从加载日志数据的开始到解析完成的时间。根据已有的工作[25,63]，我们将超时时间设置为12小时。如果解析器不能在此时间范围内完成对数据集的解析，我们将终止该过程并将其标记为“超时”。任何超过此时间限制的解析器都可能不适合在生产环境中实际部署，因为生产环境通常每天都要处理大量的日志数据[38,55,63]。由于篇幅限制，有兴趣的读者可以参考我们的知识库[1]获取更详细的评估结果。

图3 Loghub-2k和Loghub-2.0上所有日志解析器的评估结果

5.2.1有效性。

图3给出了一个框图，说明了在Loghub-2k和Loghub-2.0上所有日志解析器的有效性。每个方框以特定的度量标准封装了所有数据集的实验结果分布。此外，我们还在解析器名称旁边的括号中表示每个日志解析器可以在12小时内完成处理的数据集数量。

根据图3，我们可以观察到以下几点。(1)对于大多数日志解析器，无论是应用于Loghub-2k还是Loghub-2.0，平均FGA通常低于GA。这表明FGA是一个更严格的度量，因为它公平地对待所有类型的模板而不考虑它们的频率。(2)对比Loghub-2k和Loghub-2.0的GA和FGA，可以发现Loghub-2.0的FGA下降比Loghub2k更明显。例如，对于AEL, Loghub-2k上的平均GA和FGA之间的差异约为0.1。但是，在Loghub-2.0上，这个值大约升级到0.3。这表明Loghub-2.0中的模板分布比Loghub-2k更不平衡，这验证了我们在问题1中的发现。(3)同样，无论是在Loghub-2k还是在Loghub-2.0中，FTA也普遍低于PA，说明PA也以大班为主。

发现2。消息级指标(如GA和PA)通常比模板级指标(如FGA和FTA)产生更高的评估结果，因为它们对不平衡日志数据敏感。这些指标之间的差异在大规模的Loghub-2.0中更为明显，它显示出更大的不平衡。

此外，很明显，所有日志解析器跨所有指标的性能在Loghub-2k和Loghub-2.0之间存在显著差异。具体来说，(1)当将Loghub2k与更不平衡的Loghub-2.0进行比较时，我们通常会观察到大多数解析器(例如LenMA和LFA)的PA增加(例如AEL和Drain)而GA略有减少。这是因为GA要求对属于相同模板的日志消息进行精确分组，而PA是基于解析单个日志消息的准确性来计算的。在更大的Loghub-2.0中，准确分组的任务变得更具挑战性，这导致使用Loghub-2.0时PA显著增加，GA略有减少。(2)与在Loghub-2k上的性能相比，所有日志解析器在Loghub-2.0上的模板级指标都显着下降。例如，在Loghub-2k上达到最高FGA指标的《Drain》，其平均FGA得分从0.75降至约0.55。同样，LogPPT虽然在Loghub-2k上实现了最高的FTA，但其平均FTA从大约0.64降低到0.5。(3)此外，值得注意的是，对于大多数日志解析器(例如AEL、Drain、LenMa和LogMine)，这四个指标在不同数据集上的方差显著增加，在视觉上由箱形图的扩展范围表示。这意味着现有的解析器很难在不同的大规模系统中实现一致的有效性。

发现3。当日志解析器应用于大规模的Loghub-2.0时，在Loghub-2k上获得的评估结果并不一致。在Loghub-2.0上，现有解析器的性能下降，所有指标的方差增加。

此外，与Loghub-2k和Loghub-2.0数据集上的其他日志解析器相比，基于语义的日志解析器(如UniParser和LogPPT)始终显示出明显更高的PA和FTA分数。这表明语义信息有助于准确地识别单个日志消息的模板。但是，它们的GA和FGA分数通常低于其他日志解析器。这可归因于他们无视全球信息，如统计频率。因此，这些解析器更倾向于将来自相同模板的日志分类到不同的组中，从而导致较低的GA和FGA分数。此外，尽管基于语义的日志解析器在Loghub-2k上取得了不错的性能，但在应用于Loghub-2.0时，性能指标也会急剧下降。主要原因是Loghub-2k包含的日志消息和日志模板太少，这使得这些模型很容易了解整个数据集的特征。例如，在LogPPT中，用于调优的默认提示数是32，然而，Loghub-2k中的许多数据集的模板甚至少于32个，导致LogPPT在这些数据集上实现了近乎完美的准确性。相反，由于Loghub-2.0中的日志消息和日志模板的数量显著增加，因此这些模型很难基于有限的训练样本泛化到更多未见过的日志消息。

找到4。基于语义的日志解析器解析单个日志的能力更强，这可以从它们更高的PA和FTA中得到证明。然而，由于忽略了全局信息，它们表现出较低的分组相关指标。此外，在Loghub-2.0中，这些日志解析器的性能在更大、更多样化的数据集上可能会下降，特别是在可用于训练的带注释的样本数量有限的情况下。

5.2.2效率。

对于Loghub-2k，所有日志解析器都可以成功解析所有14个数据集。然而，当这些日志解析器应用于Loghub-2.0的更大规模数据集时，它们中的大多数(15个中的9个)无法在12小时内完成所有14个数据集的解析过程。由于空间限制，我们已经将每个解析器处理每个数据集的详细时间成本上传到我们的复制存储库[1]。如图3所示，只有6个解析器(即Drain、IPLoM、LFA、LogCluster、LogSig、UniParser和LogPPT)成功地完成了对Loghub-2.0的所有14个数据集的解析。某些解析器，如LenMa和LogMine，尽管表现出卓越的性能，但无法有效地处理更大的数据集。考虑到现实系统中对日志解析吞吐量的巨大需求，例如，每小时数百万条日志[55]，无法在合理的时间范围内(即12小时)完成解析过程的日志解析器在实际场景中的适用性可能有限。此外，像LogPPT这样基于语义的日志解析器需要GPU计算资源。当使用CPU进行计算时，与其他高效的基于统计的日志解析器(如Drain)相比，它们的时间消耗要高得多。这可能会阻碍它们在资源受限的情况下的采用。

发现5。15个日志解析器中有9个无法在合理的12小时内处理Loghub-2.0的所有15个数据集。此外，基于语义的方法通常比基于统计的解析器需要更多的计算资源

5.3、问题3:日志解析器对不同特征日志的性能

以前的研究[25,63]通常报告了日志解析器在整个完整数据集上的整体性能。然而，这可能不能完全描述它们在具有不同特征的日志上的有效性，特别是那些在实际系统维护中需要更多关注的日志。为了解决这一限制，我们的基准测试研究采用了一种更细粒度的方法，在具有不同特征的特定日志上评估日志解析器。我们主要关注模板频率和参数数的特性。具体来说，频率较低的日志模板通常表示罕见事件、隐藏问题和潜在故障。此外，参数越多的日志模板，对现场工程师分析的信息量越大。因此，准确解析这两种类型的日志消息至关重要。

为此，我们首先应用日志解析器来解析整个数据集。然后，我们选择具有不同特征的日志子集，并计算每个子集上的性能。这种方法确保每个解析器的输入数据与RQ2中的数据一致，而不是仅仅解析所选的日志子集。由于篇幅限制，我们只介绍能够解析Loghub-2.0中大多数数据集的五个具有代表性的日志解析器的结果。完整的结果可以在我们的存储库[1]中找到。

5.3.1不同模板频率下的性能。正如在RQ1中提到的，Loghub-2.0在模板频率上表现出更高的不平衡。考虑到日志解析器的数据驱动特性，它们的性能可能会受到影响。因此，我们通过查看相对不频繁和频繁的日志来研究模板频率的性能。特别是，我们以最高和最低k%的频率评估模板上的日志解析器，其中k分别设置为5、10和20。然后，我们报告这四个指标的平均分数。图4显示了k=10时的结果，k=5和20时的结果可以在我们的存储库[1]中找到。

如图4所示，所有日志解析器在频繁日志上的GA和FGA都比在不频繁日志上的GA和FGA差。以LogPPT为例，对于不频繁的模板，其GA和FGA得分接近0.95，而对于频繁的模板，GA和FGA得分低于0.5。我们对性能下降的解释如下。考虑到分组准确性要求解析器正确地对属于某个模板的所有日志进行分组，因此分组将变得更具挑战性，因为应该包含更多的日志消息。

相反，与频繁出现的日志模板相比，所有日志解析器对不频繁出现的日志模板的平均PA都较低。对于基于统计的日志解析器来说，这是意料之中的，因为模板出现的频率越低，为解析器提供的信息和证据(例如，静态令牌和动态令牌之间的计数差异)就越少，从而导致解析精度降低。对于基于语义的日志解析器，例如LogPPT，它通常需要日志样本进行训练，采样过程减少了选择不常用模板的可能性。这反过来又降低了与高频模板相比，不频繁模板的解析精度。

发现6。现有的日志解析器在处理不同频率的模板时表现出不同的有效性。对于频繁的模板，它们通常实现较低的GA和FGA，因为对于具有更多日志消息的模板，分组更具挑战性。此外，对于不常见的模板，它们实现了较低的PA和FTA，因为很少有证据(例如训练数据)可用于指导每个日志消息的准确解析。

5.3.2不同参数计数的性能。我们在RQ1中的研究表明，模板的参数计数可以在很大范围内变化(例如，Spark数据集的0到25)。因此，我们还评估了具有不同数量参数的模板的解析有效性。为了实现这一点，我们根据参数数将Loghub-2.0中每个数据集中的日志分为三类:没有参数的日志、有1到4个参数的日志和有5个或更多参数的日志。然后，我们在第5.3.1节中使用相同的方法分别计算每个类别上每个日志解析器的四个指标的平均值。

根据图5所示的结果，我们可以观察到，随着参数计数的增加，所有日志解析器在所有四个性能指标上都表现出明显的下降。更具体地说，这些解析器在没有参数的日志上表现得非常好，大大超过了它们在所有日志上的总体性能，如图3所示。例如，在没有参数的日志上，Drain在所有四个指标上的平均得分超过0.95，远远高于完整日志集的总体性能。当处理超过5个参数的日志时，所有日志解析器的性能都很差。例如，LogPPT的平均FGA只有0.16，而其他方法的平均FGA都不超过0.03。这表明，尽管许多日志解析器在整个数据集上表现出相对较高的性能，但它们在具有更多参数的日志上的性能仍然不能令人满意，这可能会导致实际应用程序中分散注意力的解析错误。

发现7。尽管日志解析器在整个数据集上取得了高分，但在处理参数密集型日志模板时，它们的解析效率仍然令人不满意。

5.4、所有研究问题总结

我们可以对所有研究问题做以下总结:(1)与常用的Loghub-2k相比，提出的用于日志解析的大规模数据集Loghub-2.0具有明显不同的日志数据特征。由于其更大的规模和更复杂的特性，Loghub-2.0对现有的日志解析器提出了更大的挑战。(2)我们的评估结果表明，Drain是性能最好的解析器，更有能力对日志消息进行分组，这一点可以从GA和FGA的最高平均水平得到证明。另一方面，基于语义的方法(例如UniParser和LogPPT)在区分每个令牌是常量部分还是动态部分方面表现出更强的能力。但是，这些方法在使用相同的模板对日志消息进行分组时影响了它们的有效性。这是因为令牌中的分类错误很容易导致不完整的组。(3)尽管在Loghub-2k中显示了令人鼓舞的结果，但在应用于Loghub-2.0时，解析性能仍然不令人满意。在解析不频繁的日志和参数密集的日志时，这一点尤其明显。(4)大多数日志解析器的效率无法满足大规模应用场景的需求。

6、讨论

6.1、影响

根据我们的发现，我们确定了以下含义，我们认为这些含义可能有助于未来对日志解析的研究。

综合考虑这两个级别的指标。虽然大多数现有任务利用消息级度量(如GA和PA)来评估性能，但这些度量通常由大规模应用程序场景中使用频率较高的日志模板主导，因此产生更高的分数。相比之下，模板级指标可以抵抗模板频率的不平衡，从而可以准确地反映具有不同模板分布的数据集的解析性能。因此，可以结合考虑这两种类型的度量，并且可以根据特定的需求对另一种进行优先级排序。例如，如果重点更多地放在频繁的日志模板的解析准确性上，并且可以容忍不频繁的模板中的错误，那么消息级度量更合适，反之亦然。

评估具有不同特征的日志的性能。尽管某些日志解析器在特定数据集上表现出了很高的整体性能，但在处理不频繁和参数密集的日志模板时，它们的解析性能仍然不足。考虑到这些日志的重要性(如2.2节所强调的)，重点关注这些日志中的性能是至关重要的。我们提出的评估协议可以更全面地挖掘日志解析器在这些日志模板上的性能。因此，未来的工作在设计新的日志解析器时应该注意这方面，从而增强它们在实际场景中的适用性。

更加注重效率。正如第5.2.2节所讨论的，许多现有的日志解析器不能满足大规模应用程序场景的性能要求，这一事实在Loghub-2k中没有得到体现。考虑到实际设置中的大量日志，未来的日志解析器必须设计成能够满足特定应用程序的性能需求。

试着把语义信息和统计信息结合起来。根据发现4，基于语义的日志解析器在区分参数和模板方面具有较强的能力，这也印证了语义信息在日志解析过程中的重要性。然而，由于忽视了全局信息，他们的分组能力受到了损害。这是不可避免的，因为这些日志解析器专门隔离地处理每个日志消息。未来研究的潜在途径可能包括将日志中的语义信息和统计信息结合起来，从而同时增强解析和分组能力。

6.2、有效性威胁

本研究的主要威胁是Loghub-2.0中潜在的注释错误，如果没有源代码，这是不可避免的。为了尽可能地缓解这个问题，我们设计了一个严格的注释框架，团队由五名在日志分析研究方面有丰富经验的成员组成。

有限的日志解析器日志解析器的选择是有限的，因为由于行业机密原因，并非所有现有的日志解析器都是开源的[55]。然而，所选的解析器包括在顶级会议上发布的最先进的日志解析器，并涵盖了所有现有的技术类别。此外，我们已经提供了我们的数据集，并以统一和用户友好的方式实现了我们的基准协议。这样就可以很容易地将额外的日志解析器与现有的日志解析器进行比较。

实现和设置为了减轻实现和设置的偏差，我们采用了来自广泛使用的基准[28,63]的几个日志解析器的源代码。对于新合并的日志解析器，我们要么使用原始作者提供的源代码，要么仔细复制它们以确保结果的保真度。此外，我们还调优了每个日志解析器的参数，以优化结果。

7、总结

在本文中，我们对日志解析技术进行了更严格和实用的大规模评估。提出了一种既高效又准确的日志模板注释框架，并对一组新的大规模数据集进行了注释，更准确地反映了真实情况下日志数据的规模和分布。我们提出的基准测试协议，包括一个新的模板级度量和对日志解析器对具有不同特征的日志的性能的评估，提供了对日志解析器性能的更全面和深入的分析。此外，我们使用Loghub-2.0对所选日志解析器进行了重新评估，发现了现有日志解析器和基准测试的局限性。我们相信，我们的工作，连同开源数据集Loghub-2.0和基准，可以有利于日志分析领域的未来研究。