监控与告警

这一课你将能做到

1. 区分 基础设施告警、Symptom（症状）告警 与 Cause（原因）告警，并解释为什么判题接口的 5xx 告警比单机 CPU 告警更适合叫值班
2. 为 POST /api/judge/submissions 设计一条可执行的 Symptom 告警，含 PromQL 条件、持续时间、严重级别、runbook 链接
3. 识别告警风暴的三种来源，给出治理动作，能解释「告警噪音 = 没有告警」

为什么要学

可观测性解决「有没有信号」；监控与告警 解决「什么时候该把人从床上叫起来」。信号再全，规则设计不好——瞬时抖动就叫、告警没有上下文、半夜几十条 Page 轰炸——团队会习惯性关闭通知，等于没有监控。

判题场景尤其敏感：比赛窗口高峰期，接口挂五分钟和单机 CPU 抖动五分钟对用户的含义完全不同。面试里「symptom 和 cause 的区别」「告警风暴怎么治」是高频题，本课结合 PromQL 和排障流程给答案。

先建立图像

类型	示例（判题系统）	响应方式
Symptom	POST /api/judge/submissions 5xx 率 > 1% 持续 5 分钟	Page（立即叫醒）
Cause	判题 worker 消费延迟增大、MySQL 连接池接近上限	Ticket（工作时间处理）
Capacity	磁盘剩余 < 15%、Kafka topic 分区扩容预警	Ticket/计划处理

好的告警链路：

  SLI 越界（症状）──► Page on-call
       │
       ├─ Grafana 面板：确认影响面、时间线、最近发布
       ├─ Runbook 第一步：优先判断是否已自动降级
       └─ 日志/Trace：定位具体 submission 与代码路径

差的告警链路：

  单机 CPU 突升到 85% ──► 半夜 Page ──► 判题接口正常 ──► 告警被静音
       │
       └── 没有上下文、没有持续时间、没有恢复步骤

与 reliability-essentials 联动：告警文案应提示「是否已触发降级或熔断」。

跟着做

步骤 1：为判题接口写一条 Symptom 告警

先写意图，再给可运行的 PromQL：

# alert: JudgeSubmissionHighErrorRate
# 判题接口 5xx 率超过 1% 持续 5 分钟，这是用户可见的症状，直接 page
expr: |
  (
    sum(rate(http_server_requests_seconds_count{
      uri="/api/judge/submissions",
      status=~"5.."
    }[5m]))
    /
    sum(rate(http_server_requests_seconds_count{
      uri="/api/judge/submissions"
    }[5m]))
  ) > 0.01
for: 5m
labels:
  severity: page
annotations:
  summary: "判题提交接口 5xx 率过高"
  runbook: "https://wiki.internal/runbooks/judge-5xx"
  impact: "用户提交后无法得到结果或结果错误"
  first_check: "Grafana: http_server_requests RED 面板"

应得到：有 for（持续时间）、有 severity、有 runbook 链接、有 impact 说明——不是「expr 满足就 Ding 一声」。

步骤 2：把两条 Cause 告警降级为 ticket

1. 单机 CPU 持续 > 70%（非关键节点）
   → 原因：资源使用增加，用户可能完全无感知
   → 响应：工作时间 ticket，关注趋势而非瞬间

2. Kafka consumer lag 轻微增加但未超阈值
   → 原因：可能正在消费积压，用户仍能看到提交进入排队
   → 响应：ticket，先观察是否需要扩容 worker