服务治理看板应该展示哪些指标？

简化版

治理看板要同时回答“用户是否受损、哪条依赖异常、哪条规则正在介入、系统能否恢复”。核心包括请求量、成功率、延迟分位数，以及限流拒绝、熔断状态、降级命中、重试放大和资源饱和度。指标必须按服务、接口、调用方向和规则版本下钻，并与发布事件关联；只有 CPU 折线或全局平均值无法指导治理。

详细版

第一层是业务与 SLO：核心请求成功率、P95/P99、降级后的业务成功率、错误预算消耗。第二层是依赖 RED：rate、errors、duration 和超时分类。第三层是治理动作：各规则命中、被拒 QPS、熔断状态转换、半开探测、重试次数与 fallback 类型。第四层是饱和度：线程、连接、队列、in-flight 和实例分布。

看板默认展示近 1 小时与基线对比，同时能按 1 分钟观察事故、按 7 天看趋势。告警依据用户影响与持续时间，而非每次状态变化。高基数标签如 userId、traceId 不进入指标标签，单请求定位交给日志和 Trace。

完整版教学

一、看板从问题而不是图表出发

治理看板的读者要判断：是否需要止血、哪条规则生效、误伤多少正常流量、恢复是否稳定。因此图表顺序应从用户结果到调用链，再到治理动作与资源，而不是按监控系统采集到什么就展示什么。每张图都应对应一个可执行判断。

记忆钩子：先看“疼不疼”，再看“哪里疼”，最后看“药有没有副作用”。

二、顶层用 SLI 表达用户影响

顶层放核心接口的有效成功率、延迟目标和错误预算消耗。有效成功要区分完整结果、可接受降级和不可接受假成功。例如 100 万次请求中 990000 次完整成功、5000 次允许的推荐降级、5000 次失败，若 SLO 把允许降级计成功，则可用性为 99.5%，但仍需单列 0.5% 降级率。

availability = good_events / valid_events
              = (990000 + 5000) / 1000000
              = 99.5%

三、依赖层采用 RED 并保留方向

Rate 表示流量，Errors 按超时、连接、5xx、业务拒绝分类，Duration 展示 P50/P95/P99。必须保留 caller -> callee -> operation 方向，否则只能看到库存服务变慢，却不知道是下单还是后台任务造成。平均延迟会被大量快请求稀释，不能替代尾延迟。

层次	关键指标	主要回答
用户/SLO	有效成功率、P99、预算	用户是否受损
依赖 RED	QPS、错误分类、延迟	哪条调用异常
治理动作	拒绝、状态、fallback	规则做了什么
资源	线程、连接、队列	是否已经饱和

四、治理动作必须可解释

限流展示允许与拒绝 QPS、规则阈值和命中维度；熔断展示 CLOSED/OPEN/HALF_OPEN、切换原因和探测结果；降级展示 fallback 类型；重试展示原请求数与额外尝试数。只画“熔断次数 10”无法判断是 10 个实例各切一次，还是一条规则来回振荡。

retryAmplification = total_attempts / original_requests
原请求 1000，额外重试 300 -> amplification = 1.3

五、规则版本与发布事件要对齐

每个规则指标携带低基数的 ruleId、version 和 result，部署、配置发布、扩缩容作为时间线标记。若 P99 在 10:05 上升，而 v42 限流规则在 10:03 发布，排查路径非常直接。规则版本不能用完整 JSON 作为标签，否则会制造不可控基数。

看板还应支持对比变更前后窗口，例如前 30 分钟与后 30 分钟的拒绝率、成功率和下游 QPS，而不是靠肉眼看两条抖动曲线。

六、标签基数与数据准确性

service、operation、zone、statusCodeClass 通常可作为标签；userId、orderId、原始 URL、异常全文不可以。假设 100 个服务、50 个接口、10 个状态、20 个区域，笛卡尔积已达 100 万时间序列，继续加入用户会让存储和查询失控。高基数上下文放 exemplars、日志或 Trace。

采集失败也要可见，包括丢样率、指标延迟和实例覆盖率。否则监控中断会被误判为请求量归零。聚合值还需与网关或账单抽样对账，确认埋点没有重复计数。

七、常见误区与追问

误区：看板指标越多越专业。 没有决策用途的图只会延长事故定位时间。
误区：平均延迟足以表示性能。 长尾问题必须看分位数和超时比例。
误区：降级响应都算正常成功。 应按业务认可范围计算，并单列质量损失。
误区：把 traceId 放进指标标签方便排查。 这会产生高基数，单请求应通过 exemplar 跳转。
追问：告警设在治理动作还是用户指标？ 用户影响做主告警，治理动作异常做诊断或预警，两者关联。
追问：如何发现规则误伤？ 对比被拒请求特征、业务成功率、下游水位和规则发布前后差异。
追问：多大时间窗口合适？ 事故用秒/分钟级，容量与 SLO 用小时/天级，需同时提供。

八、加强记忆

治理看板按“SLO—RED—动作—资源—变更”排列：先确认用户影响，再定位调用边，查看限流熔断降级做了什么，核对资源是否饱和，并用规则版本与发布时间解释变化。控制标签基数、暴露采集质量，才能让看板既查得快又值得信。

简化版

详细版