Skip to content

chenryn/aiops-handbook

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

106 Commits
LICENSE
LICENSE
 
 
README.md
README.md
 
 
README_en.md
README_en.md
 
 

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

kpi anomalydetection aiops

Resources

Readme

License

Apache-2.0 license
Activity

Stars

1.3k stars

Watchers

67 watching

Forks

281 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 3

  •  
  •  
  •