REL06-BP01 为工作负载监控全部组件（生成）
使用 Amazon CloudWatch 或第三方工具监控工作负载组件。使用 AWS Health 控制面板监控 AWS 服务。
应监控工作负载的全部组件，包括前端、业务逻辑和存储层。定义关键指标，描述如何将其从日志中提取出来（如有必要），并为对应的警报事件设置阈值。确保指标与工作负载的关键性能指标（KPI）相关，并使用指标和日志来识别服务性能下降的早期预警信号。例如，与业务成果相关的指标（例如每分钟成功处理的订单数）可以比技术指标（例如 CPU 利用率）更快地表明工作负载问题。使用 AWS Health 控制面板可提供 AWS 资源底层的 AWS 服务性能和可用性的个性化视图。
云中监控创造新的机会。大多数云提供商都开发了可自定义的挂钩，可以提供见解来帮助您监控多层工作负载。Amazon CloudWatch 等 AWS 服务应用统计和机器学习算法来持续分析系统和应用程序的指标，只需最少的用户干预即可确定正常基线和表面异常。异常检测算法将指标的季节性变化和趋势变化考虑在内。
AWS 提供了大量的监控和日志信息，这些信息可用于定义工作负载特定的指标、需求变化流程，也助于采用机器学习技术，无论是否具备机器学习专业知识如何。
此外，还可监控所有外部端点，确保这些端点独立于基本实施。这种主动监控可通过综合事务实现（有时被称为用户金丝雀，但与金丝雀部署不同），这些事务会按照工作负载的客户端所执行的操作，定期执行许多常见任务。确保这些任务的持续时间较短，不要让工作负载在测试期间过载。Amazon CloudWatch Synthetics 让您可以创建 Synthetics 金丝雀，以便对端点和 API 进行监控。您还可以整合 Synthetics 金丝雀客户端节点和 AWS X-Ray 控制台，精确定位哪些 Synthetics 金丝雀遇到错误、故障，或对指定时段的速率进行限制的问题。
期望结果：
收集并使用来自工作负载所有组件的关键指标，确保工作负载的可靠性和最佳的用户体验。若能检测到工作负载无法实现业务成果，可快速宣布发生灾难并从事件中恢复。
常见反模式：
-
仅监控连接到工作负载的外部接口。
-
不生成任何工作负载特定的指标，只依靠工作负载使用的 AWS 服务所提供的指标。
-
仅使用工作负载中的技术指标，而不监控与工作负载带来的非技术性 KPI 相关的任何指标。
-
依靠生产流量和简单的运行状况检查来监控并评估工作负载状态。
建立此最佳实践的好处：在工作负载的各个层级进行监控，便于更快地预测并解决构成工作负载的组件中的问题。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
-
启用日志记录（如适用）。应从工作负载的所有组件获取监控数据。启用其他日志记录（例如 S3 访问日志），让工作负载记录工作负载特定的数据。收集来自 Amazon ECS、Amazon EKS、Amazon EC2、弹性负载均衡、AWS Auto Scaling 和 Amazon EMR 等服务的 CPU、网络 I/O 和磁盘 I/O 平均值的指标。有关向 CloudWatch 发布指标的 AWS 服务列表，请参阅发布 CloudWatch 指标的 AWS 服务。
-
审查所有默认指标并探究任何数据收集欠缺。每项服务都会生成默认指标。通过收集默认指标，您可以更好地了解工作负载组件之间的依赖关系，以及组件的可靠性和性能对工作负载的影响。您可使用 AWS CLI 或 API 向 CloudWatch 发布自定义指标。
-
评估所有指标，决定要针对工作负载中每项 AWS 服务的哪些指标发出警报。您可以选择对工作负载可靠性有重大影响的指标子集。关注关键指标和阈值有助于细化警报数量，也助于尽量减少误报。
-
定义警报以及在调用警报之后工作负载的恢复流程。通过定义警报，您可以快速通知、上报和执行必要的步骤，以便从事件中恢复并达到规定的恢复时间目标（RTO）。您可以使用 Amazon CloudWatch 警报调用自动工作流，并根据定义的阈值启动恢复程序。
-
探索使用综合事务来收集有关工作负载状态的相关数据。综合监控遵循相同的路线并执行与客户相同的操作，让您能够持续验证客户体验，即使应用程序中没有任何客户流量。使用综合事务，您可以早于客户先行发现问题。
资源
相关最佳实践：
相关文档：
相关博客：
相关示例和讲习会：
