REL11-BP01 监控工作负载的所有组件以检测故障 - AWS Well-Architected Framework

REL11-BP01 监控工作负载的所有组件以检测故障

持续监控您的工作负载的运行状况,以便您和您的自动化系统立即发现任何故障或性能下降情况。监控基于商业价值的关键性能指标(KPI)。

所有恢复和修复机制必须从快速检测问题的能力入手。首先,应该检测技术故障并加以解决。不过,可用性基于您的工作负载创造商业价值的能力,因此衡量它的关键性能指标(KPI)需要成为您的检测和补救策略的一部分。

期望的结果: 独立监控工作负载的重要组成部分,以检测故障发生的时间和位置,并发出警报。

常见反模式:

  • 由于未配置警报,因此在发生中断时不会进行通知。

  • 虽然存在警报,但只有在达到阈值时才会发出警报,导致没有足够的响应时间。

  • 收集指标的频率不够高,无法满足恢复时间目标(RTO)。

  • 工作负载中只有面向客户的接口才会被主动监控。

  • 只收集技术指标,不收集业务功能指标。

  • 没有衡量工作负载用户体验的指标。

  • 创建的监控太多。

建立此最佳实践的好处: 如果您在所有层面都设置了适当的监控,则可以通过减少检测时间来缩短恢复时间。

未建立这种最佳实践的情况下暴露的风险等级:

实施指导

确定将接受审查以决定是否监控的所有工作负载。确定工作负载中所有需要监控的组成部分后,就需要确定监控间隔。根据检测故障所花费的时间,监控间隔将直接影响启动恢复的速度。平均检测时间(MTTD)是从故障发生到修复操作开始之间的时间。服务清单应广泛而完整。

监控必须覆盖应用程序堆栈的所有层,包括应用、平台、基础设施和网络。

您的监控策略应考虑以下因素的影响: 灰色故障。有关灰色故障的更多详细信息,请参阅《Advanced Multi-AZ Resilience Patterns》白皮书中的 Gray failures

实施步骤

  • 您的监控间隔取决于您必须以多快的速度恢复。您的恢复时间取决于恢复所需的时间,因此您在确定收集频率时,必须考虑此时间和恢复时间目标(RTO)。

  • 为组件和托管服务配置详细监控。

  • 创建 自定义指标 来衡量业务关键绩效指标(KPI)。工作负载会实现关键业务功能,这些功能应用作 KPI 来协助在发生间接问题时予以识别。

  • 使用用户金丝雀来监控用户的故障体验。 可运行和模拟客户行为的综合事务测试 (又称为“金丝雀测试”,但不要和金丝雀部署相混淆)是最重要的测试流程之一。从不同的远程位置针对您的工作负载端点持续地运行此类测试。

  • 创建 自定义指标 来跟踪用户体验。如果您可以衡量客户体验,就可以确定发生了客户体验下降。

  • 设置警报 ,以在检测到工作负载的任何部分未正常运行时发出警报,并指示什么时候自动扩展资源。警报可以直观地显示在控制面板上,通过 Amazon SNS 或电子邮件发送,并与 Auto Scaling 结合使用来扩展或缩减工作负载资源。

  • 创建 控制面板 以可视化形式呈现指标。可以使用控制面板直观地查看趋势、离群值和表示其他潜在问题的指标,或者提供您可能需要进行调查的问题的指示。

  • 为您的服务创建 分布式跟踪监控 。使用分布式监控,您可以了解应用程序及其底层服务的运行情况,以便确定和诊断性能问题及错误的根本原因。

  • 在单独的区域和账户中创建监控系统(使用 CloudWatchX-Ray)控制面板和数据收集。

  • Amazon Health Aware 集成监控功能,以便监控可能出现性能下降的 AWS 资源。对于关键业务工作负载,此解决方案可提供对 AWS 服务的主动实时警报的访问。

资源

相关最佳实践:

相关文档:

相关视频:

相关示例:

相关工具: