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