核心要点
- 可观测性要做到 AI-Ready，核心是先完成数据建模、数据查询通道和业务知识补充，再让大模型参与分析。
- AI-Ready 的可观测性系统至少要满足三个条件：AI 能理解系统，AI 能查询数据，AI 有业务和行业知识基础。
- Flashcat 用灭火图表达 IT 系统知识图谱，用数据集成打通指标、日志、链路、事件等观测数据，用 FlashAI 知识库补充业务上下文。
- 大模型不是替代数据建设的捷径，而是建立在对象、关系、健康状态和下钻路径之上的最后一公里催化剂。
- 可观测性智能化的目标不是单点解释日志或告警，而是走向系统级分析、知识推理和 AI SRE 协同。
什么是可观测性的 AI-Ready
当前，任何方向要实现智能化，首先要实现 AI-Ready，已是共识。
AI-Ready 指企业或组织在数据、技术、流程等方面具备支撑人工智能应用落地的综合能力，核心在于数据治理与业务场景深度融合。放到可观测性场景里，AI-Ready 不是“接入一个大模型”这么简单，而是让 AI 能够读懂企业 IT 系统、按需查询观测数据，并结合业务背景完成分析。
本文介绍一种可观测性数据达到 AI-Ready 的方法和实践，以及对应的产品技术支持。
可观测性是 AI 分析的基础数据
可观测性 是指通过系统外部输出来理解其内部状态的能力，其三大支柱数据为：
| 数据类型 | 作用 | 典型信息 |
|---|---|---|
| 指标 | 反映系统性能与状态的数值度量 | QPS、错误率、响应时间、CPU、慢查询数 |
| 日志 | 记录系统运行时的事件和上下文 | 错误栈、请求参数、TraceID、业务状态 |
| 链路 | 追踪一个请求在分布式系统中流经的路径 | 服务调用、Span 耗时、上下游依赖、异常节点 |
OpenTelemetry 是 CNCF 下的标准化项目，旨在统一可观测性数据的采集与格式，是事实上的行业标准。对 AI 来说，指标、日志和链路并不是孤立素材，而是判断系统状态、故障范围和根因路径的证据来源。
可观测性智能化的四个阶段
AIOps 最早可以追溯到 2011 年。Netflix 的“Chaos Monkey 实践”开创了故障注入与自动化修复的先河。2016 年，Gartner 首次提出 AIOps 的概念：Algorithmic IT Operations，描绘了算法、机器学习、大数据分析在自动化运维领域的重要性和广阔前景。
随后的十多年间，众多创新企业、互联网巨头、科研机构都在追求智能运维领域的“AGI 时刻”，但很多方案仍局限于垂直领域和单个场景，例如事件关联分析、时间序列数据预测、日志聚类分析、特征分析等。这些方案在不同企业、不同场景、不同业务系统之间很难稳定迁移。
2022 年进入 ChatGPT 时代，大语言模型的智能层次和进化速度，刷新了所有人的认知。2025 年 DeepSeek 时刻，则开启了大模型“提智降价”的螺旋竞争，足够智能的大模型和可负担的 API 调用成本，充分释放了智能的力量。大模型和智能体在重塑每个行业。在可观测领域，New Relic 最新的一项调查报告中显示，AI 监控的使用率已经从 2024 年的 42% 提升至 2025 年的 54%。一方面，可观测性数据的消费者发生了变化，从面向人转变为面向 AI 智能体；另一方面，可观测系统本身也在快速往智能进化。
针对可观测系统，智能进化可以划分为以下 4 个阶段。当前正在处于 L3 到 L4 之间，最终“智能体”将成为我们信赖的同事，进入“人”与“智能体”协同工作的新时代：AI SRE。
| 等级 | 范围 | 能力描述 | 举例 |
|---|---|---|---|
| L1 | 单点 | 智能化解读单点的文本或信息 | 针对日志原文进行 AI 解读 |
| L2 | 多点 | 智能化分析解读多个相关的信息 | 针对一批告警进行分析，找出关键告警 |
| L3 | 线性 | 智能化分析某个 workflow 或 SOP | 针对某个分析流程，由 AI 自动分析 |
| L4 | 立体 | 系统级智能分析、知识推理 | AI 从全局数据和信息中自主分析、定位根因 |
可观测性的 AI-Ready，可以理解为为了达到 L4 等级智能而做的基础建设。它不是单点工具升级，而是让 AI 获得系统级理解、查询能力和业务知识。
可观测性数据达到 AI-Ready 的条件
可观测性数据的 AI-Ready，至少需要满足以下三大条件：
| 条件 | 要解决的问题 | 建设重点 |
|---|---|---|
| AI 能够理解你的系统 | AI 需要知道企业 IT 系统由哪些对象组成、对象之间有什么关系 | 用观测数据构建企业 IT 系统的知识图谱 |
| AI 能够查询你的数据 | AI 分析过程中需要按需查询指标、日志、链路和事件 | 打通数据通道、查询能力和权限管理 |
| AI 具备业务和行业知识基础 | 同样的观测异常在不同业务中的优先级不同 | 补充业务架构、行业知识、SOP 和系统背景 |
满足以上三大条件，AI 才能在此基础上对系统状态和异常进行全面、系统的分析，得出准确的分析结论。
条件一：AI 能够理解你的系统
可观测性数据往往是海量的，一个指标系统通常有百万、千万、上亿的指标。一个日志系统动则有百 T 上 P 级的日志文本数据。一个链路系统存储数万、十万、百万的链路数据也是常态。
AI 不可能快速消化这些海量数据来识别你的系统。即使从海量数据中学习到系统结构，也需要存储为一个知识图谱，作为每次分析的基础。
一个 IT 系统的知识图谱应包括：
- 观测对象的描述：将 IT 系统抽象描述为观测对象，例如网络设备、专线、存储、MySQL、Redis、容器服务、微服务、功能接口等。
- 观测对象的属性：包括名称、标签、关联的观测数据。例如下单接口可以关联实时流量、成功率、响应时间、日志和链路数据。
- 观测对象的状态：基于观测数据量化资产健康状态，标识对象当前是否正常。例如下单接口的请求成功率低于 99.9% 或响应时间高于 100ms 时定义为异常。
- 观测对象的依赖：包括层级依赖、调用依赖等。例如网络异常会影响上层组件、微服务和功能接口，组件异常也会影响调用它的服务和接口。
需要重点说明，观测对象不应是一个具体的指标，如 CPU 使用率、数据库慢查询数量等，而应着眼于“对象”，指标是对象的属性之一。
知识图谱的建设过程，一定程度上也是 IT 系统软硬件资产的盘点过程。
条件二：AI 能够查询你的数据
AI 的分析过程一定涉及按需查询观测对象的观测数据。比如发现一个微服务异常，可能需要查询该微服务的请求量、成功率、响应时间，或输出的具体日志信息。
AI 是否能够获得或查询到相关观测数据，决定了 AI 是否能够完成整个智能分析过程。满足这个条件，需要打通并管理好企业内部所有观测数据的查询通道，落实数据的按需查询和权限管理。
这里有三种常见方法：
| 方法 | 适用情况 | 关键取舍 |
|---|---|---|
| 从零开始 | 企业刚开始建设观测系统 | 统一性强，但建设周期和迁移成本高 |
| 同步转储 | 希望把不同系统数据集中管理 | 查询体验统一，但会带来转储、转换和重复存储成本 |
| 集成打通 | 存量观测系统较多，希望利旧 | 不搬迁数据，按需通过 API 查询，但平台侧适配要求更高 |
条件三：AI 具备业务和行业的知识基础
企业业务往往有个性化和行业特色。一个 IT 系统支撑着怎样的业务，AI 分析时是否需要补充知识和侧重，这些信息都需要有途径提供给 AI，作为 AI 分析数据基础的一部分。
当前这个方向有相对成熟的 RAG（Retrieval-augmented Generation）技术可以实现，但在具体的观测产品中，需要有相应的功能支持。
Flashcat 的 AI-Ready 实践
Flashcat 是基于开源夜莺（Nightingale）实现的统一可观测性产品，包括完整的指标、日志、链路、事件维度的观测能力。Flashcat 面向稳定性保障场景进行了增强，帮助用户快速发现故障、定位故障，是企业保障服务稳定运行的支撑平台。
一、让 AI 理解你的系统：灭火图
灭火图就是 Flashcat 系统中的 IT 系统知识图谱。
灭火图设计实现的初衷是为了加速人工理解和分析系统。进入 AI 时代后，灭火图也成为 AI 理解系统的基础。
灭火图的核心是通过规则，将 IT 系统中的观测对象映射并生成为具体的卡片或节点，通过指标和条件触发卡片的飘红、飘绿来标识观测对象的健康状态。同时 Flashcat 通过模板和映射关系，将观测数据和依赖精准关联到观测对象上。
当出现问题时，用户只需要从异常对象（卡片或节点）下钻点击，即可完成所有相关路径和数据的遍历分析，而不用在各个观测系统间来回切换，也不用关心数据来自哪个观测系统。
二、让 AI 查询你的数据：数据集成
Flashcat 具备从零开始建设一整套观测体系的能力。但结合当前国内的实际现状，Flashcat 的用户多采用数据集成方案。
Flashcat 的数据集成功能不转储数据，而是和当前市面上常见的开源、商业、公有云观测系统进行 API 层面的打通，不做数据的同步和转移存储。
观测系统在 Flashcat 集成后会生成一个名称（可自定义），Flashcat 上层产品可通过对这个数据源名称的引用，完成告警配置、仪表盘配置、数据查询、权限管理等可观测性系统常见操作。
通过数据集成方案，Flashcat 实现了对所有可观测性数据通道的打通和管理。
三、让 AI 获取业务和行业知识：FlashAI 知识库
Flashcat 的 AI 产品叫做 FlashAI。FlashAI 对业务和行业知识的输入有 3 个途径：
- RAG：FlashAI 能够通过 RAG 技术处理 Flashcat 产品、可观测性和稳定性保障相关知识文档。企业部署 Flashcat 时，可以将这部分数据一并部署到环境中。
- 知识库按需输入：FlashAI 提供自定义创建知识库的能力，作为分析时的知识输入。后续还将实现和企业内部文档系统的直接集成。
- 动态交互输入：FlashAI 提供与大模型交互的对话框，可以灵活补充或修正 AI 输出。
FlashAI 对以上信息完成预处理和规范后，将把信息提交给企业的大模型（通过 API），完成最后的分析输出。
实践效果与边界
通过以上三步的实现，Flashcat 具备了为 AI 提供理解 IT 系统的知识图谱、提供观测数据的查询通道、提供补充业务信息的能力。实践中，FlashAI 已具备达成 L4 级立体分析的能力，在内部的放火系统中，FlashAI 能够重复正确地指出系统异常的根因，并在部分用户的生产环境中得到了验证。
FlashAI 发布的时间不长，但相关思路和效果得到很多企业用户的认同，已在多个用户的实际生产环境中持续验证和打磨中。
这里也要明确边界：AI-Ready 的效果依赖灭火图建模、数据集成质量、权限管理、知识库完整度和模型能力。任何一个环节薄弱，都会影响最终分析结果。大模型可以加速分析，但不能替代基础数据建设。
落地检查清单
企业评估可观测性是否接近 AI-Ready，可以先检查以下问题：
| 检查项 | 应达到的状态 |
|---|---|
| 观测对象 | 核心接口、微服务、标准组件、基础设施等对象已被建模 |
| 健康状态 | 每类对象有可量化的健康指标和异常条件 |
| 依赖关系 | 层级关系、调用关系、上下游影响范围能够被表达 |
| 数据查询 | 指标、日志、链路、事件等数据通道可以被统一调用 |
| 权限控制 | AI 查询数据和触发分析时有明确权限边界 |
| 业务知识 | 系统架构、业务优先级、故障 SOP 可以被 FlashAI 获取 |
| 验证机制 | AI 输出的根因判断可以被指标、日志、链路和事件复核 |
总结：数据建设是智能化的核心，大模型是催化剂
最后提一下 AI 应用领域目前炙手可热的公司 Palantir。
Palantir 通过本体论（Ontology）的思想，将现实世界映射为可计算的信息单元和知识图谱，最后加上 AI 的分析能力，实现了在政府决策、军事指挥、金融风控等领域的巨大实际价值输出。Palantir 的本体论所强调的不是 AI，而是前面的数据建模过程。Flashcat 的智能化思路与 Palantir 的核心思路有很大的相似性，通过对比，我们进一步增强了对 Flashcat 智能化演进方向的信心。
总结起来，在可观测性实现智能化的路上，首先要重视数据建设工作，寻找合适的产品和技术来支持可观测性数据建设，以达到 AI-Ready 状态。在此基础上加上大模型作为最后一公里的催化剂，才能实现智能化的真正飞跃。
FAQ
Q1：可观测性 AI-Ready 和接入大模型有什么区别？
A：接入大模型只是具备了分析工具。AI-Ready 还要求系统对象被建模、观测数据可查询、业务知识可获取、权限和验证机制可控。没有这些基础，大模型只能做单点解释，很难完成系统级分析。
Q2：为什么灭火图可以作为 AI 理解系统的基础？
A：灭火图把接口、服务、组件、基础设施等对象，以及对象的属性、健康状态、依赖关系和下钻数据组织在一起。这些结构化信息能帮助 AI 明确“异常发生在哪个对象、影响什么范围、应该查哪些证据”。
Q3：Flashcat 为什么倾向数据集成，而不是把所有观测数据转储到一个系统？
A：在存量观测系统较多的企业里，数据转储会增加迁移、重复存储和标准转换成本。Flashcat 的数据集成方案通过 API 打通现有系统，让上层功能按需查询数据，尽可能降低企业接入和运行成本。
