如何为一个电商系统建设灭火图：接口、服务、组件、基础设施四层模型

建设灭火图，最怕一开始就陷入工具配置。

很多团队一上来就问：

• 卡片规则怎么写？
• PromQL 怎么配？
• 日志字段选哪个？
• Trace 怎么下钻？
• 告警阈值设多少？

这些问题都重要。

但如果没有先把系统拆清楚，后面的配置很容易变成另一种形式的大盘堆叠。

灭火图不是把所有监控对象都塞进一张图里。

它真正要解决的问题，是在故障发生时，让团队快速回答三个问题：

• 哪里出问题了？
• 影响范围有多大？
• 下一步应该看什么？

所以建设灭火图的第一步，不是写规则，而是建模。

如果拿一个典型电商系统做例子，我建议先按四层来拆：

• 功能接口层。
• 微服务层。
• 标准组件层。
• 基础设施层。

这四层足够简单，也足够贴近真实排障路径。

核心要点摘要

• 电商灭火图的第一步不是写规则，而是先把业务入口、服务、组件和基础设施对象建模清楚。
• 四层模型分别回答四个问题：用户是否受影响、哪个服务承载故障、哪个依赖拖垮系统、底座是否稳定。
• 卡片规则负责动态生成和更新对象，下钻规则负责把异常对象连接到指标、日志、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，不妨先拿这四层模型做一次梳理：列出关键接口、服务、组件和基础设施对象，再为每类对象补上健康指标和下钻路径。

这张清单，就是建设灭火图最好的起点。

FAQ

Q1：电商灭火图为什么要从接口层开始？ A：因为事故现场首先要判断用户是否受影响。接口层代表浏览、搜索、下单、支付、登录等关键动作，比单看主机或 Pod 更贴近业务影响。

Q2：卡片规则和下钻规则分别解决什么问题？ A：卡片规则解决“有哪些观测对象、对象是否健康”；下钻规则解决“对象异常后下一步看什么”，例如跳到日志、Trace、组件仪表盘或 Kubernetes 事件。

Q3：灭火图和普通 Dashboard 有什么区别？ A：普通 Dashboard 更偏指标展示，灭火图更偏故障指挥入口。它要把对象健康、影响范围、上下游关系和排障路径组织起来，让值班人在事故现场少切页面、少猜路径。