LogBERT基于 BERT 的日志异常检测完整指南【免费下载链接】logbertlog anomaly detection via BERT项目地址: https://gitcode.com/gh_mirrors/lo/logbert凌晨三点被一条告警吵醒翻日志发现又是一次误报——对常值班的人来说这画面不太陌生。LogBERT 用 BERT 做日志异常检测先用模板解析把原始日志变成事件序列再用挖空补全的方式训练模型最后根据模型猜不出的 token 数量判定异常。它基于 PyTorch 从零实现了 BERT并内置 HDFS、BGL、Thunderbird 三个公开数据集的完整实验流程方便你把 DeepLog 等基线放在同一份数据上对比。 凌晨的误报规则匹配为什么会扛不住日志异常检测的传统做法基本是这几类各自有明确短板手工写规则ERROR 出现次数 5 就告警。阈值定高了漏报定低了天天误报每来一种新日志格式规则就要跟着改维护成本全压在写规则的人身上。浅层模型LR、SVM、孤立森林、PCA 等依赖人工构造的特征遇到单条日志都正常、连起来才异常的情况基本没辙。LSTM 类序列模型DeepLog只能从前往后读预测下一个最可能是什么。而异常往往要结合前后文一起看单向预测天然吃亏。LogBERT 把编码器换成双向的 BERT序列里任何一个位置都能同时参考它前后的 token。这正好对应日志里很常见的一类异常——单条看都没问题但组合起来的顺序或内容不对劲。从下载到出 F1HDFS 数据集上的完整流程以 HDFS 为例BGL、Thunderbird 目录下的步骤相同git clone https://gitcode.com/gh_mirrors/lo/logbert cd logbert conda create -f environment/environment.yml conda activate logbert cd HDFS sh init.sh # 下载原始日志到 ~/.dataset/hdfs/ python data_process.py # Drain 解析 生成训练/测试集 python logbert.py vocab python logbert.py train python logbert.py predict几个说明原始数据落在~/.dataset/中间结果和最终结果都在output/目录里。train最多跑 200 个 epoch10 个 epoch 无提升就早停默认 4 层、4 头、hidden 256、batch 32。有 GPU 会快很多纯 CPU 能跑但训练很慢。predict会自动在 0~1 里扫一个最优的序列级阈值最后打印 TP/TN/FP/FN 和精确率、召回率、F1不用手动调。一条日志是怎么被判定为异常的分三步看每步都能对应到仓库里的一小段代码。1. 原始日志变成事件序列data_process.py用 Drain 解析器把日志逐行模板化块号、IP、文件路径先被替换成*结构相同的行归为同一个模板并分配一个 EventId。对 HDFS事件再按 BlockId 串成序列——一个会话就是一个数据块的生命周期正常/异常标签来自数据集自带的anomaly_label.csv训练集只取正常块异常块全部留到测试集。2. 训练随机挖空让模型补全预训练目标很朴素随机 mask 掉 65% 的 token让 BERT 根据上下文猜被挖掉的词类似做填空题。模型见过足够多正常的日志序列后对正常的词该怎么排列就有了感觉。3. 判定看模型猜不出多少词预测时同样 mask 一部分 token。每个被 mask 的位置取模型置信度 Top 6 的候选真实 token 不在里面就记为未检测出。一条序列里未检测出的比例超过 50%seq_threshold0.5这条序列就判为异常。这个思路比输出一个概率更好解释你能直接看到是哪些词模型猜不出来候选词又是什么。 想读源码从哪几个目录入手目录内容logparser/Drain、Spell 两个日志模板解析器bert_pytorch/model/从零写的 BERT注意力、嵌入、位置编码日志专用结构在log_model.pybert_pytorch/dataset/词表构建、窗口采样、训练/验证切分bert_pytorch/trainer/训练循环、早停、超球损失Deep SVDDHDFS/、BGL/、TBird/三个数据集各自的入口脚本结构一致scripts/原始日志下载脚本每个数据集目录里除了logbert.py还有deeplog.py、loganomaly.py和baselines.ipynb跑基线不需要额外装别的东西。和 LSTM 基线比落地差异在哪维度规则/阈值DeepLogLSTMLogBERT判定依据命中规则即告警单向预测下一词双向上下文补全新日志类型出现要手写新规则词表变了需重训词表变了需重训可解释性规则本身就是原因下一个词的概率猜不出的词 Top 6 候选对序列模式的敏感度低中只有前文高前后文都参考数据要求不需要数据但要专家经验正常日志序列正常日志序列算力与算力外成本基本没有训练推理都便宜推理要载一个 4 层 BERT训练建议有 GPU一句话总结LogBERT 省掉的是写规则和调阈值的人力换来的是更高的算力要求和一份必须维护的训练流程。什么场景下值得用什么时候不必用比较适合有一批正常日志最好带异常标签想离线评估深度方法的效果异常体现在序列模式上而不是单条报错需要在同一份数据上对比 BERT 与 LSTM 基线。不太适合毫秒级实时告警的在线流——这套代码按离线评估写的是批处理推理接实时流要自己再包一层工程几乎没有历史日志可训练模型没有内容可学只有纯 CPU 小机器又要跑大日志——能跑但很慢with_cudaTrue是默认配置。下一步可以做什么三件事按顺序来在同一个 HDFS 数据集上把基线跑一遍python deeplog.py vocab python deeplog.py train python deeplog.py predict把 F1 和 LogBERT 放进同一张表。注意 DeepLog 需要把 vocab 步骤输出的词表大小手动填回脚本里的vocab_size。换到 BGL 目录重复同样流程观察模型在不同数据集上的表现差异。想调整判定松紧放宽num_candidates默认 Top 6会减少误报但可能漏掉更隐蔽的异常调seq_threshold的扫描范围则改变序列级判定的严格程度。【免费下载链接】logbertlog anomaly detection via BERT项目地址: https://gitcode.com/gh_mirrors/lo/logbert创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LogBERT基于 BERT 的日志异常检测完整指南【免费下载链接】logbertlog anomaly detection via BERT项目地址: https://gitcode.com/gh_mirrors/lo/logbert凌晨三点被一条告警吵醒翻日志发现又是一次误报——对常值班的人来说这画面不太陌生。LogBERT 用 BERT 做日志异常检测先用模板解析把原始日志变成事件序列再用挖空补全的方式训练模型最后根据模型猜不出的 token 数量判定异常。它基于 PyTorch 从零实现了 BERT并内置 HDFS、BGL、Thunderbird 三个公开数据集的完整实验流程方便你把 DeepLog 等基线放在同一份数据上对比。 凌晨的误报规则匹配为什么会扛不住日志异常检测的传统做法基本是这几类各自有明确短板手工写规则ERROR 出现次数 5 就告警。阈值定高了漏报定低了天天误报每来一种新日志格式规则就要跟着改维护成本全压在写规则的人身上。浅层模型LR、SVM、孤立森林、PCA 等依赖人工构造的特征遇到单条日志都正常、连起来才异常的情况基本没辙。LSTM 类序列模型DeepLog只能从前往后读预测下一个最可能是什么。而异常往往要结合前后文一起看单向预测天然吃亏。LogBERT 把编码器换成双向的 BERT序列里任何一个位置都能同时参考它前后的 token。这正好对应日志里很常见的一类异常——单条看都没问题但组合起来的顺序或内容不对劲。从下载到出 F1HDFS 数据集上的完整流程以 HDFS 为例BGL、Thunderbird 目录下的步骤相同git clone https://gitcode.com/gh_mirrors/lo/logbert cd logbert conda create -f environment/environment.yml conda activate logbert cd HDFS sh init.sh # 下载原始日志到 ~/.dataset/hdfs/ python data_process.py # Drain 解析 生成训练/测试集 python logbert.py vocab python logbert.py train python logbert.py predict几个说明原始数据落在~/.dataset/中间结果和最终结果都在output/目录里。train最多跑 200 个 epoch10 个 epoch 无提升就早停默认 4 层、4 头、hidden 256、batch 32。有 GPU 会快很多纯 CPU 能跑但训练很慢。predict会自动在 0~1 里扫一个最优的序列级阈值最后打印 TP/TN/FP/FN 和精确率、召回率、F1不用手动调。一条日志是怎么被判定为异常的分三步看每步都能对应到仓库里的一小段代码。1. 原始日志变成事件序列data_process.py用 Drain 解析器把日志逐行模板化块号、IP、文件路径先被替换成*结构相同的行归为同一个模板并分配一个 EventId。对 HDFS事件再按 BlockId 串成序列——一个会话就是一个数据块的生命周期正常/异常标签来自数据集自带的anomaly_label.csv训练集只取正常块异常块全部留到测试集。2. 训练随机挖空让模型补全预训练目标很朴素随机 mask 掉 65% 的 token让 BERT 根据上下文猜被挖掉的词类似做填空题。模型见过足够多正常的日志序列后对正常的词该怎么排列就有了感觉。3. 判定看模型猜不出多少词预测时同样 mask 一部分 token。每个被 mask 的位置取模型置信度 Top 6 的候选真实 token 不在里面就记为未检测出。一条序列里未检测出的比例超过 50%seq_threshold0.5这条序列就判为异常。这个思路比输出一个概率更好解释你能直接看到是哪些词模型猜不出来候选词又是什么。 想读源码从哪几个目录入手目录内容logparser/Drain、Spell 两个日志模板解析器bert_pytorch/model/从零写的 BERT注意力、嵌入、位置编码日志专用结构在log_model.pybert_pytorch/dataset/词表构建、窗口采样、训练/验证切分bert_pytorch/trainer/训练循环、早停、超球损失Deep SVDDHDFS/、BGL/、TBird/三个数据集各自的入口脚本结构一致scripts/原始日志下载脚本每个数据集目录里除了logbert.py还有deeplog.py、loganomaly.py和baselines.ipynb跑基线不需要额外装别的东西。和 LSTM 基线比落地差异在哪维度规则/阈值DeepLogLSTMLogBERT判定依据命中规则即告警单向预测下一词双向上下文补全新日志类型出现要手写新规则词表变了需重训词表变了需重训可解释性规则本身就是原因下一个词的概率猜不出的词 Top 6 候选对序列模式的敏感度低中只有前文高前后文都参考数据要求不需要数据但要专家经验正常日志序列正常日志序列算力与算力外成本基本没有训练推理都便宜推理要载一个 4 层 BERT训练建议有 GPU一句话总结LogBERT 省掉的是写规则和调阈值的人力换来的是更高的算力要求和一份必须维护的训练流程。什么场景下值得用什么时候不必用比较适合有一批正常日志最好带异常标签想离线评估深度方法的效果异常体现在序列模式上而不是单条报错需要在同一份数据上对比 BERT 与 LSTM 基线。不太适合毫秒级实时告警的在线流——这套代码按离线评估写的是批处理推理接实时流要自己再包一层工程几乎没有历史日志可训练模型没有内容可学只有纯 CPU 小机器又要跑大日志——能跑但很慢with_cudaTrue是默认配置。下一步可以做什么三件事按顺序来在同一个 HDFS 数据集上把基线跑一遍python deeplog.py vocab python deeplog.py train python deeplog.py predict把 F1 和 LogBERT 放进同一张表。注意 DeepLog 需要把 vocab 步骤输出的词表大小手动填回脚本里的vocab_size。换到 BGL 目录重复同样流程观察模型在不同数据集上的表现差异。想调整判定松紧放宽num_candidates默认 Top 6会减少误报但可能漏掉更隐蔽的异常调seq_threshold的扫描范围则改变序列级判定的严格程度。【免费下载链接】logbertlog anomaly detection via BERT项目地址: https://gitcode.com/gh_mirrors/lo/logbert创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
