核心要点
- 大模型用于可观测性根因定位时，不能简单把海量指标、日志、链路和事件全部提交给模型分析。
- 真正要解决的是两个输入问题：让大模型理解系统，让大模型能够按需读取观测数据。
- Flashcat 的灭火图把接口、微服务、组件、网络、DNS 等 IT 对象组织成健康视图，相当于为 AI 提供系统元信息和知识图谱。
- Flashcat 的数据集成能力把不同观测系统的查询通道打通，让 AI 能围绕异常对象读取相关证据。
- AI 根因定位的价值不在于“模型会说”，而在于它能沿着对象、指标、日志、链路和事件形成可复核的证据链。
故障根因定位的自动化和智能化一直是可观测性行业的重点课题，但效果一直难孚众望。
大模型出现后，利用大模型实现故障根因定位的真正智能化有了极大的可能。但面对海量的观测数据和复杂的 IT 环境，如何有效连接观测系统和大模型，产生智能化效果，总有一种“老虎吃天，无从下嘴”的感觉。
把海量的指标、日志、链路、事件等可观测数据一股脑提交给大模型做分析，无论从计算成本还是物理传输效率看都不现实。让大模型自己钻到观测数据的海洋里，自行学习、自行分析，理论上也依赖一个前提：企业各维度观测数据既标准又规范。
现实情况通常不是这样。企业的观测系统往往各自为阵，数据割裂，标准不统一。能够提前制定好各维度数据标准，并按一体化最佳实践从零建设观测系统的企业并不多。
因此，基于现实情况，我们需要先为大模型介入可观测性做准备和治理工作：提供精准、有效的数据和通道，再让大模型输出有价值的结果。
大模型做根因定位，需要先解决两个输入问题
总体看，利用大模型增强根因定位，需要解决两个重点问题：
| 问题 | 本质 | 如果缺失会怎样 |
|---|---|---|
| 如何让大模型理解你的系统 | 提供 IT 对象、对象属性、层级、依赖和健康状态 | 模型只能看到零散数据，难以判断影响范围 |
| 如何让大模型读取你的数据 | 打通指标、日志、链路、事件等数据查询通道 | 模型只能凭输入片段推断，无法形成证据链 |
有了这两个输入，再加上大模型的自主分析和推理能力，根因定位的智能化才有可能。
如何让大模型理解你的系统
答案是元信息和知识图谱。
这里的元信息，指大模型所处环境里一个个物理和逻辑 IT 对象及其描述，包括接口、微服务、组件、平台、网络、DNS 等对象，以及这些对象之间的层次、关联和依赖。
有了这些信息，大模型才基本能够理解你的系统，并具备精准分析数据的条件。否则，它只能从单条告警、单段日志、单张曲线中猜测方向，很容易给出“检查数据库、网络和下游依赖”这类泛化建议。
如何让大模型获取你的数据
第二个问题是数据查询通道。
需要打通并标准化所有观测数据的查询通道，把查询能力提供给大模型。大模型知道要查询指标数据时该从哪里查、如何查；查询日志、链路、事件时也一样。
这并不意味着必须把所有数据集中存储到一个系统里。更关键的是，AI 在分析某个异常对象时，能够按需查询与它相关的指标、日志、链路、事件和仪表盘，而不是等待人工复制粘贴片段。
Flashcat + AI 的智能化定位实践
基于以上思考，我们发现 Flashcat 并不是为了 AI 才设计这些能力，却一直在解决这两个问题。
Flashcat 是一个从数据到平台到场景的一体化可观测性产品，基于开源夜莺实现。Flashcat 的灭火图系统原本就是为加速故障定位设计的。
灭火图能够用一张图掌握全系统健康状态，快速收敛故障范围，引导用户从故障点层层下钻，联动各维度观测数据，加速完成根因分析。
灭火图的基本设计理念，是拆解并观测线上系统中的 IT 对象，包括物理对象和逻辑对象，例如接口、微服务、组件、平台、网络、DNS 等。同时，为这些对象配套量化其健康度的指标，并关联相关的指标、日志、链路、仪表盘、事件等观测数据。这样就形成了一个立体的服务“元信息”和“知识图谱”。
灭火图介绍详见：一张图掌握系统健康状态
数据集成让 AI 能按需读取证据
Flashcat 的另一个特点是数据集成能力。灭火图的数据和关联可能来自不同观测数据源，Flashcat 针对常见的开源和公有云观测系统都做了集成。
在这个结构下，AI 不是面对一个抽象的“监控系统”，而是面对一个个有名称、有健康状态、有下钻路径的 IT 对象。某个对象异常时，AI 可以沿着这个对象去查对应的指标、日志、链路和事件，从而形成分析证据。
一个灭火图 + AI 的根因定位案例
以下是 Flashcat 灭火图 + AI 大模型实现故障定位的案例：
- 在 Flashcat 灭火图上，通过飘红快速找到异常对象：订单提交接口。
- 从异常对象触发 AI 分析。
- AI 分析异常对象关联的各维度观测数据。
- AI 输出分析结论：Redis 服务不可用，并给出相关详情。
这个案例的关键不是“模型猜中了 Redis”，而是 AI 的分析入口是一个明确的异常对象，并且这个对象已经关联了可以下钻的观测数据。模型拿到的是有边界、有方向的数据，而不是一堆无结构的日志和指标。
Flashcat 如何连接企业自己的大模型
实现上，Flashcat 内会由一个内置的大模型维护故障分析的知识库、数据格式、结构化信息等。最终的分析则会提交给用户通过配置指定的大模型接口，例如私有化部署的 DeepSeek 或公有云上的大模型。
这个设计把系统知识、数据结构和企业模型选择分开：Flashcat 负责把可观测性上下文组织好，企业可以根据自身部署方式和安全要求选择大模型接口。
后续智能化方向
Flashcat 将基于良好的数据基础，结合 AI 做更多智能化实现，例如大面积故障时的整体故障特征智能分析、多个对象的并行分析和综合分析，以辅助用户快速决策服务止损方案。
这类能力能否稳定落地，仍然取决于前面的基础建设：对象建模是否清晰、健康状态是否可信、下钻数据是否完整、数据源查询通道是否可用、业务知识是否能补充到分析过程中。
总结
可观测性加大模型，不是把“所有数据交给模型”这么简单。
更可行的路径是：先把 IT 系统拆成可观测对象，用灭火图组织对象关系和健康状态；再通过数据集成打通指标、日志、链路、事件等查询通道；最后让大模型围绕异常对象读取证据、推理原因并给出建议。
这就是 Flashcat 做 AI 根因定位的基本思路。大模型负责推理和总结，Flashcat 负责把系统上下文和数据路径准备好。没有前面的数据建设，AI 很难稳定输出有价值的根因结论。
FAQ
Q1：为什么不能把所有观测数据直接提交给大模型？
A：指标、日志、链路和事件的规模很大，直接提交会遇到成本、传输、上下文长度和噪声问题。更有效的方式是先用灭火图定位异常对象，再围绕对象读取相关证据。
Q2：灭火图对 AI 根因定位有什么价值？
A：灭火图把 IT 对象、对象健康状态、层级依赖和下钻数据组织在一起。AI 可以从异常卡片出发，知道要分析哪个对象、它影响什么范围、应该查询哪些指标、日志、链路和事件。
Q3：企业可以使用自己的大模型吗？
A：可以。文章中的实现思路是由 Flashcat 维护故障分析所需的知识库、数据格式和结构化信息，最终分析提交给用户配置的大模型接口，例如私有化部署模型或公有云模型。
