4. 指标体系建设与异常检测基线

当可观测性数据已经能够被稳定采集、存储和查询之后，真正决定排障效率的往往不是“有没有数据”，而是“有没有一套能快速判断异常、并指向问题方向的指标体系”。指标不是越多越好，一个服务暴露上千个指标，如果没有分层、没有基线、没有下钻路径，告警只会变成噪声。本节围绕指标分层设计、统计基线与动态阈值、多维度下钻和异常初步定位，给出一套可落地的建设方法。

一、指标分层：黄金指标、资源指标与业务指标

生产环境的指标体系通常分为三层，每层回答不同的问题。

第一层是黄金指标（Golden Signals），即延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。它们回答“服务现在是否健康”。延迟要区分成功请求延迟和失败请求延迟，因为失败请求往往快速返回，会拉低平均延迟，掩盖真实问题；流量反映请求速率或并发量；错误包括显式错误（HTTP 5xx、gRPC 非 OK 状态码）和隐式错误（业务返回码、空结果）；饱和度描述资源接近上限的程度，如 CPU 使用率、连接池占用率、队列深度。

第二层是资源与依赖指标，包括 CPU、内存、磁盘 IO、网络、GC 次数与停顿、线程池、数据库连接池、缓存命中率、下游 RPC 成功率等。它们回答“瓶颈可能在哪里”。

第三层是业务指标，如订单创建成功率、支付转化率、登录成功率、消息投递延迟、库存扣减失败率。它们回答“业务是否真的受影响”。黄金指标正常但业务指标下跌，往往意味着逻辑层或数据层出现了不易察觉的问题，例如缓存穿透导致大量请求打到数据库但被快速兜底返回。

二、统计基线与动态阈值

静态阈值（如 CPU > 80% 告警）简单但脆弱：业务有早晚高峰，阈值定高会漏报，定低会误报。更合理的做法是基于历史数据建立统计基线。

常见基线方法有三类。第一类是周期基线：按小时、星期几、工作日/节假日分组，计算同一时间窗口内指标的中位数与分位数。例如某接口 P99 延迟在工作日 10:00 的基线为 180ms，若当前为 420ms，则偏离显著。第二类是滑动窗口统计：用过去 1 小时或 24 小时的均值与标准差，计算当前值的 Z-Score，|Z| > 3 触发异常。第三类是动态阈值：结合同比与环比，例如当前值相对上周同时刻变化超过 30%，且绝对值超过基线 P95，才判定异常。

下面给出一个基于滑动窗口的动态阈值计算示例，用于判断接口 P99 延迟是否异常：

# 示例：基于过去 24 小时滑动窗口计算动态阈值
# 假设窗口内每分钟采样一次，共 1440 个点
window = latency_p99[-1440:]          # 过去 24 小时 P99 序列
baseline = median(window)             # 基线取中位数，抗离群点
mad = median(|x - baseline| for x in window)  # 中位绝对偏差
threshold = baseline + 3 * 1.4826 * mad       # 稳健阈值，约等于 3σ

current = latency_p99[-1]
if current > threshold:
    alert("P99 延迟异常", current, threshold)

使用中位数与 MAD 而非均值与标准差，是因为延迟分布长尾明显，均值和标准差容易被极端值拉偏。1.4826 是让 MAD 在正态分布下与标准差一致的比例因子。实际生产中，阈值还应叠加“持续时长”条件，例如连续 3 个采样点超过阈值才告警，避免瞬时抖动。

三、多维度下钻与异常初步定位

指标异常后，第一步不是立刻重启服务，而是通过多维度下钻缩小范围。常见下钻维度包括：服务/实例、接口/方法、机房/可用区、版本/发布批次、用户分群、设备类型、下游依赖。

下钻的基本逻辑是“先看整体，再按维度拆分，找到贡献度最高的维度值”。例如整体错误率从 0.2% 升到 5%，按实例拆分后发现只有 2 台实例错误率高，说明是实例级问题；按接口拆分后发现集中在“提交订单”接口，说明是业务逻辑问题；按版本拆分后发现新版本错误率是旧版本 20 倍，说明是发布引入的缺陷。

为了量化“哪个维度贡献最大”，可以用贡献度公式：某维度值的异常增量 = 该维度值当前错误率 × 该维度值流量占比 − 基线错误率 × 流量占比。贡献度最高的维度值就是最可能的根因方向。

四、异常初步定位的实操顺序

结合上述分层与下钻，异常初步定位可以按以下顺序推进，但不必机械执行，应根据现象灵活调整。

1. 确认异常真实性：检查指标采集是否正常，排除采集断点、时间对齐错误、标签丢失导致的假异常。
2. 判断影响面：看业务指标是否同步下跌，若业务指标正常，可能只是资源层波动，优先级可降低。
3. 按维度拆分：从实例、接口、版本、机房等维度计算贡献度，找到异常最集中的维度值。
4. 关联依赖：查看该维度值对应的下游依赖指标，如数据库连接数、缓存命中率、第三方接口延迟。
5. 形成假设并验证：例如“v2.3.1 新增的库存校验逻辑导致 DB 查询增多”，再通过日志、链路追踪或回滚验证。

五、指标设计中的常见陷阱

第一，平均延迟陷阱：平均延迟正常不代表没有长尾问题，必须同时看 P95、P99 甚至 P999。第二，高基数标签：把用户 ID、请求 ID 作为标签会导致时间序列爆炸，应使用分群或采样。第三，缺少单位与方向：指标名应明确单位（ms、bytes、count）和方向（越大越好还是越小越好），否则告警阈值容易设反。第四，基线未随业务变化更新：大促、版本发布、流量结构变化后，旧基线会失效，应定期重新训练或采用自适应基线。

指标体系建设不是一次性任务，而是随着业务演进而持续调整的过程。黄金指标保证服务健康可见，业务指标保证影响可感知，统计基线与动态阈值降低误报漏报，多维度下钻把“异常”转化为“方向”。把这四件事串起来，异常初步定位才能从经验驱动走向数据驱动。