监控告警体系：指标选型、阈值与降噪

监控系统收集的数据越多，不代表故障越容易发现。有效体系需要回答三个问题：用户是否受影响、影响正在扩大吗、值班人员能采取什么动作。若一个告警没有明确的响应者与处置路径，它更接近噪声，而不是安全网。

黄金四指标、RED 与 USE

面向在线服务时，黄金四指标提供了一组稳定视角：

RED 方法更适合请求驱动服务：Rate、Errors、Duration。USE 方法更适合资源：Utilization、Saturation、Errors。例如排查数据库连接池，应同时看使用率、等待队列和连接错误；只看 CPU 可能遗漏真正瓶颈。三种方法不是互斥清单，可以从用户请求的 RED 定位到依赖与节点的 USE。

流量很低时，错误率容易被单个失败放大；只看错误数又会在高流量时低估影响。告警表达式可同时设置最小请求量与错误率条件，并保留“完全无流量”作为独立信号。

Counter、Gauge 与 Histogram

Counter 只累加，进程重启时归零，适合请求数、失败数和处理字节。查询时通常计算时间窗口内的增长率，不应直接比较绝对值。若 counter 因重启下降，查询函数需要识别重置。

Gauge 可升可降，适合当前队列深度、温度、活动连接和剩余磁盘。把累计请求做成 gauge 会让速率计算失去重置语义；把队列长度做成 counter 又无法表达消费后的下降。

Histogram 把观测值计入若干桶，并维护总数与总和，适合请求时延和对象大小。桶边界必须围绕 SLO 与业务尺度设置。若最关键目标是 300 毫秒内完成，边界中应包含 300 毫秒附近，而不是只用跨度过大的默认桶。

http_requests_total{route="/orders",code="5xx"}  counter
queue_depth{queue="billing"}                     gauge
http_request_duration_seconds_bucket{le="0.3"}  histogram bucket

标签会生成时间序列组合。用户 ID、订单号、原始 URL 等高基数值不能作为指标标签，否则序列数量随业务数据增长，拉高采集、存储和查询成本。此类细节应放在日志或追踪中。

分位数为何比平均值有用

平均值会掩盖长尾。假设大多数请求很快，少量请求耗时数秒，平均值仍可能看起来平稳，但受影响用户已经感知卡顿。P95、P99 表示相应比例的请求耗时不超过某个值，更适合观察尾部体验。

直方图分位数是根据桶近似计算，精度取决于桶边界；桶太宽，计算出的分位数只能落在较粗区间。客户端直接计算的分位值通常难以跨实例正确聚合，直方图桶却可以先汇总实例和区域，再求整体分位数。平均值并非无用，它适合容量估算和趋势对比，但不能代替尾延迟。

延迟统计还要区分成功与失败。快速返回错误可能让整体 P99 下降，造成“性能变好”的错觉。可分别观察成功请求延迟、错误请求延迟与超时数量。

阈值来自风险，不来自整齐数字

固定阈值适合明确容量边界，如磁盘剩余空间、证书到期时间。动态基线适合周期明显的流量或延迟，但模型异常也可能产生误报，需要保留简单的兜底规则。无论采用哪种方式，阈值都应关联用户影响和响应动作。

告警可按响应方式分级：

P0 不能仅由单个实例异常触发，应结合服务可用性、区域范围与冗余是否失效。P2 若长期无人处理，也不该继续保留为“装饰性告警”，应明确责任人与完成时限。

持续时长、抑制与聚合

瞬时毛刺可通过持续时长门槛过滤。例如错误率连续五分钟超过阈值才触发，恢复也要求持续一段时间，避免状态来回抖动：

alert: ApiHighErrorRate
expr: error_rate_5m > 0.02 and request_rate_5m > 10
for: 5m
labels:
  severity: P1

时长不能无条件设长。对快速消耗错误预算的故障，等待十几分钟会错过处置窗口；更合理的是按消耗速率设置短窗与长窗组合。

抑制规则用于屏蔽因上游根因产生的下游告警。例如整个节点失联时，抑制该节点上几十个实例的“目标不可达”；数据库主故障时，可抑制依赖服务的重复连接告警，但保留用户可用性告警。抑制必须有清晰的标签关联，不能按文本模糊匹配。

聚合分组把同一服务、区域和故障类型的实例告警合成一条通知，并在内容中列出受影响范围。聚合维度过细仍会刷屏，过粗则把独立事故混在一起。值班系统还需要去重、静默有效期和维护窗口，静默到期后自动恢复，避免永久隐藏信号。

告警疲劳的治理

告警疲劳会让值班人员形成条件反射式确认，真正高风险信号也可能被忽略。治理不能靠要求“更认真”，应定期统计每条规则的触发次数、确认耗时、实际动作和误报原因。长期无动作的告警要删除、降级为看板或改成工单；频繁波动的规则应修正指标、阈值和持续时间。

每条可呼叫告警至少包含服务所有者、影响描述、看板、查询和处置手册。手册应写可验证步骤，而不是“检查服务状态”。自动修复动作要有次数上限与失败升级，避免重启循环掩盖资源泄漏。

SLO 与错误预算

SLO 把可靠性目标定义在用户可观察的服务指标上。例如一个周期内，合格请求比例达到约定目标。错误预算是允许不合格的份额：

SLI = 合格请求数 / 有效请求总数
错误预算比例 = 1 - SLO
预算消耗速率 = 实际不合格比例 / 允许不合格比例

告警可基于预算燃烧率，而不是任意 CPU 阈值。短窗口高燃烧率捕捉突发事故，长窗口较低燃烧率发现持续退化；两者同时满足可减少瞬时误报。依赖服务超时、发布错误或容量不足最终都会映射到用户请求是否合格。

SLO 也为发布决策提供边界：预算充足时可以承担受控变更，预算快速消耗时应收紧发布并优先修复可靠性。目标过高会让正常迭代失去空间，目标过低又无法约束体验，应根据用户期望与系统架构评审，而不是照搬统一百分比。

上线一条新告警前，应在历史数据上回放表达式，检查低流量、重启、缺数据和维护窗口；触发后安排演练，确认通知能到达正确人员，手册可以执行，恢复条件也符合预期。告警只有在真实处置链中闭环，才是可运营的可靠性机制。