每秒处理超22W条日志！云服务中的高效、自适应日志解析框架 ByteBrain-LogParser

点击上方👆蓝字关注我们！

本文介绍我们即将发表于 SIGMOD'25 的研究成果——ByteBrain-LogParser，一个为云服务环境量身定制的日志解析框架。论文地址：https://arxiv.org/abs/2504.09113

ByteBrain-LogParser 能够高效地将非结构化日志文本解析为动态精细度的日志模版和变量，同时解决了云环境中日志解析面临的四大挑战：适应性、计算效率、存储效率和解析准确性。通过创新的位置相似度度量、饱和度评分机制和高效哈希编码，ByteBrain 实现了比现有最先进方法快 1-2 个数量级的解析速度，同时保持接近的准确率。在公开基准测试中，ByteBrain 每秒可处理超过 22 万条日志，比最快的基线方法快 8 倍多。更重要的是，ByteBrain 支持实时精度调整，使用户能够根据具体分析需求动态平衡解析精度和效率，无需重新处理原始日志。

ByteBrain-Log Parser 已部署于火山引擎日志服务（TLS），为用户提供开箱即用的自动化日志解析能力。

和相关工作对比，ByteBrain-LogParser 同时实现了极高的解析速度（throughput）和接近 SOTA 的准确率（accuracy）

背景：云服务中的日志解析

日志解析（Log Parsing）：将非结构化的日志文本解析为结构化的模板和变量

随着现代系统的复杂性不断增加，服务可靠性工程师（SRE）和值班工程师（Oncall Engineer）在处理海量非结构化日志时面临严峻挑战。这一困境源于大规模分布式系统中众多组件产生的格式各异、数量庞大的日志数据。在这种情况下，日志解析成为解决此类问题的关键技术手段。

日志的生成过程通常是程序通过打印格式化语句实现的，每条日志本质上由格式模板（format template）和变量值（variable values）组成。例如，一条日志 Connection from 192.168.1.1 failed after 30 seconds 实际上是由模板 Connection from <IP> failed after <TIME> seconds 和变量值"192.168.1.1"、"30"组成的。日志解析的核心任务就是将原始日志还原为这种模板和变量的组合形式。

在 TLS 中手工配置正则表达式来解析日志。手工配置依赖人力，难以覆盖海量的日志模式，只能覆盖一些最常见的公共模式

然而，目前市场上的大多数日志服务仍然依赖于手动配置日志模板（通常是正则表达式）的方法来进行日志解析。这种方法在面对复杂多变的日志模式时显得力不从心，尤其是当系统规模扩大、组件增多时，手动维护这些解析规则变得异常困难且容易出错。因此，自动化的日志解析能力对于运维人员高效分析系统状态至关重要。更进一步，自动化日志解析还是众多高级 AIOps 方法的基础设施，包括但不限于日志异常检测、日志模式匹配、根因分析等关键技术。

基于上述考虑，火山引擎 TLS 中计划引入开箱即用的自动化日志解析功能。通过将原始日志转换为结构化格式，用户能够更直观地查询和分析日志数据。这种转换不仅简化了用户与日志数据的交互，还为更高级的分析功能奠定了基础。用户只需开启 TLS topic 的日志聚类索引，系统就能实时将原始日志解析为不同精确度的模板。这使得工程师可以在查询时直接按照日志模板进行检索，极大地提高了日志分析的效率和准确性，为大规模系统的可靠性保障提供了有力支持。基于结构化的日志解析结果，TLS 还能够进一步提供多种高级分析功能，这是引入自动化日志解析的重要动机。这些功能包括：

1. 日志异常检测：能够识别模板数量的异常变化和新出现的模板，帮助用户及时发现系统异常。

2. 模板分布比较：支持跨不同时间段的模板分布比较，便于用户了解系统行为的变化趋势。

3. 自动故障匹配：将当前日志模式与已知故障场景库进行自动匹配，加速问题诊断和解决。

挑战

然而，大规模云环境中的日志解析并非易事。首先，不同的应用对解析精度有着不同的要求，甚至同一数据流中的日志也可能需要不同级别的解析精度。举个例子，当开发人员在调试过程中遇到由代码 print(register callback for {}.format(email))生成的日志时，他们可能需要将其解析为 register callback for * 和 register callback for None 两种不同的模板，以便发现意外的空值。而在其他场景下，将这两种情况合并为一个模板可能更为合适。这种多样性要求日志解析系统能够实时调整解析机制，以适应不同的用户需求。

此图展示了本文算法在同一组日志上以不同精细度（Saturation）解析出来的日志模板。不同精确度的模板没有对错之分，选择什么精确度取决于用户的具体需要，因此我们为用户必须提供不同精确度的选择。

计算效率是另一个重要挑战。云环境中的日志规模庞大，每个 Topic 每天都可能产生数十亿条记录。这要求日志解析算法在离线训练和在线匹配两个阶段都必须高效运行。如果解析过程出现延迟，不仅会影响查询响应时间，还会增加计算资源成本，最终影响用户体验和服务提供商的运营成本。

存储效率同样不容忽视。日志解析会为云租户增加额外的存储成本。为了保持服务的成本效益，必须在不影响性能的前提下最小化资源使用。这需要在算法设计和系统架构上进行精心优化，以在解析精度和资源消耗之间取得平衡。

解析精度是最基本也是最关键的挑战。云环境中的日志模式多种多样且难以预测，解析系统必须能够在缺乏先验知识的情况下，依然保持高精度的解析能力。这要求系统具有强大的自适应能力和鲁棒性。

现有的日志解析技术在应对云环境的挑战时都存在明显不足。

基于启发式规则的方法（如 AEL、SLCT 和 Drain）虽然实现简单，但它们依赖预定义的规则和固定的分隔符，难以适应多样化的日志模式，尤其是面对未见过的日志格式时表现不佳。

频繁模式挖掘方法（如 LogSig、LogMine 和 SHISO）通过识别共同出现的词汇模式来构建模板，但这些方法对参数调整和预处理极为敏感，且难以处理变长日志和罕见模式，限制了它们在复杂云环境中的鲁棒性。

日志聚类方法（如 LenMa、LogCluster 和 SLCT）尝试将相似日志分组并提取共同模式，但在面对大规模数据时计算开销巨大，且难以动态调整聚类精度，常常无法生成足够准确的模板。

近年来的深度学习方法（如 LogParse 和 UniParser）虽然在精度上有所突破，但它们需要大量标记数据进行训练，计算资源需求高，且模型一旦训练完成就难以适应新出现的日志模式。最新的基于大语言模型的方法提供了更好的灵活性和适应性，但推理成本高昂且延迟大，难以满足云服务实时处理的需求。

更为关键的是，几乎所有现有方法都难以实现精度和效率的灵活平衡。它们要么追求高精度而牺牲处理速度，要么追求高效率而损失解析质量，无法根据不同应用场景的需求动态调整解析精度。此外，这些方法通常设计用于离线批处理环境，难以应对云服务中实时流数据的挑战。它们缺乏在不重新处理原始日志的情况下调整解析精度的能力，这在云环境中是至关重要的功能。这些局限性使得现有方法难以满足作为一种云服务的日志解析对高适应性、高效率、存储优化和高精度的综合要求，因此我们需要开发新的解决方案来克服这些挑战。

方法

为了应对这些挑战，我们推出了 ByteBrain-LogParser，这是一个专为云服务环境量身定制的综合框架。本章将介绍 ByteBrain-LogParser 的整体框架和核心思路，展示它如何应对云环境中日志解析的挑战。

整体流程

ByteBrain-LogParser 包括离线训练阶段和在线匹配阶段。

ByteBrain-LogParser 的系统架构

在离线训练阶段，系统首先从目标日志流中采样一批日志数据。这些日志经过预处理后，使用层次聚类算法将其组织成树状结构。我们特别选择了层次聚类算法，正是考虑到云环境中不同应用场景对日志解析精度的多样化需求。层次聚类能够自然地构建一个多层次的模板体系，使系统能够在后续匹配阶段提供不同精确度的解析结果，而无需重新训练模型。

聚类过程采用自底向上的方法，从单条日志作为初始叶节点开始，逐步合并相似的日志聚类，形成一个多层次的模板树。树中的每个节点代表一个日志模板，而树的不同层次对应不同的精度级别——越接近叶子节点的模板越精确，越接近根节点的模板越通用。聚类过程使用位置敏感的相似度计算和饱和度评分机制，确保生成的模板既准确又有效率。

离线训练不是一次性执行的过程，而是根据系统配置定期执行。具体来说，系统会在以下两种情况下触发离线训练：一是按照预设的时间间隔（如每天或每周）定期执行，确保模板库能够适应日志模式的渐进变化；二是当新的日志主题（topic）积累了足够数量的日志记录后立即执行，以快速适应新出现的日志类型。这种双重触发机制确保了系统既能保持对现有日志模式的高效解析，又能迅速适应新出现的日志格式，提高了整个框架的适应性和鲁棒性。

在在线匹配阶段，系统接收实时流入的日志，并将其与预先训练好的模板进行匹配。用户可以通过设置精度阈值参数来控制匹配过程，较低的阈值会导致系统使用树的较深层次进行更精细的模板匹配，而较高的阈值则使系统使用树的较浅层次进行更通用的模板匹配。这种动态调整精度的能力是 ByteBrain-LogParser 的关键创新，它使用户能够根据具体应用场景的需求灵活平衡精度和效率，无需重新处理原始日志。匹配完成后，系统从原始日志中提取变量值，并将解析结果返回给用户。

ByteBrain-LogParser 还实现了增量更新机制，利用定期执行的离线训练结果更新模板树，确保系统能够适应不断演变的日志模式。此外，系统采用了多种优化技术，包括哈希编码、模板索引和结果缓存，进一步提高了处理效率和存储效率。这些设计使 ByteBrain-LogParser 能够在保持高解析精度的同时，实现卓越的吞吐量和灵活的适应性，满足云环境中日志解析的严苛需求。

预处理

在离线训练和在线匹配阶段，日志都先会被预处理为便于计算的数值向量，然后根据日志的长度和前缀等进行预分组来，不同的预分组可以并行。

首先，日志会被分割成词（token）序列。分词是许多日志解析方法的基础步骤，它使系统能够在词级别上比较日志之间的相似性，而不是简单地进行字符级别的比较。我们选择正则表达式进行分词，因为它具有高效率、简单性和可定制性的优势。虽然正则表达式只能基于常见分隔符进行分段而无法考虑语义上下文，但它处理速度快且允许用户为每个主题轻松定义自定义分词规则。在默认的分词正则中， 我们考虑了常见的标点符号、URL 和小数点等情况。为了保持效率，系统禁止在用户定义的表达式中使用高复杂度的正则特性（如环视），这些特性可能使复杂度从 O（n）增加到 O（2^n）。

  
(?:://)|(?:(?:[\s\'\";=()\[\]{}?@&<>:\n\t\r,])|(?:[\.](\s+|$))|(?:\\[\"\']))+  

其次，尽管 ByteBrain-LogParser 专注于自动日志解析而不需要手动规则，但系统允许用户选择性地指定明显变量的正则表达式模式以优化性能。这些用户定义的模式通常针对在日志中一致出现的常见、特定领域的变量。提前替换这些已知变量可以显著降低后续自动解析的复杂性。对于每个主题，系统提供默认模式来识别常见变量（如时间戳、IP 地址、MD5 哈希值、UUID 等），同时用户可以添加特定领域的规则来进一步提高效率。

然后，ByteBrain-LogParser 去重输入的日志数据。日志数据经常包含大量重复记录，这种冗余在替换常见变量后变得更加明显。这不仅增加了存储开销，还降低了处理和分析效率。去重涉及识别并合并重复的日志条目，同时维护每个唯一日志语句出现次数的计数。这种方法通过减少冗余数据显著提高了计算效率。

在多个数据集上的实验表明，日志数据中普遍存在大量的重复日志。而且在常见变量替换后，日志的重复性大幅增加

为了计算效率，系统将标记编码为数值向量。传统的词袋编码（bad of words）方法忽略了标记的顺序，且无法直接从聚类生成模板文本。而序号编码（ordinal encoding）虽然保留顺序，但需要存储每个不同标记与其对应数值 ID 之间的映射，考虑到日志中可能存在的大量不同标记，这会导致显著的存储开销。

图中展示了多个日志数据集上，日志大小和存储 ordinal encoding 字段所需空间的关系。使用 ordinal encoding 将消耗大量存储空间，为云上用户带来较高的存储成本。

为解决这些挑战，ByteBrain 采用哈希编码，利用确定性哈希函数将每个标记映射到 64 位整数。在离线聚类和在线匹配中使用相同的哈希函数，消除了存储标记到 ID 映射的需求。与序号编码不同，哈希编码支持日志的并行处理，因为哈希函数可以独立处理每个标记，从而提高可扩展性。哈希碰撞的概率极低（对于 1000 万个不同标记，碰撞概率仅为 0.000271%），可以忽略不计。这种编码方式显著减少了存储开销，提高了系统效率，使得日志解析服务的成本大幅降低。

最后，ByteBrain-LogParser 使用初始分组（Initial Grouping）将那些不太可能属于同一模板的日志直接分开。初始分组的首要目的是使后续的聚类过程能够并行化，将日志分成较小的组还能降低后续聚类算法的计算复杂度并提高准确性。ByteBrain-LogParser 采用了两种简单而有效的初始分组策略：

1. 长度分组：具有不同标记数量的日志被假定属于不同的模板。这基于一个观察：同一代码生成的日志通常具有相同数量的标记，而标记数量的差异往往表明它们来自不同的日志语句。
2. 前缀分组：日志通过比较前 k 个标记（由用户配置，默认为 0）进行分组，将前缀不同的日志分到不同组中。这种策略特别有效，因为日志语句通常以表示操作类型或模块名称的固定前缀开始，这些前缀对区分不同类型的日志至关重要。

另外，后续的聚类算法依赖逐位置的单词比较计算日志间的相似性，因此按照长度分组也是必需的。然而，日志中可能存在可变长度的变量，比如直接打印 list 和 dict 等。我们特意选择不实现动态匹配解决方案（如使用最长公共子序列比较不同长度的日志），因为允许通配符匹配可变数量的标记需要在在线匹配过程中进行搜索，以确定每个通配符的最佳标记范围。这种方法会显著增加在线匹配的计算复杂性，使其在需要每秒匹配数百万条日志的云环境中变得不切实际。

我们认为可以在查询结果处理层做一个简单而有效的优化：例如，对于由语句 print(f'users={users}')生成的三个模板（其中 users 列表包含一个、两个和三个元素）：users *、users * * 和 users * * *，在呈现结果前，我们合并每个模板中的连续通配符，得到统一的 users *。然后将具有相同合并模板的日志在响应中分组在一起。这种优化在用户体验和系统性能之间取得了平衡：用户看到一个直观的模板 users *，它能够适应可变长度列表，而底层系统在日志解析和匹配过程中使用原始的固定长度模板，从而保持效率。

聚类算法

自适应精度控制的树状结构

层次聚类生成的树状结构是 ByteBrain 最显著的特点之一。这种设计的关键优势在于它能够实现精度的动态调整——用户可以在查询时指定阈值，系统会找到满足该阈值的最粗略模板。

这种设计解决了云环境中一个关键挑战：不同应用甚至同一日志流内的不同部分可能需要不同级别的解析精度。例如，在调试阶段，用户可能需要高精度的模板来识别细微的异常；而在监控阶段，可能更关注高级模式。很多传统方法通常需要重新处理日志以调整精度，而树状结构允许实时调整，无需额外计算开销。

位置相似度距离度量的创新

ByteBrain-LogParser 使用哈希编码将日志标记转换为数值向量。在这种编码方案中，标记值仅作为标识符，不具有有意义的数值关系。这意味着两个不同标记的哈希值之间的数值差异与它们的语义相似性没有关联。

而欧氏距离基于向量空间中点之间的直线距离，这种度量假设向量空间中的数值差异具有实际意义，即数值上接近的点在语义上也接近。然而，对于哈希编码的日志数据，这一假设并不成立。

所以，在单次聚类过程中，ByteBrain-LogParser 采用了位置相似度距离而非传统的欧几里得距离来计算日志与聚类的距离。这一距离考虑了两个关键因素：

1. 每个位置的标记频率：评估日志中每个标记在聚类中相应位置的出现频率。频率越高，表示该标记在该位置越具代表性。
2. 位置重要性：具有较大可变性的位置更可能包含变量，因此被赋予较低的重要性。系统为每个位置

引入权重

，其中

表示聚类中位置

处不同标记的数量。

这种度量方法的设计理念是识别日志的结构相似性，而非简单的文本相似性。它特别适合日志数据，因为日志通常由固定模板和可变部分组成。通过强调结构相似性，系统能够更准确地将具有相似模板的日志分组，即使它们的变量值完全不同。

饱和度评分：精确控制聚类过程

一组日志中一个位置如果被确定解析为常量或者变量，那么称之为饱和。饱和度评分用于评估日志组中的位置已经被确定的程度，并控制层次聚类的终止。与前人工作不同，ByteBrain-LogParser 的饱和度计算同时考虑已确认的常量和可能的变量。

饱和度计算包括三个步骤：

1. 常量比例：计算所有日志中完全相同的标记位置占总位置的比例。
2. 未解析位置的可变性：对于每个未解析位置，计算不同标记数量的对数比例，选择最小值作为整体可变性因子。
3. 置信度调整：引入置信度因子，随着未解析位置减少而增加，确保未解析位置对最终评分的贡献适当。

这种复杂的饱和度计算允许更快的聚类终止，同时避免不必要的分裂，从而提高效率和准确性。例如，当一组日志中除了令牌值外的所有位置都相同时，饱和度已达到 1，系统会避免进一步无意义的分割。

在 Set 1 中，除了 token 值外，所有位置在所有日志中都是相同的。这意味着：

• "UserService"、"createUser"、"token="和"success"这些位置是常量
• token值位置显示出高度可变性，强烈表明它是一个变量

由于这组日志的结构非常一致，系统能够轻松识别出常量和变量，因此饱和度得分为 1.0，表示这组日志已经被完全解析为一个明确的模板。

在 Set 2 中，情况更为复杂：

• 虽然token位置仍然在每个日志中有不同的值，但其他位置（如action和status字段）也存在变化
• 这种更广泛的可变性表明，token可能不仅仅是一个独立的变量，而可能与其他字段存在结构相关性

在这种情况下，将所有日志归为一个模板会丢失重要的结构模式，因此整体饱和度较低（0.4）。系统会进一步分割：

• 日志 4 和 6 形成一个子聚类（操作不同但状态相同），饱和度为 0.6
• 日志 5 单独形成一个聚类，饱和度为 1.0
• 最终，日志 4 和 6 也会各自形成单独的叶子节点，饱和度均为 1.0

优化技术：提升效率与可扩展性

ByteBrain-LogParser 还实现了多项优化技术来提高聚类效率：

1. 平衡分组：当日志与多个聚类具有相同距离时，随机分配，而非确定性地分配给第一个聚类，这有助于最小化结果聚类树的深度。
2. 提前停止：在特定条件下（如日志数量少、单一未解析位置或完全不同的未解析位置），算法可以立即确定每个不同的日志应形成单独的聚类，无需进行完整的聚类过程。
3. 并行处理：系统在所有阶段都利用并行化。预处理任务（分词、变量替换和哈希编码）和层次聚类可以并行操作，每个初始分组的层次聚类也可以并行执行。

在线匹配

在 ByteBrain-LogParser 系统中，在线匹配阶段是将新到达的日志与预先训练好的模板进行匹配的过程。ByteBrain-LogParser 的在线匹配阶段采用了一种基于文本的模板匹配方法，而非重新计算距离或遍历聚类树。这一设计决策的核心理念是在保持高准确性的同时，最大限度地提高效率和降低资源消耗。。其基本工作流程如下：

1. 预处理：新到达的日志首先经过与训练阶段相同的预处理步骤，包括分词、常见变量替换和哈希编码。
2. 模板匹配：系统按照饱和度评分降序排列所有模板，并依次将日志与每个模板进行匹配，一旦找到匹配就停止。
3. 位置比较：匹配过程是基于位置的：日志中的标记必须与模板中的标记完全匹配，或者与通配符（表示变量）匹配。
4. 未匹配处理：对于罕见的、无法匹配任何现有模板的日志，系统将其作为临时模板插入聚类树，并在下一次训练周期中考虑。
5. 模板 ID 分配：成功匹配后，系统为日志分配对应的模板 ID，该 ID 随后与其他传统文本索引一起存储。

存储效率的关键考量

在云环境中，存储资源直接关系到服务成本。如果在每个树节点存储详细的标记级信息（如标记频率或可变性指标）以支持重新计算距离，将导致巨大的存储开销。通过仅存储最终的模板文本，ByteBrain-LogParser 显著降低了存储需求：

1. 最小化存储占用：每个节点只需存储模板文本、饱和度评分和父子关系，而不是完整的聚类统计数据。
2. 避免冗余信息：模板文本已经捕获了日志的关键结构特征，无需存储中间计算结果。
3. 降低传输开销：更小的存储占用意味着在分布式系统中更低的数据传输成本。

实验结果表明，这种方法使模型大小保持在几兆字节级别，即使处理数百兆字节每秒的日志流也是如此。在生产环境中，处理 189 MB/s 的文本流时，模型大小仅为 3 MB，这对于云服务的成本效益至关重要。

计算效率的突破

基于文本的模板匹配不仅节省存储，还显著提高了计算效率：

1. 避免距离重计算：无需在每个节点重新计算位置相似度距离，大幅减少了计算开销。
2. 简化匹配逻辑：位置比较是一种简单而高效的操作，可以快速确定日志是否匹配模板。
3. 优先级排序：按饱和度评分降序排列模板，使系统能够更快找到最匹配的模板，减少平均匹配时间。

准确性保证

尽管优先考虑效率，ByteBrain 的在线匹配方法并不牺牲准确性：

1. 结构捕捉：模板通过聚类生成，已经捕获了日志的关键结构模式。
2. 饱和度优先：通过饱和度评分排序，系统优先考虑既精确又通用的模板。
3. 实验验证：消融研究表明，直接使用模板文本匹配与重新计算距离的方法相比，几乎没有准确性损失。

实验结果显示，使用训练期间分配给日志的模板与使用在线匹配方法产生的结果几乎完全相同，证明了这种方法的有效性。这意味着 ByteBrain 成功地在效率和准确性之间取得了平衡。

实时精度调整能力

ByteBrain 的在线匹配阶段与查询处理紧密集成，实现了实时精度调整能力：

1. 阈值指定：用户可以在查询时指定饱和度阈值，系统根据该阈值动态调整模板精度。
2. 高效导航：系统从检索到的模板 ID 开始，向上遍历祖先节点，直到找到满足指定阈值的最粗略模板。
3. 无需重处理：这种方法无需重新处理日志或存储冗余模板，实现了实时精度调整，同时最小化计算和存储开销。

在实际部署中，这一功能通过火山引擎 TLS 的 Web 界面中的交互式滑块提供给用户，使他们能够根据特定分析需求动态控制模板粒度。这种交互式能力帮助用户通过允许他们按需在不同抽象级别之间切换，更有效地识别模式和异常。

实验评估与关键发现

实验设置

ByteBrain-LogParser 在两个广泛使用的公共数据集上进行了全面评估：LogHub (https://github.com/logpai/loghub) 和 LogHub-2.0 (https://github.com/logpai/loghub-2.0)。LogHub 包含 16 个多样化的数据集，每个数据集有 2,000 条标记日志，涵盖分布式系统、操作系统和软件应用等多种来源。LogHub-2.0 则扩展了 LogHub，提供更大规模的标记日志，部分数据集超过 5000 万条消息，为可扩展日志解析提供了更具挑战性的基准。这两个数据集的结合使我们能够全面评估方法的解析准确性和大规模处理效率。

实验在配备 Intel（R） Xeon（R） Platinum 8336C CPU @ 2.30GHz 和 128GB RAM 的服务器上进行。ByteBrain-LogParser 的算法（包括训练和匹配）使用 Python 实现，并利用即时（JIT）编译加速代码执行和多线程并行处理。我们将 ByteBrain-LogParser 与多种基线方法进行比较，包括基于聚类的方法（如 IPLoM、LogCluster）、基于频繁模式挖掘的方法（如 SLCT、LFA）、基于启发式规则的方法（如 Drain、Spell）、基于深度学习的方法（如 UniParser、LogPPT）以及基于 LLM 的方法（如 LILAC）。

评估采用两个标准指标：分组准确率（GA）和吞吐量（logs/sec）。分组准确率衡量正确分组的日志比例，只有当日志与所有共享其真实模板的其他日志放在一起时，才被视为正确分组。吞吐量则衡量系统每秒处理的日志数量，计算为总日志数除以模型训练和日志匹配的总时间。

主要实验结果

准确性评估

ByteBrain 在 LogHub 数据集上取得了令人印象深刻的平均分组准确率 0.98，超过了大多数现有方法。它在各个数据集上一致排名靠前，展示了其处理各种日志模式的多功能性。ByteBrain 在复杂数据集（如 Linux 和 Mac）上的表现尤为出色，凸显了其对多样化日志结构的鲁棒性和适应性。

在大规模的 LogHub-2.0 数据集上，ByteBrain 的优势更加明显，平均分组准确率达到 0.90，显著优于大多数基线方法，其中许多方法在扩展到更大日志量时性能大幅下降。值得注意的是，ByteBrain 在不同类型的日志上保持了高准确率，从系统日志（如 HDFS、Spark）到应用日志（如 Thunderbird、HealthApp），展示了其处理海量多样化日志数据的可扩展性和一致性。虽然 LILAC 显示略高的准确率，但其效率较差，限制了其在实际场景中的应用，尤其是大规模、实时日志解析任务。

效率评估

在效率方面，ByteBrain-LogParser 的表现尤为突出。它平均每秒处理 229,000 条日志，比最快的基线方法（LogCluster）快 840.68%，比其他方法快 1-3 个数量级。这种卓越性能在大规模数据集（如 Thunderbird）上尤为明显，ByteBrain-LogParser 每秒处理 519,000 条日志，远超第二名。

为确保公平比较，我们还评估了 ByteBrain-LogParser 在使用单核（ByteBrain Sequential）和禁用即时编译（ByteBrain w/o JIT，同时也禁用了并行化）的情况下的吞吐量。即使使用单核，ByteBrain-LogParser 仍保持平均每秒 166,000 条日志的吞吐量，显著优于所有基线方法。当禁用 JIT 编译时，尽管吞吐量降至每秒 89,100 条日志，但仍至少比基线方法高一个数量级。这些结果表明，ByteBrain-LogParser 的卓越性能源于其算法效率，而非仅仅来自优化的实现。

运行时间与日志大小的关系图显示，ByteBrain 的处理时间与日志量呈近似线性关系，大多数数据集沿着类似轨迹聚集。这种线性扩展表明我们的方法能够有效处理不断增加的日志量，这对于云端日志解析服务至关重要。

总结

论文地址：https://arxiv.org/abs/2504.09113

ByteBrain-LogParser 是一个为云环境专门设计的创新日志解析框架，旨在解决大规模、多样化日志处理的关键挑战。本文详细介绍了这一系统的设计理念、核心算法和实验评估结果，展示了其在云服务环境中的卓越性能和实用价值。

ByteBrain-LogParser 采用两阶段方法——离线训练和在线匹配，通过层次聚类算法构建一个模板精度可调的树状结构。系统的核心创新包括位置相似度距离度量、饱和度评分机制、哈希编码和基于文本的高效匹配方法。这些技术共同解决了云环境中日志解析面临的四大挑战：适应性、计算效率、存储效率和解析准确性。

在预处理阶段，ByteBrain-LogParser 通过分词、常见变量替换、去重和哈希编码将非结构化日志转换为数值向量，为后续处理奠定基础。初始分组阶段基于长度和前缀将日志组织成不同组，确保不太可能属于同一模板的日志早期分开，提高并行处理效率。层次聚类阶段是系统的核心，通过迭代分裂过程构建模板树，使用位置相似度距离和饱和度评分指导聚类过程。在线匹配阶段则采用基于文本的高效方法，在仅存储模板文本的情况下实现高速、准确的匹配。

实验评估表明，ByteBrain-LogParser 在 LogHub 和 LogHub-2.0 数据集上分别达到 0.98 和 0.90 的平均准确率，接近最先进的方法。在效率方面，它平均每秒处理 229,000 条日志，比最快的基线方法快 840.68%，比其他方法快 1-3 个数量级。这种卓越性能使 ByteBrain-LogParser 成为云环境中理想的日志解析解决方案。

通过这些创新，ByteBrain-LogParser 不仅解决了传统方法的局限性，还为用户提供了一个高效、灵活且精确的工具，帮助他们更好地理解和管理云环境中的系统行为。无论是日常监控、异常检测还是故障诊断，这项服务都能为用户提供宝贵的支持，使他们能够更加从容地应对云计算环境中的各种挑战。

作者团队

论文作者来自字节跳动 ByteBrain 团队和火山引擎 TLS 团队。

ByteBrain 是面向系统优化的 AI 服务平台（AI for Infra），旨在利用 AI 技术（机器学习、LLM 和运筹优化）对系统的全生命周期进行自动优化，服务对象包括数据库、存储系统、大数据系统、虚机容器、网络等，主要功能包括容量预测、资源调度、数据冷热识别、参数优化、SQL 优化、异常检测、根因分析、智能问答等。同时，ByteBrain 也正在把服务能力作为 Infra 的一部分向应用层输出（AI as an Infrastructure Service），例如运筹优化和调度能力服务于公司的排班团队、工位编排、流量调度等。

TLS 是火山引擎提供的针对日志类数据的一站式服务，提供日志采集、海量存储、检索分析、监控告警、数据可视化等功能，适用于应用运维、服务监控、等保合规等场景，全方位提升研发与运维效率。