3. 阈值校准的数学基础：均值、中位数、百分位数（p50/p90/p99）、标准差在阈值设定中的应用

在 Prometheus 告警体系中，阈值是触发告警的“扳机”。如果阈值设置不当，要么告警泛滥（灵敏度太高），要么故障漏报（灵敏度太低）。要科学地设定阈值，不能仅凭经验拍脑袋，而需要借助统计学工具对历史指标数据进行量化分析。本节将介绍四个核心统计量——均值、中位数、百分位数和标准差——并说明它们在阈值校准中的具体应用场景与计算方法。

3.1 核心统计量定义与适用场景

以下表格对比了四个统计量的数学定义、抗干扰能力以及它们在阈值设定中的典型用途：

3.2 百分位数：p50、p90、p99 的阈值意义

百分位数是阈值校准中最常用的工具，尤其适用于非正态分布（如请求延迟、错误率）的指标。以下是三个关键百分位数的业务解读：

• p50（中位数）：50% 的请求在此值以下。用于衡量“典型体验”，适合作为低优先级告警的基线。
• p90：90% 的请求在此值以下。代表“大多数用户”的体验，适合作为主要告警阈值。
• p99：99% 的请求在此值以下。代表“最差 1% 用户”的体验，适合作为严重告警或紧急响应的阈值。

在 PromQL 中，使用 histogram_quantile 函数从 Histogram 指标中计算百分位数：

# 计算过去 5 分钟的 p99 请求延迟（单位：秒）
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

3.3 标准差与动态阈值模型

标准差描述了数据围绕均值的波动程度。在阈值设定中，标准差常用于构建“自适应”或“动态”阈值，公式为：

阈值 = 均值 ± n × 标准差

其中 n 为倍数系数，通常取 2 或 3：

• n=2：覆盖约 95% 的正常数据（假设正态分布），适合中等敏感度告警。
• n=3：覆盖约 99.7% 的正常数据，适合高敏感度告警（减少误报）。

在 Prometheus 中，可以使用 stddev_over_time 和 avg_over_time 组合实现动态阈值：

# 动态上界：均值 + 3倍标准差
avg_over_time(node_cpu_seconds_total[1h]) + 3 * stddev_over_time(node_cpu_seconds_total[1h])

3.4 统计量选择决策流程

以下 SVG 流程图展示了在实际阈值校准中，如何根据指标特征选择最合适的统计量：

3.5 综合案例：使用百分位数校准 API 延迟阈值

假设我们需要为一个 API 网关设置延迟告警阈值。以下是基于历史数据的校准步骤：

1. 数据采集：使用 rate 和 histogram_quantile 计算过去 7 天的 p50、p90、p99 延迟。
2. 基线确定：取 p50 的周均值作为“正常基线”，p90 的周均值作为“警告线”，p99 的周均值作为“严重线”。
3. 阈值微调：在 p99 基础上增加 20% 缓冲（避免瞬态尖峰误报），作为最终严重告警阈值。

# 步骤1：计算过去7天p99延迟的均值（单位：ms）
avg_over_time(
  histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
  [7d]
)

# 步骤2：最终严重告警阈值 = p99均值 * 1.2
# 在告警规则中使用：
- alert: APIHighLatency
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > (avg_over_time(histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))[7d]) * 1.2)
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "API p99延迟超过基线20%"