相关内容以前记录的比较多。
逐渐级别推断
资源
应用视角==》单个报警
alarm 报警
报警的主视角
metric 指标
普米: (cpu/mem/disk/net)
SQL: SQL 报警
CAT
log===>异常日志
知识库
日志
top3 去重的异常日志?
Trace
cmdb
rpc
事件
变更(标准化)
相关内容以前记录的比较多。
资源
应用视角==》单个报警
报警的主视角
普米: (cpu/mem/disk/net)
SQL: SQL 报警
CAT
log===>异常日志
知识库
top3 去重的异常日志?
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
app
phy / vm / redis / mysql / pod / ...
包括网络:
vm / phy ====> nginx
结合 ai 打造 rca 系统,先让 ai 回答一下。
NOC 是 Network Operations Center(网络运营中心)的缩写。
NOC 是一个集中监控、管理和维护 IT 基础设施和服务可用性的指挥中心,主要职责是确保网络、服务器、应用、服务等持续稳定运行。
功能 | 说明 |
---|---|
🔍 实时监控 | 网络设备、服务器、应用、链路、指标、告警等 |
🚨 故障响应 | 第一时间响应报警,初步诊断、升级或处理 |
📈 性能分析 | 长期观察网络与系统的健康状态,识别瓶颈 |
🛠️ 例行运维 | 执行计划任务、补丁更新、重启、配置调整等 |
📊 报表输出 | 生成服务SLA、可用性、故障统计等运营数据 |
📞 客户支持对接 | 某些NOC也兼任部分一线技术支持角色 |
结合 ai 打造 rca 系统,先让 ai 回答一下。
“COT” 有多个含义,具体要看上下文。但结合你目前的关注点(AI + 根因分析 + 智能推理 + 运维场景),COT 更可能是指:
这是在使用 大语言模型(LLM) 时的一种提示工程和推理策略,它通过**引导模型“逐步推理”**来提升复杂任务(如故障分析、逻辑推理、多步骤计算等)的准确率。
结合 ai 打造 rca 系统,先让 ai 回答一下。
很好,这是一个非常有挑战性且具有前瞻性的系统性工程。你想打造的“AI智能根因分析系统平台”,是典型的AIOps高阶场景核心组成部分。下面我会以“从0到1”思路,从架构理念、模块拆解、数据流转、AI应用、落地方式等角度,帮你系统梳理方案。
结合 ai 打造 rca 系统,先让 ai 回答一下。
非常好,这是在构建AIOps根因分析系统时最核心的一环:从 NOC 一线告警接收开始,逐步推理 → 定位根因 → 输出解释型分析报告 → 人工反馈修正 → 模型持续学习提升准确率。
我会结合你的背景,给出一套实战可落地的完整闭环流程(Pipeline),包括数据路径、推理链、打分机制与学习反馈。