Nothing Special   »   [go: up one dir, main page]

Skip to content

chenryn/aiops-handbook

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 

Repository files navigation

AIOps 手册

英文版见 <README_en.md>。

AIOps 的论文、演讲、开源库的汇总手册。按照《企业AIOps实施建议白皮书》中的场景分类进行收集和展示。

对于同一个场景,尽量提供比较新的链接。因为新论文里一般会引用和对比旧论文。

异常检测

指标

单指标

多指标

大模型方法

  • 清华大学基于 GPT2 做的GPT4TS大模型。本领域的开山之作,后续进展的基准。
  • 卡内基梅隆大学 MOMENT 模型和 Time-Series Pile 数据集:https://arxiv.org/pdf/2402.03885.pdf。对标大语言模型的 Pile 数据集,收集了目前最常用的 5 个指标数据集,同时覆盖了单维度和多维度指标的分类、长短期预测、异常检测等任务。然后类似 T5 的方式预训练了 moment-base、large、small 三个规格的指标大模型。论文主要对比的基线是 TimesNet 和 GPT4TS。
  • 谷歌开源的时序指标预测基础模型:https://github.com/google-research/timesfm
  • 微软/清华发表的MonitorAssistant: 主要是在指标监控和标注的流程里,引入 LLM 助手。比如新指标上线时的配置参数推荐,和指标告警时的历史告警推荐,除了指标时序相似度加上指标描述的文本相似度;还有在工单对话中,通过文本问答来反馈哪些时段的异常类型是误报或不关心。
  • datadog 的 Toto 指标大模型技术报告:https://arxiv.org/pdf/2407.07874,预训练数据包含一万亿个指标数据点,其中 75% 来自 datadog 云平台上的匿名数据。

日志

传统方法

大模型方法

  • 北航发表的 LogQA 论文,利用 T5 大模型,和手工标记生成的训练数据,实现了对日志的自然语言问答:https://arxiv.org/pdf/2303.11715.pdf
  • 澳大利亚纽卡斯尔大学开源的 LogPPT 项目,利用 RoBERTa 大模型和 loghub 数据集。最有趣的点是 loghub 数据集中虽然 80G 日志但每类只有 2k 条有标签的。本论文思路正好就反向用 2k 有标签的做 prompt:https://github.com/LogIntelligence/LogPPT
  • 香港中文大学发表的 DivLog 论文,利用 GPT3 大模型,全面超过 LogPPT 的效果。并探讨了 ICL 方法用 5-shot 可能效果最佳:https://arxiv.org/pdf/2307.09950v3.pdf
    • 后续的 LILAC 开源项目,通过设计的 sampling 方法和 cache,在日志模板推理速率上逼近 Drain 效果!此外,和 LogPPT/LogDiv 的对比中,也验证了基础模型从 110MB 的 RoBerta 到 13B 的 Curie 到 176B 的 ChatGPT,似乎提升不太高。在模板识别任务上,可能中型 LM 的语言理解力就不错了?https://github.com/logpai/LILAC
    • 后续的 ULog 论文:https://arxiv.org/pdf/2406.07174。最前面先加一个简单的日志长度分桶,让任务可以并行起来。单任务的速度其实比 LILAC 慢,并行以后就更快了。
  • IBM 开源的 BERTOps 项目,利用 BERT 大模型,和一部分人工标记数据,尝试了日志领域的三个分类任务,日志格式分类、黄金信号分类,故障分类(不过这个库就是纯展示,跑不起来,train.sh 里的 pretrain.txt不存在,只给了清洗前的 annotation Excel 文件):https://github.com/BertOps/bertops
  • IBM 开源的 KubePlaybook 数据集,包括 130 份自然语言查询生成 ansible playbook 的语料,分为配置查询和故障分析操作等场景。该团队同时基于这个数据集验证了 few-shot learning 对生成 ansible playbook 的重要性(GPT4 和 llama2-70B 下测试,成功率从个位数提升到百分之七八十。另一个有趣的结论是温度设置最好为 0.6):https://dl.acm.org/doi/pdf/10.1145/3663529.3663855
  • 浙大/华为开源的 KTeleBERT 项目,综合知识图谱和 BERT 大模型,同时利用产品手册、设备告警日志和 KPI 异常进行通讯领域故障分析:https://github.com/hackerchenzhuo/KTeleBERT
  • 华为/中科大开源的 Biglog 大模型,基于 Bert 利用 16 个项目的4 亿 5 千万日志做无监督预训练:https://github.com/BiglogOpenSource/PretrainedModel。对应论文见:https://ieeexplore.ieee.org/document/10188759/
  • 华为/北邮发布的 LogPrompt 论文,利用 ChatGPT 和 Vicuna-13B 验证 zero-shot、CoT、ICL 几种不同 prompt 方案下的日志模板提取和异常检测效果:https://arxiv.org/pdf/2308.07610.pdf。对比基准就是上面的 LogPPT,结论是 ChatGPT 即使 zero-shot 也比 LogPPT 强一点。而开源的 Vicuna-13B 在 zero-shot 情况下差很多,但 ICL 方案下效果提升很大,接近可用水准。
  • 北航/云智慧开源的 Owl 运维大模型数据集,包括问答题和多选题两类:https://github.com/HC-Guo/Owl。对应论文中还评测了 MoA 微调、NBCE 长上下文支持、在 loghub 日志模式识别上的差异,不过优势都很微弱。
  • 北航/云智慧发表的 ECLIPSE 论文,重点解决实际日志模式过多问题(除了 logpub 以外还自己做了一个 ECLIPSE-Bench 数据集):https://arxiv.org/pdf/2405.13548。大致思路是在日志模式提取后,再用 LLM 提取模板对应的核心单词和punct标点,然后构建{关键词:标点模板}词典存入 faiss 向量数据库。然后新日志先通过faiss 做 kNN 搜索,只在搜索结果内做 LCS 最长子串匹配逻辑来考虑是否合并更新模式。
    • 北大/港中深的 AdaParser 论文:https://arxiv.org/pdf/2406.03376。类似思路上,加了一个 corrector 模块,包括对匹配失败的“错误”模式的更正、“正确”模式里一些不恰当变量(关键信息保留为常量)的更正。
    • 重庆大学的 LogBatcher 项目:https://anonymous.4open.science/r/LogBatcher/README.md。类似思路,而且就用了基础的 TF-IDF 和 DBSCAN 来实现聚类,DPP 实现采样。一个额外改进就是模板缓存里会记录频率并重排序。最后评估结果里还对比了 tokens 消耗,比 LILAC 省钱~
    • 阿里巴巴美国的 LogParser-LLM 论文:https://dl.acm.org/doi/pdf/10.1145/3637528.3671810。类似思路,额外改进时候区分了“松散匹配”,对松散匹配的模式可以让 LLM 更新。最后评估结果里还对比了 LLM 调用次数,但是如果换算成 tokens 消耗的话,应该不如 LogBatcher 省钱~
  • 清华/必示发表的 OpsEval 论文,场景和 Owl 类似,不过仅对比开源模型的表现,并区分中英文差异。实践发现中文问答质量差很多:https://arxiv.org/pdf/2310.07637.pdf
  • 北大/蚂蚁金服开源的 CodeFuse-DevOpsEval 评测数据集,包括 DevOps 和 AIOps 两大块12类场景的选择器:https://github.com/codefuse-ai/codefuse-devops-eval/blob/main/README_zh.md,不过 AIOps 里根因分析场景 qwen 的分数异常的高,我个人怀疑是不是 qwen 预训练用到了阿里巴巴内部资料。
  • 香港中文大学/微软发表的 UniLog 论文,把 LLM 的 ICL 方法用在日志增强领域:https://www.computer.org/csdl/proceedings-article/icse/2024/021700a129/1RLIWpCelqg
  • 复旦大学开源的 KnowLog 项目,爬取了思科、新华三、华为三家网络设备的公开文档里关于日志模板的描述内容,基于 Bert 和 RoBerta 做预训练模型:https://github.com/LeaperOvO/KnowLog

标注

指标异常标注

预测

单指标

容量规划

网络

事件关联挖掘

根因分析

调用链

多维定位

时序相关性分析

解决方案相关性推荐

大模型方法

  • 北大发表的故障管理领域大模型研究综述:https://arxiv.org/pdf/2406.11213
  • 东南大学发表的根因分析领域算法研究综述,3.5 小节是大模型部分:https://arxiv.org/pdf/2408.00803。比较有意思是开篇总结了一个表格,列出来了最近 3 年国内外有名的 14 次互联网厂商大型故障影响和原因。
  • 微软发表的 Xpert 论文,从告警工单入口,依赖告警消息内容作为上下文,生成微软Azure自有的 Kusto Query Language:https://arxiv.org/pdf/2312.11988.pdf。论文提出了一个 Xcore 评价方法,从文本、符号、字段名匹配度多方面综合评估。不过文中举的错误示例,告警上线文和正确输出之间一个字都对不上,实在是不可能写对——本文给我的另一个提示:纯粹通过 Chat 形式让人提问生成查询语句,上下文信息太少,太难。当前阶段合适的策略还是找一些特定入口。
  • 微软发表的《Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models》论文,通过对微软内部4万个故障数据复盘,研究 GPT 模型对比 BERT 模型是否在故障诊断方面更有优势。大概的结论可以认为是:有优势,但依然没啥用。:https://arxiv.org/pdf/2301.03797.pdf
  • 微软亚研/南开发表的《Assess and Summarize: Improve Outage Understanding with Large Language Models》论文,对比 GPT2(本地单卡微调),GPT3(6.7b)和 GPT3.5(175b) 的告警概要水平。3 到 2 确实差异非常明显,但 6.7b 到 175b 倒没有提升特别多:https://arxiv.org/pdf/2305.18084.pdf
  • 微软发表的 RCACopilot 论文:https://yinfangchen.github.io/assets/pdf/rcacopilot_paper.pdf。先对告警信息做摘要,然后用预训练的 fasttext 嵌入模型来做历史故障的向量搜索,在最终的 prompt 里同时提供摘要和历史故障的分类和描述,让 LLM 判断是不是老故障,是的话用 CoT 推理怎么处理。论文中提供了较多的评估数据,但本身对实验运用的团队和业务环境有强依赖,很难判断适用性。
  • 微软发表的另一篇 ReAct 框架做 RCA 的技术报告:https://arxiv.org/pdf/2403.04123.pdf。大概结论是:不开发特定 Tool,靠通用的文档召回 tool,ReAct 效果还不如直接 RAG 或 CoT。即使开发特定 Tool,知识库里的分析计划写的如何,也才是影响最大的。一旦涉及多个知识库文档,ReAct 差不多到第二三轮就会一直失败下去了。
  • 阿里云 Flink 团队发表的 RCAgent 论文: https://arxiv.org/pdf/2310.16340v1。其中为了对 flink 错误日志做概要,设计了一大段巨复杂的流程(向量转换,滚动构建矩阵,Louvain贪婪去重聚类,RGA 生成解释和证据,计算证据和原始日志的LEVENSHTEIN距离做过滤,最后二次概要)。
  • Flip.AI 公司,自研的 DevOps 大模型,发表了技术报告。采用了 1 encoder -> N decoder 的 MoE 架构,在 80B token 上增量预训练;微调训练部分主要数据来源是基于 RAG 的 evol-instruct 仿真数据再辅以 18 个月的人工双盲过滤;强化学习阶段是 RLHAIF,构建一个故障注入环境,让模型生成 RCA 报告:https://assets-global.website-files.com/65379657a6e8b5a6ad9463ed/65a6ec298f8b53c8ddb87408_System%20of%20Intelligent%20Actors_FlipAI.pdf

告警归并

图谱

行为异常

扩展阅读

About

Collection of slides, repositories, papers about AIOps

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published