北极星如何下钻到灭火图定位技术根因

北极星下钻到灭火图定位技术根因

很多监控系统在事故现场会遇到一个尴尬问题：业务指标和技术对象都在平台里，但它们彼此不认识。

大屏上能看到订单量下降、支付成功率抖动、在线用户数掉了一截。另一边，服务、接口、数据库、Redis、Kafka、Kubernetes 工作负载、网络链路也都各有指标、日志、Trace 和告警。数据不少，页面也不少，可值班人真正要回答的问题很简单：该先看哪个技术对象？

如果这个问题没有被提前设计好，排障就会回到人肉搜索。看到订单量下降，先问交易负责人订单链路有哪些服务；看到支付成功率下降，再去翻支付服务、订单服务、三方通道、数据库、消息队列；看到在线用户数下降，还要猜是登录、网关、长连接、客户端版本、统计任务，还是某个地区网络问题。

这不是数据不够，而是路径断了。

Flashcat 里的北极星和灭火图，分别解决这条路径上的两个关键问题。北极星负责看业务或系统核心指标，判断有没有真故障；灭火图负责看技术对象健康状态，帮助人沿着接口、服务、组件、基础设施继续定位原因。北极星如果不能下钻到灭火图，就像业务方报了“支付不好了”，技术方还要从通讯录开始找系统边界。北极星能下钻到灭火图，才算把“业务异常”交给了“技术对象”。

北极星不是业务大屏，灭火图也不是指标墙

北极星最容易被误解成业务大屏。

它当然可以展示业务曲线，比如实时订单量、支付成功率、在线用户数、GMV、登录成功率、设备在线率、报单量。但它真正的价值不是展示，而是把这些核心指标变成故障发现入口。北极星里的首页卡片通常对应一条业务线或一个 IT 系统，业务线下有图表，图表里关联一个或多个指标。指标可以来自 MySQL、日志报表、Prometheus、其他时序库或外部系统。指标进入指标池以后，可以被图表复用，也可以被异常检测和告警策略接管。

这个层次很重要。业务大屏只是让人看见曲线。北极星要回答的是：这条曲线现在是否异常，异常是否代表业务或系统真的出问题，是否需要启动响应。

灭火图也不是把 CPU、内存、错误率铺成另一张大屏。它的视角是对象，不是单个指标。一个下单接口、一组支付服务、一个 MySQL 实例、一个 Redis 集群、一条 IDC 间网络链路，都可以成为灭火图里的卡片。卡片有健康状态：绿色表示正常，红色表示异常，灰色表示未知或无数据。底层详情卡片由健康指标和异常条件计算状态，上层卡片再根据下层状态聚合，把异常从具体对象向上呈现。

北极星回答“业务结果有没有异常”。灭火图回答“支撑这个业务结果的技术对象，哪些不健康”。

业务指标如果没有技术对象承接，事故现场会停在“知道坏了，但不知道哪里坏了”。技术对象如果没有业务指标牵引，又容易陷入“很多地方有波动，但不知道是否影响用户”。两者之间必须有桥。

下钻不是简单跳转，而是把当时的状态带过去

北极星下钻到灭火图，表面上看是一个入口：在北极星图表里配置下钻规则，把某个指标或图表关联到对应的灭火图节点。配置完成后，图表右上角会出现火苗标识。关联的灭火图卡片全部正常时，标识是绿色；只要有关联卡片异常，标识就会变红。

这个交互看起来很小，但在事故现场很有用。

值班人看到支付成功率曲线异常时，不需要先打开灭火图再搜索支付相关卡片。图表右上角的火苗已经告诉他：这条业务曲线背后的技术对象现在是否有异常。如果火苗变红，点击后可以看到所有关联灭火图卡片及其状态，再进入灭火图继续分析。

更关键的是，曲线上的时刻也可以点击查看对应时刻的灭火图状态。事故排查经常不是“现在是什么状态”这么简单。业务曲线可能在 10:05 开始下降，10:13 恢复，值班人 10:20 才进入平台。如果只能看当前状态，很多对象已经恢复，现场就丢了。北极星曲线时刻和灭火图时间轴连起来以后，可以回到异常发生的那个分钟，看当时哪些卡片飘红，哪些仍然正常。

这比单纯跳到一个页面更有价值。下钻应该带着时间上下文，而不是把人扔到另一个系统首页。

同样道理，灭火图内部的下钻也不是“放几个链接”。一张卡片应该关联排查这个对象需要的数据：指标、日志、Trace、仪表盘、事件、上下游卡片、自动化工作流。下单接口卡片应该能看接口流量、成功率、响应时间、错误日志、慢 Trace 和相关发布事件；支付服务卡片应该能看服务错误率、依赖调用、数据库访问、消息积压和三方通道状态；Redis 卡片应该能看连接数、慢查询、内存、主从状态和相关业务调用。

北极星把人带到正确的对象，灭火图再把人带到正确的数据。

带时间上下文的北极星下钻路径

没有下钻时，业务和技术是割裂的

很多团队的监控建设已经走了很远，但仍然停在割裂状态。

业务侧有自己的报表和大屏，技术侧有自己的监控体系。平时各看各的，事故一来就开始对齐口径。

订单量下降，到底是业务活动结束，还是下单入口有问题？支付成功率下降，失败是用户主动取消、风控拒绝、三方通道超时，还是内部接口 5xx？在线用户数下降，是用户真实离开，还是长连接网关抖动、登录服务异常、埋点统计中断、某个 App 版本发错了？

如果北极星没有下钻到灭火图，业务异常之后只能靠会议、群聊和经验传递。技术团队要先判断这条业务指标背后有哪些接口、服务、组件和基础设施，再一个个打开不同页面排查。熟悉系统的人在场，速度可能还可以；新人值班、凌晨故障、系统刚重构过，速度就会明显下降。

更麻烦的是复盘也会变弱。大家会记录“支付成功率下降，原因是支付服务依赖 Redis 异常”，但不会把这个映射固化到监控系统里。下一次支付成功率再下降，还是要重新找一遍。很多组织的稳定性建设慢，就慢在这里：每次事故都学到了东西，但这些知识没有变成下一次排障的默认路径。

下钻配置的价值，就是把这种经验产品化。不是把人的判断完全替掉，而是把“先看哪里”这件事提前规划好。

订单量应该映射到交易入口和下单链路

订单量是最常见的北极星指标。它适合发现交易入口异常，也适合发现统计链路中断。订单量突然低于预测区间，或比昨天同一时间明显下降，通常意味着用户完成交易动作受阻；订单量突然升高，也可能是活动流量、重复提交、消息重放或接口异常。

但订单量本身不能定位根因。它只告诉你“交易结果不正常”。所以配置下钻时，订单量不要只关联订单服务这一张卡片。真实下单链路通常跨过入口、业务服务、库存、优惠券、价格、风控、订单库、消息队列和网关。

一个实用的映射方式是按用户动作拆。

订单量图表首先应该关联接口层卡片，比如商品详情、购物车、订单创建、订单确认、库存锁定接口。这些卡片直接反映用户关键请求是否成功，常用健康指标包括流量、成功率、错误率、P95/P99 延迟。

第二层关联服务卡片，比如订单服务、商品服务、库存服务、优惠券服务、价格服务、风控服务。这些卡片帮助判断问题是不是从某个业务服务开始扩散。订单量下降但下单接口还正常，可能是上游浏览或加购出了问题；下单接口飘红且订单服务也飘红，方向就更明确。

第三层关联组件卡片，比如订单库、库存库、Redis、Kafka 或 RocketMQ、搜索引擎、配置中心。订单链路对数据库连接池、缓存、消息队列都很敏感。订单创建成功但后续消息积压，也会影响支付、履约和数据统计。

第四层关联基础设施卡片，比如网关、负载均衡、DNS、CDN、Kubernetes 集群、机房网络、跨 IDC 链路。订单量按地区或渠道下降时，这一层尤其重要。一个地区的订单下降，未必是订单服务坏了，可能是某条网络链路、某个边缘节点或某个接入集群有问题。

这样配置以后，订单量异常时，北极星右上角火苗的颜色就不只是一个状态提示，而是在告诉值班人：支撑交易入口的对象有没有异常，异常集中在哪一层。

北极星指标到灭火图对象的四层映射

支付成功率要同时关联内部链路和外部通道

支付成功率比订单量更接近真实用户伤害。用户已经走到付款环节，失败一次就是一次明确的业务损失。它适合作为 P0 级北极星指标，但它的下钻也更容易漏。

很多团队配置支付指标时，只把支付成功率关联到支付服务。这个粒度太粗。支付成功率下降可能来自内部支付接口 5xx，也可能来自订单状态校验失败、库存回滚异常、Redis 超时、数据库锁等待、消息消费延迟、三方通道不可用、回调处理失败，甚至是某个客户端版本传参错误。

支付成功率的下钻应该至少覆盖四类对象。

第一类是支付入口接口，包括发起支付、确认支付、查询支付结果、支付回调、退款申请等接口。接口卡片要能看请求量、成功率、错误码分布、响应时间和慢请求。比例指标不能只看百分比，还要看分母。低流量时 2 笔失败 1 笔，成功率是 50%；高峰时 10 万笔失败 2000 笔，成功率仍可能看起来没那么夸张，但影响已经很大。

第二类是支付相关服务，包括支付服务、订单服务、账户服务、风控服务、回调消费服务、对账服务。支付链路经常不是一个服务能解释清楚的。比如支付发起正常，但回调消费异常，会导致订单状态迟迟不更新；支付服务正常，但订单服务状态校验变更，也可能让支付请求被拒。

第三类是支付依赖组件，包括支付库、订单库、Redis、消息队列、配置中心、密钥或证书相关组件。支付事故里，数据库连接池、Redis 连接耗尽、消息队列积压、证书过期、配置变更，都很常见。它们不是支付业务指标，但会直接改变支付成功率。

第四类是外部通道和网络链路，包括微信、支付宝、银联、银行通道、渠道网关、出口网络、专线或代理。支付成功率下降时，如果只看内部服务，很容易误判。外部通道卡片至少要能反映通道可用性、超时率、错误码、回调延迟和请求量。

支付成功率异常时，如果北极星火苗变红，值班人点击后看到三方通道卡片飘红，就可以先收敛到通道侧；如果支付接口和支付服务飘红，但通道正常，就优先看内部服务、数据库、缓存和发布事件；如果所有卡片都是绿色，反而说明当前灭火图覆盖还不够，可能要补业务规则、客户端版本、统计口径或更细的失败原因卡片。

绿色不是万能答案。它有时是在提醒你：技术对象建模还不够。

在线用户数要把入口、连接层和统计链路分开

在线用户数看起来简单，实际最容易误判。它可能代表 WebSocket 连接数，可能代表最近 5 分钟活跃用户数，也可能代表设备在线数、账号在线数或 Session 数。口径不同，下钻对象也不同。

如果在线用户数来自长连接，异常下降要优先看接入网关、长连接服务、负载均衡、心跳服务、认证服务、消息通道和接入集群。它还要按客户端版本、地区、运营商、租户、接入集群拆分。只有 iOS 新版本下降，方向可能在客户端；只有某个地区下降，方向可能在网络或接入节点。

如果在线用户数来自行为活跃，除了登录服务和核心接口，还要关注埋点采集、日志上报、Kafka Topic、消费任务和计算任务。业务正常但在线用户数掉了，可能只是统计链路断了。北极星要做数据中断检测，灭火图也要有统计链路卡片，否则会把“看不见用户”误判成“用户不在线”。

如果是设备在线数或设备在线率，比如 IoT、制造、门店设备、车联网，要把设备接入网关、MQTT Broker、设备影子服务、指令下发服务、区域网络、运营商链路和消息队列纳入映射。设备真实离线和平台接入异常，处理方式完全不同。前者可能是现场电源、网络或设备固件问题；后者可能是接入网关、Broker、认证、证书或平台消费延迟。

在线用户数的下钻重点不是把所有可能对象都塞进去，而是把入口、连接层、统计链路分开。否则曲线一下降，团队很容易在“用户真的少了”和“统计断了”之间反复争论。

映射规划要按影响面和排障路径来做

北极星到灭火图的下钻，不建议事故发生后临时配置。它应该在设计北极星指标时同步规划。

第一步是写清楚指标口径。订单量是创建订单数，还是支付订单数；支付成功率的分母是发起支付笔数，还是收到结果的支付笔数；在线用户数是连接在线，还是行为活跃。口径不清，下钻再完整也会跑偏。

第二步是列出用户关键路径。订单量背后是浏览、加购、确认订单、库存锁定、优惠券、下单、消息投递；支付成功率背后是发起支付、风控、调用通道、回调、订单状态更新；在线用户数背后是登录、认证、连接、心跳、消息、统计。不要从现有服务名开始列，要从用户动作开始列。

第三步是把用户动作映射到四层对象：接口、服务、组件、基础设施。接口层解释用户请求是否成功；服务层解释业务处理是否正常；组件层解释数据库、缓存、消息队列、配置中心等依赖是否健康；基础设施层解释网络、集群、机房、DNS、CDN、网关等底座是否有问题。

第四步是为每张灭火图卡片补健康指标和下钻数据。接口卡片至少要有流量、成功率、响应时间；服务卡片要有错误率、延迟、实例状态、依赖调用；组件卡片要有存活状态、连接、容量、慢查询、积压；基础设施卡片要有可达性、丢包、延迟、节点健康。卡片上还要能继续下钻到日志、Trace、仪表盘和事件。

第五步是控制范围。一个北极星图表不应该关联几十上百张不相干卡片。关联对象太少，无法定位；关联对象太多，火苗一红又变成噪音。比较好的做法是先关联能解释该指标的一条主路径，再把高频根因对象逐步补进来。事故复盘后，如果发现某次根因没有被任何关联卡片覆盖，就补卡片、补规则、补下钻，而不是只在复盘文档里写一句“后续关注”。

一条可执行的落地顺序

如果团队准备把北极星和灭火图连起来，不要一开始就覆盖所有业务线。先选一个最关键的业务，比如交易、支付、登录、设备接入、证券报单，做出一条能跑通的路径。

先在北极星里放三类指标：一条结果指标，比如订单量或报单量；一条质量指标，比如支付成功率或登录成功率；一条入口指标，比如在线用户数、请求量或设备在线数。每条指标都要写清楚口径、数据来源、维度和异常检测方式。量类指标可以用智能预测、同环比和数据中断检测，比例类指标可以用阈值叠加规模条件，避免低样本误报。

然后在灭火图里为这三条指标建立对应对象。不要只建服务卡片，也要覆盖接口、组件和基础设施。卡片状态要能反映对象健康，而不是只做静态目录。每张关键卡片都要有继续排查的入口，包括指标、日志、Trace、仪表盘和事件。

最后配置北极星图表到灭火图节点的下钻。配置完成后，去看三个动作是否成立：图表右上角火苗是否出现；关联卡片异常时火苗是否变红；点击曲线异常时刻，是否能看到那个时刻对应的灭火图状态。

这三个动作成立，业务异常到技术对象的路径才算真正接上。

北极星到灭火图的落地验证闭环