AIOps论文翻译：日志解析的一般方法
楔子
日常工作查找资料的过程中发现了2019年的一篇论文，对日志解析的工具和使用情况进行了详细的统计和对比，对于了解日志解析/模板提取领域有很大帮助，故此翻译论文如下。
摘要
在许多软件系统的开发和维护过程中，日志是必不可少的。它们记录详细的运行时信息，使开发人员和支持工程师能够监控他们的系统并剖析异常行为和错误。然而，现代软件系统日益扩大的规模和复杂性使得日志量呈爆炸式增长。
在许多情况下，传统的手动日志检查方式变得不切实际。许多最近的研究以及工业工具都求助于强大的文本搜索和基于机器学习的分析解决方案。由于日志的非结构化性质，第一个关键步骤是将日志消息解析为结构化数据以供后续分析。
近年来，自动化日志解析在学术界和工业界都得到了广泛的研究，产生了一系列不同技术的日志解析器。为了更好地理解这些日志解析器的特点，在本文中，我们对自动化日志解析进行了全面的评估研究，并进一步发布了工具和基准，以便于重用。
更具体地说，我们在跨越分布式系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件的总共 16 个日志数据集上评估了 13 个日志解析器。我们报告了准确性、稳健性和效率方面的基准测试结果，这在生产中部署自动日志解析时具有实际重要性。
我们还分享了华为在工业应用中的成功案例和经验教训。我们相信我们的工作可以作为基础，并为未来自动日志解析的研究和部署提供有价值的指导。
介绍
日志在软件系统的开发和维护中发挥着重要作用。将详细的系统运行时信息记录到日志中是一种常见的做法，目的是便于开发人员和支持工程师了解系统行为并跟踪可能出现的问题。 日志的丰富信息和普遍性支持各种系统管理和诊断任务，例如分析使用统计、确保应用程序安全、识别性能异常以及诊断错误和崩溃。
尽管日志中隐藏着巨大的价值，但如何有效地分析它们仍然是一个巨大的挑战。
首先，现代软件系统通常会生成大量日志（例如，商业云应用程序每小时大约产生千兆字节的数据 ）。即使是通过搜索和grep实用程序提供的帮助，手动检查大量的日志消息中的关键诊断信息也变得不切实际。其次，日志消息本质上是非结构化的，因为为了方便和灵活，开发人员通常使用自由文本记录系统事件 。这进一步增加了日志数据自动化分析的难度。
许多最近的研究（例如，工业解决方案（例如，Splunk 、ELK 、Logentries ）已经发展到提供强大的文本搜索和机器学习-基于分析能力。要启用此类日志分析，第一步也是最重要的一步是日志解析 [9]，这是一个将自由文本原始日志消息解析为结构化事件流的过程。
如图1所示的示例，每条日志消息都由日志语句打印，并记录特定的系统事件及其消息头和消息内容。消息头由日志框架确定，因此可以相对容易地提取，例如时间戳、详细级别（例如，ERROR/INFO/DEBUG）和组件。相比之下，开发人员编写的自由文本消息内容通常很难结构化，因为它是常量字符串和变量值的组合。
常量部分显示日志消息的事件模板，并且对于每个事件发生都保持不变。可变部分携带感兴趣的动态运行时信息（即参数），这些信息可能因不同的事件发生而异。
日志解析的目标是将每条日志消息转换为与关键参数相关联的特定事件模板（例如，“Received block <> of size <> from /<>”）（例如，[“blk_-562725280853087685”） ，“67108864”，“10.251.91.84”]）。这里，“<>”表示每个参数的位置。
传统的日志解析方式依赖于手工制作的正则表达式或 grok 模式 来提取事件模板和关键参数。虽然很简单，但手动编写临时规则来解析大量日志确实是一种耗时且容易出错的痛苦（例如，我们的 Android 数据集中超过 76K 的模板）。特别是，现代软件系统中的日志代码通常会频繁更新（每月多达数千条日志语句 ），导致定期修改这些手工解析规则的成本不可避免。
为了减少日志解析中的手动工作，一些研究探索了直接从源代码中提取事件模板的静态分析技术。虽然在某些情况下这是一种可行的方法，但在实践中并不总是可以访问源代码（例如，在使用第三方组件时）。同时，为跨不同编程语言开发的软件系统构建这样一个静态分析工具需要付出不小的努力。
为了实现自动日志解析的目标，学术界和工业界都提出了许多数据驱动的方法，包括频繁模式挖掘（SLCT [20] 及其扩展 LogCluster ）、迭代分区（IPLoM ） ，层次聚类（LKE ），最长公共子序列计算（Spell），解析树（Drain）等。与手工规则和基于源代码的解析相比，这些方法能够学习来自日志数据的模式并自动生成常见的事件模板。
在我们之前的工作中，我们对四个具有代表性的日志解析器进行了评估研究，并朝着可重现的研究和自动化日志解析的开源工具迈出了第一步。这在一定程度上促进了一些工具的最新发展，例如 LenMa、LogMine、Spell、Drain和 MoLFI。更重要的是，自动日志解析最近成为一些趋势日志管理解决方案（例如，Logentries 和 Loggly）中的一个吸引人的卖点。
在本文中，我们对自动日志解析进行了更全面的研究，并进一步向研究人员和从业者发布了一整套工具和基准。 在现实中，公司通常因为机密问题而不愿公开他们的系统日志，导致现实世界的日志数据稀缺。 通过与我们的行业合作伙伴以及一些先驱研究人员的密切合作，我们收集了由 16 个不同系统生成的大量日志（总共超过 77GB），这些系统跨越分布式 系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件。 自这些日志首次发布以来，来自工业界和学术界的 150 多个组织都要求使用它们。
同时，缺乏公开可用的工具阻碍了自动日志解析的采用。因此，我们发布了一个易于使用的开源工具包，其中包含最近发布的 13 种日志解析方法。我们在 16 个不同的日志数据集上对它们进行了彻底的评估，并在准确性、稳健性和效率方面报告了结果。基准测试结果可以帮助用户更好地了解不同日志解析器的特性，并指导自动化日志解析在生产中的部署。 我们还分享了华为在工业应用中的成功案例和经验教训。 我们相信，工具和基准的可用性，以及本研究中分享的行业经验，将有利于未来的研究，并促进自动化日志解析在行业中的广泛采用。
本文其余部分安排如下。 第二节回顾了最先进的日志解析器。 第三部分报告了基准测试结果。我们在第四节分享我们的工业部署，并在第五节总结相关工作。最后，我们在第六节总结论文。
日志解析
在本节中，我们将介绍一些具有启发性的日志解析应用程序，回顾现有日志解析器的特征和技术，然后描述我们的工具实现。
A.应用方向
日志解析
日志解析通常作为下游日志分析任务的第一步。 将文本日志消息解析为结构化格式可实现高效的日志搜索、过滤、分组、计数和复杂挖掘。 为了说明，我们在此处提供了一个示例工业应用列表，这些示例已被研究人员和从业者广泛研究。
使用分析
使用日志进行使用分析是软件开发和维护期间的常见任务。 典型示例包括用户行为分析（例如 Twitter）、API 分析、基于日志的指标计数（例如 Google Cloud ）和工作负载建模（例如 Microsoft）。这些应用程序通常需要结构化事件作为输入。
异常检测
如今，异常检测在系统监控中发挥着核心作用。日志记录了详细的执行信息，因此可作为检测异常系统行为的宝贵数据源。最近的一些工作研究了使用机器学习技术（例如，PCA 、不变挖掘和深度学习）进行异常检测。在这种情况下，日志解析是训练机器学习模型的必要数据预处理步骤。
重复的问题识别
在实践中，系统问题（例如，磁盘错误，网络断开）经常重复出现或可能被不同的用户重复报告，导致许多重复问题。自动识别重复问题以减少开发人员和支持工程师的工作量至关重要。微软报告了一些关于这项任务的研究，其中需要结构化的事件数据。
性能建模
Facebook 最近报告了一个用例，将日志作为有价值的数据源应用于性能建模，可以快速验证潜在的性能改进。这种方法的先决条件是从日志中提取所有可能的事件模板。性能模型构建将事件序列作为输入。
故障诊断
手动故障诊断是一项耗时且具有挑战性的任务，因为日志不仅数量庞大，而且非常冗长和混乱。最近的一些进展已经在基于机器学习技术的自动化根本原因分析方面取得了进展。同样，日志解析被视为先决条件。
B.日志解析的特点
作为日志分析的一个重要步骤，日志解析的自动化方法得到了广泛的研究，产生了大量的日志解析器，从研究原型到工业解决方案。为了概述现有的日志解析器，我们总结了它们的关键特征。
工业解决方案
表一提供了一些工业日志分析和管理工具的总结。随着大数据的兴起，许多云提供商以及初创公司都为日志管理提供本地或软件即服务 (SaaS) 解决方案。它们支持强大的日志搜索、可视化和机器学习 (ML) 分析功能。为了说明，我们列出了市场上的 10 种代表性产品，包括成熟的产品（例如 Splunk）和新启动的产品（例如 Logz.io）。
作为一个关键组件，自动日志解析最近已成为某些产品的一个吸引人的卖点。然而，当前自动日志解析的解决方案是通过对常见日志类型的内置解析支持来实现的，例如 Apache 和 Nginx 日志。对于其他类型的日志，他们必须依靠用户使用正则表达式脚本、grok 模式或解析向导执行自定义解析。当前的工业解析解决方案需要深厚的领域知识，因此超出了本研究的范围。
文献研究
表二总结了文献中提出的 13 个具有代表性的日志解析器，它们是我们研究的主要主题。这些日志解析器都针对自动日志解析，但质量可能不同。在回顾了文献之后，我们列出了日志解析器的一些具有实际重要性的关键特性。
策略
不同的日志解析器可能采用不同的日志解析策略。 我们将它们分为7种类型的策略，包括频繁模式挖掘、聚类、迭代划分、最长公共子序列、解析树、进化算法和其他启发式。 我们将在第 II-C 节中介绍这些日志解析方法的更多细节。
模式
根据日志解析的不同场景，日志解析器主要分为离线和在线两种模式。离线日志解析器是一种批处理，要求在解析之前所有日志数据都可用。相反，在线日志解析器以流的方式逐条处理日志消息，这在将日志收集为流时通常更实用。
效率
考虑到大量的日志，效率始终是实践中日志解析的主要关注点。在实时异常检测和性能监控等情况下，低效的日志解析器会极大地阻碍后续对延迟要求较低的日志分析任务。在表二中，当前工具的效率分为三个等级：高、中、低。
覆盖范围
覆盖率表示日志解析器成功解析所有输入日志消息的能力。如果是，则标记为“√”。 “×”表示日志解析器只能结构化部分日志。例如，SLCT可以通过应用频繁模式挖掘来提取频繁发生的事件模板，但无法精确处理稀有事件模板。高质量的日志解析器应该能够处理所有输入日志消息，因为忽略任何重要事件可能会错过异常检测和根本原因识别的机会。
预处理
预处理是通过手动指定简单的正则表达式来删除一些常见变量值（例如 IP 地址和数字）的步骤。预处理步骤很简单，但需要一些额外的手动工作。如果在日志解析方法中明确指定了预处理步骤我们标记“√”，除此以外标记为“×”。
开源
开源日志解析器可以让研究人员和从业者轻松重用和进一步改进现有的日志解析方法。这不仅可以有益于相关研究，还可以促进自动日志解析的广泛采用。但是，当前用于日志解析的开源工具仍然有限。如果现有的日志解析器是开源的我们标记“√”，除此以外标记为“×”。
工业用途
日志解析器具有更多的实用价值，如果它已部署在生产中以供工业使用，则应该更可靠。如果已报告日志解析器在工业环境中使用我们标记“√”，除此以外标记为“×”。
C.日志解析的策略
频繁模式挖掘
频繁模式是数据集中频繁出现的一组项目。同样，事件模板可以看作是日志中经常出现的一组常量标记。因此，频繁模式挖掘是自动化日志解析的一种直接方法。 示例包括 SLCT、LFA和 LogCluster。 所有三个日志解析器都是离线方法并遵循类似的解析过程：
1）通过多次遍历日志数据，
2）在每次遍历时构建频繁项集（例如，频繁项，频繁项位置对），
3）对日志消息进行分组分成几个集群
- 从每个集群中提取事件模板。
据我们所知，SLCT 是第一个将频繁模式挖掘应用于日志解析的工作。此外，LFA考虑每个日志消息中的频繁项频率分布而不是整个日志数据来解析罕见的日志消息。LogCluster 是 SCLT 的扩展，并且可以对频繁项位置的变化具有鲁棒性。
聚类
事件模板形成一组日志消息的自然模式。从这个角度来看，日志解析可以建模为日志消息的聚类问题。将聚类算法应用于日志解析的示例包括3种离线方法（即LKE、LogSig 和 LogMine）和 2 种在线方法（即 SHISO和 LenMa）.
具体来说，LKE 采用基于成对日志消息之间的加权编辑距离的层次聚类算法。LogSig 是一种基于消息签名的算法，用于将日志消息聚集到预定义数量的簇中。LogMine 可以通过分层集群的方式生成事件模板，将日志消息从下到上分组到集群中。 SHISO 和 LenMa 都是在线方法，它们以类似的流式方式解析日志。对于每个新出现的日志消息，解析器首先计算其与现有日志集群的代表性事件模板的相似性。如果匹配成功，则将日志消息添加到现有集群中，否则将创建新的日志集群。然后，相应的事件模板将相应更新。
启发式
不同于一般的文本数据，日志消息有一些独特的特点。因此，一些工作（即 AEL、IPLoM、Drain）提出了基于启发式的日志解析方法。具体来说，AEL 通过比较常量标记和可变标记之间的出现将日志消息分成多个组。IPLoM 采用迭代分区策略，根据消息长度、频繁项位置和映射关系将日志消息划分为组。Drain 采用固定深度的树形结构来表示日志消息并有效地提取常用模板。这些启发式方法利用了日志的特性，在很多情况下都表现得很好。
其他
存在其他一些方法。例如，Spell利用最长公共子序列算法以流的方式解析日志。最近，Messaoudi 等人提出 MoLFI，它将日志解析建模为一个多目标优化问题，并使用进化算法解决它。
D.策略实现
尽管自动日志解析已经研究了几年，但它仍然不是工业界普遍接受的技术。这主要是由于缺乏可用于工业用途的公开可用工具。对于在机器学习技术方面的专业知识通常有限的运维工程师来说，实施自动化日志解析工具需要付出不小的努力。这可能会超过手动制作正则表达式的开销。
我们的工作旨在弥合学术界和工业界之间的差距，并促进采用自动化日志解析。我们已经实现了一个开源日志解析工具包，即 logparser，并发布了一个大型基准测试集。作为一个兼职项目，logparser 的实现耗时两年多，在 Python 中有11.7K LOC。目前，logparser 包含研究人员和从业者提出的总共 13 种日志解析方法。其中，五个日志解析器（即 SLCT、LogCluster、LenMa、Drain、MoLFI）是从现有研究工作中开源的。但是，它们以不同的编程语言实现，并具有不同的输入/输出格式。示例和文件也缺失或不完整，给审判带来困难。
为了方便使用，我们为不同的日志解析方法定义了一个标准统一的输入/输出接口，并将现有的工具进一步包装到一个单独的 Python 包中。Logparser 需要一个带有自由文本日志消息的原始日志文件作为输入，最后输出一个结构化日志文件和一个带有聚合事件计数的事件模板文件。输出可以很容易地输入到后续的日志挖掘任务中。我们的 logparser 工具包可以帮助工程师快速识别不同日志解析方法的优缺点，并评估它们在工业用例中的可能性。
评估
在本节中，我们在16个基准数据集上评估了13个日志解析器，并报告了准确性、稳健性和效率方面的基准测试结果。 在生产中应用日志解析时，它们是三个令人感兴趣的关键品质。
准确度衡量日志解析器区分常量部分和可变部分的能力。准确性是现有日志解析研究的主要焦点之一，因为不准确的日志解析器可能会极大地限制下游日志挖掘任务的有效性。
鲁棒性，日志解析器的鲁棒性衡量其在不同大小或来自不同系统的日志数据集下的准确性的一致性。 一个健壮的日志解析器应该在不同的数据集上一致地执行，因此可以在通用的生产环境中使用。
效率衡量日志解析器的处理速度。我们通过记录解析器解析特定数据集所花费的时间来评估效率。日志解析器消耗的时间越少，它提供的效率就越高。
A.建立实验
数据集。由于机密问题，现实世界的日志数据目前公开稀缺，这阻碍了新的日志分析技术的研究和开发。在这项工作中，我们在我们的 loghub 数据存储库上发布了来自16个不同系统的大量日志集合，这些系统涵盖分布式系统、超级计算机、操作系统、移动系统、服务器应用程序和独立软件。表 III 提供了数据集的摘要。其中一些（例如，HDFS 、Hadoop、BGL）是先前研究发布的生产日志，而其他（例如，Spark、Zookeeper、HealthApp、Android）是从现实世界的系统中收集的我们的实验室。 Loghub 总共包含 4.4 亿条日志消息，大小为 77 GB。据我们所知，它是最大的日志数据集集合。在可能的情况下，不会以任何方式对日志进行清理、匿名或修改。它们可免费用于研究目的。在撰写本文时，我们的 loghub 数据集已被来自行业 (35%) 和学术界 (65%) 的 150 多个组织下载超过 1000 次。
在这项工作中，我们使用 loghub 数据集作为基准来评估所有现有的日志解析器。 loghub 数据集的庞大规模和多样性不仅可以衡量日志解析器的准确性，还可以测试它们的鲁棒性和效率。为了便于重现基准测试结果，我们从每个数据集中随机抽取 2000 条日志消息，并手动将事件模板标记为基本事实。具体而言，在表 III 中，“#Templates (2k sample)”表示日志样本中的事件模板数，而“#Templates(total)”表示基于规则的日志解析器生成的事件模板总数。
准确度指标。为了量化自动日志解析的有效性，我们将解析精度 (PA) 指标定义为正确解析的日志消息与日志消息总数的比率。解析后，每条日志消息都有一个事件模板，该模板依次对应同一模板的一组消息。当且仅当其事件模板对应于与基本事实相同的日志消息组时，才认为日志消息已正确解析。例如，如果将日志序列 [E1, E2, E2] 解析为 [E1, E4, E5]，我们得到 PA=1/3，因为第 2 条和第 3 条消息没有组合在一起。与先前研究中使用的标准评估指标（例如精度、召回率和 F1-measure）相比，PA是一个更严格的指标。在PA中，部分匹配的事件被认为是不正确的。
B.日志解析器的准确性
在这一部分中，我们评估日志解析器的准确性。我们发现一些日志解析器（例如，LKE）无法在合理的时间内（例如，甚至几天）处理原始数据集。因此，为了公平比较，准确性实验是在采样子集上进行的，每个子集包含 2,000 条日志消息。日志消息是从原始日志数据集中随机抽取的，但保留了关键属性，例如事件冗余和事件多样性。
表 IV 展示了在 16 个日志数据集上评估的 13 个日志解析器的准确度结果。具体来说，每一行表示不同日志解析器在一个数据集上的解析精度，便于不同日志解析器之间的比较。每列代表一个日志解析器对不同数据集的解析精度，这有助于识别其在不同类型日志中的稳健性。特别是，我们用粗体标记了大于 0.9 的精度值，因为它们在实践中表示高精度。对于每个数据集，最佳准确度用星号“*”突出显示，并显示在“最佳”列中。
我们可以观察到，大多数数据集都被至少一个日志解析器准确（超过 90%）解析。总共13个日志解析器中有8个在至少两个日志数据集上达到了最佳精度。更重要的是，一些日志解析器可以 100% 准确地解析 HDFS 和 Apache 数据集。这是因为 HDFS 和 Apache 错误日志的事件模板相对简单，易于识别。然而，由于结构复杂、事件模板丰富（例如，Mac 日志中的 341 个模板），几种类型的日志（例如，OpenStack、Linux、Mac、HealthApp）仍然无法准确解析。因此，应该进一步改进以更好地解析那些复杂的日志数据。
为了衡量日志解析器的整体有效性，我们计算了每个日志解析器在不同数据集上的平均准确度，如表 IV 的最后一行所示。 我们可以观察到，平均而言，最准确的日志解析器是Drain，它在16个数据集中的9个数据集上达到了高精度。 其他排名靠前的日志解析器包括 IPLoM、AEL 和 Spell，它们在6个数据集上实现了高精度。相比之下，平均准确率最低的四个日志解析器是 LogSig、LFA、MoLFI 和 LKE。从结果可以简单得出结论，日志解析器应该充分利用日志消息的固有结构和特性来实现良好的解析精度，而不是直接应用聚类和频繁模式挖掘等标准算法。
C.日志解析器的健壮性
图2显示了一个箱线图，指示每个日志解析器在16个日志数据集中的准确度分布。对于每个框，从底部到顶部的水平线对应于最小值、25%、中值、75% 和最大精度值。菱形标记表示异常点，因为 LenMa 在 HealthApp 日志上的准确度仅为 0.174。图中从左到右，日志解析器按平均准确率升序排列，如表 IV 所示。
也就是说，平均而言，LogSig 的准确度最低，而 Drain 的准确度最高。一个好的日志解析器应该能够解析许多不同类型的日志以供一般使用。然而，我们可以观察到，尽管大多数日志解析器的最大准确度都超过了 0.9，但它们在不同的数据集上存在很大的差异。仍然没有对所有日志数据都表现良好的日志解析器。因此，我们建议用户先在自己的日志上尝试不同的日志解析器。
目前，Drain在所有13个正在研究的日志解析器中表现最好。它不仅平均达到最高的准确率，而且显示出最小的方差。
此外，我们评估了日志解析器在不同日志量上的鲁棒性。在本实验中，我们选择了六个日志解析器，即 MoLFI、Spell、LenMa、IPLoM、AEL 和 Drain。他们在四个以上的日志数据集上实现了高精度（超过 90%），如表 IV 所示。同时，MoLFI 是最近发布的日志解析器，其他五个日志解析器在图 2 中排名靠前。我们还选择了三个大型数据集，即 HDFS、BGL 和 Android。每个原始日志的容量超过 1GB，并且可以很容易地使用 groundtruth 模板进行准确度计算。HDFS 和 BGL 在之前的工作中也被用作基准数据集。对于每个日志数据集，我们将容量从 300 KB 更改为 1 GB，同时修复了在 2k 日志样本上微调的日志解析器的参数。
具体来说，300KB 大约是每个 2k 日志样本的大小。我们截断原始日志文件以获取其他卷的样本（例如 1GB）。图 3 显示了解析精度结果。请注意，图中有些行是不完整的，因为像 MoLFI 和 LenMa 这样的方法无法在合理的时间内（我们的实验中为 6 小时）完成解析。一个好的日志解析器应该对日志卷的这种变化具有鲁棒性。但是，我们可以看到在小日志样本上调整的参数不能很好地适应大日志数据。随着日志量的增加，所有六个性能最佳的日志解析器的准确性都有所下降或显示出明显的波动。除 IPLoM 外，日志解析器在 HDFS 数据上相对稳定，准确率达到 80% 以上。
Drain 和 AEL 在 BGL 数据上也显示出相对稳定的精度。然而，在Android数据上，所有解析器的准确性都有很大的下降，因为Android日志的事件模板数量相当多，解析起来也比较复杂。与其他日志解析器相比，Drain实现了相对稳定的精度，并且在更改日志量时显示了其鲁棒性。
D.日志解析器的效率
为了处理大规模的日志数据，效率是日志解析器需要考虑的一个重要方面。为了衡量日志解析器的效率，我们记录了它完成整个解析过程所需的运行时间。与之前实验的设置类似，我们在三个日志数据集上评估六个日志解析器。
结果如图 4 所示。很明显，解析时间随着所有三个数据集上日志大小的增加而增加。Drain 和 IPLoM 具有更好的效率，它与日志大小成线性关系。两种方法都可以在几十分钟内完成对 1GB 日志的解析。除了大型 BGL 数据外，AEL 也表现良好。这是因为 AEL 需要与 bin 中的每条日志消息进行比较，而 BGL 在数据集较大时具有较大的 bin 大小。其他日志解析器不能很好地适应日志量。尤其是 LenMa 和 MoLFI 甚至无法在 6 小时内完成解析 1GB 的 BGL 数据或 Android 数据。日志解析器的效率还取决于日志的类型。当日志数据简单且事件模板数量有限时，日志解析通常是一个高效的过程。例如，HDFS 日志仅包含 30 个事件模板，因此所有日志解析器可以在一个小时内处理 1GB 的数据。但是，对于具有大量事件模板（例如，Android）的日志，解析过程会变慢。
工业部署
在本节中，我们将分享我们在华为在生产环境中部署自动化日志解析的经验。 System X（匿名名称）是华为的热门产品之一。在整个产品生命周期中收集日志，从开发、测试、beta 测试到在线监控。它们被用作故障诊断、性能优化、用户分析、资源分配和其他一些提高产品质量的任务的主要数据源。当系统还处于小规模时，这些分析任务中的许多都可以手动执行。 然而，经过近年来的快速增长，如今的 System X 每天产生超过 TB 的日志数据。工程师手动检查日志以获取诊断信息变得不切实际，这不仅需要付出不小的努力，还需要对日志有深入的了解。在许多情况下，事件统计和相关性是帮助工程师做出明智决策的宝贵提示。
为了减少工程师的工作量，我们构建了一个平台（称为 LogKit）来自动化日志分析过程，包括日志搜索、基于规则的诊断以及事件统计和相关性的仪表板报告。该平台的一个关键特性是将日志解析为结构化数据。起初，日志解析是通过编写正则表达式来匹配感兴趣的事件以一种特别的方式完成的。但是，解析规则很快变得难以管理。首先，现有的解析规则不能涵盖所有类型的日志，因为要一个一个地编写解析规则是很耗时的。其次，System X 发展迅速，导致日志结构频繁变化。维护这样的日志解析规则库成为了新的痛点。因此，对自动日志解析的需求很高。
成功的例子
通过与产品团队的密切合作，我们在生产环境中成功部署了自动化日志解析。 在第三节中描述的不同日志解析器的详细比较之后，我们选择Drain是因为它在准确性、鲁棒性和效率方面的优势。另外，利用System X的日志特性，我们从以下几个方面对Drain方式进行了优化。
1）预处理。 System X 的日志拥有上万个事件模板以及广泛的参数。正如我们在 [9] 中所做的那样，我们应用了一个简单而有效的预处理步骤来过滤常见参数，例如 IP、包名称、编号和文件路径。这大大简化了后续解析的问题。特别是，一些预处理脚本是从已经可用的原始解析规则库中提取的。
2) 重复数据删除。许多日志消息仅包含常量字符串，内部没有参数（例如，“VM 已终止。”）。这些日志消息的重复出现会导致日志中出现大量重复消息。同时，预处理步骤也会产生大量重复的日志消息（例如，“Connected to
3) 分区。日志消息头包含两个字段：详细级别和组件。事实上，不同级别或组件的日志消息总是由不同的日志语句打印（例如，DEBUG 与 INFO）。因此，根据级别和组件信息将日志消息划分为不同的组是有益的。这自然将原始问题划分为独立的子问题。
4）并行化。日志的分区不仅可以缩小事件模板的搜索空间，还可以实现并行化。特别是，我们使用 Spark 扩展 Drain，并自然地利用上述日志数据分区来实现快速并行化。到目前为止，我们已经在生产环境中成功运行Drain一年多，在 System X 中达到了 90% 以上的准确率。我们相信上述优化是通用的，也可以很容易地扩展到其他类似的系统。
改进方向
在 Drain 的工业部署过程中，我们观察到了一些需要进一步改进的方向。
1) 状态识别。状态变量在日志分析中非常重要（例如，“DB connection ok”与“DB connection error”）。但是，当前的日志解析器无法将状态值与其他参数区分开来。
2) 处理可变长度的日志消息。单个日志语句可能会产生长度可变的日志消息（例如，在打印列表时）。当前的日志解析器对长度敏感，无法处理这种情况，从而导致准确性下降。
3) 自动参数调整。当前大多数日志解析器应用数据驱动的方法来提取事件模板，并且一些模型参数需要手动调整。需要开发一种用于自动参数调整的机制。我们呼吁进行研究以实现上述潜在改进，这将有助于更好地采用自动日志解析。
相关工作
略（此处主要说明了论文的人员贡献）
结论
日志解析在系统维护中扮演着重要的角色，因为它是自动化日志分析的第一步。近年来，许多研究工作都致力于自动日志解析。但是，缺乏公开可用的日志解析工具和基准数据集。在本文中，我们总共实现了 13 种日志解析方法，并在来自不同类型软件系统的16个日志数据集上对它们进行了评估。我们已经开源了我们的工具包，并向研究人员和实践发布了基准数据集，以便于重用。此外，我们分享了在华为部署自动日志解析的成功案例和经验。我们希望我们的工作，连同发布的工具和基准，可以促进对日志分析的更多研究。
文末
本文翻译自论文《Tools and Benchmarks for Automated Log Parsing》，作者：Jieming Zhu, Shilin He, Jinyang Liu, Pinjia He, Qi Xie, Zibin Zheng, [Michael R. Lyu]等。相关引用在翻译过程中取消了，引用部分和更多参考请查阅论文原文。
如有错漏和不通顺的地方或者感兴趣的地方欢迎在评论区提出。
如有侵权，还请联系我删除，本文目的旨在技术分享。
浙公网安备 33010602011771号