容量告警

在容量耗尽（余量、饱和、增长率）成宕机前告警。

为什么

宕机告警（"服务挂"）在损害后触发 — 客户已在失败。容量告警（"余量 < 10%"、"DB 池 80% 满"、"盘 90%"）在损害前触发，给你数分钟到数小时在客户受影响前扩或修。这是从反应性到前瞻性运维的转：按先导指标（利用、饱和、增长率）告警非滞后（错误、延迟）。三容量信号是：利用（CPU 70%、盘 80%）、饱和（队列深长、DB 池等）和增长率（流量月增 20%、2 周内撞天花板）。三者都告警，带够前导时间行动 — "盘 90%"给你数小时、"盘 99%"给你数分钟、"盘满"给你宕机。按容量告警的团队报影响客户事件少 70%，因他们在坏任何东西前修容量问题。

何时使用

总是。在所有关键资源上设给行动前导时间的容量告警阈值。

如何做

1. 按利用告警（基本信号）
   - CPU >70% 持续 5m → 警；>85% 持续 2m → page
   - 内存 >80% → 警；>90% → page（OOM 迫）
   - 盘 >80% → 警；>90% → page（盘满 = 服务挂）

2. 按饱和告警（长信号）
   - 队列深长（现深 > 5m 前深 2x）→ 警
   - DB 池等（wait_time > 100ms）→ 警；>500ms → page
   - 线程池耗尽（拒任务 > 0）→ page

3. 按增长率告警（预测信号）
   - 流量周增 >20% → 警（若趋势续将撞天花板）
   - 盘用日增 >5% → 警（N 天内满）
   - DB 大小月增 >10% → 警（将撞存储限）

4. 设带前导时间阈值
   - 盘 80% → 10%/天 2 天满 → 警（时行动）
   - 盘 90% → 1 天满 → page（立即行动）
   - 别设 99% — 那 1 小时满，前导时间不足

5. 把容量告警路由到正确响应者
   - 盘 → 平台队（加存或清理）
   - DB 池 → DB 队（提池或调查询）
   - 流量增 → 服务队（扩或调查增长因）

示例

# 容量告警（Prometheus）：
groups:
  - name: capacity
    rules:
      # 1. 利用（基本）
      - alert: CheckoutCPUHigh
        expr: avg(rate(cpu_usage[5m])) > 0.70
        for: 5m
        labels: { severity: warn, team: payments }
      - alert: CheckoutCPUCritical
        expr: avg(rate(cpu_usage[5m])) > 0.85
        for: 2m
        labels: { severity: page, team: payments }

      # 2. 饱和（长）
      - alert: CheckoutQueueGrowing
        expr: queue_depth > 2 * queue_depth offset 5m
        labels: { severity: warn, team: payments }
      - alert: DbPoolWaiting
        expr: db_pool_wait_time_ms > 500
        for: 1m
        labels: { severity: page, team: db-platform }

      # 3. 增长率（预测）
      - alert: DiskFillingFast
        expr: deriv(disk_usage[1d]) > 0.05  # >5%/天
        labels: { severity: warn, team: platform }
        annotations:
          summary: "盘 >5%/天填 — {{ $value }} 天内满"
      - alert: TrafficGrowingFast
        expr: rate(http_requests[1w]) > 1.2  # >20% 周增
        labels: { severity: warn, team: payments }
        annotations:
          summary: "流量 >20% 周增 — 查容量 vs 天花板"

# 前导时间：
#   盘 80% 5%/天 → 4 天满 → 警（4 天前导）
#   盘 90% 5%/天 → 2 天满 → page（2 天前导）
#   盘 95% 5%/天 → 1 天满 → page（1 天前导，立即行动）

常见问题

⚠仅宕机告警无容量告警 — 客户失败时才知；按利用/饱和/增长告警取前导时间。
⚠阈值 99% — 1 小时满，前导时间不足；设 80%（警）和 90%（page）取数天前导。
⚠无增长率告警 — 流量月增 20% 且 2 周撞天花板无警；按趋势告警非仅当前值。
⚠所有容量告警一队 — 盘告警给无法加存的 app 队；按资源路由给能修的队。

最佳实践

✓按全三容量信号告警：利用（CPU/盘 %）、饱和（队列/池等）、增长率（流量/盘长）。
✓设带前导时间阈值：盘 80% 警（数天满）、90% page（立即行动）；别设 99% — 那是宕机非容量告警。
✓按增长率（1d/1w 导数）告警以数周前预测撞天花板；趋势是早期警告。
✓按资源把容量告警路由给能修的队（盘 → 平台、DB 池 → DB 队、流量 → 服务队）。