灭火图只有卡片飘红还不够。
它只能告诉你“哪里可能异常”。真正减少排障弯路的，是下钻规则。
一张支付接口卡片飘红后，值班人不应该再问：日志在哪个索引？Trace 里服务名叫什么？Grafana 大盘地址是什么？时间范围怎么选？接口路径填哪个字段？
下钻规则要做的事很直接：把异常对象和相关日志、Trace、仪表盘、其他卡片、拓扑、只读工作流连接起来，并自动带上时间范围、服务名、接口路径、实例地址、集群、环境等上下文。
所以，下钻规则不是“加几个链接”，而是把团队排障经验固化成产品路径。
核心要点
- 下钻规则的目标不是跳转页面，而是把异常对象、时间窗口和排障上下文一起带到目标系统。
- 规则设计要从对象类型出发，而不是从工具列表出发；接口、服务、数据库、Kubernetes 节点需要不同入口。
- 标签是下钻规则的基础。服务名、接口路径、实例地址、集群、环境等字段必须能被目标系统识别。
- 第一版不要追求全量，先让关键卡片的日志、Trace、仪表盘、关联卡片和拓扑跑通。
- 验收标准不是页面能打开，而是新人能否从飘红卡片出发完成一次有效排障。
先设计排障路径，再配置入口
很多团队一开始就问“能不能跳到日志、Trace、Grafana”。这不是最好的起点。
正确的问题是：这类卡片异常时，值班人应该按什么顺序看证据？
- 接口卡片：接口黄金指标 -> 网关日志 -> Trace -> 承载服务 -> 发布和外部依赖。
- 服务卡片：服务指标 -> 应用日志 -> Trace/拓扑 -> 实例、Pod、主机和依赖组件。
- 数据库卡片：实例仪表盘 -> 慢查询、连接数、主从延迟 -> 调用它的上游服务。
- Kubernetes Node 卡片：节点资源和状态 -> Pod 分布 -> K8s 事件 -> 网络和宿主机指标。
不要给所有卡片挂同一组入口。每张卡片都有“日志、Trace、仪表盘、链接 1、链接 2”，用户仍然要自己判断先看哪个。
下钻规则应该围绕对象类型设计，而不是围绕工具列表设计。
生效范围按对象类型选
Flashcat 的下钻规则可以按灭火图树结构选择生效范围。范围选错，下钻会失真。
范围太大，会污染无关卡片。例如把“网关日志”挂到整个空间，MySQL、Redis、Kubernetes Node 卡片下面也会出现这个入口。
范围太小，新卡片又无法自动继承。例如为每个订单接口单独配置日志下钻，新增退款接口后，卡片规则生成了卡片，但没有下钻入口。
更好的方式是按对象集合配置：
- 接口层详情卡片：网关日志、接口 Trace、承载服务卡片。
- 微服务层服务卡片：应用日志、服务 Trace、服务仪表盘、上下游拓扑。
- MySQL 分组实例卡片：MySQL 仪表盘、慢查询日志、上游服务卡片。
- Kubernetes Node 卡片：节点仪表盘、K8s 事件、运行在节点上的 Pod 或服务。
卡片规则负责生成对象，下钻规则负责给对象挂路径。两者都按对象类型设计，灭火图才会随系统变化自动维护。
| 对象类型 | 推荐下钻入口 | 不建议的配置方式 |
|---|---|---|
| 接口卡片 | 网关日志、接口 Trace、承载服务卡片、接口指标 | 给所有接口逐个手工配置重复入口 |
| 服务卡片 | 应用日志、服务 Trace、服务仪表盘、上下游拓扑 | 只挂一个通用 Grafana 链接 |
| MySQL 卡片 | 实例仪表盘、慢查询、错误日志、上游服务卡片 | 把数据库入口挂到整个空间 |
| Kubernetes Node 卡片 | 节点仪表盘、K8s 事件、Pod 或服务关联 | 只按节点名模糊搜索日志 |
标签是下钻规则的基础
下钻规则靠卡片标签注入变量，不靠卡片名称，也不靠人眼识别。
创建卡片规则时就要提前想：
- 这类卡片未来要下钻到哪里？
- 下钻目标需要哪些参数？
- 这些参数是否已经在卡片标签里？
- 目标系统里的字段名和标签值是否能对上？
典型标签要求：
- 服务卡片：
service、env、cluster、namespace、instance/pod。 - 接口卡片：
http_host、request/route、method、service、env。 - MySQL 卡片：
cluster、address、role、env、instance。 - Kubernetes 卡片：
cluster、namespace、node/pod/workload、env。
标签缺失时，下钻只能做模糊查询。模糊查询平时看起来能用，事故现场最容易出错。
变量注入要做到跳过去就有结果
下钻不是跳转。
跳转只是打开另一个页面。下钻应该带着上下文打开另一个页面。
比如点击“日志”以后，日志页面应该自动选好数据源、时间范围，并带上查询条件：
http_host:$http_host AND request:$request
service:$service AND env:$env
点击“MySQL 仪表盘”以后，仪表盘变量应该自动注入：
address=$address
cluster=$cluster
点击“Trace”以后，Trace 系统应该自动使用：
service=$service
operation=$request
真实环境里字段经常不统一：日志叫 app_name，卡片叫 service；Trace 叫 service.name，卡片叫 app；仪表盘变量叫 instance，卡片标签叫 address。
这时只有两个办法：在卡片规则里用标签增强补统一标签，或在下钻规则里明确做字段映射。不要把映射关系留给人脑。
日志下钻看字段、索引和时间窗口
日志下钻最常见，也最容易配置得不准。
至少检查三件事：
- 查哪个日志库和索引：接口查网关日志，服务查应用日志，数据库查慢查询或审计日志，Kubernetes 查容器日志或事件。
- 用哪些字段过滤：接口常用
host、uri、method、status、trace_id；服务常用service、pod、namespace、env、level、trace_id。 - 时间窗口是否继承：卡片在 14:05 到 14:15 飘红，日志下钻就应该围绕这段时间查。
验收日志下钻时，不要只看页面能否打开。要看跳过去以后，是否直接出现与该卡片、该时间窗口相关的日志。
Trace 下钻不要只按 trace_id
trace_id 很重要，但灭火图卡片通常代表对象，不是单条请求。
接口卡片飘红，代表某个接口在一段时间内成功率下降或延迟升高。这时更需要按 service、operation/route、时间范围找一批相关 Trace，而不是只看某一个 trace_id。
常见做法：
- 接口卡片：
service=$service，operation=$request或route=$route。 - 服务卡片：
service=$service，必要时结合 Trace 拓扑。 - 时间范围：继承卡片异常窗口或当前排障窗口。
Trace 下钻要回答的问题是：慢调用是否集中在某个下游？错误是否集中在某个 span？异常是否只发生在某类 operation？服务是否被某个上游打爆？
所以 Trace 下钻最好和卡片拓扑一起设计。
仪表盘要服务对象
已有 Grafana、Flashcat、数据库、Kubernetes 仪表盘不要浪费。问题不是有没有大盘，而是能不能从异常对象进入正确大盘，并自动带上变量。
常见注入方式：
- 服务卡片：
service、cluster、namespace。 - MySQL 卡片：
address/instance、cluster。 - Kubernetes Node 卡片：
cluster、node。 - 接口卡片：
host、route、method。
如果用户打开大盘后还要重新选一堆变量，这个下钻只完成了一半。
也不要把仪表盘当成唯一入口。仪表盘适合看指标趋势，但日志解释错误，Trace 解释请求链路，拓扑解释依赖关系，卡片关联解释影响范围。
其他卡片和拓扑用来连关系
很多故障不是看一个对象就能解释。
接口异常，可能要看承载服务。服务异常，可能要看数据库、缓存、消息队列。数据库异常，可能要看调用它的上游服务。基础设施异常，可能要看受影响的服务和接口。
Flashcat 支持固定选择目标卡片，也支持按标签动态匹配：
- 接口卡片有
service=order-api，服务卡片也有service=order-api，可以动态关联。 - 服务卡片有
db_cluster=order-mysql，MySQL 卡片有cluster=order-mysql，可以动态关联。
固定关系适合少量核心链路。动态匹配适合批量对象，前提是标签标准。
卡片拓扑进一步回答四个问题：它依赖谁？谁依赖它？异常可能从哪里传来？它会影响哪些上游业务？
拓扑可以来自 Trace，也可以来自拓扑词表。Trace 覆盖不了的第三方通道、批处理任务、网络依赖、配置中心和人工梳理的关键链路，适合用拓扑词表显式建模。
工作流只做低风险只读诊断
有些下钻目标不是数据页面，而是固定排查动作，例如：
- 检查 Pod 最近重启原因。
- 执行网络探测。
- 查询数据库连接状态。
- 拉取服务最近发布版本。
- 运行只读诊断脚本。
这些动作可以通过工作流挂到卡片上，但第一版要克制。
建议只做只读诊断，不要把重启、回滚、扩容、删 Pod 这类变更动作放进通用入口，除非权限、审批、审计和防误触都已经设计好。
工作流下钻的价值是减少重复劳动，不是绕过变更管理。
第一版下钻组合怎么配
可以按对象类型设计第一版组合：
- 接口卡片：网关日志、接口 Trace、接口黄金指标、承载服务卡片、接口调用拓扑。
- 服务卡片：应用日志、服务 Trace、服务仪表盘、上游接口、下游数据库/缓存/消息队列、服务拓扑。
- MySQL 卡片：慢查询、错误日志、实例仪表盘、调用它的服务卡片、只读连接诊断。
- Redis 卡片：异常日志、客户端错误、命中率/连接数/内存/延迟仪表盘、依赖服务卡片、只读状态检查。
- Kubernetes Node 卡片：节点日志、K8s 事件、节点资源仪表盘、运行在节点上的 Pod 或服务、只读节点诊断。
这不是标准答案。它的作用是让团队先把“异常后看什么”写清楚，再去配置规则。
十个问题验收下钻规则
不要只验收页面能不能打开。真正要看这十件事：
- 入口是否只出现在相关卡片上？
- 服务名、接口路径、实例地址、集群、环境是否正确注入？
- 时间范围是否继承当前排障窗口？
- 目标页面是否直接有结果？
- 查询结果是否过宽，出现大量无关日志或 Trace？
- 查询结果是否过窄，经常查不到数据？
- 新卡片能否自动获得入口？
- 删除单卡后，批量规则是否仍可复用？
- 新人能否按入口完成一次排障？
- FlashAI 是否能利用这些下钻路径读取日志、Trace、仪表盘和拓扑证据？
如果仍然需要老同学解释“这个入口不用点”“这个字段要改一下”，说明排障经验还没有真正沉淀到规则里。
常见错误
最容易出问题的地方有这些：
- 只挂仪表盘，不挂日志和 Trace。
- 每张卡片入口太多，没有优先级。
- 生效范围过大，无关卡片也出现入口。
- 变量注入不完整，跳过去还要手工选。
- 字段命名不统一，也没有映射。
- 只在单卡配置，长期不可维护。
- 没有用真实异常或演练窗口验证。
- 忽略拓扑和对象关系，把传播结果误判成根因。
- 用户有卡片权限，但没有目标日志库、Trace 或仪表盘权限。
- 卡片标签变了，下钻规则没有同步治理。
FAQ
Q1：下钻规则和普通链接有什么区别？ 普通链接只是打开目标页面；下钻规则要自动带上卡片对象、时间范围、标签变量和字段映射，让目标页面直接出现相关证据。
Q2：为什么不建议给所有卡片挂同一组入口？ 不同对象的排障路径不同。接口要看网关日志和 Trace，数据库要看慢查询和实例指标，Kubernetes 节点要看事件和 Pod 分布。统一入口会增加判断成本。
Q3：第一版下钻规则应该先做什么？ 先选关键系统和关键详情卡片，把日志、Trace、仪表盘和卡片关联跑通，再复制到同类系统。不要一开始追求全空间、全对象覆盖。
一套更短的建设顺序
如果要配置第一批下钻规则，按这个顺序来：
- 选一个已经建好卡片规则的核心系统。
- 按对象类型列出下钻路径。
- 检查卡片标签是否足够。
- 先配置日志下钻。
- 再配置 Trace 下钻。
- 挂接已有仪表盘，并注入变量和时间范围。
- 配置卡片关联和拓扑。
- 补充低风险只读工作流。
- 用历史故障或演练窗口验收。
- 沉淀模板，复制到同类系统和空间。
第一批不要追求全量。建议选 20 到 50 张关键详情卡片，把日志、Trace、仪表盘、卡片关联和拓扑下钻跑通。
最后
灭火图的卡片回答“哪里异常”。
下钻规则回答“下一步看什么”。
日志告诉你发生了什么错误。Trace 告诉你请求慢在哪里、错在哪里。仪表盘告诉你对象的指标趋势和资源状态。其他卡片告诉你上下游对象是否异常。拓扑告诉你依赖关系和影响范围。工作流帮助你执行固定的只读诊断。
这些能力都应该围绕同一张卡片、同一个观测对象、同一个时间窗口工作。
如果你已经完成第一批卡片规则，下一步不要急着扩大卡片数量。先把关键卡片的日志、Trace、仪表盘、卡片关联和拓扑跑通。
当新人能从一张飘红卡片出发，沿着这些入口完成一次故障分析，这张灭火图才真正开始有价值。
