3. 监控指标设计

监控指标设计不是把所有能采集到的数字都堆到看板上，而是围绕“系统是否健康、用户是否满意、业务是否正常”这三个问题，挑选出少量能反映真实状态、能驱动处置动作的指标。指标选错，告警会淹没运维人员；指标缺失，故障会以用户投诉的形式才被发现。本节从四类指标的分工出发，给出可落地的选取与定义方法。

四类指标的分工与关系

黄金指标（Golden Signals）来自 Google SRE 实践，指延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）四项，它描述的是“服务本身运行得好不好”，适用于任何有请求响应的服务。业务指标描述“业务运转得好不好”，如订单创建成功率、支付转化率、日活用户数，它把技术状态翻译成业务语言。资源指标描述“承载服务的底座够不够用”，如 CPU 使用率、内存占用、磁盘 IO、连接数、带宽。用户体验指标描述“用户实际感受到的快不快、顺不顺”，如首屏时间、接口端到端耗时、页面可用性、错误提示率。

四者不是并列堆叠，而是存在因果链：资源不足会推高延迟和错误，进而恶化用户体验，最终反映为业务指标下滑。因此设计时应先确定业务指标作为“北极星”，再用黄金指标定位服务层问题，用资源指标定位根因，用用户体验指标验证真实影响。下图展示了这一分层与传导关系。

选取方法：从 SLO 反推指标

指标选取应从服务等级目标（SLO）出发，而不是从“能采什么”出发。以某订单服务为例，假设业务方要求“下单接口 99% 的请求在 300ms 内返回，月度可用性不低于 99.9%”。由此可反推出：延迟指标取 P99 而非平均值，阈值 300ms；可用性用成功请求数除以总请求数，统计窗口为月度。再往下，为支撑这两个指标，需要采集请求量（QPS）、错误码分布、下游依赖耗时、数据库连接池占用等。

选取时遵循三条原则：可行动——指标异常时运维能采取明确动作，如“连接池占用超 80%”可触发扩容；可归因——指标能指向具体组件或链路环节；可对比——有基线或历史同期数据，能判断“是否真的异常”。无法行动、无法归因、无法对比的指标，即使数值好看，也不应进入核心看板。

定义方法：名称、口径、维度与阈值

一个指标只有被精确定义后才可被信任。定义至少包含五要素：名称、计算口径、采集维度、统计周期、告警阈值。以“下单接口 P99 延迟”为例：

口径必须写清楚“分母是什么、是否包含失败请求、是否剔除预热流量”。例如错误率若把客户端 4xx 计入，会把用户输入错误误判为服务故障，通常应区分 5xx 服务端错误率与 4xx 客户端错误率。维度设计要控制基数，避免用用户 ID、订单号等高基数字段作为标签，否则会拖垮时序数据库。

实操示例：为支付服务设计指标集

假设支付服务需接入监控，按四层设计如下指标集（示例参数，非实测）：

业务指标：
  pay_success_rate        支付成功率 = 成功笔数 / 发起笔数，阈值 < 99.5%
  pay_amount_per_min      每分钟支付金额，用于容量与异常检测

用户体验指标：
  pay_e2e_latency_p95     端到端支付耗时 P95，阈值 > 2s
  pay_page_availability   支付页可用性，阈值 < 99.9%

黄金指标：
  pay_qps                 支付请求速率
  pay_error_rate_5xx      服务端错误率，阈值 > 0.5%
  pay_latency_p99         服务处理延迟 P99，阈值 > 800ms
  pay_saturation          线程池饱和度，阈值 > 80%

资源指标：
  db_conn_usage           数据库连接池使用率，阈值 > 85%
  redis_mem_usage         Redis 内存使用率，阈值 > 80%
  host_cpu_usage          主机 CPU 使用率，阈值 > 75% 持续 5 分钟

采集后需验证指标是否“灵敏且不误报”。可用一次受控压测或历史故障回放来检验：例如人为将数据库连接池上限调低，观察 db_conn_usage 是否先升高、pay_latency_p99 是否随后上升、pay_success_rate 是否最终下降。若传导链在预期时间内出现，说明指标集能反映真实故障；若某指标始终不动，则需检查采集点或口径是否正确。

最后，指标定义应随服务演进定期复核。当接口拆分、依赖变更或业务目标调整时，原有阈值和口径可能失效。建议每季度对照 SLO 复核一次指标集，删除不再行动的指标，补充新链路的关键观测点，使监控始终与真实风险对齐。