monitoring-and-alerting

监控与告警

确定要监控什么、针对什么发出告警，以及发生故障时如何确保通知到合适的人。

---

适用场景

• 为新网站或服务设置监控
• 定义 SLO（服务级别目标）和错误预算
• 确定哪些告警需要呼叫人员，哪些只需发送到低干扰频道
• 设计或调整值班轮班
• 排查告警疲劳
• 补齐事故中发现的监控盲区
• 迁移监控供应商

不适用场景

• 响应正在发生的事故（使用 incident-response）
• 撰写事后分析报告（使用 after-action-report）
• 为产品指标设计分析仪表板（使用 analytics-strategy）
• 性能优化本身（使用 performance-optimization）

---

所需输入

• 要监控的系统（URL、服务、依赖项）
• 现有监控工具（可用性、错误、日志、APM）
• 工作时间和团队所在时区
• 值班人员或可处理事故的人员
• 现有 SLO 或成功指标（如有）

---

框架：4 个层次

监控分层进行。跳过任何一层，都会漏掉一类问题。

第 1 层：可用性

网站是否正常运行？这是最简单、也最重要的一层。

• 从多个区域进行 HTTP 检查（每 1～5 分钟一次）
• DNS 解析检查
• 证书过期检查
• 状态码检查（针对 5xx 告警，而不只是超时）

阈值：任何持续性宕机（连续失败超过 2 次检查）都应呼叫人员。

第 2 层：正确性

网站正在运行，但提供的内容是否正确？

• 合成检查（脚本加载主页、点击按钮并验证预期文本）
• 关键用户旅程（注册、结账、搜索）
• 内容存在性检查（确保主页没有变成空白）
• API 契约检查（确保响应结构和关键字段都存在）

阈值：关键路径合成检查失败时应呼叫人员。非关键页面级合成检查仅在工作时间告警。

第 3 层：性能

网站运行正常、内容正确，但速度够快吗？

• 从真实用户获取 Core Web Vitals（LCP、INP、CLS）（RUM）
• 合成性能测试（Lighthouse、WebPageTest、自定义工具）
• API 响应时间（p50、p95、p99）
• 慢查询的数据库查询耗时
• 依赖项响应时间（第三方 API）

阈值：相较基线出现退化时告警（例如，p95 在 5 分钟内翻倍）。没有基线时，不要针对绝对阈值告警。

第 4 层：错误与异常

网站对大多数用户来说运行正常、内容正确、速度也够快，但仍有错误发生。

• 错误率（返回 5xx 的请求占比）
• 客户端错误率（未捕获的 JS 异常）
• 日志错误量（意外激增）
• 异常检测（流量骤降）
• 后台作业失败
• 队列深度

阈值：基于比率，而不是计数。“错误率连续 5 分钟高于 1%”优于“每分钟超过 100 个错误”。

---

SLO 和错误预算

服务级别目标（SLO）是可靠性的目标值。常见表述：“在 30 天的统计周期内，99.9% 的主页请求能在 2 秒内成功完成。”

组成部分：

• 衡量对象（主页请求）
• 成功标准（在 2 秒内返回 2xx）
• 目标值（其中 99.9%）
• 统计周期（30 天）

错误预算是其反向值：0.1% 的请求可以失败。如果预算已全部用完，就应放缓高风险变更。

选择 SLO

不要以 100% 为目标。除非确有需要，也不要追求“五个 9”（99.999%）。每增加一个 9，成本就会增加一个数量级。

SLO	每月允许的停机时间
99%	7 小时 18 分钟
99.9%	43 分钟
99.95%	21 分钟
99.99%	4 分 22 秒
99.999%	26 秒

对大多数营销网站来说，99.9% 已经足够。对 SaaS 来说，99.95% 是合理的。更高的目标则需要大幅增加基础设施投入。

使用错误预算

当预算状况良好时，积极发布。当预算消耗一半时，放缓节奏。当预算耗尽时，冻结高风险变更，直到可靠性恢复。

这正是 SLO 发挥作用的原因：它们在可靠性与交付速度之间建立了反馈循环。

---

工作流

步骤 1：盘点现有监控

目前部署了哪些工具？有哪些检查？有哪些仪表板？有哪些告警？

许多团队都有一堆配置不完整、错综复杂的工具。第一项工作就是盘点。

步骤 2：梳理系统

绘制架构图。前端、后端、数据库、第三方 API、队列、工作进程。每个方框都是监控的候选对象。

对于每个方框，问问：

• 什么情况算“正常运行”？
• 什么情况算“正确”？
• 什么情况算“快速”？
• 最常见的故障模式是什么？

步骤 3：定义 SLO

选择 3-5 个 SLO。它们应该：

• 与用户可见的行为相关（而非内部指标）
• 以当前基础设施能够实现为准
• 自动测量
• 至少每季度审查一次

步骤 4：在 4 个层面设置检查

为每个方框配置各层面的检查。有些方框不适用全部四层；这没问题。

方框	可用性	正确性	性能	错误
首页	HTTP 检查	合成监控	LCP/INP	JS 错误
登录 API	HTTP 检查	合成流程	p95 延迟	5xx 比率

步骤 5：决定哪些情况需要通知，哪些不需要

分为三个级别：

1. 页面（唤醒值班人员）： 网站宕机、关键流程中断、错误率激增、安全事件。
2. 通知（工作时间内）： 非关键合成监控失败、性能退化、查询缓慢、依赖项性能下降。
3. 记录（不通知）： 留待之后审查的异常、低优先级警告、信息级事件。

第 1 级的任何告警都必须：

• 可采取行动（值班人员能够采取措施）
• 重要（代表实际影响）
• 少见（目标是每周少于 1-2 次）

如果第 1 级告警频繁触发，就会产生告警疲劳。人们会停止响应。

步骤 6：配置路由

告警发送到哪里？

• 第 1 级：寻呼系统（例如 PagerDuty）。不要迁移到 Opsgenie：Atlassian 已于 2025 年 6 月停止销售，并将于 2027 年 4 月终止支持。直接通知值班人员。
• 第 2 级：聊天频道（Slack、Teams）。标记对应的领域。
• 第 3 级：仅显示在仪表板上或写入日志。

每个级别都应有文档记录的升级处理路径。如果值班人员在 5-15 分钟内未确认，则升级处理。

步骤 7：构建仪表板

为不同受众各建一个仪表板：

• 实时运维仪表板： 当前健康状况、近期告警、错误率、吞吐量
• SLO 仪表板： SLO 状态和错误预算消耗情况
• 各服务仪表板： 单个服务或页面的详细信息
• 高管仪表板： 数周/数月的正常运行时间、关键业务指标

仪表板与告警不同。告警是在说“现在就看”。仪表板是在说“当前情况如下”。

步骤 8：审计告警

每季度审计：

• 哪些告警触发了？是否可采取行动？
• 哪些告警本该触发却没有触发？
• 是否有告警过于频繁（每周超过一次，且可采取行动的程度较低）？
• 运维手册是否为最新版本？
• 是否达到 SLO？是否有任何 SLO 持续未达标？

调整系统。缺乏主动维护时，监控会逐渐偏离预期。

故障模式

针对原因告警，而非症状。“CPU 使用率高”是原因。“用户感觉慢”是症状。针对症状告警；调查原因。

**告警没有配套操作手册。**如果值班人员不知道该怎么做，这个告警就毫无用处。每个需要触发呼叫的告警都必须有操作手册（哪怕只有一行）。

**没有“正常”基线。**针对“每分钟错误超过 100 次”设置告警听起来合理，但繁忙时段可能会超过这个值，而系统并无异常。使用基于速率和异常检测的告警。

**仅在单个区域进行监控。**如果监控服务与你的网站位于同一区域，你就会漏掉区域性故障；而且监控服务本身出问题时，你也会被叫醒。

**监控监控系统。**更准确地说，是没有监控。如果你的告警平台宕机了，谁会告诉你？大多数呼叫服务都提供自己的状态订阅源。订阅它。

**严重级别划分过多。**P0/P1/P2/P3/P4 分别对应不同的 SLA，会变成排序工作。三个级别（呼叫、通知、记录）就足够了。

**合成监控与实际情况不符。**每分钟访问一次主页的合成监控，只能测试“主页是否正常”。它无法测试“实际用户流程是否正常”。为重要的用户旅程构建合成监控。

**从不调整的静态阈值。**流量会增长，行为会改变，去年设置的阈值可能已经不合适。每季度审查阈值。

**值班轮换没有交接。**每位新值班人员都得自己摸索系统。做好文档记录。每周举行交接会议或异步更新。

**告警疲劳。**如果值班人员每周被呼叫超过一两次，就说明出了问题。审查告警，减少告警、调整告警或修复底层问题。

---

输出格式

监控计划包括：

• **系统图：**监控哪些内容
• **SLO：**3-5 个可靠性目标
• **各层检查项：**可用性、正确性、性能、错误
• **告警分级：**哪些触发呼叫，哪些发送通知，哪些仅记录
• **路由：**告警发送到哪里，升级路径是什么
• **仪表板：**不同受众能看到哪些内容
• **操作手册：**从每个需要触发呼叫的告警链接到相应手册
• **审查周期：**何时进行审查

---

所需数据不可用时

此技能的输出依赖于其无法独立生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时，获准的输出是交付成果，并说明存在的缺口：需要什么、实际获取或验证了什么，以及输出中的哪些部分受到影响。绝不允许为了完成交付成果而捏造、估算或插值所需数字。说明存在缺口本身就是完整的答复。

---

参考文件

• references/slo-design-guide.md：详细介绍如何为 Web 服务编写 SLO、制定错误预算策略，以及常见的 SLO 错误。