相关内容以前记录的比较多。

逐渐级别推断

资源

应用视角==》单个报警

alarm 报警

报警的主视角

metric 指标

普米: （cpu/mem/disk/net）

SQL: SQL 报警

CAT

log===>异常日志

知识库

日志

top3 去重的异常日志？

Trace

cmdb

rpc

事件

变更（标准化）

说明

如果一个变更，可能会导致对应的异常。

标准化

首先要对报警的数据进行标准的格式化处理。

比如应用名，执行时间等等

变更的内容

ip + appName

时间范围

如果页面选择了一个时间范围

比如：18:00~18:30

那么，对应的变更事件应该怎么办呢？

1）create_time

事件的创建时间刚好介于 18:00~18:30

16:00 and 18:30

都是这样来处理是不是比较合理？

说明

要考虑哪些异常的内因呢？

同时考虑一些依赖资源的异常。

现状

特别精确的时间范围控制，会导致无法准确的命中。

内因

磁盘 一般 A2 以及以下可以忽略

mem 内存 A2 以及以下可以忽略?

disk ?

cpu ?

可以看一下 A2 以及以下的是不是没什么用？

GC

服务不可用

依赖资源

公共资源

app

vm

phy

应用

从报警的应用触发，经过 3 层左右，关联到所有报警的物理机器资源？

通用性

可以考虑将开头的 appList 放在入参，和目标存在问题的资源 ipList 放在那里？

精致的细分

可以把各种资源还是区分开？

统一调整一下【查看子图】的具体实现逻辑？

去重

去重的时候，不要把 app 之类的给去没有了？？

参考资料

场景

我们接收到报警之后，需要把报警信息落库。

其实有两种思路。

一种是流，一种是批模式。

优缺点

批

批模式可以做一些批量的优化操作。

比如 A2 的 disk 之类的无用异常过滤。

批模式如果改为 10 秒一次呢？

有什么问题？

批模式还可以支持数据的重跑，但是流没有这个能力。

可以两种模式都保留。

流

流模式可以在数据全部落库之后，最后做一下数据的落库处理。

实时性比较高。

场景

我们需要分析报警，但是资源信息等很多，所以需要分级+剪枝过滤

基本的步骤

1）从 alarm==>app

从报警关联到所有的 app

2. 从 alarm 找到所有的关联报警的资源

app

phy / vm / redis / mysql / pod / ...

包括网络：

vm / phy ====> nginx

3. app 的进一步关联资源

结合 ai 打造 rca 系统，先让 ai 回答一下。

chat

NOC 是什么？

NOC 是 Network Operations Center（网络运营中心）的缩写。

---

✅ 简单定义：

NOC 是一个集中监控、管理和维护 IT 基础设施和服务可用性的指挥中心，主要职责是确保网络、服务器、应用、服务等持续稳定运行。

---

📡 NOC 的典型职责：

功能	说明
🔍 实时监控	网络设备、服务器、应用、链路、指标、告警等
🚨 故障响应	第一时间响应报警，初步诊断、升级或处理
📈 性能分析	长期观察网络与系统的健康状态，识别瓶颈
🛠️ 例行运维	执行计划任务、补丁更新、重启、配置调整等
📊 报表输出	生成服务SLA、可用性、故障统计等运营数据
📞 客户支持对接	某些NOC也兼任部分一线技术支持角色

结合 ai 打造 rca 系统，先让 ai 回答一下。

chat

详细介绍一下 COT

“COT” 有多个含义，具体要看上下文。但结合你目前的关注点（AI + 根因分析 + 智能推理 + 运维场景），COT 更可能是指：

---

🧠 COT = Chain of Thought（思维链）

这是在使用 大语言模型（LLM） 时的一种提示工程和推理策略，它通过**引导模型“逐步推理”**来提升复杂任务（如故障分析、逻辑推理、多步骤计算等）的准确率。

结合 ai 打造 rca 系统，先让 ai 回答一下。

chat

你是一名监控报警+运维的资深架构师，经验丰富，知识跨多个领域。现在让你使用AI大模型，利用报警信息、日志、指标、Trace+专家知识库（可以降级为AI通识），如何从零到1打造AI智能根因分析系统平台？

很好，这是一个非常有挑战性且具有前瞻性的系统性工程。你想打造的“AI智能根因分析系统平台”，是典型的AIOps高阶场景核心组成部分。下面我会以“从0到1”思路，从架构理念、模块拆解、数据流转、AI应用、落地方式等角度，帮你系统梳理方案。

---

🎯 目标定义