日志自动分析和解析开源工具

淩亂°似流年 2023-06-23 10:56 220阅读 0赞

论文原文

[https://arxiv.org/pdf/1811.03509.pdf][https_arxiv.org_pdf_1811.03509.pdf]

翻译原文

[https://blog.csdn.net/arpospf/article/details/98795806][https_blog.csdn.net_arpospf_article_details_98795806]

GitHub

日志解析：[https://github.com/logpai/logparser][https_github.com_logpai_logparser]

# 自动日志分析的工具和基准 #

Abstract——在许多软件系统的开发和维护过程中，日志是必不可少的。它们记录了详细的运行时信息，允许开发人员和支持工程师监视系统并分析异常行为和错误。然而，随着现代软件系统的规模和复杂性的不断增加，日志的数量会急剧增加。在许多情况下，手工检查日志的传统方法变得不切实际。最近的许多研究，以及工业工具，都求助于强大的文本搜索和基于机器学习的分析解决方案。由于日志的非结构化特性，第一个关键步骤是将日志消息解析为结构化数据，以便进行后续分析。近年来，日志自动解析在学术界和工业界都得到了广泛的研究，通过不同的技术产生了一系列日志解析器。为了更好地理解这些日志解析器的特性，本文对自动日志解析进行了全面的评估研究，并进一步发布了易于重用的工具和基准。更具体地说，我们评估了分布系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件的16个日志数据集中的13个日志解析器。我们报告了基准测试结果的准确性、健壮性和效率，这些在生产环境中部署自动化日志解析时非常重要。我们还分享了华为在工业应用方面的成功经验和教训。我们相信，我们的工作可以作为基础，并为将来的自动日志解析的研究和部署提供有价值的指导。

1.引言

日志在软件系统的开发和维护过程中扮演着重要的角色。将详细的系统运行时信息记录到日志中是一种常见的做法，允许开发人员和支持工程师理解系统行为并跟踪可能出现的问题。日志的丰富信息和广泛性支持各种各样的系统管理和诊断任务，比如分析使用统计数据\[1\]、确保应用程序安全性\[2\]、识别性能异常\[3\]、\[4\]以及诊断错误和崩溃\[5\]、\[6\]。

尽管日志具有巨大的价值，但是如何有效地分析日志仍然是\[7\]面临的一大挑战。首先，现代软件系统通常会生成大量日志(例如，对于商业云应用程序\[8\]，大约每小时生成十亿字节的数据)。大量的日志使得手动检查日志消息以获取关键诊断信息变得不切实际，即使提供了搜索和grep实用程序。其次，日志消息本质上是非结构化的，因为开发人员通常使用灵活的文本格式记录系统事件，以方便和灵活地使用\[9\]。这进一步增加了自动分析日志数据的难度。许多最近的研究(例如，\[10\]-\[12\])以及工业解决方案(例如，Splunk\[13\]、ELK\[14\]、Logentries\[15\])已经发展为提供强大的文本搜索和基于机器学习的分析功能。要启用这种日志分析，第一步也是最重要的一步是日志解析\[9\]，这是一个将自由文本原始日志消息解析为结构化事件流的过程。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70][]

如图1所示，每个日志消息由一个日志语句打印，并记录一个特定的系统事件及其消息头和消息内容。消息头由日志框架决定，因此相对容易提取，例如时间戳、详细级别(例如，错误/信息/调试)和组件。相反，开发人员编写的自由文本消息内容通常很难结构化，因为它是由常量字符串和变量值组成的。常量部分显示日志消息的事件模板，并对每个事件的发生保持相同。变量部分携带感兴趣的动态运行时信息(即参数)，这些信息在不同的事件发生之间可能有所不同。日志解析的目标是将每个日志消息转换为与关键参数(例如，\[" blk\_-562725280853087685 "、" 67108864 "、" 10.251.91.84 ")相关联的特定事件模板(例如，" receive block <\*>， size <\*> from /<\*> ")。这里，“<\*>”表示每个参数的位置。

传统的日志解析方法依赖于手工编写的正则表达式或grok模式\[16\]来提取事件模板和关键参数。虽然很简单，但是手工编写专门的规则来解析大量日志确实是一项费时且容易出错的工作(例如，在我们的Android数据集中有超过76K个模板)。特别是，现代软件系统中的日志代码通常更新频繁(每个月多达数千条日志语句\[17\])，导致定期修改这些手工编写的解析规则的不可避免的成本。为了减少日志解析中的手工工作，一些研究\[18\]、\[19\]探索了直接从源代码中提取事件模板的静态分析技术。虽然在某些情况下这是一种可行的方法，但是在实践中并不总是可以访问源代码(例如，当使用第三方组件时)。同时，为跨不同编程语言开发的软件系统构建这样一个静态分析工具也需要付出不小的努力。

为了实现日志自动解析的目标，学术界和工业界提出了许多方法，包括频繁模式挖掘(SLCT\[20\]及其扩展LogCluster\[21\])、迭代分区(IPLoM\[22\])、层次聚类(LKE\[23\])、最长公共子序列计算(Spell\[24\])、解析树(Drain\[25\])等。与手工编写的规则和基于源代码的解析不同，这些方法能够从日志数据学习模式并自动生成公共事件模板。在我们之前的工作\[9\]中，我们对四个具有代表性的日志解析器进行了评估研究，并朝着可重复研究和用于自动日志解析的开源工具迈出了第一步。这在一定程度上促进了一些工具的最新开发，如LenMa\[26\]、LogMine\[27\]、拼写\[24\]、沥干\[25\]和MoLFI\[28\]。更重要的是，自动日志解析最近成为一些趋势日志管理解决方案(例如，Logentries\[15\]和Loggly\[29\])的一个吸引人的卖点。

在本文中，我们对自动日志解析进行了更全面的研究，并进一步向研究人员和实践人员发布了一整套工具和基准测试。实际上，由于机密问题，公司通常不愿意打开他们的系统日志，这导致了真实日志数据的稀缺。通过与我们的工业伙伴以及一些高级研究人员(来自\[10\]、\[18\]、\[30\]的作者)的密切合作，我们收集了16个不同系统生成的大量日志(总计超过77GB)，这些系统横跨分布式系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件。自从这些日志\[31\]首次发布以来，已经有超过150个来自业界和学术界的组织请求使用它们。

同时，缺少公开可用的工具阻碍了自动日志解析的采用。因此，我们发布了一个易于使用的开源工具包（https://github.com/logpai/logparser），其中包含13种最近发布的日志解析方法。我们对16个不同的日志数据集进行了全面的评估，并在准确性、鲁棒性和效率方面报告了结果。基准测试结果可以帮助用户更好地理解不同日志解析器的特性，并指导在生产环境中部署自动日志解析。我们还分享了华为在工业应用方面的成功经验和教训。我们相信，工具和基准的可用性，以及本研究中共享的行业经验，将有益于未来的研究，并有助于在行业中广泛采用自动化日志解析。

本文的其余部分组织如下。第二节回顾了最先进的日志解析器。第三节报告基准测试结果。我们在第四部分分享了我们的产业部署，并在第五部分总结了相关的工作。

2.日志解析

在本节中，我们将介绍一些激发日志解析的应用程序，回顾现有日志解析器的特性和技术，然后描述我们的工具实现。

**A.****有意义的应用场景**

日志解析通常作为后续日志分析任务的第一步。将文本日志消息解析为结构化格式可以有效地搜索、过滤、分组、计数和复杂的日志挖掘。为了说明这一点，我们在这里提供了一个示例工业应用程序列表，这些应用程序已被研究人员和实践者广泛研究。

•使用分析。在软件开发和维护过程中，使用日志进行使用分析是一项常见的任务。典型的例子包括用户行为分析(例如，API概要分析、基于日志的度量计数(例如，Google Cloud\[32\])和工作负载建模(例如，Microsoft\[33\])。这些应用程序通常需要结构化事件作为输入。

•异常检测。异常检测是当前系统监控的核心内容。日志记录了详细的执行信息，因此可以作为检测异常系统行为的有价值的数据源。最近的一些工作研究了使用机器学习技术(例如PCA\[18\]、不变挖掘\[34\]和深度学习\[10\])来检测异常。在这种情况下，日志解析是训练机器学习模型的必要数据预处理步骤。

•重复的问题识别。在实践中，系统问题(例如。，磁盘错误，网络断开)经常复发或可以重复报告由不同的用户，导致许多重复的问题。自动识别重复的问题对于减少开发人员和支持工程师的工作是至关重要的。微软已经报道了一些关于\[11\]、\[35\]、\[36\]任务的研究，其中需要结构化的事件数据。

•性能建模。Facebook最近报告了一个用例\[3\]，它将日志作为一个有价值的数据源应用到性能建模中，从而可以快速验证潜在的性能改进。此方法的先决条件是从日志中提取所有可能的事件模板。性能模型构建以事件序列作为输入。

•故障诊断。手工故障诊断是一项费时且具有挑战性的任务，因为日志不仅容量巨大，而且极其冗长和混乱。近年来\[4\]、\[37\]在基于机器学习技术的根源分析自动化方面取得了一定的进展。同样，日志解析被视为先决条件。

**B.****日志解析器的特性**

作为日志分析的一个重要步骤，日志分析的自动化方法得到了广泛的研究，产生了从研究原型到工业解决方案的大量日志解析器。为了全面了解现有的日志解析器，我们总结了它们的关键特性。

1)工业解决方案。表I提供了一些工业日志分析和管理工具的摘要。随着大数据的兴起，许多云提供商以及初创公司都提供了基于本地或SaaS (software-as-a-service, SaaS)的日志管理解决方案。它们支持强大的日志搜索、可视化和机器学习(ML)分析功能。为了说明这一点，我们列出了市场上具有代表性的10种产品，包括成熟的产品(如Splunk\[13\])和新推出的产品(如Logz.io\[38\])。作为一个关键组件，自动日志解析最近在一些产品\[39\]-\[41\]中成为一个吸引人的卖点。然而，自动日志解析的当前解决方案是通过对常见日志类型(如Apache和Nginx logs\[39\])的内置解析支持来实现的。对于其他类型的日志，它们必须依赖用户使用regex脚本、grok模式\[16\]或解析向导执行自定义解析。目前的工业解析解决方案需要较深的领域知识，超出了本研究的范围。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 1][]

**技术**。不同的日志解析器可能采用不同的日志解析策略。我们将它们分为7类策略，包括频繁模式挖掘、聚类、迭代划分、最长公共子序列、解析树、进化算法和其他启发式。我们将在II-C节中详细介绍这些日志解析方法。

**模式**。根据日志解析的不同场景，日志解析器可以分为两种主要模式，即，离线和在线。脱机日志解析器是一种批处理类型，要求在解析之前所有日志数据都可用。相反，在线日志解析器以流的方式逐个处理日志消息，当将日志收集为流时，这种方法通常更实用。

**效率**。在实际中，考虑到日志量很大，效率一直是日志解析的主要关注点。低效的日志解析器会极大地阻碍后续的日志分析任务，这些任务在实时异常检测和性能监视等情况下具有较低的延迟需求。表二将当前工具的效率分为三个层次:高、中、低。

**覆盖率**。覆盖率表示日志解析器成功解析所有输入日志消息的能力。如果是，则标记为“√”。“×”表示日志解析器只能结构化部分日志。例如，SLCT可以通过应用频繁模式挖掘来提取频繁发生的事件模板，但无法精确地处理罕见的事件模板。高质量的日志解析器应该能够处理所有输入的日志消息，因为忽略任何重要事件可能会错过异常检测和根本原因识别的机会。

**预处理**。预处理是通过手动指定简单正则表达式来删除一些常见的变量值，比如IP地址和数字。预处理步骤很简单，但是需要一些额外的手工工作。如果在日志解析方法中显式指定预处理步骤，则标记为“√”，否则标记为“×”。

**开源**。一个开源的日志解析器可以让研究人员和实践者方便地重用和进一步改进现有的日志解析方法。这不仅有利于相关的研究，而且有助于广泛采用自动日志解析。然而，目前用于日志解析的开源工具仍然有限。如果现有的日志解析器是开源的，我们标记“√”，否则标记“×”。

**工业应用**。日志解析器具有更大的实用价值，如果已经部署到生产环境中供工业使用，那么它应该更可靠。如果在工业场景中报告使用了日志解析器，则标记为“√”，否则标记为“×”。

**C.日志解析器技术**

在本文中，我们总共研究了13个日志解析器。从以下几个方面简要总结了这些日志解析器使用的技术:

1)频繁模式挖掘：频繁模式是数据集中频繁出现的一组项，同样，事件模板可以看作是日志中频繁出现的一组常量令牌。因此，频繁模式挖掘是自动日志解析的一种直接方法。例如SLCT\[20\]、LFA\[42\]和LogCluster\[21\]。所有这三个日志解析器都是脱机方法，并且遵循类似的解析过程:1)通过多个遍历遍历日志数据，2)在每次遍历时构建频繁项集(例如令牌、令牌位置对)，3)将日志消息分组到多个集群中，4)从每个集群中提取事件模板。据我们所知，SLCT是第一个将频繁模式挖掘应用于日志解析的工作。此外，LFA考虑每个日志消息中的令牌频率分布，而不是整个日志数据，以解析罕见的日志消息。LogCluster是SCLT的扩展，对令牌位置的移动具有健壮性。

2)聚类：事件模板形成一组日志消息的自然模式。从这个角度看，日志解析可以建模为日志消息的集群问题。应用聚类算法进行日志解析的例子包括3种离线方法(即LKE\[23\]、LogSig\[43\]、LogMine\[27\])和2种在线方法(即SHISO\[44\]和LenMa\[26\])。具体来说，LKE采用基于成对日志消息之间加权编辑距离的层次聚类算法。LogSig是一种基于消息签名的算法，用于将日志消息聚类到预定义的集群中。LogMine可以以分层集群的方式生成事件模板，将日志消息从下到上分组到集群中。SHISO和LenMa都是在线方法，它们以类似的流方式解析日志。对于每个新出现的日志消息，解析器首先计算其与现有日志集群的代表性事件模板的相似性。如果成功匹配，日志消息将被添加到现有集群中，否则将创建一个新的日志集群。然后，相应的事件模板将相应地更新。

3)启发式：与一般文本数据不同，日志消息具有一些独特的特征。因此，有些工作(即AEL\[45\]、IPLoM\[22\]、Drain\[25\])提出了基于启发式的日志解析方法。具体地说，通过比较常量令牌和变量令牌之间的出现情况，AEL将日志消息分成多个组。IPLoM采用迭代分区策略，根据消息长度、令牌位置和映射关系将日志消息划分为组。Drain应用固定深度树结构来表示日志消息，并有效地提取常见模板。这些启发式利用了日志的特性，在许多情况下都表现得很好。

4)其他：存在其他一些方法。例如，Spell\[24\]使用最长公共子序列算法以流的方式解析日志。最近，Messaoudi等人\[28\]提出了MoLFI，将日志解析建模为一个多目标优化问题，并用进化算法求解。

**D****.工具实现**

尽管自动日志解析技术已经研究了多年，但在业界仍未得到广泛的应用。这在很大程度上是由于缺乏可供工业使用的公开工具。对于通常在机器学习技术方面专业知识有限的操作工程师来说，实现自动化日志解析工具需要付出不小的努力。这可能会超过手工创建正则表达式的开销。我们的工作旨在弥合学术界和工业界之间的这种差距，并促进采用自动日志解析。我们实现了一个开源的日志解析工具包，即logparser，并发布了一个大型基准集。作为一个兼职项目，logparser的实现需要两年多的时间，并且使用Python编写了11.7K行代码。目前，logparser总共包含13种日志解析方法

由研究人员和实践者提出。其中，五个日志解析器(即， SLCT, LogCluster, LenMa, Drain, MoLFI)都是现有研究工作的开源软件。但是，它们是用不同的编程语言实现的，并且具有不同的输入/输出格式。一些例子和文件也丢失或不完整，这使得试验很困难。为了便于使用，我们为不同的日志解析方法定义了一个标准的、统一的输入/输出接口，并将现有的工具进一步封装到一个Python包中。Logparser需要一个带有自由文本日志消息的原始行日志文件作为输入，最后输出一个结构化日志文件和一个带有聚合事件计数的事件模板文件。输出可以很容易地输入到后续的日志挖掘任务中。我们的logparser工具包可以帮助工程师快速识别不同日志解析方法的优缺点，并评估它们在工业用例中的可能性。

3.评估

在本节中，我们将评估16个基准数据集上的13个日志解析器，并报告基准测试结果的准确性、健壮性和效率。在生产中应用日志解析时，它们是我们感兴趣的三个关键特性。

*  **精确度**度量日志解析器区分常量部分和变量部分的能力。准确性是现有日志解析研究的主要焦点之一，因为不准确的日志解析器会极大地限制下游日志挖掘任务\[9\]的效率。
 *  日志解析器的**健壮性**度量其准确性在不同大小或不同系统的日志数据集下的一致性。健壮的日志解析器应该跨不同的数据集执行一致的操作，因此可以在通用的生产环境中使用。
 *  **效率**度量日志解析器的处理速度。我们通过记录解析器解析特定数据集所需的时间来评估效率。日志解析器消耗的时间越少，它提供的效率就越高。

*A. **试验设置*

**数据集**。由于存在机密性问题，目前公开的真实日志数据很少，这阻碍了新的日志分析技术的研究和开发。在这项工作中，我们在loghub数据存储库\[31\]上发布了大量来自16个不同系统的日志，这些系统包括分布式系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件。表III显示了数据集的摘要。其中一些(如HDFS\[18\]、Hadoop\[11\]、BGL\[30\])是前期研究中发布的生产日志，而另一些(如Spark、Zookeeper、HealthApp、Android)则是从我们实验室的真实系统中收集的。Loghub包含4.4亿条日志消息，大小77GB。据我们所知，它是最大的日志数据集集合。在任何可能的情况下，日志都不会被清洗、匿名或以任何方式修改。它们可以免费用于研究目的。在撰写本文时，我们的loghub数据集已经被来自行业(35%)和学术界(65%)的150多个组织下载了1000多次。

在这项工作中，我们使用loghub数据集作为基准来评估所有现有的日志解析器。loghub数据集的大容量和多样性不仅可以测量日志解析器的精度，而且可以测试它们的鲁棒性和效率。为了方便复制基准测试结果，我们从每个数据集中随机抽取2000条日志消息，并手动将事件模板标记为ground truth。具体来说，在表III中，“\#Templates(2k sample)”表示日志样本中的事件模板数量，而“\#Templates (total)”则显示由基于规则的日志解析器生成的事件模板的总数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 2][]

**       精确度指标**。为了量化自动日志解析的有效性，就像使用\[24\]一样，我们将解析精确度(PA)指标定义为正确解析的日志消息占日志消息总数的比例。解析后，每个日志消息都有一个事件模板，该事件模板又对应于同一模板的一组消息。当且仅当日志消息的事件模板与基本事实所对应的同一组日志消息相对应时，日志消息才被认为是正确解析的。例如，如果将一个日志序列\[E1, E2, E2\]解析为\[E1, E4, E5\]，我们得到PA=1/3，因为第2和第3条消息没有分组在一起。与以往研究中使用的标准评估指标，如精度、召回率和F1-measure\[9\]、\[22\]、\[28\]相比，PA是一个更为严格的指标。在PA中，部分匹配的事件被认为是不正确的。

为了比较的公平性，我们对每个日志解析器应用相同的预处理规则(例如，IP或数字替换)。所有的日志解析器的参数都经过了超过10次的优化，并得到了最好的结果，避免了随机化带来的偏差。所有实验都是在一台安装了32个Intel(R) Xeon(R) 2.60GHz cpu、62GB RAM和Ubuntu 16.04.3 LTS的服务器上进行的。

*B.**日志解析器的准确性*

在这一部分中，我们评估了日志解析器的准确性。我们发现一些日志解析器(例如LKE)不能在合理的时间(例如，甚至几天)内处理原始数据集。因此，为了公平比较，对采样的子集进行了精度实验，每个子集包含2000条日志消息。日志消息从原始日志数据集中随机取样，但保留了关键属性，如事件冗余和事件多样性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 3][]

表Ⅳ给出了在16个日志数据集上评估的13个日志解析器的精度结果。具体来说，每一行表示一个数据集中不同日志解析器的解析精度，便于不同日志解析器之间的比较。每一列表示一个日志解析器在不同数据集上的解析精度，这有助于识别它在不同类型日志上的健壮性。特别地，我们在黑体字中标记了大于0.9的精度值，因为它们在实践中表明了较高的精度。对于每个数据集，使用星号“\*”突出显示最佳准确度，并在“best”列中显示。我们可以观察到，大多数数据集都被至少一个日志解析器精确地解析(超过90%)。总的来说，13个日志解析器中有8个在至少两个日志数据集上具有最佳精度。甚至，一些日志解析器可以100%准确地解析HDFS和Apache数据集。这是因为HDFS和Apache错误日志具有相对简单的事件模板，易于识别。然而，由于OpenStack、Linux、Mac、HealthApp等多种日志结构复杂、事件模板丰富(如Mac日志中的341个模板)，仍然无法准确解析。因此，应该进一步改进以更好地解析这些复杂的日志数据。

为了测量日志解析器的整体有效性，我们计算每个日志解析器在不同的数据集上的平均精确度，如表Ⅳ最后一行所示。我们可以观察到,平均而言,最准确的日志解析器是Drain,在16个数据集中的9个获得高精度。其他排名靠前的日志解析器包括IPLoM、AEL和Spell，它们在6个数据集上实现了很高的精度。相比之下，平均精度最低的四个日志解析器是LogSig、LFA、MoLFI和LKE。结果表明，日志解析器应充分利用日志消息的固有结构和特征，实现良好的解析精度，而不是直接应用聚类和频繁模式挖掘等标准算法。

*C.**日志解析器的鲁棒性*

健壮性对于在生产环境中实际使用日志解析器至关重要。在这一部分中，我们从两个方面来评估日志解析器的鲁棒性：1)对不同类型日志的鲁棒性;2)对不同日志卷的鲁棒性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 4][]

图2显示了一个箱形图，它表示每个日志解析器在16个日志数据集中的精度分布。对于每个框，从底部到顶部的水平线对应最小值、25-百分位数、中值、75-百分位数和最大精度值。钻石标记表示一个异常点，因为LenMa在HealthApp日志上的准确率只有0.174。图中从左到右，日志解析器按表Ⅳ平均精度的升序排列，即LogSig精度最低，Drain平均精度最高。一个好的日志解析器应该能够解析许多不同类型的日志以供一般使用。然而，我们可以观察到，尽管大多数日志解析器的最大精度超过0.9，但是它们在不同的数据集上有很大的差异。仍然没有对所有日志数据执行良好的日志解析器。因此，我们建议用户首先在自己的日志上尝试不同的日志解析器。目前，在所研究的13个日志解析器中，Drain的性能最好。该方法不仅平均精度最高，而且方差最小。

此外，我们还评估了日志解析器在不同日志卷上的鲁棒性。在本实验中，我们选择了六个日志解析器，即，MoLFI, Spell, LenMa, IPLoM, AEL，和Drain。同时，MoLFI是最新发布的日志解析器，其他5个日志解析器在图2中位于前五位。我们还选择了三个大型数据集，即、HDFS、BGL和Android。原始行日志的每个卷都超过1GB, groundtruth模板很容易用于精确计算。在以前的工作中，HDFS和BGL也被用作基准数据集\[22\]、\[24\]。对于每个日志数据集，我们将其容量从300 KB更改为1 GB，同时修复在2k日志样本上进行微调的日志解析器的参数。具体来说，300KB大约是每个2k日志样本的大小。我们截断原始行日志文件以获得其他卷的样本(例如，1GB)。图3显示了解析精度结果。注意图中的一些行是不完整的，因为像MoLFI和LenMa这样的方法不能在合理的时间内完成解析(在我们的实验中是6小时)。一个好的日志解析器应该对日志卷的这种变化具有健壮性。但是，我们可以看到，在小日志样本上调优的参数不能很好地适应大日志数据。所有六种性能最好的日志解析器的精度都有所下降，或者随着日志容量的增加而出现明显的波动。除IPLoM外，日志解析器在HDFS数据上相对稳定，准确率超过80%。在BGL数据上，Drain和AEL也表现出相对稳定的准确性。但是，对于Android数据，所有解析器的精度都有很大的下降，因为Android日志有大量的事件模板，而且解析起来更复杂。与其他日志解析器相比，Drain实现了相对稳定的精度，并且在改变日志量时表现出了鲁棒性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 5][]

*D.**日志解析器的效率*

为了处理大规模的日志数据，效率是日志解析器需要考虑的一个重要方面。为了度量日志解析器的效率，我们记录了它完成整个解析过程所需的运行时间。与前一个实验的设置类似，我们在三个日志数据集上评估了六个日志解析器。结果如图4所示。很明显，在所有三个数据集上，解析时间都随着日志大小的增加而增加。Drain和IPLoM具有较好的效率，随日志大小线性增长。这两种方法都可以在几十分钟内完成1GB的日志解析。除了在大的BGL数据上，AEL也表现得很好。这是因为AEL需要与bin中的每个日志消息进行比较，而当数据集较大时，BGL的bin大小较大。其他日志解析器不能很好地随日志量伸缩。特别是LenMa和MoLFI甚至无法在6小时内解析完1GB的BGL数据或Android数据。日志解析器的效率还取决于日志的类型。当日志数据简单且事件模板数量有限时，日志解析通常是一个有效的过程。例如，HDFS日志只包含30个事件模板，因此所有的日志解析器都可以在一个小时内处理1GB的数据。但是，对于具有大量事件模板(例如，Android)的日志，解析过程会变得很慢。

4.工业部署

在本节中，我们将分享在华为生产环境中部署自动日志解析的经验。System X(匿名)是华为最受欢迎的产品之一。日志是在整个产品生命周期中收集的，从开发、测试、beta测试到在线监视。它们被用作故障诊断、性能优化、用户分析、资源分配和其他一些用于提高产品质量的任务的主要数据源。当系统仍然处于小规模时，许多这些分析任务可以手工执行。然而，经过近年来的快速增长，System X现在每天产生超过TB的日志数据。对于工程师来说，手动检查日志以获取诊断信息变得不切实际，这不仅需要付出大量的努力，还需要对日志有深入的了解。在许多情况下，事件统计和相关性是帮助工程师做出明智决策的宝贵提示。

为了减少工程师的工作量，已经构建了一个平台(称为LogKit)来自动化日志分析过程，包括日志搜索、基于规则的诊断以及事件统计和关联的仪表板报告。该平台的一个关键特性是将日志解析为结构化数据。首先，通过编写正则表达式来匹配感兴趣的事件，以一种特殊的方式进行日志解析。然而，解析规则很快就变得不可管理。首先，现有的解析规则不能覆盖所有类型的日志，因为逐个编写解析规则是费时的。其次，System X发展迅速，导致日志结构频繁变化。维护这样一个用于日志解析的规则库已经成为一个新的难点。因此，自动日志解析是一个高需求。

**成功案例**。通过与产品团队的密切合作，我们成功地在生产环境中部署了自动日志解析。在对第三节中描述的不同日志解析器进行详细比较之后，我们选择了Drain，因为它在准确性、健壮性和效率方面具有优势。此外，利用X系统日志的特点，从以下几个方面对Drain方法进行了优化。1)预处理。System X的日志中包含了一万多个事件模板和各种参数。正如我们在\[9\]中所做的那样，我们应用一个简单但有效的预处理步骤来过滤常见参数，比如IP、包名、数字和文件路径。这大大简化了后续解析的问题。特别是一些预处理脚本是从已经可用的原始解析规则库中提取的。2)去重。许多日志消息只包含常量字符串，内部没有参数(例如,"VM已终止")。这些日志消息的重复出现导致日志中有大量重复的消息。与此同时，预处理步骤也会产生大量重复的日志消息(例如,"Connected to <IP>")，其中的公共参数已被删除。我们对这些重复的日志消息执行去重以减少数据大小，这显著提高了日志解析的效率。3)分区。日志消息头包含两个字段：详细级别和组件。事实上，不同级别或组件的日志消息总是由不同的日志语句(例如，DEBUG vs. INFO)。因此，根据级别和组件信息将日志消息划分为不同的组是有益的。这自然地将原始问题划分为独立的子问题。4)并行化。日志的分区不仅可以缩小事件模板的搜索空间，还可以实现并行化。特别是，我们使用Spark扩展了Drain，并自然地利用上面的日志数据分区来快速并行化。到目前为止，我们已经成功地在生产中运行了一年多的Drain，在System X中达到了90%以上的准确率。我们相信上述优化是通用的，可以很容易地扩展到其他类似的系统中。

**潜在的改进**。在Drain的工业部署过程中，我们注意到一些需要进一步改进的方向。1)状态识别。状态变量在日志分析中非常重要(例如,"DB连接ok"vs."DB连接错误")。但是，当前日志解析器无法将状态值与其他参数区分开来。2)处理长度可变的日志消息。单个日志语句可能产生长度可变的日志消息(例如，在打印列表时)。当前的日志解析器对长度敏感，无法处理这种情况，从而导致精度下降。3)参数自动调整。当前大多数日志解析器都使用数据驱动的方法来提取事件模板，并且需要手动调整一些模型参数。开发一种用于自动参数调优的机制是可取的。我们呼吁进行研究，以实现上述潜在的改进，这将有助于更好地采用自动日志解析。

5.相关工作

日志解析只是日志管理这个大问题的一小部分。在本节中，我们将从日志质量、日志解析和日志分析方面回顾相关工作。

**日志质量**。日志分析的有效性直接取决于日志质量。为了提高日志质量，近年来的研究重点是在开发过程中提供信息化的日志说明或有效的日志机制。Yuan等人\[46\]和Fu等人\[47\]分别报告了开源和工业系统中的日志实践。Zhu等人提出了LogAdvisor，这是一种基于分类的方法，可以对日志记录的位置提出建议。Zhao等人进一步提供了一个熵度量来确定具有控制流最大覆盖率的日志点。Yuan等人设计LogEnhancer来使用信息变量增强现有的日志语句。最近，He等人对日志语句的自然语言描述进行了实证研究。Ding等人\[52\]为有限开销的动态日志提供了一种经济有效的方法。

**日志解析**。日志解析近年来得到了广泛的研究，可分为基于规则的、基于源代码的和数据驱动的解析。目前大多数日志管理工具都支持基于规则的解析(例如，\[40\]、\[41\])。一些研究\[18\]、\[19\]使用静态分析技术进行基于源代码的解析。数据驱动的日志解析方法是本文的主要研究重点，其中大部分在第二节中进行了总结。最近，He等人通过Spark上的并行化研究了大规模日志解析。Thaler等人使用深度神经网络对文本日志消息进行建模。Gao等人使用优化算法从日志中发现多行结构。

**日志分析**。日志分析是一个具有重要现实意义的研究领域。日志分析有丰富的技术和应用。典型应用包括异常检测\[12\]、\[18\]、\[23\]、\[56\]、问题诊断\[4\]、\[5\]、运行时验证\[57\]、性能建模\[3\]等。为了解决日志分析所涉及的挑战，已经开发了许多数据分析技术。例如，Xu等人使用主成分分析(PCA)来识别异常问题。Du等人研究了利用深度学习对事件序列建模。Lin等人开发了一种聚类算法来对类似问题进行分组。我们在日志解析方面的工作是执行此类分析的基础，可以大大减少后续日志分析过程的工作量。

6.结论

日志解析在系统维护中扮演着重要的角色，因为它是实现自动化日志分析的第一步。近年来，许多研究致力于日志自动解析。但是，缺少公开可用的日志解析工具和基准数据集。在本文中，我们总共实现了13种日志解析方法，并对来自不同类型软件系统的16个日志数据集进行了评估。我们已经开放了工具包的源代码，并向研究人员和实践人员发布了基准数据集，以便于重用。此外，我们还分享了在华为部署自动日志解析时的成功案例和经验。我们希望我们的工作，连同已发布的工具和基准，能够促进更多关于日志分析的研究。

[https_arxiv.org_pdf_1811.03509.pdf]: https://arxiv.org/pdf/1811.03509.pdf
[https_blog.csdn.net_arpospf_article_details_98795806]: https://blog.csdn.net/arpospf/article/details/98795806
[https_github.com_logpai_logparser]: https://github.com/logpai/logparser
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191218165453690.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191218170001718.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191218170107197.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191218170154385.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20191218170216596.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20191218170244188.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzODczNDMx,size_16,color_FFFFFF,t_70