克拉玛依市网站建设_网站建设公司_内容更新_seo优化

作者：来自 Elastic Nastia Havriushenko

了解一种混合 ML 方法如何通过在 Streams 中使用 log 格式指纹识别的自动化实验，实现 94% 的 log 解析准确率和 91% 的 log 分区准确率。

更多阅读：Elastic Streams 介绍 - 9.2

无缝连接领先的 AI 和 machine learning 平台。开始一个免费的 cloud 试用来探索 Elastic 的 gen AI 能力，或者现在就在你的机器上试用。

在现代可观测性技术栈中，将来自不同数据提供方的非结构化 log 摄取到像 Elasticsearch 这样的平台仍然是一个挑战。依赖手工编写的解析规则会产生脆弱的管道，即使上游代码的轻微更新也会导致解析失败和数据无法被索引。这种脆弱性还因可扩展性问题而加剧：在动态的 microservices 环境中，不断新增的新服务使得手动维护规则变成一场运维噩梦。

我们的目标是转向一种自动化、可自适应的方法，能够同时处理 log 解析（字段提取）和 log 分区（来源识别）。我们假设，大语言模型 LLMs 凭借其对代码语法和语义模式的内在理解，可以在几乎不需要人工干预的情况下自动完成这些任务。

数据集描述

我们选择了 Loghub 的 log 集合作为 PoC 的数据来源。在本次研究中，我们从以下关键领域选择了具有代表性的样本：

• 分布式系统：我们使用了 HDFS（Hadoop Distributed File System）和 Spark 数据集。这些数据集包含了典型的大数据平台中的 info、debug 和 error 消息。
• 服务器和 web 应用：来自 Apache web 服务器和 OpenSSH 的 logs 提供了大量访问、错误以及与安全相关的事件。这些对于监控 web 流量和检测潜在威胁至关重要。
• 操作系统：我们包含了 Linux 和 Windows 的 logs。这些数据集代表了运维团队日常遇到的常见、半结构化的系统级事件。
• 移动系统：为了确保我们的模型能够处理来自移动环境的 logs，我们加入了 Android 数据集。这些 logs 通常非常冗长，记录了移动设备上大量应用级和系统级活动。
• 超级计算机：为了测试在高性能计算 HPC 环境下的表现，我们引入了 BGL（Blue Gene/L）数据集。该数据集包含高度结构化的 logs，并带有特定领域的术语。

Loghub 集合的一个关键优势在于，这些 logs 大多是未清洗、未标注的，真实地模拟了具有 microservice 架构的嘈杂生产环境。

Log 示例：

[Sun Dec 04 20:34:21 2005] [notice] jk2_init() Found child 2008 in scoreboard slot 6 [Sun Dec 04 20:34:25 2005] [notice] workerEnv.init() ok /etc/httpd/conf/workers2.properties [Mon Dec 05 11:06:51 2005] [notice] workerEnv.init() ok /etc/httpd/conf/workers2.properties 17/06/09 20:10:58 INFO output.FileOutputCommitter: Saved output of task 'attempt_201706092018_0024_m_000083_1138' to hdfs://10.10.34.11:9000/pjhe/test/1/_temporary/0/task_201706092018_0024_m_000083 17/06/09 20:10:58 INFO mapred.SparkHadoopMapRedUtil: attempt_201706092018_0024_m_000083_1138: Committed

此外，我们还创建了一个 Kubernetes 集群，采用典型的 web 应用 + 数据库 的设置，在最常见的领域中挖掘额外的 logs。

常见 log 字段示例：timestamp、log level（INFO、WARN、ERROR）、source、message。

使用 LLM 进行 few-shot log 解析

我们的第一组实验聚焦于一个基础问题：LLM 是否能够可靠地识别关键字段，并生成一致的解析规则来提取它们？

我们让模型分析原始 log 样本，并生成 regular expression（regex）和 Grok 格式的 log 解析规则。结果表明，这种方法具有很大潜力，但在实现层面也存在显著挑战。

高置信度与上下文感知

初步结果令人鼓舞。LLM 展现了很强的能力，能够以高置信度生成与提供的 few-shot 示例相匹配的解析规则。除了简单的模式匹配之外，模型还表现出对 log 的理解能力 —— 它可以正确识别并命名 log 来源（例如 健康追踪 app、Nginx web app、Mongo 数据库）。

输入样本的 “Goldilocks（恰到好处困境）” 困境

我们的实验很快暴露出一个显著的鲁棒性不足问题，即模型对输入样本极度敏感。模型的表现会随着 prompt 中包含的具体 log 示例而剧烈波动。我们观察到一个 log 相似性问题：log 样本需要恰到好处地多样化：

• 过于同质（overfitting）：如果输入的 logs 过于相似，LLM 往往会过度具体化。它会把可变数据 —— 例如 stack trace 中的特定 Java class 名称 —— 当作模板中的静态部分。这会导致生成的规则非常脆弱，只能覆盖极少比例的 logs，并且提取出的字段不可用。
• 过于异质（confusion）：相反，如果样本中包含明显的格式差异 —— 或者更糟的是，包含诸如 progress bars、memory tables、ASCII art 等 “trash logs” —— 模型就很难找到共同点。它往往会生成复杂但有问题的 regex，或者干脆过度泛化，把整行都解析成一个单一的 message blob 字段。

上下文窗口限制

我们还遇到了 context window 的瓶颈。当输入的 logs 很长、差异很大，或者包含大量可提取字段时，模型的输出质量往往会下降，变得 “杂乱”，或者长度过长而无法放入输出的 context window。自然地，chunking 在这种情况下会有所帮助。通过使用基于字符和基于实体的分隔符来拆分 logs，我们可以帮助模型专注于提取主要字段，而不会被噪声淹没。

一致性与标准化差距

即使模型成功生成了解析规则，我们仍然注意到一些细微的不一致性：

• 服务命名差异：模型在不同运行中会为同一实体提出不同名称（例如，将 source 标注为 “Spark”、 “Apache Spark” 和 “Spark Log Analytics”）。
• 字段命名差异：字段名称缺乏标准化（例如 id、 service.id、 device.id）。我们使用标准化的 Elastic 字段命名对名称进行了归一化。
• 解析粒度差异：字段提取的解析粒度会根据输入日志彼此之间的相似程度而变化。

日志格式指纹

为了解决日志相似性的问题，我们引入了一种高性能的启发式方法：日志格式指纹（log format fingerprint, LFF）。

我们不再直接把原始、嘈杂的日志输入到 LLM 中，而是先对每条日志应用一个确定性的转换，以揭示其底层结构。这个预处理步骤会抽象掉可变数据，生成一个简化的 “指纹”，从而让我们可以对相关日志进行分组。

映射逻辑被设计得非常简单，以保证速度和一致性：

• 数字抽象：任何由数字（ 0–9 ）组成的序列都会被替换为一个 ‘0’。
• 文本抽象：任何由字母字符组成并包含空格的序列都会被替换为一个 ‘a’。
• 空白规范化：所有连续的空白（空格、制表符、换行符）都会折叠为一个空格。
• 符号保留：标点符号和特殊字符（例如 : 、 [ 、 ] 、 / ）会被保留下来，因为它们通常是日志结构中最强的指示信号。

我们引入了这种日志映射方法。基础的映射规则包括以下内容：

• 任意长度的数字 0–9 → 替换为 ‘0’。
• 任意长度的文本（带空格的字母字符） → 替换为 ‘a’。
• 空格、制表符和换行符 → 合并为一个空格。

下面来看一个示例，展示这种映射是如何帮助我们转换日志的。

17/06/09 20:10:56 INFO executor.CoarseGrainedExecutorBackend: Got assigned task 912 0/0/0 0:0:0 a a.a: a 0 17/06/09 20:10:58 INFO mapred.SparkHadoopMapRedUtil: attempt_ 2017060920_081_136: Committed 0/0/0 0:0:0 a a.a: a_0_0_0: a 2015-07-29 19:23:30,320 - WARN [RecvWorker:18861024:$RecvWorker@765] - Interrupting SendWorker 0-0-0 0:0:0,0 - a [a:0:a$a@0]

因此，我们得到如下的日志掩码：

0/0/0 0:0:0 a a.a: a 0 0/0/0 0:0:0 a a.a: a_0_0_0: a 0-0-0 0:0:0,0 - a [a:0:a$a@0] a

注意前两条日志的指纹。尽管它们的 timestamp、source class 和 message 内容不同，但它们的前缀（0/0/0 0:0:0 a a.a:）是相同的。这种结构上的一致性使我们能够自动将这些日志归入同一个簇。

然而，第三条日志生成了完全不同的指纹（0-0-0…），这使我们能够在调用 LLM 之前，通过算法将其从第一组中分离出来。

额外部分：使用 ES|QL 即刻实现

只需在 Discover 中传入以下查询即可。

FROM loghub | EVAL pattern = REPLACE(REPLACE(REPLACE(REPLACE(raw_message, "[ \t\n]+", " "), "[A-Za-z]+", "a"), "[0-9]+", "0"), "a( a)+", "a") | STATS total_count = COUNT(), ratio = COUNT() / 2000.0, datasources=VALUES(filename), example=TOP(raw_message, 3, "desc") BY SUBSTRING(pattern, 0, 15) | SORT total_count DESC | LIMIT 100

查询解析：

FROM loghub:Targets our index containing the raw log data. EVAL pattern = …: The core mapping logic. We chain REPLACE functions to perform the abstraction (e.g. digits to '0', text to 'a', etc.) and save the result in a “pattern” field. STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15): This is a clustering step. We group logs that share the first 15 characters of their pattern and create aggregated fields such as total log count per group, list of log datasources, pattern prefix, 3 log examples SORT total_count DESC | LIMIT 100 : Surfaces the top 100 most frequent log patterns

LogHub 上的查询结果如下所示：

如可视化所示，这种 “LLM-free” 方法能够高精度地对日志进行分区。它成功地将 16 个数据源中的 10 个完全聚类（>90%，基于 LogHub 标签），并在 16 个数据源中有 13 个实现多数聚类（>60%）——全部无需额外清洗、预处理或微调。

日志格式指纹（ log format fingerprint, LFF）为复杂的 ML 解决方案（如日志模式分析）提供了一个务实且高效的替代方案和补充。它能够立即洞察日志之间的关系，并有效管理大规模日志簇。

作为基础工具的多用途性
得益于 ES|QL 的实现，LFF 既可作为快速数据诊断/可视化的独立工具，也可作为高吞吐量日志分析管道中的构建模块。

灵活性
LFF 易于自定义和扩展，以捕获特定模式，例如十六进制数字和 IP 地址。

确定性稳定性
与基于 ML 的聚类算法不同，LFF 的逻辑简单且确定性。新进入的日志不会对已有日志簇产生回溯影响。

性能与内存
它占用最少的内存，无需训练或 GPU，非常适合实时高吞吐量环境。

将日志格式指纹与 LLM 结合

为了验证所提出的混合架构，每次实验都包含来自每个数据源的随机 20% 日志子集。这个限制模拟了真实生产环境中日志按批处理而非作为单一历史数据块处理的情况。

目标是证明 LFF 作为有效压缩层的作用。我们旨在证明可以从小型、精心挑选的样本生成高覆盖率的解析规则，并成功推广到整个数据集。

执行流程

我们实现了一个多阶段管道，在数据到达 LLM 之前进行过滤、聚类，并应用分层采样。

1）两阶段分层聚类

• 子类（精确匹配）：日志按完全相同的指纹聚合。每个子类中的日志共享完全相同的格式结构。
• 异常清理：我们丢弃占总日志量不足 5% 的子类。这确保 LLM 专注于主导信号，而不会被噪声或格式错误的日志分散注意力。
• 元类（前缀匹配）：剩余子类按指纹匹配的前 N 个字符分组到元类中。这种分组策略有效地将词汇相似的格式归入同一类。对于未知数据源，我们在日志解析中选择 N=5，日志分区中选择 N=15。分层采样

2）一旦构建好分层树，我们就为 LLM 构建日志样本。战略目标是最大化方差覆盖，同时最小化 token 使用量。

• 我们从每个元类中每个有效子类选择代表性日志。
• 为处理子类过多的极端情况，我们应用随机下采样以适应目标窗口大小。

3）规则生成

• 最后，我们提示 LLM 为每个元类提供的样本生成适配所有日志的 regex 解析规则。在我们的 PoC 中，我们使用了 GPT-4o mini 模型。

实验结果与观察

在 Loghub 数据集上，我们实现了 94% 的解析准确率和 91% 的分区准确率。

上图的混淆矩阵展示了日志分区结果。纵轴表示实际数据源，横轴表示预测数据源。热力图的颜色深浅对应日志数量，颜色越浅表示数量越多。对角线的对齐显示模型在源归属上的高准确性，散布最小。

我们的性能基准洞察：

• 最优基线：每类 30–40 条日志样本的上下文窗口被证明是“最佳区间”，能够稳定生成可靠的 Regex 和 Grok 解析模式。
• 输入最小化：我们将每类的输入规模压缩到 10 条日志用于 Regex 模式，解析性能仅下降 2%，确认基于多样性的采样比原始数量更关键。

原文：https://www.elastic.co/search-labs/blog/log-parsing-partitioning-automation-experiments-streams