在现代分布式系统中，性能不仅仅是速度——它是在规模上平衡延迟、可用性和资源效率的问题。有效的警报对于维持这种平衡至关重要。没有它，团队可能会错过真正的故障，对假阳性反应过度，或者对缓慢的退化视而不见。本指南概述了设计重要警报的实用方法——这样您就可以捕捉到出错的，忽略那些没有问题的，并自信地扩展。
警报取决于被监控的服务类型。面向客户的服务需要与后端系统或批处理作业不同的警报。但无论哪种服务，您至少应该为以下关键领域设置警报。
核心要点
- 重要告警应围绕真实服务风险设计，而不是围绕每一个可观测指标设计。
- 面向客户的服务、后端系统和批处理作业需要不同的告警方式，但都应覆盖可用性、延迟、资源和调用量。
- 严重性应反映业务影响和处理紧迫性；高严重性告警最好配套更敏感的低严重性预警。
- 阈值应结合 SLA、历史性能和即将发生的变更设置，不能只凭经验拍脑袋。
- 通知渠道是告警策略的一部分，必须确保正确的人能在正确时间收到正确级别的通知。
| 告警领域 | 主要回答的问题 | 常见指标或信号 |
|---|---|---|
| 可用性 | 服务能否完成它该完成的工作 | 服务存活、请求处理、任务执行状态 |
| 延迟 | 服务完成工作需要多久 | 请求耗时、队列处理时间、批处理耗时 |
| 计算资源 | 单个服务器或资源是否接近瓶颈 | CPU、内存、磁盘空间、USE 指标 |
| 调用量 | 当前规模能否承受请求压力 | 请求数、队列量、依赖调用限制 |
可用性 Availability
可用性仅仅意味着系统可以完成其工作。对于接受请求的服务，这意味着服务正在运行并且可以处理任何传入的请求。对于后端进程，这意味着系统目前正在工作或者有任务要处理时可以启动。
可用性告警最适合表达“系统还能不能提供基本功能”。如果服务对用户开放，可用性通常应优先于内部资源异常进入高严重等级告警。
延迟 Latency
延迟是指系统完成某事所需的时间。对于服务来说，这是从请求到来到响应发送出去的时间。这是请求到达服务以及响应返回的总时间。然而，我们只能从服务的角度来衡量延迟，所以像网络延迟或其他服务外部的问题不计入。
对于后端进程，延迟是指完成一个任务所需的时间——比如处理队列中的消息、完成工作流中的一个步骤或完成批量作业。
延迟告警要注意观察口径。平均延迟可能掩盖长尾问题，因此 P90、P99、P99.9 这类百分位数通常更适合描述用户体验中的慢请求。
计算资源指标
计算指标跟踪诸如 CPU 使用率、内存使用率、磁盘空间等事物。这些警报有助于确保个别服务器不会造成可能隐藏在整体系统指标中的问题。有个方法论叫 USE 就是用于衡量计算资源的使用率、饱和度和错误率。它可以帮助我们更好地理解计算资源的使用情况。
资源告警不一定都应该打断值班人。CPU 短时升高、队列短时堆积、单机资源波动，很多时候更适合做低严重性记录或异步通知；但磁盘空间耗尽这类难以自愈的问题，应更早触发预警。
调用量
它们有助于保护您的服务不会达到其限制，并让您知道是否需要扩展。这些警报应跟踪您的服务在其当前规模下可以处理的请求数量，包括服务器和任何依赖的限制。
告警严重性
严重性应反映系统的重要性以及解决问题的紧迫性。如果您创建了一个高严重性警报，那么在更敏感的级别创建一个低严重性警报也是一个好主意。这可以作为早期警报，在问题升级之前捕捉到问题。甚至，如果能够在更敏感的级别告警之后直接自动处理了，那就更好了。
对于某些服务，在客户影响非常低的情况下，只有低严重性警报可能工作得很好。
严重性设置可以参考下面的思路：
| 严重性 | 判断依据 | 推荐处理 |
|---|---|---|
| 低 | 可能发展成问题，但当前客户影响很低 | 记录、异步通知、自动处理 |
| 中 | 需要处理，但不一定立即打断值班人 | 通知服务负责人或创建工单 |
| 高 | 客户影响明显，或核心 SLA 已经受到威胁 | 进入 OnCall 升级流程 |
设置阈值
阈值设置取决于服务的 SLA。如果该服务影响大量客户群，则阈值可能很敏感。
可用性
延迟
- P50（第50个百分位数）是延迟的中位数，这意味着一半的请求处理得更快，一半需要更长的时间。
- P90（第90个百分位数）是90%的请求更快，10%需要更长时间的延迟。
- P99（第99个百分位数）是99%的请求更快的延迟，只有1%需要更长的时间。
- P99.9（99.9百分位数）是99.9%的请求更快的延迟，只有0.1%需要更长的时间。
阈值应根据您的SLA和应用程序过去的性能来设置。最高阈值应符合您的SLA或客户的期望。如果您的服务导致延迟，在客户注意到之前，您的系统提醒您非常重要。
要设置最大阈值，请与您的客户联系以了解他们的SLA。
对于最低阈值，请查看您的服务至少在过去45天内的性能。考虑任何最近或即将发生的更改，例如增加的流量、新的API、新的依赖项。
因此，阈值设置不是一次性动作。只要服务容量、流量模式、依赖关系或 SLA 发生变化，告警阈值就应该重新检查。
计算资源指标
应根据CPU使用率设置计算指标，例如CPU使用率高于80%时发出警报。内存使用率、磁盘空间等类似
调用量
调用量阈值应设置在服务开始中断或失败的点下方。
通知渠道
为了提醒待命通知警报立即采取行动，可以有各种通知通道与警报框架集成。
PagerDuty 在国内用的较多，国内用的较多的 OnCall 产品是 Flashduty。
总结
好的警报可以帮助团队及早发现问题，并在问题影响用户之前解决它们。为可用性、延迟、计算使用和呼叫量等关键领域设置警报非常重要。每个服务都不同，因此警报应该与服务类型及其重要性相匹配。
设置正确的严重性和阈值有助于减少噪音并将注意力集中在实际问题上。使用正确的通知渠道可确保正确的人及时收到警报。通过清晰的警报和智能设置，团队可以保持系统健康可靠。
一句话总结：重要告警不是“监控所有指标”，而是围绕服务能否正常完成工作、用户是否受到影响、资源是否即将成为瓶颈来设计告警。
参考
- Datadoghq Blogs. (2015). Monitoring 101: Alerting on what matters
- Microsoft Blogs. (2014). Recommendations for designing a reliable monitoring and alerting strategy
- Medium. (2024). Managing Critical Alerts through PagerDuty’s Event Rules
关于作者
我是Uber的高级软件工程师，在可扩展、高性能分布式系统方面拥有十多年的经验。我从事过云原生架构、数据库优化和构建大规模分布式系统的工作。欢迎通过 LinkedIn 联系我。
原文：https://dev.to/gaurav_bansal_2e1ca573623/alert-strategy-best-practices-1b79
