187 lines
6.4 KiB
Markdown
187 lines
6.4 KiB
Markdown
|
---
|
|||
|
|
tags: [microservice, alerting, slo, error-budget, on-call]
|
|||
|
|
create time: 2026-05-05
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 告警管理
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
收集了这么多 Metrics、Logs 和 Traces，下一步是**用数据驱动决策**。告警系统是在问题影响用户之前及时响应的最后一道防线。
|
|||
|
|
|
|||
|
|
> [!warning] 核心挑战：告警疲劳
|
|||
|
|
>
|
|||
|
|
> 如果一个团队每天收到 200 条告警，其中 195 条是误报或无需处理，工程师会对剩下的 5 条真正重要的告警产生"脱敏"。这就是 **告警疲劳 (Alert Fatigue)**。
|
|||
|
|
|
|||
|
|
## SLO / Error Budget 告警
|
|||
|
|
|
|||
|
|
### SLI / SLO / SLA 三层模型
|
|||
|
|
|
|||
|
|
| 层级 | 全称 | 含义 | 示例 |
|
|||
|
|
|------|------|------|------|
|
|||
|
|
| **SLI** | Service Level Indicator | 实际测量的指标 | P99 延迟 = 120ms |
|
|||
|
|
| **SLO** | Service Level Objective | 内部目标值 | P99 延迟 < 200ms（99.9%） |
|
|||
|
|
| **SLA** | Service Level Agreement | 对外契约承诺 | 可用性 ≥ 99.95%，否则赔偿 |
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
Real["真实用户请求"] --> SLI{成功率达标?}
|
|||
|
|
SLI -- 是 --> SLO_OK["✅ SLO 达成"]
|
|||
|
|
SLI -- 否 --> BUDGET["消耗错误预算"]
|
|||
|
|
|
|||
|
|
BUDGET --> Left{"预算 > 0?"}
|
|||
|
|
Left -- 是 --> Continue["继续发布新功能 🚀"]
|
|||
|
|
Left -- 否 --> Freeze["冻结发布 ❄️<br/>专注稳定性修复"]
|
|||
|
|
|
|||
|
|
style SLO_OK fill:#e8f5e9
|
|||
|
|
style Freeze fill:#ffebee
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 错误预算计算
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
每月允许停机时间 = 月总分钟数 × (1 - SLO)
|
|||
|
|
|
|||
|
|
SLO = 99.9% → 30×24×60×0.1% = 43.2 分钟
|
|||
|
|
SLO = 99.95% → 30×24×60×0.05% = 21.6 分钟
|
|||
|
|
SLO = 99.99% → 30×24×60×0.01% = 4.3 分钟
|
|||
|
|
SLO = 99% → 30×24×60×1% = 432 分钟 ≈ 7.2 小时（几乎无意义）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 基于错误预算的告警策略
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart TD
|
|||
|
|
BudgetLeft{"错误预算剩余"}
|
|||
|
|
|
|||
|
|
BudgetLeft -- "> 50%" --> Aggressive["激进策略:<br/>保持常规告警阈值<br/>加快迭代节奏"]
|
|||
|
|
BudgetLeft -- "10~50%" --> Moderate["保守策略:<br/>降低告警阈值<br/>收紧发布频率"]
|
|||
|
|
BudgetLeft -- "< 10%" --> Emergency["紧急策略:<br/>所有非紧急告警暂停<br/>全员关注稳定性"]
|
|||
|
|
|
|||
|
|
style Aggressive fill:#e8f5e9
|
|||
|
|
style Moderate fill:#fff3e0
|
|||
|
|
style Emergency fill:#ffebee
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 告警设计原则
|
|||
|
|
|
|||
|
|
### 1. 告警必须 Actionable
|
|||
|
|
|
|||
|
|
收到告警后知道该做什么，否则不要告。
|
|||
|
|
|
|||
|
|
每条告警规则都应该能回答以下问题：
|
|||
|
|
|
|||
|
|
| # | 问题 | 示例答案 |
|
|||
|
|
|---|------|---------|
|
|||
|
|
| 1 | **什么问题？** | `支付服务 P99 延迟 > 2s 持续 5 分钟` |
|
|||
|
|
| 2 | **谁负责？** | `支付组 On-Call: @zhangsan` |
|
|||
|
|
| 3 | **怎么修复？** | 链接到 Runbook `📖 Runbook: 支付超时排查指南` |
|
|||
|
|
| 4 | **多久升级？** | `P1 无人响应 → 5min 后升级至组长` |
|
|||
|
|
|
|||
|
|
### 2. 分级设计
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart TD
|
|||
|
|
subgraph L1["P0 — 立即响应（电话 + IM）"]
|
|||
|
|
A1["HTTP 5xx 错误率 > 1% 持续 2min"]
|
|||
|
|
A2["核心接口 P99 > 2s 持续 5min"]
|
|||
|
|
A3["数据库连接池耗尽"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph L2["P1 — 当天处理（IM 通知）"]
|
|||
|
|
B1["单个服务错误率 > 5%"]
|
|||
|
|
B2["下游依赖超时率升高"]
|
|||
|
|
B3["磁盘使用 > 75%"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph L3["P2 — 本周修复（日报汇总）"]
|
|||
|
|
C1["CPU 使用率 > 80% 持续 1h"]
|
|||
|
|
C2["内存使用 > 85% 持续 1h"]
|
|||
|
|
C3["非核心服务 P99 异常"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
L1 --> ONCALL[On-Call 值班群]
|
|||
|
|
L2 --> OPS[运维监控群]
|
|||
|
|
L3 --> DAILY["每日健康报告"]
|
|||
|
|
|
|||
|
|
style L1 fill:#ffebee
|
|||
|
|
style L2 fill:#fff3e0
|
|||
|
|
style L3 fill:#e3f2fd
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3. 降噪与抑制
|
|||
|
|
|
|||
|
|
同一个根因可能触发连锁告警，需要抑制机制：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
┌──────────┐ ┌──────────┐ ┌──────────┐
|
|||
|
|
│ DB 宕机 │───→│ 服务 A 报错│───→│ 关联告警 │
|
|||
|
|
└──────────┘ └──────────┘ │ 只发 Root Cause│
|
|||
|
|
│ 其他静默 │
|
|||
|
|
└──────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
| 技术 | 说明 |
|
|||
|
|
|------|------|
|
|||
|
|
| **告警分组** | 同一根因的多个告警合并为一条 |
|
|||
|
|
| **静默期** | Pod 重启后 5 分钟内不重复告警 |
|
|||
|
|
| **维护窗口** | 已知变更期间暂时抑制非关键告警 |
|
|||
|
|
| **继承抑制** | DB 挂了 → 自动抑制依赖 DB 的所有服务的告警 |
|
|||
|
|
|
|||
|
|
## On-Call 最佳实践
|
|||
|
|
|
|||
|
|
### Runbook：告警处置手册
|
|||
|
|
|
|||
|
|
> [!summary] Runbook 模板
|
|||
|
|
>
|
|||
|
|
> | 字段 | 内容 |
|
|||
|
|
> |------|------|
|
|||
|
|
> | **标题** | `支付服务 P99 延迟 > 2s 持续 5 分钟` |
|
|||
|
|
> | **影响范围** | 下单接口超时，用户体验受损 |
|
|||
|
|
> | **检查步骤** | ① 看 Grafana 延迟面板确认峰值时间点 → ② 查同期部署记录 → ③ 检查下游 DB 慢查询 |
|
|||
|
|
> | **常见原因** | ① 新代码性能 regression → ② DB 连接池耗尽 → ③ 下游超时风暴 |
|
|||
|
|
> | **快速恢复** | ① 回滚最近一次发布 → ② 扩容实例 → ③ 开启熔断降负载 |
|
|||
|
|
> | **彻底解决** | 排查根本原因，补充回归测试，完善容量规划 |
|
|||
|
|
|
|||
|
|
### Blameless Postmortem
|
|||
|
|
|
|||
|
|
事故复盘不问"谁干的"，问"流程哪里可以改进"：
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
Incident["事故发生"] --> Contain["控制影响面"]
|
|||
|
|
Contain --> Investigate["调查根因"]
|
|||
|
|
Investigate --> Action["制定改进行动"]
|
|||
|
|
Action --> Share["分享经验教训"]
|
|||
|
|
|
|||
|
|
style Incident fill:#ffebee
|
|||
|
|
style Contain fill:#fff3e0
|
|||
|
|
style Investigate fill:#e3f2fd
|
|||
|
|
style Action fill:#e8f5e9
|
|||
|
|
style Share fill:#f3e5f5
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!tip] 事后复盘三问
|
|||
|
|
>
|
|||
|
|
> 1. **什么导致了这次事故？** （技术根因）
|
|||
|
|
> 2. **为什么监控系统没有更早发现？** （检测延迟）
|
|||
|
|
> 3. **下次如何避免同类问题？** （流程改进）
|
|||
|
|
|
|||
|
|
## 告警疲劳自检清单
|
|||
|
|
|
|||
|
|
如果你的团队出现以下情况，说明告警体系需要重构：
|
|||
|
|
|
|||
|
|
- [ ] On-Call 工程师下班前都要关闭/忽略一堆告警
|
|||
|
|
- [ ] 有人会在群里说 "这个告警不用管"
|
|||
|
|
- [ ] 同一个服务每天都触发相同的告警
|
|||
|
|
- [ ] 新同事不知道哪些告警是真的严重
|
|||
|
|
- [ ] PagerDuty/Oncall 通知已读率低于 50%
|
|||
|
|
|
|||
|
|
如果以上超过 2 项 ✅ —— 你的告警需要认真治理了。
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
|
|||
|
|
- [[04-可观测性/01-Metrics监控]] — Metrics 是告警的数据来源
|
|||
|
|
- [[05-部署运维/04-SRE实践]] — SLO/Error Budget 的详细方法论
|
|||
|
|
- [[02-服务治理/06-容错模式]] — 熔断器状态可以作为告警信号
|