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