Shadowgraph
TrendingBuzzResearch
Chrome extension
Sign in

chenryn/aiops-handbook

Collection of slides, repositories, papers about AIOps

1,571

111 commits

updated Mar 17, 2026

See the code

README

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 云平台上的匿名数据。
  • 清华裴丹团队开源的 ChatTS 指标问答大模型：https://github.com/NetManAIOps/ChatTS。基于 qwen2.5-14B 做的增量预训练和微调对齐。预训练数据的合成，参照 evol-instruct 设计了一套 TS-Evol 方案。指标数据入大模型之前，先有一个自训练的 5 层 MLP encoder。
    • MCQ2 reasoning 指标问答推理数据集：https://aclanthology.org/2024.findings-emnlp.201.pdf。数据集不限于运维场景，ChatTS 中只是抽取里这个数据集的一小部分。该数据集也是合成数据，不过是由 GPT4o 根据不同场景设定生成 python 代码再运行合成的。
    • 北邮/中国联通发表的 ChatTime 论文：在 llama2-7B 基础上做的增量预训练和微调对齐。直接将指标数据做归一化再分桶，然后当 token 处理，扩展词表。和 ChatTS 都有指标分类场景的评估，按 GPT4 为共同基准的话，ChatTime 效果差一些。
  • 阿里/复旦发表的 PromAssistant 论文：通过类 GraphRAG 方案实现针对 k8s 监控指标的 NL2PromQL。根据测试，直接调用 LLM 的语法准确率就有96%，因此主要解决的是怎么写对指标和标签名称的问题。

日志

传统方法

大模型方法

  • 北航发表的 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
  • 浙大/华为开源的 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 方案下效果提升很大，接近可用水准。
    • 后续发布的 R-Log 论文和开源项目：在 LogPrompt 数据集基础上，通过人工经验总结的模板，扩展出thinking 过程，然后进行 qwen2.5 冷启动微调和强化学习。论文额外还训练了一个 R-Log-fast，先输出结果再输出 thinking，对比发现在日志解读方面效果明显变差。
  • 北航/云智慧开源的 Owl 运维大模型数据集，包括问答题和多选题两类：https://github.com/HC-Guo/Owl。对应论文中还评测了 MoA 微调、NBCE 长上下文支持、在 loghub 日志模式识别上的差异，不过优势都很微弱。
  • 华为开源的 SuperLog 数据集：在 loghub 数据集的基础上，进行模式比例调整重构，然后针对每个模板，分 5 个维度(Grok 正则、日志解读、根因分析、组件关联分析、潜在故障预测) 10 个模板，生成25 万条问答。
  • 北航/云智慧发表的 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 省钱～
    • 北大的 VISTA 论文：https://dl.acm.org/doi/pdf/10.1145/3696630.3728506。认为 ICL 里提供给 LLM 的示例，不应该找模板文本相似度最高的，而应该找参数变量相似度最高的？！本文评估中速度比 Drain 还快一点，但是没给准确度数据？
      • 后续进展：https://github.com/mianmaner/VarParser。在 VISTA 的基础上，进一步修改，连ICL 里的示例，也不用日志原文，直接处理成变量的“内容→名称”对。这次评测数据也比较全面，但速度慢了一点点。
  • 中山大学开源的 InferLog 项目，通过对 ICL 示例的优化(排序和参数替换等)，提升大模型推理的 KVCache 命中率，从而加速大模型日志解析效率。本方案应该可以跟 LILAC/DivLog/AdaParser/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
  • NVidia/Cadence 发表的 schemaCoder 论文：http://arxiv.org/pdf/2508.18554。采用智能体方案生成日志解析规则。大致思路是先聚类采样，基于采样日志生成探索性问题，让 LLM 根据问题找出聚类中可以用来回答的原文，然后根据原文生成 python 正则，最后遍历迭代直到全部解析成功。两个大问题：迭代巨慢，loghub 日志解析 77 秒，迭代 4 小时；大模型完全不熟悉 EDA 的place & route 日志，最后由专家编写探索性问题——所以我个人质疑 TDEngine 公司所谓“无问智推”功能的落地可行性。

标注

指标异常标注

预测

单指标

容量规划

网络

事件关联挖掘

根因分析

调用链

多维定位

时序相关性分析

解决方案相关性推荐

大模型方法

  • 北大发表的故障管理领域大模型研究综述：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 形式让人提问生成查询语句，上下文信息太少，太难。当前阶段合适的策略还是找一些特定入口。
  • google 开源的 NL2LogQL 问答数据集：https://huggingface.co/datasets/nl-to-logql/natural-logql。数据集主要针对 loghub 里 openstack、hdfs 和 openssh 三种源日志，对应的 grafana dashboard 的趋势图，然后按照 LogQL 语句的复杂度做了比例调整。
  • 新加坡国立大学开源的 RulePilot 项目：https://github.com/LLM4SOC-Topic/RulePilot，主要实现把安全场景的 SPL 转换成 KQL。中间有一层自己设计的 IR 结构化描述。但本文研究完全忽略了 SPL 中大量存在的 macro 嵌套、datamodel 定义情况，所以不可能普遍使用！
  • 微软发表的《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 推理怎么处理。论文中提供了较多的评估数据，但本身对实验运用的团队和业务环境有强依赖，很难判断适用性。
  • 微软/港中文发表的 AidAI 论文：http://arxiv.org/pdf/2506.01481。针对 GPU 集群故障诊断的多智能体框架。其实核心是总结好的故障分类树。文中附图 17 建议放大细看。
  • 浙大/阿里云发表的 Kunlun Anomaly Troubleshooter 论文：http://arxiv.org/pdf/2511.05978。针对LLM 推理集群的异常检测和故障分析方案。主要是针对 GPU 线程的 kernel 级 trace 树构建和耗时 3-sigma 检测。
  • 微软发表的另一篇 ReAct 框架做 RCA 的技术报告：https://arxiv.org/pdf/2403.04123.pdf。大概结论是：不开发特定 Tool，靠通用的文档召回 tool，ReAct 效果还不如直接 RAG 或 CoT。即使开发特定 Tool，知识库里的分析计划写的如何，也才是影响最大的。一旦涉及多个知识库文档，ReAct 差不多到第二三轮就会一直失败下去了。
  • 清华/微软开源的 AIOpsLab 项目：https://microsoft.github.io/AIOpsLab/。提供了一套 AIOps 从检测到定位到修复的评估框架。首批对比了直接使用 GPT 和 ReAct 方案、以及微软之前发表的FLUSH智能体方案的差异。结果分析里最有趣的是：成功 case 里其实调用 get_metric 和 get_trace tools 的比例很低！也就是说直接 kubectl 工具分析不出来的故障，就算再加指标和调用链，成功概率也不高了。
    • 清华/IBM 开源的 STRATUS 项目：https://anonymous.4open.science/r/stratus-agent。基于 crewai 框架实现，在 AIOpsLab 和 ITBench 上测试的智能体方案。最大贡献点是 undo agent，和怎么判断需要回退。也是我见到的第一个真正尝试修复故障的探索！
    • RSAC 实验室公布的论文：https://pasquini-dario.github.io/me/aioops.pdf，用 AIOpsLab 测试床演示如何注入攻击运维智能体。
    • 沙特阿卜杜拉国王科技大学/中国电子科大开源的 NIKA，在 AIOpsLab 的启发下，做的针对网络运维故障发现和分析的基准测试床（包括开源 kathara 仿真、iperf 压测、基于 FastMCP 和 langgraph 构建的智能体）。
  • 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
  • 阿里云 Flink 团队发表的 RCAgent 论文: https://arxiv.org/pdf/2310.16340v1。其中为了对 flink 错误日志做概要，设计了一大段巨复杂的流程（向量转换，滚动构建矩阵，Louvain贪婪去重聚类，RGA 生成解释和证据，计算证据和原始日志的LEVENSHTEIN距离做过滤，最后二次概要）。
  • 港中深开源的 OpenRCA 数据集：将之前三届 AIOps 挑战赛的数据集整理过滤，方便进行 RCA 智能体评测。论文自己也实现了一个简单的 Agent 但是效果很一般。注意数据集中有一些号称故障但其实对业务指标毫无影响的场景，我个人认为并无 RCA 必要。
  • 中山大学开源的 Cloud-OpsBench 数据集，和 OpenRCA、AIOpsLab、ITBench 相比，可复现、工具明确、支持 agentic 流程、考虑了外部知识增强场景。
  • 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
  • IncidentFox 公司，对应开源项目：https://github.com/incidentfox/incidentfox。其中有大量的 skills。但其实 skills 之间区分度也不太明显。至少我自己测试同样问题，GPT-5.3 一会儿选 investigator 一会儿选 observability……

告警归并

图谱

行为异常

扩展阅读

aiops
anomalydetection
kpi

Significant stargazers

Kay Yan

321 followers · starred Dec 2025

Qingsong Wen

659 followers · starred Aug 2019

Daniel (Shijun) Qian

225 followers · starred Feb 2024

conghuhu

85 followers · starred Oct 2023

Similar repos

OpsPAI/awesome-AIOps

A curated list of awesome academic researches and industrial materials about Artificial…

331

linjinjin123/awesome-AIOps

AIOps学习资料汇总，欢迎一起补全这个仓库，欢迎star

1,753

phamquiluan/awesome-failure-diagnosis

Awesome resources for failure diagnosis research.

68

yzhao062/anomaly-detection-resources

Anomaly detection related books, papers, videos, and toolboxes. Last update late 2025 for LLM and…

9,414

rob-med/awesome-TS-anomaly-detection

List of tools & datasets for anomaly detection on time-series data.

3,168

Jun-jie-Huang/awesome-LLM-AIOps

A list of awesome academic researches and industrial materials about Large Language Model (LLM) and…

673

logpai/logparser

A machine learning toolkit for log parsing [ICSE'19, DSN'16]

1,993

TSCenter/awesome-time-series-papers

An Awesome List of the latest time series papers and code from top AI venues.

1,130

chenryn/aiops-handbook

Collection of slides, repositories, papers about AIOps

1,571

111 commits

updated Mar 17, 2026

See the code

README

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 云平台上的匿名数据。
  • 清华裴丹团队开源的 ChatTS 指标问答大模型：https://github.com/NetManAIOps/ChatTS。基于 qwen2.5-14B 做的增量预训练和微调对齐。预训练数据的合成，参照 evol-instruct 设计了一套 TS-Evol 方案。指标数据入大模型之前，先有一个自训练的 5 层 MLP encoder。
    • MCQ2 reasoning 指标问答推理数据集：https://aclanthology.org/2024.findings-emnlp.201.pdf。数据集不限于运维场景，ChatTS 中只是抽取里这个数据集的一小部分。该数据集也是合成数据，不过是由 GPT4o 根据不同场景设定生成 python 代码再运行合成的。
    • 北邮/中国联通发表的 ChatTime 论文：在 llama2-7B 基础上做的增量预训练和微调对齐。直接将指标数据做归一化再分桶，然后当 token 处理，扩展词表。和 ChatTS 都有指标分类场景的评估，按 GPT4 为共同基准的话，ChatTime 效果差一些。
  • 阿里/复旦发表的 PromAssistant 论文：通过类 GraphRAG 方案实现针对 k8s 监控指标的 NL2PromQL。根据测试，直接调用 LLM 的语法准确率就有96%，因此主要解决的是怎么写对指标和标签名称的问题。

日志

传统方法

大模型方法

  • 北航发表的 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
  • 浙大/华为开源的 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 方案下效果提升很大，接近可用水准。
    • 后续发布的 R-Log 论文和开源项目：在 LogPrompt 数据集基础上，通过人工经验总结的模板，扩展出thinking 过程，然后进行 qwen2.5 冷启动微调和强化学习。论文额外还训练了一个 R-Log-fast，先输出结果再输出 thinking，对比发现在日志解读方面效果明显变差。
  • 北航/云智慧开源的 Owl 运维大模型数据集，包括问答题和多选题两类：https://github.com/HC-Guo/Owl。对应论文中还评测了 MoA 微调、NBCE 长上下文支持、在 loghub 日志模式识别上的差异，不过优势都很微弱。
  • 华为开源的 SuperLog 数据集：在 loghub 数据集的基础上，进行模式比例调整重构，然后针对每个模板，分 5 个维度(Grok 正则、日志解读、根因分析、组件关联分析、潜在故障预测) 10 个模板，生成25 万条问答。
  • 北航/云智慧发表的 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 省钱～
    • 北大的 VISTA 论文：https://dl.acm.org/doi/pdf/10.1145/3696630.3728506。认为 ICL 里提供给 LLM 的示例，不应该找模板文本相似度最高的，而应该找参数变量相似度最高的？！本文评估中速度比 Drain 还快一点，但是没给准确度数据？
      • 后续进展：https://github.com/mianmaner/VarParser。在 VISTA 的基础上，进一步修改，连ICL 里的示例，也不用日志原文，直接处理成变量的“内容→名称”对。这次评测数据也比较全面，但速度慢了一点点。
  • 中山大学开源的 InferLog 项目，通过对 ICL 示例的优化(排序和参数替换等)，提升大模型推理的 KVCache 命中率，从而加速大模型日志解析效率。本方案应该可以跟 LILAC/DivLog/AdaParser/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
  • NVidia/Cadence 发表的 schemaCoder 论文：http://arxiv.org/pdf/2508.18554。采用智能体方案生成日志解析规则。大致思路是先聚类采样，基于采样日志生成探索性问题，让 LLM 根据问题找出聚类中可以用来回答的原文，然后根据原文生成 python 正则，最后遍历迭代直到全部解析成功。两个大问题：迭代巨慢，loghub 日志解析 77 秒，迭代 4 小时；大模型完全不熟悉 EDA 的place & route 日志，最后由专家编写探索性问题——所以我个人质疑 TDEngine 公司所谓“无问智推”功能的落地可行性。

标注

指标异常标注

预测

单指标

容量规划

网络

事件关联挖掘

根因分析

调用链

多维定位

时序相关性分析

解决方案相关性推荐

大模型方法

  • 北大发表的故障管理领域大模型研究综述：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 形式让人提问生成查询语句，上下文信息太少，太难。当前阶段合适的策略还是找一些特定入口。
  • google 开源的 NL2LogQL 问答数据集：https://huggingface.co/datasets/nl-to-logql/natural-logql。数据集主要针对 loghub 里 openstack、hdfs 和 openssh 三种源日志，对应的 grafana dashboard 的趋势图，然后按照 LogQL 语句的复杂度做了比例调整。
  • 新加坡国立大学开源的 RulePilot 项目：https://github.com/LLM4SOC-Topic/RulePilot，主要实现把安全场景的 SPL 转换成 KQL。中间有一层自己设计的 IR 结构化描述。但本文研究完全忽略了 SPL 中大量存在的 macro 嵌套、datamodel 定义情况，所以不可能普遍使用！
  • 微软发表的《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 推理怎么处理。论文中提供了较多的评估数据，但本身对实验运用的团队和业务环境有强依赖，很难判断适用性。
  • 微软/港中文发表的 AidAI 论文：http://arxiv.org/pdf/2506.01481。针对 GPU 集群故障诊断的多智能体框架。其实核心是总结好的故障分类树。文中附图 17 建议放大细看。
  • 浙大/阿里云发表的 Kunlun Anomaly Troubleshooter 论文：http://arxiv.org/pdf/2511.05978。针对LLM 推理集群的异常检测和故障分析方案。主要是针对 GPU 线程的 kernel 级 trace 树构建和耗时 3-sigma 检测。
  • 微软发表的另一篇 ReAct 框架做 RCA 的技术报告：https://arxiv.org/pdf/2403.04123.pdf。大概结论是：不开发特定 Tool，靠通用的文档召回 tool，ReAct 效果还不如直接 RAG 或 CoT。即使开发特定 Tool，知识库里的分析计划写的如何，也才是影响最大的。一旦涉及多个知识库文档，ReAct 差不多到第二三轮就会一直失败下去了。
  • 清华/微软开源的 AIOpsLab 项目：https://microsoft.github.io/AIOpsLab/。提供了一套 AIOps 从检测到定位到修复的评估框架。首批对比了直接使用 GPT 和 ReAct 方案、以及微软之前发表的FLUSH智能体方案的差异。结果分析里最有趣的是：成功 case 里其实调用 get_metric 和 get_trace tools 的比例很低！也就是说直接 kubectl 工具分析不出来的故障，就算再加指标和调用链，成功概率也不高了。
    • 清华/IBM 开源的 STRATUS 项目：https://anonymous.4open.science/r/stratus-agent。基于 crewai 框架实现，在 AIOpsLab 和 ITBench 上测试的智能体方案。最大贡献点是 undo agent，和怎么判断需要回退。也是我见到的第一个真正尝试修复故障的探索！
    • RSAC 实验室公布的论文：https://pasquini-dario.github.io/me/aioops.pdf，用 AIOpsLab 测试床演示如何注入攻击运维智能体。
    • 沙特阿卜杜拉国王科技大学/中国电子科大开源的 NIKA，在 AIOpsLab 的启发下，做的针对网络运维故障发现和分析的基准测试床（包括开源 kathara 仿真、iperf 压测、基于 FastMCP 和 langgraph 构建的智能体）。
  • 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
  • 阿里云 Flink 团队发表的 RCAgent 论文: https://arxiv.org/pdf/2310.16340v1。其中为了对 flink 错误日志做概要，设计了一大段巨复杂的流程（向量转换，滚动构建矩阵，Louvain贪婪去重聚类，RGA 生成解释和证据，计算证据和原始日志的LEVENSHTEIN距离做过滤，最后二次概要）。
  • 港中深开源的 OpenRCA 数据集：将之前三届 AIOps 挑战赛的数据集整理过滤，方便进行 RCA 智能体评测。论文自己也实现了一个简单的 Agent 但是效果很一般。注意数据集中有一些号称故障但其实对业务指标毫无影响的场景，我个人认为并无 RCA 必要。
  • 中山大学开源的 Cloud-OpsBench 数据集，和 OpenRCA、AIOpsLab、ITBench 相比，可复现、工具明确、支持 agentic 流程、考虑了外部知识增强场景。
  • 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
  • IncidentFox 公司，对应开源项目：https://github.com/incidentfox/incidentfox。其中有大量的 skills。但其实 skills 之间区分度也不太明显。至少我自己测试同样问题，GPT-5.3 一会儿选 investigator 一会儿选 observability……

告警归并

图谱

行为异常

扩展阅读

aiops
anomalydetection
kpi

Significant stargazers

Kay Yan

321 followers · starred Dec 2025

Qingsong Wen

659 followers · starred Aug 2019

Daniel (Shijun) Qian

225 followers · starred Feb 2024

conghuhu

85 followers · starred Oct 2023

Similar repos

OpsPAI/awesome-AIOps

A curated list of awesome academic researches and industrial materials about Artificial…

331

linjinjin123/awesome-AIOps

AIOps学习资料汇总，欢迎一起补全这个仓库，欢迎star

1,753

phamquiluan/awesome-failure-diagnosis

Awesome resources for failure diagnosis research.

68

yzhao062/anomaly-detection-resources

Anomaly detection related books, papers, videos, and toolboxes. Last update late 2025 for LLM and…

9,414

rob-med/awesome-TS-anomaly-detection

List of tools & datasets for anomaly detection on time-series data.

3,168

Jun-jie-Huang/awesome-LLM-AIOps

A list of awesome academic researches and industrial materials about Large Language Model (LLM) and…

673

logpai/logparser

A machine learning toolkit for log parsing [ICSE'19, DSN'16]

1,993

TSCenter/awesome-time-series-papers

An Awesome List of the latest time series papers and code from top AI venues.

1,130