建设灭火图，最怕一开始就陷入工具配置。
很多团队一上来就问：
卡片规则怎么写？
PromQL 怎么配？
日志字段选哪个？
Trace 怎么下钻？
告警阈值设多少？
这些问题都重要。
但如果没有先把系统拆清楚，后面的配置很容易变成另一种形式的大盘堆叠。
灭火图不是把所有监控对象都塞进一张图里。
它真正要解决的问题，是在故障发生时，让团队快速回答三个问题：
哪里出问题了？
影响范围有多大？
下一步应该看什么？
所以建设灭火图的第一步，不是写规则，而是建模。
如果拿一个典型电商系统做例子，我建议先按四层来拆：
功能接口层。
微服务层。
标准组件层。
基础设施层。
这四层足够简单，也足够贴近真实排障路径。
第一层：功能接口层，看业务入口有没有问题
电商系统最上层应该先看用户能不能完成关键动作。
浏览商品。
搜索商品。
加入购物车。
提交订单。
支付。
查询订单。
登录注册。
这些是用户视角的入口，也是业务故障最容易被感知的地方。
很多团队做监控时，会直接从服务或主机开始看。CPU 高不高，Pod 是否重启，数据库连接数是否异常。
这些当然要看。
但事故现场最先要回答的往往不是“哪台机器有问题”，而是“用户有没有受到影响”。
如果支付接口成功率从 99.9% 掉到 92%，这就是明确的业务影响。即使 CPU、内存、磁盘都还正常，也应该优先处理。
所以在灭火图里，功能接口层应该放在最上面。
它代表业务入口是否健康。
接口层的卡片通常来自网关日志或 API 日志。每个详情卡片可以代表一个域名加路径，也可以代表一个更业务化的接口分组。
比如：
checkout.example.com /api/order/create 可以命名为“提交订单”。
pay.example.com /api/payment/submit 可以命名为“支付提交”。
user.example.com /api/login 可以命名为“用户登录”。
卡片指标不需要一开始就很多。
我会先放三类：
流量。
成功率。
响应时间。
这三个指标足够构成接口健康的基本判断。
如果提交订单接口流量突然归零，可能是入口异常、网关异常、前端异常或上游链路断了。
如果成功率下降，可能是服务报错、依赖失败或参数异常。
如果 P95、P99 响应时间升高，可能是下游慢、数据库慢、线程池打满或外部接口变慢。
接口层的异常条件也应该围绕这几个指标设置。
比如成功率低于 95% 飘红，P99 超过某个阈值飘红，流量异常归零时飘红。
注意，阈值不要照搬。
下单接口和查询接口不一样。支付接口和商品浏览接口也不一样。核心交易接口宁愿敏感一点，低价值查询接口可以放宽一点。
灭火图不是为了追求全绿。
它是为了让飘红代表真实需要处理的异常。
第二层：微服务层，看哪个服务承载了故障
接口层告诉你业务入口有没有问题。
但它通常不能直接告诉你根因在哪里。
提交订单失败，可能是订单服务报错，也可能是库存服务超时，也可能是优惠券服务慢，也可能是 MySQL 连接池耗尽。
所以第二层要看微服务。
电商系统里，常见服务包括：
订单服务。
支付服务。
商品服务。
库存服务。
用户服务。
营销服务。
购物车服务。
物流服务。
微服务层的卡片可以来自 Kubernetes、Prometheus 指标，也可以来自 Flashcat APM、SkyWalking、ARMS 这类链路系统。
如果已经接入 OpenTelemetry 或 Flashcat APM，服务卡片会更自然。
因为服务本身就有比较明确的 service.name、接口、错误率、耗时、调用关系和依赖信息。
服务层卡片的核心指标，我通常会看四类：
请求量。
错误率。
响应时间。
实例健康。
如果服务是 Kubernetes 部署，还应该关注 Pod Ready 数、重启次数、CPU、内存、限流、队列积压等。
但不要把所有指标都堆到卡片上。
卡片只需要表达健康状态。
更完整的指标集合，可以作为下钻到仪表盘的内容。
这点很重要。
灭火图卡片不是小号 Dashboard。卡片只负责告诉你这个服务是否健康，以及为什么大致不健康。真正的指标细节应该通过下钻进入服务仪表盘、Trace、日志和拓扑。
微服务层最关键的是标签。
每张服务卡片都应该带上稳定的标签，比如：
service_name=order-service
namespace=prod-order
cluster=prod-k8s-a
env=prod
这些标签后面会变成下钻规则的变量。
下钻到日志时，用 service_name 或 namespace 过滤。
下钻到 Trace 时，用 service_name 查询。
下钻到 Kubernetes 大盘时，用 cluster、namespace、deployment 注入变量。
如果标签不规范，后面下钻会很痛苦。
所以灭火图建设经常会倒逼团队做数据规范治理。
这不是坏事。
没有稳定标签，就没有稳定排障路径。
第三层：标准组件层，看依赖是否在拖垮系统
很多线上故障，最后都落到标准组件上。
MySQL 慢查询增加。
Redis 延迟升高。
Kafka 消费堆积。
Elasticsearch 查询变慢。
对象存储或外部接口响应异常。
消息队列连接数异常。
这些组件不一定直接面对用户，但它们经常决定上层服务是否稳定。
电商系统里，标准组件层至少应该覆盖：
MySQL。
Redis。
Kafka。
Elasticsearch。
对象存储。
网关和消息中间件。
如果系统依赖了支付渠道、短信服务、风控服务、推荐系统，也可以把它们作为外部依赖对象纳入这一层，或者单独建一个“外部依赖层”。
组件层的建模要避免一个误区：只建一个“MySQL”大卡片。
这太粗。
如果电商系统有订单库、支付库、商品库、库存库，那么至少应该能看到具体集群或实例。
比如：
MySQL -> 订单库 -> 10.0.1.5:3306
MySQL -> 支付库 -> 10.0.1.8:3306
Redis -> 购物车缓存 -> redis-cart-01
Kafka -> 订单 Topic -> order-created
详情卡片要代表可以被定位和处理的对象。
如果一张卡片太粗，飘红后仍然不知道谁负责处理。
如果一张卡片太细，首页会变成资源列表。
比较实用的做法是：上层首页卡片按组件类别或业务集群组织，详情卡片落到实例、Topic、集群节点或关键依赖。
组件层的健康指标要跟对象类型绑定。
MySQL 看存活状态、连接数、慢查询、QPS、复制延迟、磁盘空间。
Redis 看可用性、内存、命中率、延迟、连接数、阻塞命令。
Kafka 看消费堆积、生产速率、消费速率、Broker 状态、ISR。
Elasticsearch 看查询延迟、写入延迟、集群状态、磁盘水位。
不同组件的异常条件不能统一套模板。
但规则创建可以模板化。
Flashcat 灭火图支持从模板创建卡片规则，也支持基于数据源和规则模板做一键配置。对于 MySQL、Redis、Kubernetes 这类常见对象，优先用模板会更快。
模板不是为了偷懒。
模板的价值是把常见对象的筛选条件、卡片路径、核心指标和异常条件先固化下来，减少每个团队从零摸索的成本。
第四层：基础设施层，看底座是否稳定
基础设施层容易被低估。
很多团队做云原生之后，会觉得主机、网络、DNS、CDN 已经离业务很远。
但真实故障不会按组织边界发生。
一个机房链路抖动，可能导致支付回调超时。
一个 DNS 解析异常，可能导致部分地区用户登录失败。
一个节点磁盘打满，可能导致某个关键 Pod 无法写日志或重启失败。
一个 Kubernetes 集群网络问题，可能表现成服务间随机超时。
所以电商灭火图里，基础设施层至少应该覆盖：
主机和节点。
Kubernetes 集群。
网络链路。
DNS。
CDN。
机房或可用区。
这里要根据企业实际情况决定粒度。
如果是云上系统，可以按 Region、可用区、VPC、Kubernetes 集群、节点池来组织。
如果是私有化机房，可以按 IDC、网络区域、交换机、链路、服务器集群来组织。
如果业务强依赖 CDN 和外部入口，还应该把 CDN、DNS、拨测结果放进去。
基础设施层的价值，不是让 SRE 每天盯所有底层资源。
它的价值是在上层业务飘红时，快速判断是不是底座问题。
比如支付接口飘红、支付服务飘红，同时某个可用区网络链路也飘红。这个信息在事故现场非常关键。
它可以让团队更快判断影响范围，而不是每个服务团队都在自己系统里找原因。
四层之间要能串起来
四层模型的核心，不是把对象分成四个区域。
真正有价值的是四层之间能下钻、能关联、能协同。
接口层飘红，要能下钻到对应 Trace，看慢调用发生在哪个服务。
服务层飘红，要能下钻到应用日志、服务拓扑、Pod 指标和依赖组件。
组件层飘红，要能下钻到组件仪表盘、慢查询、消费堆积和相关服务。
基础设施层飘红，要能下钻到网络探测、节点指标、Kubernetes 事件和变更记录。
这就是灭火图建设里第二个重点：下钻规则。
卡片规则解决的是“有哪些观测对象”。
下钻规则解决的是“对象异常后看什么”。
下钻规则通常依赖卡片标签。
比如 MySQL 实例卡片有 address=10.0.1.5:3306，下钻到 MySQL 仪表盘时，就把 $address 注入仪表盘变量。
订单服务卡片有 service_name=order-service，下钻到日志时，就把它注入日志查询条件。
支付接口卡片有 http_host 和 request，下钻到 Trace 时，就用这两个字段定位相关调用链。
所以建设灭火图时，不要只关心卡片名字好不好看。
更要关心卡片标签是否能用于下钻。
卡片名称给人看。
卡片标签给系统用。
如果标签设计得好，后续新服务、新接口、新组件加入时，卡片规则能自动生成对象，下钻规则也能自动匹配。
这才是灭火图可维护的关键。
卡片规则要服务动态系统
电商系统变化很快。
新接口会上线。
服务会拆分。
Pod 会扩缩容。
数据库实例会迁移。
Kafka Topic 会新增。
某些旧服务会下线。
如果灭火图靠手工维护，很快就会失真。
所以卡片规则应该作为默认方式。
一条卡片规则，本质上做几件事：
从数据源筛选对象元信息。
用元信息组织卡片路径。
为详情卡片配置健康指标。
设置异常条件。
周期性执行并更新卡片。
比如接口层可以从日志报表里筛选 http_host 和 request，生成接口卡片。
服务层可以从 APM 或 Kubernetes 指标中筛选 service_name、namespace、deployment，生成服务卡片。
组件层可以从 Prometheus 指标中筛选 cluster、instance、role，生成 MySQL、Redis、Kafka 卡片。
这个机制解决的是维护成本。
系统变了，规则重新执行，卡片随之变化。
团队不需要每上线一个接口就手工加一张卡片，也不需要每迁移一个实例就手工改一堆图。
当然，规则也需要治理。
卡片数量不能无限增长。
卡片路径要稳定。
过期对象要能删除。
命名要让一线值班人看得懂。
异常条件要定期复盘。
灭火图不是一次性项目。
它是持续治理系统健康视图的机制。
告警应该围绕对象配置
灭火图建设到这里，还差最后一步：告警闭环。
传统告警往往围绕底层规则配置。
某条 PromQL 触发。
某个日志查询命中。
某个指标超过阈值。
这当然能发告警。
但如果你已经把系统建成了灭火图，更推荐围绕对象配置告警。
也就是说，异常条件先配置在详情卡片上。卡片飘红，说明这个观测对象不健康。然后告警规则关联到对应分层、首页卡片、分组卡片或详情卡片。
这样做有两个好处。
第一，告警和健康状态一致。
值班人收到告警后，回到灭火图看到的就是同一个异常对象，而不是一条孤立的底层规则。
第二，告警范围更容易管理。
比如可以对整个功能接口层配置一条告警规则，对支付相关卡片配置更高优先级的告警规则，对非核心接口配置较低优先级。
告警消息里最好带上卡片截图和健康度趋势，也应该能直接回到灭火图卡片，甚至触发 FlashAI 分析。
这样从发现异常、查看影响面、下钻排查、AI 分析到后续治理，才是一条完整路径。
POC 时怎么验收这张图
如果你准备用一个电商系统做 Flashcat POC，我建议不要只验收“有没有接入数据”。
数据接入只是第一步。
更应该验收这几个问题：
第一，四层对象是否完整。
核心接口、核心服务、关键数据库、缓存、消息队列、基础设施入口是否都在图里。缺一个关键对象，事故时就可能断一条排障路径。
第二，卡片飘红是否可信。
正常情况下不要长期误报。真实异常时不要漏报。阈值不一定一次调准，但要能解释为什么这么设。
第三，下钻是否能直接用。
从支付接口卡片能不能进入对应 Trace？从订单服务卡片能不能进入服务日志？从 MySQL 卡片能不能进入实例仪表盘和慢查询？时间范围和标签变量有没有自动带过去？
第四，告警是否能回到对象。
收到告警后，值班人能不能直接知道哪个对象异常、影响哪一层、下一步查什么？
第五，规则是否可维护。
新增服务、新增接口、新增实例后，卡片能不能通过规则生成？下钻规则能不能复用？还是每次都要人工补配置？
这几个问题，比“页面好不好看”重要得多。
一张有价值的灭火图，应该能在事故现场缩短判断时间。
它不只是展示系统结构。
它要把系统健康状态、数据上下文和排障路径组织起来。
对电商系统来说，四层模型是一个很好的起点。
功能接口层回答用户是否受影响。
微服务层回答哪个服务承载故障。
标准组件层回答依赖是否拖垮系统。
基础设施层回答底座是否稳定。
再用卡片规则保持对象动态更新，用下钻规则把指标、日志、链路和事件串起来，用告警规则把异常推送到人。
这时，灭火图就不再是一张图。
它会变成电商系统的故障指挥入口。
如果你正在为核心业务系统规划可观测性 POC，不妨先拿这四层模型做一次梳理：列出关键接口、服务、组件和基础设施对象，再为每类对象补上健康指标和下钻路径。
这张清单，就是建设灭火图最好的起点。
