灭火图系统简介
一张图看清 IT 系统各块健康度:立体层级、对象化观测、飘红飘绿与下钻联动;支持模板建卡、时间轴回放与 AI 智能诊断。
服务出了故障时,大家都希望用一张图就能看清:系统里到底是哪一块不健康,技术同学能马上缩小排查范围,负责人和值班经理也能心里有数、指挥有序——这是很多团队在稳定性建设里反复提出的诉求。
Flashcat 灭火图就是为这种场景设计的:把在线系统拆成一张张可观测的「卡片」,在首页一眼看到全局哪些区域异常(飘红),再逐层下钻到详情,直到定位到具体接口、服务、中间件实例或基础设施单元,并从这里继续跳进日志、链路、大盘、变更事件等——把「故障定位」这条路径串成一条线,少在多个系统之间来回切屏。

更多场景化效果请参考 《一张图掌握 IT 系统健康状态》
灭火图在做的五件事(结合「立体视图 → 对象 → 状态 → 量化 → 下钻」)
1)立体视图,而不是满屏平铺曲线
灭火图有 首页 和 详情页:首页负责「全貌与分层」,可以下钻进详情;详情里还可以按分层继续展开,整体观感类似大家熟悉的 服务树——但树上的每个节点不再只是「一台机器」,而是各类 IT 对象(接口、服务、组件、基础设施等)。在平台实现里,完整路径是:
首页 → 分层 → 首页卡片 →(可选)分组 → 详情卡片(详见下文术语表)。
2)从「盯着零散指标」到「盯住观测对象」
传统大盘常常把大量指标平铺展示,更适合日常看图;灭火图侧重把问题先收敛到 「哪一个对象不对劲」——再从这个对象去看它身上的流量、成功率、延迟、存活、资源等。这样更容易从对象之间的影响关系里找原因,而不是在一堆互不关联的曲线里猜。
平台通过 卡片规则 从 Prometheus、Kubernetes、日志分析等数据源里发现与创建这些对象,并由你定义它们在树上的层级与视角。
3)正常 / 异常一眼区分:飘绿与飘红
每张底层卡片都有健康与否的状态:异常则飘红,正常则飘绿。状态会沿层级向上传导——只要下层有飘红,上层也会呈现异常,最终把「哪里着火了」收敛到首页。这样在入口处就能判断异常落在哪一层、哪一类系统。
4)用「核心指标 + 异常条件」把健康说清楚
对每一类底层对象,灭火图会配套用于量化健康度的指标和何时算异常的条件。例如:
- 对象若是核心接口/功能,常会用流量、成功率、响应时间等「黄金指标」,异常条件可以是成功率低于某阈值;
- 对象若是 MySQL 实例,可能是存活、慢查询、连接、CPU 等组合条件。
不同对象类型模板不同;平台沉淀了常见对象类型的健康度量模板,可快速套用,并结合 模板中心与数据源匹配度 辅助生成规则(详见下文智能化能力)。
5)从异常点下钻,把各维观测数据串起来
从首页发现「异常区域」→ 逐层点到异常对象→ 看该对象的健康趋势与触发条件是否满足 → 再沿 下钻规则 进入日志、链路(Trace)、仪表盘、事件(如变更)等。灭火图提供的是「对象到多维度数据」的映射与入口,减少定位和救火时的路径断点。
Flashcat 每分钟会计算底层卡片的健康度并刷新展示;时间轴则能把历史上的每分钟状态拉出来,对照故障时刻与变更、发布会更顺手。
智能化能力(在「对象 + 关联」之上的加速)
在灭火图建设过程中,对象的层级、指标与下钻关联其实已经被结构化描述;在此基础上,Flashcat 提供以下智能化相关能力(具体以当前租户开通能力与控制台为准):
| 能力 | 说明 |
|---|---|
| 异常卡片 AI 根因分析(智能诊断) | 对异常详情卡片在给定时间点触发 AI 分析,结合对象侧上下文生成结构化结论,回答「为何飘红」类问题;宜与指标、日志等证据交叉验证。 |
| 时间轴与历史回放 | 按时间查看全局与卡片健康态势,把异常发生时刻与其它系统事件对齐。 |
| 模板中心与匹配度驱动的建卡 | 面向 MySQL、Kubernetes、APM 微服务等提供规则模板,按数据源做 匹配度 评估,支持 一键生成/辅助生成 卡片规则,降低从零手写查询的成本。 |
| 下钻规则预置与串联 | 微服务、K8s 等模板生成的卡片常带丰富下钻;也可自定义到大盘、日志、Trace、事件墙等。 |
| 智能告警联动 | 通过灭火图 告警规则 与平台通知策略衔接,使「飘红」有机会触发可行动的告警(通道依赖全局告警配置)。 |
有了对象元信息、对象与观测数据之间的关联,以及各维度查询能力,人眼可以按固定套路排障;把这些结构化上下文交给大模型,则有机会进一步加速分析过程、提高结论的可读性与完整性——智能诊断即是这一方向的落地之一。
核心术语(与平台一致)
| 概念 | 说明 |
|---|---|
| 灭火图 | 分 首页 与 详情页。首页有分层与首页卡片;详情页可有分组(可选)与详情卡片。 |
| 路径 | 空间内完整层次:首页 → 分层 → 首页卡片 → 分组(可选)→ 详情卡片。 |
| 分层 | 首页上组织观测对象的方式,例如:接口层、微服务层、组件层、基础设施层。分层顺序建议贴合排障时从上到下/从外到内的自然顺序。 |
| 首页卡片 | 隶属于某分层,常对应一套服务系统、集群或子域等集合。 |
| 分组 | 详情页内对卡片的归类,非必须。 |
| 详情卡片 | 最底层观测对象(接口、实例、Deployment 等);含观测指标、异常条件、下钻路径。 |
| 健康状态 / 飘红 | 由指标与异常条件计算;下层异常向上传导,便于首页总览。 |
| 卡片规则 | 批量生成并组织卡片与层级的规则。 |
| 下钻规则 | 把仪表盘、日志、链路、事件等分析路径挂到卡片上。 |
| 告警规则 | 卡片异常时的通知策略,与平台告警体系衔接。 |
| 时间轴 | 回溯历史状态,可还原任一分钟的全局视图。 |
三类核心规则
灭火图建设围绕三类规则展开(三者齐备即形成从建模 → 分析路径 → 通知的闭环):
- 卡片规则:观测对象、层级、健康指标与异常条件。
- 下钻规则:指标、日志、Trace、大盘等排障路径。
- 告警规则:异常时告警与通知。
实践中推荐 模板优先:能用内置/官方模板就不要从零手写。
与北极星的分工
| 维度 | 北极星 | 灭火图 |
|---|---|---|
| 主要问题 | 「业务 / 核心功能是否明显异常?」 | 「IT 侧哪里红了?如何缩到具体对象?」 |
| 典型指标 | 订单、支付、GMV 等业务可读指标 | 黄金指标、存活、组件与资源类等 |
| 关联 | 北极星可配置下钻到灭火图 | 从飘红对象下钻到日志、链路等 |
分层与传导:举例(电商)
首页分层可组织为(示例):
- 功能接口 / 业务接口
- 微服务 / 服务模块 / 容器服务
- 标准中间件
- 基础设施
关键原则:下层对象的故障往往会向上传导——例如基础设施或中间件异常,可能在微服务与接口层表现为飘红。分层合理时,可以从上层异常顺势下钻到所属下层,更快贴近根因层。
各层典型对象包括:浏览/下单/支付等接口;各 namespace 的 Deployment/StatefulSet 或 APM 模块;MySQL、Redis、Kafka 等;主机、网络、DNS、CDN 等。卡片具体指标随对象类型变化(见上文第 4 点)。
产品架构
