REL11-BP01 监控工作负载的所有组件以检测故障
持续监控您的工作负载的运行状况，以便您和您的自动化系统立即发现任何故障或性能下降情况。监控基于商业价值的关键性能指标（KPI）。
所有恢复和修复机制必须从快速检测问题的能力入手。首先，应该检测技术故障并加以解决。不过，可用性基于您的工作负载创造商业价值的能力，因此衡量它的关键性能指标（KPI）需要成为您的检测和补救策略的一部分。
期望的结果： 独立监控工作负载的重要组成部分，以检测故障发生的时间和位置，并发出警报。
常见反模式：
-
由于未配置警报，因此在发生中断时不会进行通知。
-
虽然存在警报，但只有在达到阈值时才会发出警报，导致没有足够的响应时间。
-
收集指标的频率不够高，无法满足恢复时间目标（RTO）。
-
工作负载中只有面向客户的接口才会被主动监控。
-
只收集技术指标，不收集业务功能指标。
-
没有衡量工作负载用户体验的指标。
-
创建的监控太多。
建立此最佳实践的好处： 如果您在所有层面都设置了适当的监控，则可以通过减少检测时间来缩短恢复时间。
未建立这种最佳实践的情况下暴露的风险等级： 高
实施指导
确定将接受审查以决定是否监控的所有工作负载。确定工作负载中所有需要监控的组成部分后，就需要确定监控间隔。根据检测故障所花费的时间，监控间隔将直接影响启动恢复的速度。平均检测时间（MTTD）是从故障发生到修复操作开始之间的时间。服务清单应广泛而完整。
监控必须覆盖应用程序堆栈的所有层，包括应用、平台、基础设施和网络。
您的监控策略应考虑以下因素的影响： 灰色故障。有关灰色故障的更多详细信息，请参阅《Advanced Multi-AZ Resilience Patterns》白皮书中的 Gray failures 。
实施步骤
-
您的监控间隔取决于您必须以多快的速度恢复。您的恢复时间取决于恢复所需的时间，因此您在确定收集频率时，必须考虑此时间和恢复时间目标（RTO）。
-
为组件和托管服务配置详细监控。
-
确定 详细监控对于 EC2 实例 和 Auto Scaling 来说是否有必要。详细监控以 1 分钟为间隔提供指标，默认监控以 5 分钟为间隔提供指标。
-
确定 增强监控 对于 RDS 来说是否有必要。增强监控使用 RDS 实例上的代理，来获取关于不同进程或线程的有用信息。
-
确定以下各项的关键无服务器组件的监控要求： Lambda、 API Gateway、 Amazon EKS、 Amazon ECS
，以及所有类型的 负载均衡器。 -
确定以下各项的存储组件的监控要求： Amazon S3、 Amazon FSx、 Amazon EFS和 Amazon EBS。
-
-
创建 自定义指标 来衡量业务关键绩效指标（KPI）。工作负载会实现关键业务功能，这些功能应用作 KPI 来协助在发生间接问题时予以识别。
-
使用用户金丝雀来监控用户的故障体验。 可运行和模拟客户行为的综合事务测试 （又称为“金丝雀测试”，但不要和金丝雀部署相混淆）是最重要的测试流程之一。从不同的远程位置针对您的工作负载端点持续地运行此类测试。
-
创建 自定义指标 来跟踪用户体验。如果您可以衡量客户体验，就可以确定发生了客户体验下降。
-
设置警报 ，以在检测到工作负载的任何部分未正常运行时发出警报，并指示什么时候自动扩展资源。警报可以直观地显示在控制面板上，通过 Amazon SNS 或电子邮件发送，并与 Auto Scaling 结合使用来扩展或缩减工作负载资源。
-
创建 控制面板 以可视化形式呈现指标。可以使用控制面板直观地查看趋势、离群值和表示其他潜在问题的指标，或者提供您可能需要进行调查的问题的指示。
-
为您的服务创建 分布式跟踪监控
。使用分布式监控，您可以了解应用程序及其底层服务的运行情况，以便确定和诊断性能问题及错误的根本原因。 -
在单独的区域和账户中创建监控系统（使用 CloudWatch 或 X-Ray
）控制面板和数据收集。 -
为 Amazon Health Aware
集成监控功能，以便监控可能出现性能下降的 AWS 资源。对于关键业务工作负载，此解决方案可提供对 AWS 服务的主动实时警报的访问。
资源
相关最佳实践：
相关文档：
相关视频：
相关示例：
相关工具：
