监控重要事项：大规模系统的告警实践
在现代分布式系统中，性能不仅仅是速度——它是在规模上平衡延迟、可用性和资源效率的问题。有效的警报对于维持这种平衡至关重要。没有它，团队可能会错过真正的故障，对假阳性反应过度，或者对缓慢的退化视而不见。本指南概述了设计重要警报的实用方法——这样您就可以捕捉到出错的，忽略那些没有问题的，并自信地扩展。
警报取决于被监控的服务类型。面向客户的服务需要与后端系统或批处理作业不同的警报。但无论哪种服务，您至少应该为以下关键领域设置警报。
可用性 Availability
可用性仅仅意味着系统可以完成其工作。对于接受请求的服务，这意味着服务正在运行并且可以处理任何传入的请求。对于后端进程，这意味着系统目前正在工作或者有任务要处理时可以启动。
延迟 Latency
延迟是指系统完成某事所需的时间。对于服务来说，这是从请求到来到响应发送出去的时间。这是请求到达服务以及响应返回的总时间。然而，我们只能从服务的角度来衡量延迟，所以像网络延迟或其他服务外部的问题不计入。
对于后端进程，延迟是指完成一个任务所需的时间——比如处理队列中的消息、完成工作流中的一个步骤或完成批量作业。
计算资源指标
计算指标跟踪诸如 CPU 使用率、内存使用率、磁盘空间等事物。这些警报有助于确保个别服务器不会造成可能隐藏在整体系统指标中的问题。有个方法论叫 USE 就是用于衡量计算资源的使用率、饱和度和错误率。它可以帮助我们更好地理解计算资源的使用情况。
调用量
它们有助于保护您的服务不会达到其限制，并让您知道是否需要扩展。这些警报应跟踪您的服务在其当前规模下可以处理的请求数量，包括服务器和任何依赖的限制。
告警严重性
严重性应反映系统的重要性以及解决问题的紧迫性。如果您创建了一个高严重性警报，那么在更敏感的级别创建一个低严重性警报也是一个好主意。这可以作为早期警报，在问题升级之前捕捉到问题。甚至，如果能够在更敏感的级别告警之后直接自动处理了，那就更好了。
对于某些服务，在客户影响非常低的情况下，只有低严重性警报可能工作得很好。
设置阈值
阈值设置取决于服务的 SLA。如果该服务影响大量客户群，则阈值可能很敏感。
可用性
延迟
- P50（第50个百分位数）是延迟的中位数，这意味着一半的请求处理得更快，一半需要更长的时间。
- P90（第90个百分位数）是90%的请求更快，10%需要更长时间的延迟。
- P99（第99个百分位数）是99%的请求更快的延迟，只有1%需要更长的时间。
- P99.9（99.9百分位数）是99.9%的请求更快的延迟，只有0.1%需要更长的时间。
阈值应根据您的SLA和应用程序过去的性能来设置。最高阈值应符合您的SLA或客户的期望。如果您的服务导致延迟，在客户注意到之前，您的系统提醒您非常重要。
要设置最大阈值，请与您的客户联系以了解他们的SLA。
对于最低阈值，请查看您的服务至少在过去45天内的性能。考虑任何最近或即将发生的更改，例如增加的流量、新的API、新的依赖项。
计算资源指标
应根据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
