2. 传统规则阈值基础：固定阈值、静态阈值的定义与适用场景

在告警降噪策略中，固定阈值（Fixed Threshold）与静态阈值（Static Threshold）是最早被广泛采用的方法。它们基于运维专家对系统行为的先验知识，设定一个或多个不变的数值边界，当监控指标超出边界时触发告警。理解这两种阈值是后续对比动态阈值、评估机器学习降噪效果的前提。

2.1 固定阈值与静态阈值的定义

2.2 传统规则阈值的核心特征

• 确定性： 给定相同的指标值，告警结果完全可预测，便于审计和故障回溯。
• 低计算开销： 仅需简单的数值比较，无需历史数据存储或模型推理，适合大规模基础设施的实时监控。
• 配置依赖专家经验： 阈值通常由 SRE、运维工程师根据 SLI/SLO、容量规划或历史故障复盘手动设定。
• 无自适应能力： 阈值不会因业务高峰、版本发布、流量突增或系统演进而自动调整。

2.3 适用场景分析

传统规则阈值并非在所有场景下都失效。在以下环境中，它们仍然是最优选择：

2.4 传统规则阈值的局限性

• 误报（False Positive）： 业务高峰期（如双11、秒杀）CPU 短暂飙高到 92%，但系统仍健康，固定阈值 90% 触发大量无效告警。
• 漏报（False Negative）： 低负载时段（凌晨 3 点）CPU 从 10% 缓慢爬升到 60%，虽未达到 90% 阈值，但已表明存在内存泄漏或死锁。
• 配置维护成本高： 每新增一个指标或服务，都需要人工评估并设定阈值；随着微服务数量增长，配置量呈线性甚至指数级上升。
• 无法感知趋势： 只关注瞬时值，忽略指标的变化速率、周期模式或相关性。

2.5 固定阈值 vs 动态阈值：核心差异一览

2.6 传统规则阈值的工作流示意

下图展示了固定阈值在典型监控系统中的处理流程：

2.7 配置示例：Prometheus 中的固定阈值告警规则

以下是一个典型的 Prometheus 告警规则配置，展示了固定阈值的实际写法：

groups:
  - name: example-fixed-thresholds
    rules:
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} CPU usage > 90%"

      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Instance {{ $labels.instance }} memory usage > 85%"

      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} root disk < 10% free"

2.8 小结