REL11-BP06 当事件影响可用性时发出通知
在检测到突破阈值时发送通知，即使导致问题的事件已自动解决。
自动修复使您的工作负载变得可靠。不过，它也可能会掩盖需要处理的潜在问题。实施适当的监控和措施，以便检测问题的模式，包括那些被自动修复的问题，从而从根本上解决问题。
弹性系统经过精心设计，可以立即将性能下降事件传达给相应的团队。这些通知应通过一个或多个通信渠道发送。
期望的结果： 在突破阈值 [例如错误率、延迟或其他重要的关键绩效指标（KPI）] 时，系统会立即向运营团队发送警报，以便尽快解决这些问题，从而避免或最大限度地减少对用户的影响。
常见反模式：
-
发送的警报过多。
-
发送不可操作的警报。
-
将警报阈值设置得太高（过于敏感）或太低（不够敏感）。
-
不针对外部依赖项发送警报。
-
在设计监控和警报时，没有考虑 灰色故障 。
-
执行自动修复，但未通知相应的团队需要进行该修复。
建立此最佳实践的好处： 恢复通知可以让运营和业务团队了解到服务性能下降的情况，这样他们就可以立即做出反应，尽可能地缩短平均检测时间（MTTD，Mean Time To Detect）和平均修复时间（MTTR，Mean Time To Repair）。恢复事件通知还可确保您不会忽略不经常发生的问题。
未建立这种最佳实践的情况下暴露的风险等级： 中。未能实施适当的监控和事件通知机制，会导致未能检测到出现的问题模式，包括那些被自动修复的问题。只有当用户联系客户服务或者在偶然的情况下，团队才会了解到系统性能下降的情况。
实施指导
在定义监控策略时，触发的警报是常见事件。此事件可能包含警报的标识符、警报状态（例如 IN ALARM 或 OK），以及触发该警报的对象的详细信息。在许多情况下，系统应该检测到警报事件并发送电子邮件通知。这是对警报执行操作的示例。警报通知对于可观测性至关重要，因为它会告知相关人员所存在的问题。不过，当您的可观测性解决方案能够针对事件采取合理的操作时，它可以自动修复问题，而无需人工干预。
建立 KPI 监控警报后，在超过阈值时，应向相应的团队发送警报。这些警报还可用于触发自动流程，尝试修复性能下降问题。
对于更复杂的阈值监控，应考虑使用复合警报。复合警报使用多个 KPI 监控警报，根据运营业务逻辑创建警报。CloudWatch 警报可被配置为发送电子邮件，或使用 Amazon SNS 集成或 Amazon EventBridge 将事件记录到第三方事件跟踪系统。
实施步骤
根据监控工作负载的方式，创建各种类型的警报，例如：
-
使用应用程序警报，检测工作负载的任何部分未正常工作的情况。
-
基础设施警报 指明何时扩展资源。警报可以直观地显示在控制面板上，通过 Amazon SNS 或电子邮件发送，并与 Auto Scaling 结合使用来扩展或缩减工作负载资源。
-
您可以创建简单的 静态警报 ，用于监控在指定数量的评估周期内，指标突破静态阈值的情况。
-
复合警报 可以处理来自多个来源的复杂警报。
-
创建警报后，请创建相应的通知事件。您可以直接调用 Amazon SNS API 来发送通知，并关联任何自动化的修复或通信机制。
-
集成 Amazon Health Aware
监控功能，以便监控可能出现性能下降的 AWS 资源。对于关键业务工作负载，此解决方案可提供对 AWS 服务的主动实时警报的访问。
资源
相关的 Well-Architected 最佳实践：
相关文档：
相关工具：
