夜间正能量网站做网站用的什么服务器

夜间正能量网站,做网站用的什么服务器,软件开发具体工作内容,wordpress 禁止加载js作者#xff1a;来自 Elastic Nastia Havriushenko 了解一种混合 ML 方法如何通过在 Streams 中使用 log 格式指纹识别的自动化实验#xff0c;实现 94% 的 log 解析准确率和 91% 的 log 分区准确率。 更多阅读#xff1a;Elastic Streams 介绍 - 9.2 无缝连接领先的 AI 和…作者来自 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 的数据来源。在本次研究中我们从以下关键领域选择了具有代表性的样本分布式系统我们使用了 HDFSHadoop Distributed File System和 Spark 数据集。这些数据集包含了典型的大数据平台中的 info、debug 和 error 消息。服务器和 web 应用来自 Apache web 服务器和 OpenSSH 的 logs 提供了大量访问、错误以及与安全相关的事件。这些对于监控 web 流量和检测潜在威胁至关重要。操作系统我们包含了 Linux 和 Windows 的 logs。这些数据集代表了运维团队日常遇到的常见、半结构化的系统级事件。移动系统为了确保我们的模型能够处理来自移动环境的 logs我们加入了 Android 数据集。这些 logs 通常非常冗长记录了移动设备上大量应用级和系统级活动。超级计算机为了测试在高性能计算 HPC 环境下的表现我们引入了 BGLBlue 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 levelINFO、WARN、ERROR、source、message。使用 LLM 进行 few-shot log 解析我们的第一组实验聚焦于一个基础问题LLM 是否能够可靠地识别关键字段并生成一致的解析规则来提取它们我们让模型分析原始 log 样本并生成 regular expressionregex和 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:$RecvWorker765] - Interrupting SendWorker 0-0-0 0:0:0,0 - a [a:0:a$a0]因此我们得到如下的日志掩码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$a0] 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, datasourcesVALUES(filename), exampleTOP(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 patternsLogHub 上的查询结果如下所示如可视化所示这种 “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 个字符分组到元类中。这种分组策略有效地将词汇相似的格式归入同一类。对于未知数据源我们在日志解析中选择 N5日志分区中选择 N15。分层采样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