8.5 告警设计：燃烧率与领先指标

❌ P99 > 200ms → 告警       （看瞬时值，天天响）
✅ 燃烧率 > 14.4 → 告警      （看消耗速度 + 双窗口交叉验证）

燃烧率 = 当前错误率 / 允许的错误率

例：SLO = 99.9% → 允许错误率 = 0.1%
    当前错误率 = 1%
    → 燃烧率 = 1% / 0.1% = 10
    → 意味着"照这个速度，30 天的预算 3 天就用完了"

长窗口（1 小时）：抑制误报——偶发的尖刺不会让 1 小时的平均错误率超标
短窗口（5 分钟）：保证灵敏——真实的持续故障会立刻让 5 分钟的错误率飙升

两个窗口【同时】满足才告警 → 既灵敏又不误报

# 只用一个窗口的问题
- alert: Bad
  expr: error_ratio_5m > 0.0144    # ❌ 5 分钟窗口太短，偶发尖刺就触发

- alert: AlsoBad
  expr: error_ratio_1h > 0.0144    # ❌ 1 小时窗口反应太慢，故障持续 50 分钟才报警

# ✅ 双窗口
- alert: ErrorBudgetBurnFast
  expr: |
    error_ratio_1h > 14.4 * 0.001
    and
    error_ratio_5m > 14.4 * 0.001
  for: 2m

groups:
  - name: leading-indicators
    rules:
      # ① 连接池排队（最早的信号）
      - alert: ConnectionPoolSaturated
        expr: db_pool_pending > 0
        for: 5m
        labels: { severity: ticket }
        annotations:
          summary: "连接池出现排队（pending > 0 持续 5 分钟）"
          runbook: |
            ① 【先查慢查询，不要先加池】
               psql -c "SELECT calls, mean_exec_time, total_exec_time, left(query,50)
                        FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"
            ② 查长事务：SELECT pid, now()-xact_start, state FROM pg_stat_activity
                          WHERE xact_start IS NOT NULL ORDER BY 2 DESC LIMIT 10;
            ③ 只有在查询正常、并发确实高时，才用 Little's Law 调整池大小
            ④ 详见第 6.5 节

      # ② GC 停顿（影响尾延迟）
      - alert: GcPauseHigh
        expr: |
          histogram_quantile(0.99,
            sum by (le) (rate(jvm_gc_pause_seconds_bucket[5m]))) > 0.2
        for: 10m
        labels: { severity: ticket }
        annotations:
          summary: "GC 停顿 P99 > 200ms"
          runbook: |
            ① 与 P99 尖刺做时间对齐（第 6.6 节）——不对齐则排除 GC
            ② 采分配火焰图找分配热点
            ③ 检查堆大小与 GC 选型
            ④ 详见第 7.7 节

      # ③ 容器 CPU 节流（"本地好、上线慢"的头号原因）
      - alert: ContainerCpuThrottled
        expr: |
          rate(container_cpu_cfs_throttled_periods_total[5m])
          / rate(container_cpu_cfs_periods_total[5m]) > 0.25
        for: 10m
        labels: { severity: ticket }
        annotations:
          summary: "容器被 CPU 配额节流 > 25%"
          runbook: |
            ① 确认 CPU limit 是否过低
            ② 看 CPU 需求是否合理（可能是日志/序列化浪费）
            ③ 详见第 4.8 节

      # ④ 队列积压（无界队列 OOM 的前兆）
      - alert: ExecutorQueueBacklog
        expr: executor_queue_depth > 100
        for: 10m
        labels: { severity: ticket }
        annotations:
          summary: "线程池队列积压 > 100"
          runbook: |
            ① 查线程在忙什么（可能是在等 IO，不是真的在算）
               jcmd <pid> Thread.print | grep -A3 BLOCKED
            ② 检查是否有慢依赖
            ③ 详见第 6.5 节

只有【用户已经在受影响，且需要立刻介入】才 page。
其余都是 ticket 或 log。

① 某个告警一天响 10 次
② 工程师开始忽略它（或设成静音）
③ 三个月后真实故障发生时 → 也被忽略
④ 告警实际上已经死了

## 告警复盘（2025-01）

| 告警 | 触发次数 | 有效次数 | 有效率 | 处理 |
| --- | --- | --- | --- | --- |
| ErrorBudgetBurnFast | 2 | 2 | 100% | 保持 |
| ConnectionPoolSaturated | 15 | 3 | 20% | 阈值从 pending>0 改成 pending>5，for 从 5m 改成 10m |
| GcPauseHigh | 30 | 0 | 0% | ⛔ 降级为 ticket（或删除，因为 GC 停顿与 P99 不对齐） |
| ContainerCpuThrottled | 1 | 1 | 100% | 保持 |

**结论**：GcPauseHigh 的 0% 有效率说明阈值（200ms）太紧 —— 要么放宽，要么删除

## 必加告警（按优先级）

### P0：page（立即叫人）
- [ ] 错误预算燃烧率 > 14.4（双窗口：1h + 5m）
- [ ] 核心接口完全不可用（成功率 < 90% 持续 2 分钟）
- [ ] 数据库不可用

### P1：ticket（当天处理）
- [ ] 连接池 pending > 5（持续 10 分钟）
- [ ] 容器 CPU 节流 > 25%（持续 10 分钟）
- [ ] 线程池队列深度 > 100（持续 10 分钟）
- [ ] 错误预算消耗 > 80%
- [ ] 磁盘使用率 > 85%

### P2：log（定期 review）
- [ ] GC 停顿 P99 > 200ms
- [ ] 文件描述符使用率 > 70%
- [ ] 缓存命中率下降 > 20%
- [ ] 慢请求计数异常上升