>100 Views
July 20, 26
スライド概要
cnusergroup
From Signals to Cognition: Building Ontology-Driven AIOps on Graph 从信号到认知:基于图与本体构建智能运维(AIOps) Report By:郭晗
NebulaGraph JDC Tec. 郭晗【NebulaGraph SA】 Email:[email protected] Github:Hans-bot666 SensorsData
https://nebula-graph.com.cn What is Graph ? ● A graph is an abstract data structure consisting of nodes(vertices) and edges. ●Every node/edge has a type and some attributes. Name:“Lucy” Birthday:1996.06 Name:“John” Birthday:1998.05 Couple Transfer Node ⚫ Represent objects in the graph Edge ⚫ Connect nodes(with/without direction) ⚫ Denoting connections or associations A Transaction _Time:“2025-1-1 18:00:00” Amount:”1” Currency: ”Bitcoin” Ratio: "0.2" Title:“GM” Work_Period:”2025-1-1" between them. Attribute(on Node/Edge) ⚫ Name-value B Company_Name:“Vesoft”
How to Store/Query/Analyze ? —— Graph Database Relational Database https://nebula-graph.com.cn Graph Database • Use table to store data ✓ Use graph to store data • Query via SQL ✓ Query via ISO-GQL • Good performance in single-table CURD ✓ Built for super large-scale graphs with milliseconds of latency • Bad performance in multi joins ✓ Good performance in multi-hop query ✓ Support Graph Algorithm
1.Why AIOps Has Yet to Reach Enterprise-Scale Adoption?
AIOps 现状 成熟度 监控 Prometheus、Zabbix 告警降噪、异常检测 AIOps1.0 AI调查事故、分析日志 生成修复建议 AIOps2.0 Autono mous Ops AI分析事故根因, 自动执行修复 AI参与度
Why Hasn't AIOps Truly Landed? 挑战二:AI 无法统一理解运维数据 日志、指标、Trace、CMDB 等数据相互割裂,缺乏统一对象模型。 挑战一:AI 无法理解企业运维系统 缺乏系统拓扑与业务语义,无法进行因果推理。 502 errors usually relate to gateways OOM Killed means container memory shortage Which business module does metric biz_order_latency_p99 belong to? Which services call each other, and how (sync/async)?
2.How Graph Ontology Empower AIOps?
AIOps Graph Ontology Schema 01 核心节点类型包括 实体集(可观察实体的集合,定义了一类实体资源的主 键、属性和状态) 观测数据集(可观察数据的通用表示,涵盖日志集、指 标集、跟踪集、事件集等)、存储(存储抽象)和资源 管理器(可视化抽象)。 02 核心关系类型包括 实体关系链接(实体之间的关系,例如“服务”、“调 用”、“包含”、“运行于”、“与……相同”) 数据关系链接(数据与实体之间的关联关系,例如,某一 类日志属于某一服务) 存储关系链接(建模抽象与具体存储之间的关联) 探索者链接(数据节点与可视化节点之间的关系)。
Best practice-KGops
从数据到知识,从事实到事理 本体定义(Thomas R. Gruber) : Ontology is a formal, explicit specification of a shared conceptualization 本体是对某一领域“共享概念模型”的形式化、明确化描述 本体定义 Conceptualization “世界是什么” (概念化) 账户表 订单表 作用 、 交易记录 数据 企业难题 不显性 碎片化 Explicit (显式化) 消除隐式理解 弱语义 歧义性 Formal (形式化) 让机器可处理 弱语义 歧义性 统一认知标准 随意性 歧义性 碎片化 Shared (共享) 客户画像 知识 商品画像 购买习惯 本体是 AI 落地企业核心的数字骨架 描述的是 事实 描述的是 事理
有了图+本体后区别在哪里 观测 数据 观测 数据 指标/日志 链路事件 订单服务 实体 依赖 关系 依赖 关系 上游:Mysql主库 下游:支持服务 绑定 的知识 慢查询Runbook 故障 传播 Node-5
数据流与访问关系分析 xx Application Crashed xx Application Crashed pod restart trigger 应用崩溃可能由以下原因 引起: 1、磁盘使用率已达90% 2、pod重启次数增加; metrics Logs Trace HealthCheck failed Log written failed Node-A Disk full 磁盘属于哪个应用 健康检查依赖哪些组件 Kubernetes Restart 的触发条件 由于节点 Node-A 磁盘空 间耗尽,导致 Payment Service 日志写入失败, 引发健康检查失败,最终 触发 Kubernetes 重启 Pod, 是本次故障的根因
风险分摊模型:从资源风险到业务风险传导 supports runs_on deploys_on Business Service Sever Risk Middleware Application Physical Server Database Risk LPA: Weight=10 Risk(Node)=自身风险×业务权重×传播系数 Application Risk 1.DB-01影响: 支付系统 清算系统 影响普通测试系统? OR sever risk = High Risk=80 影响核心交易系统? 风险会传播到哪里? 风险:95 2.Server-23 影响: 查询系统 风险:30 ✓ 优先治理高价值风险 ✓ 优化资源部署 ✓ 提升系统可靠性
单点隐患发现:架构可靠性分析 Server CPU Application Normal Database Normal Normal Server-01故障 将影响: 4个核心应用; 120个接口; Status NOT System Architecture 300万用户; 建议增加节点冗余 或进行服务迁移
3.Why Graph Is the Natural Foundation for Ontology?
RDF-RDFS-Ontology Payment Service为什 么 重要? Pod 是服 务还 是软 件? CPU 使用 率和 Pod 有什 么关 系? Nod e Pod Service Property cpu/ memor y restart count SLA subClassOf ........ Worke r Node St atefulS et Pod Core Sevice worker Node 运行 W orker Pod Event 发生于 Standb y Service Order 运行 属于 Pod A PodA woerker no de 属于 Nod e 属于 Nod e Payment Service 记录客观事实 {} Payment Node A CPU:55% Payment Service 推理 故障 传播 逻辑 {name,cpu,memory} Class pod A 理解 运维 本体 模型 Core Service 有状 态吗? Pod B restart count:8 定义类别和关系 属于 Core Service NodeA payment service 发生于 Service Unavail ab le 定义本体模型
业界实践:Palantir 的操作本体论实践 Palantir Ontology 对象类型(Object Types) Palantir在其Foundry和AIP平台中,将本体论从学术概念 转化为企业级操作工具。 核心思想: 让业务用户和系 统能够以统一的 「对象语言」操 作数据,而不需 要理解底层数据 库结构,充当了 企业数字孪生的 语义核心。 本体=数据的「业务语义层」 将原始数据表映射为业务对象(如「客户」「订单」「资产」),屏蔽 技术细节 关系链接(Link Types) 定义对象间的关系(一对一/一对多),跨数据源自动关联,形成知识 网络 操作动作(Actions) 将业务操作绑定到本体对象,触发下游系统更新,实现「读写一体」的 本体 AI 接入层(AIP) LLM通过本体理解数据语义,Agent可以用自然语言查询和操作企业知 识图谱
记忆能力-AI memory与推演 每一次方案的执行结果都可以记录下来,从而形成AI的长期记忆,让AI不必每一次都是“从0到1”的制定方案。 仿真推演 Action 持续积累经验,形成可复用的“内部知识库” 支持反思与自我修正; 实现增量式个性化适配; 辅助规划与推理的迭代优化; 支持跨任务与跨场景的知识迁移; temp_grap h
Graph Ontology 驱动的 Agentic AIOps 发现3条P1告警信息! Graph Ontology Kafka 请分析根因并给出处置建 议! Root Cause:Node-03磁 盘耗尽 影响:Paymen t Service、 Order Service 建议:① 清理磁盘② Drain Node③ 重启Pod④ 回滚Release 故 障 代 码 物 理 资 源 磁 盘 Prometheus Metrics 告 警 软 件 资 源 中 间 间 C P U 网 络 p o d 数 据 库 数 据 接 入 Kubernetes Events CMDB Exchange 实时数据流 云平台API CoE【Chain of Explorations】 2 驱动模型进行 知识抽取 主动推送 OpenTelemetry Trace Run boo k SOP Known Issue Agent Change Log 知识集 自动化抽取 Incident 架构设计 知识手册、排障日志等
精准的执行能力 在Foundry平台,每个数据主体(本体)都可以关联规则、程序和算法。 B 供应 商 自制 件 采购 订单 A零件 规 则 程 序 {当库存量不足以满足需 求时,触发生成指定供 应商的采购订单,且采 购数量必须遵循预定的 供货比例} D仓 库 通过触发 API,在ERP 系统生成A 零件的采购 订单 操作动作(Actions) 将业务操作绑定到本体对象,触发下游系统更新,实 现「读写一体」的本体
How is execution capability implemented in graph? 规则 程序 执行 器 B A C 函数
Nebula Fushion Graph RAG Fusion GraphRAG: 动态意图理解与导航:LLM根据问题意 图动态决定“去哪里找”,而非静态匹 配“什么看起来像”。 PDF PNG 数据库 Word 音频 视频 保持语义单元完整性:以自然章节(如 页面、段落)为检索单元,避免了硬分 割,维护了上下文的连贯性。 无缝处理内部引用:当在内容中遇到“ 参见附录G”时,LLM可以直接在目录树 索引中导航至对应节点,实现精确的交 叉引用。 整合多轮对话上下文:检索过程可以利 用之前的对话历史来 精炼当前查询的理 解,实现连贯的多轮探索。
4.NebulaGraph Database Over View
NebulaGraph Over View First to Natively Support ISO-GQLNebulaGraph is the first distributed graph database to natively support ISO-GQL, ensuring standardized graph queries. High Performance- Delivers high throughput and low latency, ideal for large-scale graph data. Separation of Storage and Computation- Enables linear scalability and uninterrupted operations during scaling. High Availability - Built with robust fault tolerance and automatic failover for continuous operation.
Vibrant Open-source Community 40k ForumReplies ■ 1.2M Page View and 2.4k+ total posts; 18-month CMGR ~35% ~1000 2,000 Active Users 800+ registered users; 18-month CMGR ~30% ■ 1,500+ active users in the community ■ Tracking Customers 6-month CMGR ~21% ■ Customers in the industry including Internet, Finance, Telecom, Government, etc. ■ 9k 30%+ DAU ■ Users are active on GitHub, NebulaGraph forum, and Slack channel Weekly Downloads ■ Users can download NebulaGraph at GitHub, Docker Hub, and OSS
2000+ Leading Innovators Choose NebulaGraph
Don't let your LLM navigate the dark. Give it a map. The graph is the map.
Thank You! vesoft-inc/nebula https://www.linkedin.com/company/nebula-graph/ @NebulaGraph https://www.nebula-graph.io/join-slack