很多团队做可观测性，最后都会掉进同一个坑里：数据越来越多，页面越来越多，大盘越来越多，但真正故障发生时，大家还是不知道先看哪里。
这听起来有点反常。
按理说，有了指标、日志、链路追踪，有了 Prometheus、Grafana、ELK、SkyWalking、Jaeger，有了各种告警规则，系统应该更容易理解才对。但真实情况往往不是这样。数据变多之后，工程师看到的是更多曲线、更多列表、更多查询入口，而不是更清晰的判断路径。
故障现场最缺的不是数据。
最缺的是三个答案：
哪里出问题了？
影响范围有多大？
下一步应该看什么？
Flashcat 的灭火图，就是围绕这三个问题设计出来的。
灭火图不是一张大盘
很多人第一次听到“灭火图”，会自然把它理解成一种大屏或 Dashboard。
这其实低估了它。
传统大盘的核心是展示指标。你可以把 CPU、内存、QPS、错误率、P99、慢查询、连接数、消息堆积量都画出来。它的问题不是没用，而是它默认把判断责任交给人。
你要自己知道哪个图重要。
你要自己知道哪个曲线异常。
你要自己知道异常曲线对应哪个服务、哪个接口、哪个组件。
你还要自己知道下一步应该去查日志、Trace、数据库还是网络。
系统小的时候，这件事靠经验可以解决。
但系统一复杂，尤其是多个业务线、多个微服务、多个中间件、多个云环境混在一起时，大盘会变成一个很重的认知负担。事故发生时，大家不是没有图看，而是图太多，不知道哪个图能帮助做决策。
灭火图的视角不一样。
它不是先问“我要画哪些指标”，而是先问“我要观测哪些对象”。
这些对象可以是一个接口、一个微服务、一个数据库实例、一个 Redis 集群、一个 Kafka Topic、一个 Pod、一个网络链路，也可以是一个更高层级的业务系统。
换句话说，灭火图把可观测性的视角从“指标”提升到了“对象”。
这一步很关键。
因为故障处理时，人脑天然不是按指标工作的。我们不会说“某条 PromQL 曲线坏了”，我们会说“支付接口有问题”“订单服务不稳定”“MySQL 集群慢了”“某个机房网络抖了”。
灭火图让平台的表达方式更接近人处理故障的方式。
先看到哪里着火
灭火图最直观的价值，是让团队在一个页面里看到系统的全局健康状态。
健康对象是绿色的。异常对象会飘红。没有数据或未知状态会显示为灰色。
这件事看起来简单，但它解决的是故障现场非常关键的第一步：快速判断影响面。
比如一个电商系统，可以按四层来组织：
功能接口层：浏览、下单、支付、登录等核心接口。
微服务层：订单服务、支付服务、用户服务、库存服务等。
标准组件层：MySQL、Redis、Kafka、Elasticsearch 等。
基础设施层：主机、容器、网络、DNS、CDN、机房链路等。
当支付接口成功率下降时，接口层会飘红。
如果同时支付服务的错误率升高，微服务层也会飘红。
如果再往下看，发现某个 MySQL 实例慢查询增加，组件层也会飘红。
这种层级化的健康状态，比一堆孤立曲线更接近真实排障过程。它让团队先看到“哪里着火”，再决定从哪里下钻。
灭火图里的卡片不是手工贴上去的一组图标。它背后有健康度计算。
底层详情卡片会基于核心指标和异常条件判断状态。比如一个下单接口，可以用流量、成功率、响应时间作为健康指标；当成功率低于 95%，或者响应时间超过阈值时，卡片就会飘红。
上层卡片的状态可以由下层卡片聚合出来。
这意味着，一个底层对象异常，可以层层上浮到首页。值班人不需要先知道哪个实例坏了，只要看到首页哪里飘红，就能沿着层级往下找。
这就是灭火图和普通大盘的第一个区别：它不只是展示数据，它在表达健康状态。
真正的价值在下钻
只知道哪里着火还不够。
很多系统也能告诉你“某个服务异常”，但下一步仍然要靠人自己打开 Grafana、Kibana、Trace 系统、数据库监控、云监控，再把时间范围、服务名、实例名、接口路径手动填进去。
这就是为什么很多团队明明有全套可观测工具，排障仍然很慢。
工具之间没有形成路径。
灭火图的核心能力之一是下钻。
下钻的意思是：当一个卡片异常时，用户可以直接从这个对象出发，查看它关联的指标、日志、链路、仪表盘、事件，甚至跳到其他相关卡片。
比如一个 MySQL 实例卡片飘红，卡片上可以直接下钻到：
MySQL 监控仪表盘。
该实例的慢查询日志。
相关业务服务的调用链。
依赖这个数据库的上游服务卡片。
最近是否有发布、配置变更或告警事件。
再比如一个接口卡片飘红，可以下钻到：
这个接口的请求量、成功率、P95/P99 延迟。
对应网关日志。
该接口相关 Trace。
错误码分布和异常特征。
关联的微服务或下游组件。
这一步看似只是“跳转”，但本质上是把排障经验产品化。
过去一个资深 SRE 会知道：看到支付接口成功率下降，先看网关错误码，再看订单服务 Trace，再看支付服务日志，再看数据库慢查询，再看最近发布事件。
但这个路径通常只存在人的脑子里。
灭火图把这些路径通过下钻规则挂到观测对象上。新同学不需要完全依赖经验，也能沿着正确路径分析问题。资深同学也不用每次重复打开一堆系统、复制一堆条件。
这就是灭火图和普通大盘的第二个区别：它不只是告诉你哪里异常，还告诉你下一步该看什么。
卡片规则让灭火图能跟上系统变化
很多可观测建设失败，不是因为第一版做不出来，而是因为后面维护不下去。
系统一直在变。
服务会新增。实例会上下线。Kubernetes 里的 Pod 和 Deployment 会变化。数据库集群会扩容。接口会新增和废弃。云资源会调整。中间件会迁移。
如果所有观测对象都靠人工维护，很快就会失真。
灭火图的推荐建设方式不是手工创建卡片，而是通过卡片规则生成。
卡片规则做几件事：
从数据源里筛选观测对象的元信息。
基于标签或字段组织卡片路径。
为每个对象配置核心健康指标。
设置异常条件。
按周期执行，自动生成、更新或清理卡片。
比如从 Prometheus 里发现 MySQL 实例，用 cluster、address、instance 等标签生成组件层卡片；从网关日志报表里发现接口，用域名和路径生成接口层卡片；从 APM 数据里发现服务和接口，生成微服务层卡片。
这样做的好处是，灭火图不是一次性画出来的静态图，而是一套持续运行的观测对象生成机制。
这对中大型企业尤其重要。
因为真正复杂的不是“能不能画一张好看的图”，而是“系统变化之后，这张图还能不能保持可信”。
如果灭火图能通过规则持续更新，它就可以成为团队日常值守和排障的入口。否则它很快会变成另一个没人敢信的大屏。
灭火图是系统知识图谱
我觉得灭火图最值得重视的一点，是它天然在构建一张系统知识图谱。
这张图里有四类关键信息：
第一，系统有哪些观测对象。
第二，这些对象如何分层、如何归属。
第三，每个对象当前是否健康，历史上什么时候异常过。
第四，每个对象出现异常时，应该关联哪些数据继续分析。
这四类信息加在一起，就不只是监控数据了。
它变成了系统稳定性知识。
过去很多企业的知识分散在不同地方：架构图在文档里，接口列表在网关里，服务关系在 APM 里，指标在 Prometheus 里，日志在 ES 或 Doris 里，告警规则在监控系统里，故障经验在人的脑子里。
灭火图试图把这些东西围绕“观测对象”重新组织起来。
这也是为什么它对 AI 很重要。
现在很多团队都在谈 AI 运维、AI RCA、智能根因分析。但如果 AI 拿到的只是几条日志、几段告警文本、几条曲线，它很难真的理解系统。
AI 要想分析故障，必须先知道：
这个异常对象是什么？
它属于哪个系统、哪个分层？
它有哪些上游和下游？
它的健康指标是什么？
哪些日志、Trace、仪表盘和事件与它相关？
历史上类似异常是怎么发生的？
灭火图正好提供这些上下文。
所以 FlashAI 在灭火图里不是简单加一个聊天窗口。更关键的是，当卡片飘红时，FlashAI 可以基于卡片上下文，自动遍历关联的指标、日志、链路等下钻数据，输出故障原因分析和处理建议。
这比让用户手工把一堆数据复制给 AI，要可靠得多。
一句话：没有灭火图，AI 看到的是碎片数据；有了灭火图，AI 才开始看到系统结构。
灭火图也改变告警方式
传统告警通常围绕底层指标配置。
CPU 超 90%。
磁盘使用率超 85%。
接口错误率超过阈值。
Kafka 消费堆积超过阈值。
数据库连接数异常。
这些规则当然需要，但问题是它们经常太分散。
当系统复杂之后，告警会变成一堆孤立事件。值班人收到告警后，还要自己判断它对应哪个业务对象、影响哪个系统、下一步看哪里。
有了灭火图以后，告警可以更多围绕观测对象来配置。
卡片飘红，就意味着这个对象的健康状态异常。告警消息里可以带上卡片的指标趋势截图，也可以带上进入灭火图详情页的链接，还可以带上 FlashAI 分析入口。
这样告警不再只是一个文本通知，而是直接连到故障现场。
这条链路更自然：
建设观测对象。
定义健康状态。
卡片飘红触发告警。
从告警进入灭火图。
沿下钻路径分析。
必要时触发 AI 分析。
故障后通过时间轴和 SLO 报表复盘。
这就是 Flashcat 想做的稳定性闭环。
为什么说灭火图是 Flashcat 的灵魂
Flashcat 是一个一体化可观测性平台。它能接指标、日志、链路、事件；能做查询、告警、仪表盘；能接入 OpenTelemetry、Prometheus、Elasticsearch、Doris、SkyWalking、云监控等数据源；也有北极星、事件墙、FlashAI 等能力。
这些能力都重要。
但如果只把它们并排摆出来，Flashcat 很容易被理解成“功能很多的监控平台”。
灭火图把这些能力串起来了。
指标不再只是曲线，而是对象健康度的一部分。
日志不再只是检索结果，而是异常对象的分析入口。
链路不再只是 Trace 列表，而是服务和接口下钻路径的一部分。
事件不再只是流水账，而是故障定位时的关键线索。
AI 不再只是问答窗口，而是基于对象上下文执行分析的助手。
SLO 不再只是手工报表，而是基于卡片健康状态持续计算的结果。
所以我说，灭火图是 Flashcat 的灵魂。
它把“数据层”“平台层”“场景层”“智能层”连接到了一起。
没有灭火图，Flashcat 仍然是一个能力完整的可观测平台；但有了灭火图，Flashcat 才真正形成了自己的产品性格：不是让用户自己在数据海里找答案，而是把系统健康状态和排障路径组织好，让人和 AI 都能更快做出判断。
什么团队最应该建设灭火图
不是所有团队一开始都需要完整灭火图。
如果系统很小，服务不多，排障主要靠两三个熟人，普通监控和大盘可能已经够用。
但如果你的团队出现了这些情况，就应该认真考虑灭火图：
系统已经微服务化，服务、接口、组件数量很多。
监控大盘很多，但故障时仍然不知道先看哪里。
指标、日志、链路分别在不同系统里，排障需要来回切换。
新人排障高度依赖老同学经验。
活动保障或核心业务值守需要快速判断全局健康状态。
希望用 AI 做根因分析，但发现 AI 缺少系统上下文。
管理层希望看到 SLO、健康度、巡检报告，而不是一堆底层指标。
这类团队最需要的不是再多接一个数据源，也不是再画几张大盘。
真正需要的是把已有观测数据重新组织成一套稳定性工作台。
灭火图就是这个工作台的中心。
建设灭火图的正确顺序
建设灭火图不要一上来追求“大而全”。
更好的方式是从一个核心系统开始，做一张可以真的用于排障的图。
第一步，规划空间和分层。
比如按功能接口、微服务、标准组件、基础设施四层来组织。不要只按团队组织，也不要只按资源类型组织，要贴近故障处理路径。
第二步，用卡片规则生成对象。
接口层可以来自网关日志或日志报表。微服务层可以来自 APM、Kubernetes 或 Prometheus。组件层可以从 MySQL、Redis、Kafka 等数据源生成。基础设施层可以从主机、容器、网络探测等数据生成。
第三步，给对象定义健康指标和异常条件。
每类对象都要有自己的健康判断。接口看流量、成功率、耗时；服务看请求量、错误率、延迟和实例状态；数据库看存活、慢查询、连接数、资源指标；消息队列看堆积、消费速率和错误。
第四步，配置下钻规则。
这是最容易被低估、但最决定价值的一步。没有下钻，灭火图只是状态面板；有了下钻，灭火图才是故障分析入口。
第五步，接入告警、截图、SLO 和 FlashAI。
当卡片飘红时，告警要把人带回故障现场；日常巡检要看历史健康状态；SLO 要基于对象健康度计算；AI 要基于卡片上下文分析原因。
这五步做完，灭火图才真正开始发挥价值。
最后
可观测性行业过去几年一直在强调 Metrics、Logs、Traces。
这三个东西当然重要。没有数据，一切都无从谈起。
但我越来越觉得，真正决定可观测性价值的，不是你采了多少数据，而是这些数据能不能在故障现场帮助团队更快做判断。
灭火图的意义就在这里。
它不是又一张图，也不是又一个大屏。
它是一种把系统健康状态、观测对象、排障路径、告警入口、SLO 和 AI 上下文组织起来的方法。
如果说传统监控解决的是“有没有看到异常”，那灭火图想解决的是“看到异常之后，能不能立刻知道哪里出问题、影响多大、下一步看什么”。
这也是 Flashcat 和很多通用可观测工具最大的区别。
Flashcat 不只是把数据接进来，而是试图把数据变成稳定性保障的工作流。
而灭火图，就是这个工作流的中心。
如果你正在建设核心系统的可观测性，或者你已经有很多监控系统但排障效率仍然不高，可以先从一件事开始：选一个最重要的业务系统，尝试用灭火图把它的接口、服务、组件和基础设施组织起来。
你会很快发现，真正有价值的不是那张图本身，而是那张图背后沉淀下来的系统理解。
