# REL 6. 如何监控工作负载资源？
日志和指标是深入了解工作负载运行状况的强大工具。您可以将工作负载配置为监控日志和指标，并在超过阈值或发生重大事件时发送通知。通过监控，您的工作负载可以发现超出低性能阈值和发生故障的情形，从而自动恢复以做出响应。
**Topics**
+ [
# REL06-BP01 为工作负载监控全部组件（生成）
](rel_monitor_aws_resources_monitor_resources.md)
+ [
# REL06-BP02 定义与计算指标（聚合）
](rel_monitor_aws_resources_notification_aggregation.md)
+ [
# REL06-BP03 发送通知（实时处理和报警）
](rel_monitor_aws_resources_notification_monitor.md)
+ [
# REL06-BP04 自动响应（实时处理和警报）
](rel_monitor_aws_resources_automate_response_monitor.md)
+ [
# REL06-BP05 分析日志
](rel_monitor_aws_resources_storage_analytics.md)
+ [
# REL06-BP06 定期审核监控范围和指标
](rel_monitor_aws_resources_review_monitoring.md)
+ [
# REL06-BP07 对系统中的请求进行端到端跟踪监控
](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 为工作负载监控全部组件（生成）
使用 Amazon CloudWatch 或第三方工具监控工作负载组件。使用 AWS Health 控制面板监控 AWS 服务。
应监控工作负载的全部组件，包括前端、业务逻辑和存储层。定义关键指标，描述如何将其从日志中提取出来（如有必要），并为对应的警报事件设置阈值。确保指标与工作负载的关键性能指标（KPI）相关，并使用指标和日志来识别服务性能下降的早期预警信号。例如，与业务成果相关的指标（例如每分钟成功处理的订单数）可以比技术指标（例如 CPU 利用率）更快地表明工作负载问题。使用 AWS Health 控制面板可提供 AWS 资源底层的 AWS 服务性能和可用性的个性化视图。
云中监控创造新的机会。大多数云提供商都开发了可自定义的挂钩，可以提供见解来帮助您监控多层工作负载。Amazon CloudWatch 等 AWS 服务应用统计和机器学习算法来持续分析系统和应用程序的指标，只需最少的用户干预即可确定正常基线和表面异常。异常检测算法将指标的季节性变化和趋势变化考虑在内。
AWS 提供了大量的监控和日志信息，这些信息可用于定义工作负载特定的指标、需求变化流程，也助于采用机器学习技术，无论是否具备机器学习专业知识如何。
此外，还可监控所有外部端点，确保这些端点独立于基本实施。这种主动监控可通过综合事务实现（有时被称为*用户金丝雀*，但与金丝雀部署不同），这些事务会按照工作负载的客户端所执行的操作，定期执行许多常见任务。确保这些任务的持续时间较短，不要让工作负载在测试期间过载。Amazon CloudWatch Synthetics 让您可以[创建 Synthetics 金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，以便对端点和 API 进行监控。您还可以整合 Synthetics 金丝雀客户端节点和 AWS X-Ray 控制台，精确定位哪些 Synthetics 金丝雀遇到错误、故障，或对指定时段的速率进行限制的问题。
**期望结果：**
收集并使用来自工作负载所有组件的关键指标，确保工作负载的可靠性和最佳的用户体验。若能检测到工作负载无法实现业务成果，可快速宣布发生灾难并从事件中恢复。
**常见反模式：**
+ 仅监控连接到工作负载的外部接口。
+ 不生成任何工作负载特定的指标，只依靠工作负载使用的 AWS 服务所提供的指标。
+ 仅使用工作负载中的技术指标，而不监控与工作负载带来的非技术性 KPI 相关的任何指标。
+ 依靠生产流量和简单的运行状况检查来监控并评估工作负载状态。
**建立此最佳实践的好处：**在工作负载的各个层级进行监控，便于更快地预测并解决构成工作负载的组件中的问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
1. **启用日志记录（如适用）。**应从工作负载的所有组件获取监控数据。启用其他日志记录（例如 S3 访问日志），让工作负载记录工作负载特定的数据。收集来自 Amazon ECS、Amazon EKS、Amazon EC2、弹性负载均衡、AWS Auto Scaling 和 Amazon EMR 等服务的 CPU、网络 I/O 和磁盘 I/O 平均值的指标。有关向 CloudWatch 发布指标的 AWS 服务列表，请参阅[发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)。
1. **审查所有默认指标并探究任何数据收集欠缺。**每项服务都会生成默认指标。通过收集默认指标，您可以更好地了解工作负载组件之间的依赖关系，以及组件的可靠性和性能对工作负载的影响。您可使用 AWS CLI 或 API 向 CloudWatch [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
1. **评估所有指标，决定要针对工作负载中每项 AWS 服务的哪些指标发出警报。**您可以选择对工作负载可靠性有重大影响的指标子集。关注关键指标和阈值有助于细化[警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)数量，也助于尽量减少误报。
1. **定义警报以及在调用警报之后工作负载的恢复流程。**通过定义警报，您可以快速通知、上报和执行必要的步骤，以便从事件中恢复并达到规定的恢复时间目标（RTO）。您可以使用 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)调用自动工作流，并根据定义的阈值启动恢复程序。
1. **探索使用综合事务来收集有关工作负载状态的相关数据。**综合监控遵循相同的路线并执行与客户相同的操作，让您能够持续验证客户体验，即使应用程序中没有任何客户流量。使用[综合事务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，您可以早于客户先行发现问题。
## 资源
**相关最佳实践：**
+ [REL11-BP03 自动修复所有层](rel_withstand_component_failures_auto_healing_system.md)
**相关文档：**
+ [Getting started with your AWS Health Dashboard – Your account health](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Access Logs for Your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Access logs for your application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [访问 AWS Lambda 的 Amazon CloudWatch Logs](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 服务器访问日志记录](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Enable Access Logs for Your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exporting log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [在 Amazon EC2 实例上安装 CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [What are Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**用户指南：**
+ [创建跟踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Monitoring memory and disk metrics for Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [将 CloudWatch Logs 与容器实例结合使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC 流日志](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**相关博客：**
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**相关示例：**
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 定义与计算指标（聚合）
从工作负载组件收集指标和日志，并从中计算相关的聚合指标。这些指标为工作负载提供了广泛而深入的可观测性，并可以显著提高韧性态势。
可观测性不仅仅是从工作负载组件中收集指标以及能够查看指标和针对指标发出警报。其最终目的是对工作负载的行为进行全面的了解。此类行为信息来自工作负载中的所有组件，包括它们所依赖的云服务、精心制定的日志和指标。这些数据使您能够监督工作负载的整体行为，并可以非常详细地了解每个组件与每个工作单元的交互情况。
**期望结果：**
+ 可以从工作负载组件和 AWS 服务依赖关系中收集日志，然后将其发布到一个便于访问和处理的中心位置。
+ 日志包含高保真和准确的时间戳。
+ 日志包含有关处理上下文的相关信息，例如跟踪标识符、用户或账户标识符以及远程 IP 地址。
+ 可以从日志中创建聚合指标，这些指标从高层次视角表示工作负载的行为。
+ 可以查询聚合的日志，以获得有关工作负载的深入和相关的见解，并确定实际和潜在的问题。
**常见反模式：**
+ 您未从运行工作负载的计算实例或工作负载使用的云服务中收集相关日志或指标。
+ 您忽略了与业务关键绩效指标（KPI）相关的日志和指标的收集。
+ 您单独分析与工作负载相关的遥测数据，而没有采用聚合和关联。
+ 您让指标和日志过快过期，这会阻碍趋势分析和识别反复出现的问题。
**建立这些最佳实践的好处：**您可以检测更多异常情况，并使工作负载的不同组件之间的事件和指标相关联。您可以根据日志中包含的信息，从工作负载组件中创建见解，而这些信息通常仅在指标中不可用。通过大规模查询日志，您可以更快地确定失败原因。
**在未建立这些最佳实践的情况下暴露的风险等级：**高
## 实施指导
确定与您的工作负载及其组件相关的遥测数据来源。这些数据不仅来自发布指标的组件，例如您的操作系统（OS）和应用程序运行时（例如 Java），还来自应用程序和云服务日志。例如，Web 服务器通常会记录每个请求以及诸如时间戳、处理延迟、用户 ID、远程 IP 地址、路径和查询字符串等详细信息。这些日志中的详细程度有助于您执行详细的查询，并生成原本可能无法得到的指标。
使用适当的工具和流程收集指标和日志。在 Amazon EC2 实例上运行的应用程序生成的日志可以由 [Amazon CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)等代理收集，并发布到 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 等中央存储服务。[AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) 等 AWS 托管式计算服务会自动将日志发布到 CloudWatch Logs。为工作负载使用的 AWS 存储和处理服务启用日志收集，如 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[Amazon S3](https://aws.amazon.com/s3/)、[弹性负载均衡](https://aws.amazon.com/elasticloadbalancing/)和 [Amazon API Gateway](https://aws.amazon.com/api-gateway/)。
使用*[维度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)* 丰富遥测数据，维度有助于您更清楚地看到行为规律，并将相关问题隔离到相关组件组中。添加后，您可以更详细地观察组件行为，检测相关的故障，并采取适当的补救措施。有用维度的示例包括可用区、EC2 实例 ID 和容器任务或容器组（pod）ID。
收集指标和日志后，您可以编写查询并从中生成聚合指标，从而为正常和异常行为提供有用的见解。例如，您可以使用 [Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 从应用程序日志中得出自定义指标，使用 [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) 大规模查询您的指标，使用 [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 从容器化应用程序和微服务中收集、聚合和汇总指标和日志，或者，如果您使用的是 AWS Lambda 函数，则可以使用 [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)。要创建聚合错误率指标，可以在每次在组件日志中发现错误响应或消息时递增计数器，或者计算现有错误率指标的聚合值。可以使用这些数据来生成显示*尾部行为* 的直方图，例如性能最差的请求或进程。还可以使用 CloudWatch Logs [anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html) 等解决方案实时扫描这些数据，来发现异常规律。这些见解可以放在控制面板上，以便根据您的需求和偏好进行整理。
查询日志有助于您了解工作负载组件如何处理特定的请求，并揭示影响工作负载韧性的请求规律或其它上下文。根据您对应用程序和其它组件行为的了解，提前研究和准备查询可能很有用，这样您就可以更轻松地根据需要运行它们。例如，使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)，您能够以交互方式搜索和分析存储在 CloudWatch Logs 中的日志数据。还可以使用 [Amazon Athena](https://aws.amazon.com/athena/) 查询来自多个来源（包括[许多 AWS 服务](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html)）的日志，数据量可达 PB 级。
在定义日志保留策略时，请考虑历史日志的价值。历史日志有助于确定工作负载性能的长期使用情况和行为规律、回归以及改进领域。永久删除的日志以后无法分析。然而，历史日志的价值往往会随着时间推移而减少。选择的策略应能够适当平衡您的需求，并符合您可能需要遵守的任何法律或合同要求。
### 实施步骤
1. 为您的可观测性数据选择收集、存储、分析和显示机制。
1. 在工作负载的适当组件上安装和配置指标和日志收集器（例如，在 Amazon EC2 实例上和[边车容器](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)中）。将这些收集器配置为在意外停止时自动重新启动。为收集器启用磁盘或内存缓冲，这样，临时发布失败就不会影响应用程序或导致数据丢失。
1. 在您用作工作负载一部分的 AWS 服务上启用日志记录，并在需要时将这些日志转发到您选择的存储服务。有关详细说明，请参阅相应服务的用户或开发人员指南。
1. 定义与基于遥测数据的工作负载相关的操作指标。这些指标可能基于从工作负载组件发出的直接指标，其中可能包括与业务 KPI 相关的指标，也可能基于聚合计算的结果，例如总和、比率、百分位数或直方图。使用日志分析器计算这些指标，并根据需要将其放在控制面板上。
1. 根据需要准备相应的日志查询，来分析工作负载组件、请求或事务行为。
1. 为组件日志定义并启用日志保留策略。当日志的时间超过策略允许的时间时，定期删除日志。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 发送通知（实时处理和报警）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL06-BP04 自动响应（实时处理和警报）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html)
+ [REL06-BP05 分析日志](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html)
+ [REL06-BP06 定期审核监控范围和指标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html)
+ [REL06-BP07 对系统中的请求进行端到端跟踪监控](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
**相关文档：**
+ [说明 Amazon CloudWatch 的工作原理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)。
+ [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)
+ [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [使用 CloudWatch Metrics Insights 查询您的指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [适用于 OpenTelemetry 的 AWS Distro](https://aws.amazon.com/otel/)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Searching and Filtering Log Data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Sending Logs Directly to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
**相关讲习会：**
+ [One Observability 讲习会](https://observability.workshop.aws/)
**相关工具：**
+ [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/)
# REL06-BP03 发送通知（实时处理和报警）
当组织检测到潜在问题时，会向相应的人员和系统发送实时通知和警报，以便快速有效地处理这些问题。
**期望结果：**通过根据服务和应用程序指标配置相关警报，可对运维事件做出快速响应。当超出警报阈值时，相应的人员和系统会收到通知，以便解决潜在的问题。
**常见反模式：**
+ 配置的警报阈值过高，导致无法发送重要通知。
+ 配置的警报阈值过低，导致通知过多，而重要警报无法得到处理。
+ 使用情况发生变化时不更新警报及其阈值。
+ 对于最好通过自动操作来处理的警报，向人员发送通知而不是生成自动操作，导致发送的通知过多。
**建立此最佳实践的好处：**通过向相应的人员和系统发送实时通知和警报，可以及早发现问题并快速处理运维方面的意外事件。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
工作负载应配备实时处理和报警功能，从而更及时地检测到可能影响应用程序可用性的问题，并充当自动响应的触发器。组织可以通过使用定义的指标创建警报来执行实时处理和报警，以便在发生重大事件或指标超过阈值时收到通知。
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 有助于您使用基于静态阈值、异常检测和其他标准的 CloudWatch 警报创建[指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和复合警报。有关可以使用 CloudWatch 配置的警报类型的更多详细信息，请参阅 [CloudWatch 文档的警报部分](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
您可以使用 [CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)为团队自定义 AWS 资源指标和警报的视图。通过 CloudWatch 控制台中的可自定义主页，您可以在单一视图中监控多个区域的资源。
警报可执行一项或多项操作，例如向 [Amazon SNS 主题](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)发送通知、执行 [Amazon EC2](https://aws.amazon.com/ec2/) 操作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 操作，或在 AWS Systems Manager 中[创建 OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
Amazon CloudWatch 使用 [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 在警报状态发生变化时发送通知，提供从发布者（生产者）到订阅用户（使用者）的信息传递。要了解有关设置 Amazon SNS 通知的更多信息，请参阅 [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)。
每当 CloudWatch 警报被创建、更新、删除或警报状态发生变化时，CloudWatch 都会发送 [EventBridge](https://aws.amazon.com/eventbridge/) [事件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html)。您可以将 EventBridge 与这些事件结合使用来创建执行操作的规则，例如，每当警报状态发生变化时通知您，或者使用 [Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)在账户中自动触发事件。
随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的最新信息。AWS Health 是有关 AWS 云资源运行状况的权威信息来源。使用 AWS Health 可获取任何已确认的服务事件的通知，以便您可以快速采取措施来减轻任何影响。通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 创建要发送到电子邮件和聊天渠道且契合目标的 AWS Health 事件通知，并以编程方式[通过 Amazon EventBridge 与监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。如果您使用 AWS Organizations，则跨账户汇总 AWS Health 事件。
**EventBridge 和 Amazon SNS 的使用时机**
EventBridge 和 Amazon SNS 都可用于开发事件驱动型应用程序，您可以根据自己的具体需求进行选择。
如果想要构建能够对自己的应用程序、SaaS 应用程序和 AWS 服务中的事件做出反应的应用程序，建议使用 Amazon EventBridge。EventBridge 是唯一直接与第三方 SaaS 合作伙伴集成的基于事件的服务。EventBridge 还可以自动从 200 多项 AWS 服务中提取事件，无需开发者在其账户中创建任何资源。
EventBridge 使用已定义的基于 JSON 的事件结构，有助于您创建应用于整个事件主体的规则，以便选择要转发到[目标](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)的事件。EventBridge 目前支持 20 多项 AWS 服务作为目标，包括 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon SQS](https://aws.amazon.com/sqs/)、Amazon SNS、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 和 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)。
对于需要高扇出（数千或数百万个端点）的应用程序，建议使用 Amazon SNS。常见的一种模式是，客户将 Amazon SNS 用作规则的目标，来筛选所需的事件并扇出到多个端点。
消息是非结构化的，可以采用任意格式。Amazon SNS 支持将消息转发到六种不同类型的目标，包括 Lambda、Amazon SQS、HTTP/S 端点、短信、移动推送和电子邮件。Amazon SNS [典型延迟不超过 30 毫秒](https://aws.amazon.com/sns/faqs/)。有许多 AWS 服务通过配置服务来发送 Amazon SNS 消息（超过 30 项服务，包括 Amazon EC2、[Amazon S3](https://aws.amazon.com/s3/) 和 [Amazon RDS](https://aws.amazon.com/rds/)）。
### 实施步骤
1. 使用 [Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)创建警报。
1. 指标警报可监控单个 CloudWatch 指标或依赖于 CloudWatch 指标的表达式。这种警报会根据在若干时间间隔内，指标或表达式的值与阈值的比较结果，启动一项或多项操作。操作可以是向 [Amazon SNS 主题](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)发送通知、执行 [Amazon EC2](https://aws.amazon.com/ec2/) 操作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 操作，或在 AWS Systems Manager 中[创建 OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
1. 复合警报由一个规则表达式组成，该规则表达式考虑了您创建的其他警报的警报条件。只有满足所有规则条件，复合警报才会进入警报状态。复合警报的规则表达式中指定的警报可以包括指标警报和其他复合警报。复合警报可以在改变状态时发送 Amazon SNS 通知，并且可以在进入警报状态时创建 Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)，但无法执行 Amazon EC2 Auto Scaling 操作。
1. 设置 [Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)。创建 CloudWatch 警报时，可以包括 Amazon SNS 主题，以便在警报状态发生变化时发送通知。
1. [在 EventBridge 中创建](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)与指定的 CloudWatch 警报相匹配的规则。每条规则都支持多个目标，包括 Lambda 函数。例如，您可以定义一个会在可用磁盘空间不足时启动的警报，通过 EventBridge 规则触发 Lambda 函数来清理空间。有关 EventBridge 目标的更多详细信息，请参阅 [EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定义与计算指标（聚合）](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 使用行动手册调查故障](rel_testing_resiliency_playbook_resiliency.md)
**相关文档：**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [设置 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [CloudWatch 异常检测](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch Logs data protection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon Simple Notification Service](https://aws.amazon.com/sns/)
**相关视频：**
+ [re:Invent 2022 observability 视频](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 – Observability best practices at Amazon](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**相关示例：**
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 自动响应（实时处理和警报）
检测到事件后，利用自动化功能执行操作；例如，更换故障组件。
实施警报的自动实时处理，以便系统可以快速采取纠正措施，并在触发警报时尝试防止故障或服务降级。警报的自动响应可能包括更换故障组件，调整计算容量，将流量重定向到运行状况良好的主机、可用区或其他区域，以及通知操作员。
**期望结果：**识别实时警报，并设置警报的自动处理，以便调用适当措施来维护服务级别目标和服务水平协议（SLA）。自动处理的范围可以是单个组件的自我修复活动，也可以是全站点的失效转移。
**常见反模式：**
+ 没有明确的关键实时警报的清单或目录。
+ 关键警报没有自动响应（例如，当计算资源即将耗尽时自动进行扩展）。
+ 警报响应操作相互矛盾。
+ 操作员在收到警报通知时没有任何标准操作程序（SOP）可以遵循。
+ 不监控配置更改，因为未检测到的配置更改可能会导致工作负载停机。
+ 没有撤消意外配置更改的策略。
**建立此最佳实践的好处：**自动处理警报可以提高系统的韧性。系统会自动采取纠正措施，从而减少手动操作，而手动操作往往是容易出错的人工干预。工作负载的运行符合可用性目标，并减少服务中断。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
为了有效地管理警报并自动进行响应，请根据警报的严重程度和影响对警报进行分类，记录响应程序，并在对任务进行评级之前制定好响应计划。
确定需要特定操作的任务（通常在运行手册中详细说明），并检查所有运行手册和行动手册，判断哪些任务可以自动执行。如果操作可以定义，通常就可以实现自动化。如果操作无法自动化，请在 SOP 中记录手动步骤并对操作员进行培训。不断挑战手动流程，寻找自动化机会，以便制定和维护自动响应警报的计划。
### 实施步骤
1. **创建警报清单：**要获取所有警报的列表，您可以使用 [Amazon CloudWatch 命令](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` 来使用 [AWS CLI](https://aws.amazon.com/cli/)。根据设置的警报数量，您可能需要使用分页来检索每个呼叫的警报子集，或者也可以使用 AWS SDK [通过 API 调用](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html)获取警报。
1. **记录所有警报操作：**更新包含所有警报及其操作的运行手册，无论它们是手动还是自动的。[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) 提供预定义的运行手册。有关运行手册的更多信息，请参阅[使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)。有关如何查看运行手册内容的详细信息，请参阅 [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json)。
1. **设置和管理警报操作：**对于任何需要操作的警报，请[使用 CloudWatch SDK 指定自动操作](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)。例如，您可以通过创建和启用警报操作或禁用警报操作，根据 CloudWatch 警报自动更改 Amazon EC2 实例的状态。
您还可以使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 自动响应系统事件，例如应用程序可用性问题或资源更改。您可以创建规则来指示要关注的事件，以及在事件匹配规则时要执行的操作。可以自动启动的操作包括调用 [AWS Lambda](https://aws.amazon.com/lambda/) 函数、调用 [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`、将事件中继到 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 以及查看[使用 EventBridge 自动执行 Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html)。
1. **标准操作程序（SOP）：**根据应用程序组件，[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 会推荐多个 [SOP 模板](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html)。您可以使用这些 SOP 来记录在出现警报时操作员应遵循的所有流程。您还可以根据韧性监测中心的建议[构造 SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html)，前提是有一个具有相关韧性策略的 Resilience Hub 应用程序，以及针对该应用程序的历史韧性评测。针对 SOP 的建议由韧性评测生成。
韧性监测中心与 Systems Manager 结合使用，通过提供大量可用作这些 SOP 基础的 [SSM 文档](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html)，自动执行 SOP 的步骤。例如，韧性监测中心可能会根据现有的 SSM 自动化文档推荐用于添加磁盘空间的 SOP。
1. **使用 Amazon DevOps Guru 执行自动操作：**可以使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 自动监控应用程序资源的异常行为并提供针对性的建议，缩短识别问题和进行修复所需的时间。借助 DevOps Guru，您可以近乎实时地监控来自多个来源的运营数据流，包括 Amazon CloudWatch 指标、[AWS Config](https://aws.amazon.com/config/)、[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 和 [AWS X-Ray](https://aws.amazon.com/xray/)。您还可以使用 DevOps Guru 在 OpsCenter 中自动创建 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)，并将事件发送到 [EventBridge](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html) 实现更多自动化操作。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定义与计算指标（聚合）](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 发送通知（实时处理和报警）](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 对部署等标准活动使用运行手册](rel_tracking_change_management_planned_changemgmt.md)
**相关文档：**
+ [AWS Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [使用自动化文档（行动手册）](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
**相关视频：**
+ [AWS re:Invent 2022 – Observability best practices at Amazon](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)
**相关示例：**
+ [Amazon CloudWatch and Systems Manager 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# REL06-BP05 分析日志
收集日志文件和指标历史记录并加以分析，获得更全面的趋势和工作负载见解。
Amazon CloudWatch Logs Insights 支持[简单但强大的查询语言](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)，可用于分析日志数据。Amazon CloudWatch Logs 还支持订阅，允许数据无缝流动到 Amazon S3（可在其中使用数据）或 Amazon Athena（可在其中查询数据）。该服务支持查询多种格式。请参阅《Amazon Athena 用户指南》，了解[支持的 SerDes 和数据格式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html)。针对大型日志文件集的分析，您可以运行 Amazon EMR 集群以执行 PB 级分析。
AWS 合作伙伴和第三方提供了许多用于聚合、处理、存储和分析的工具。这些工具包括 New Relic、Splunk、Loggly、Logstash、CloudHealth 和 Nagios。但是，系统和应用程序日志之外的生成对于每个云提供商，甚至每个服务来说都是独一无二的。
监控过程中常常被忽视的部分是数据管理。您需要确定数据监控的保留要求，然后相应地应用生命周期策略。Amazon S3 支持 S3 存储桶级别的生命周期管理。此生命周期管理可以通过不同的方式应用到存储桶中的不同路径。您可以在生命周期临近结束时，将数据转移到 Amazon Glacier 进行长期存储，然后在保留期结束后让它们过期。S3 Intelligent-Tiering 存储类旨在通过将数据自动移动到最具成本效益的访问层来优化成本，却不会对性能或运营开销产生影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 您可以使用 CloudWatch Logs Insights，通过交互方式搜索并分析 Amazon CloudWatch Logs 中的日志数据。
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ 使用 Amazon CloudWatch Logs 将日志发送到 Amazon S3 以供使用，或发送到 Amazon Athena 以查询数据。
+ [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ 为服务器访问日志存储桶创建 S3 生命周期策略。配置生命周期策略以定期删除日志文件。这样做可以减少 Athena 为每个查询分析的数据量。
+ [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## 资源
**相关文档：**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 定期审核监控范围和指标
经常审核工作负载监控的实施情况，并根据工作负载及其架构的发展进行更新。定期审计监控有助于降低遗漏或忽视故障指标的风险，并进一步协助工作负载实现其可用性目标。
有效的监控以关键业务指标为基础，这些指标会随着业务优先级变化而变化。监控审核过程应强调服务级别指标（SLI），并纳入来自基础设施、应用程序、客户和用户的见解。
**期望结果：**您拥有有效的监控策略，该策略会定期进行审核和更新，并在发生任何重大事件或变更后进行更新。随着工作负载和业务需求发生变化，您可以验证关键的应用程序运行状况指标是否仍然相关。
**常见反模式：**
+ 您仅收集默认指标。
+ 您设置了监控策略，但从不对其进行审核。
+ 部署重大更改时，您不讨论监控。
+ 您信任过时的指标来确定工作负载运行状况。
+ 由于指标和阈值过时，误报的警报让您的运营团队不堪重负。
+ 您对未受监控的应用程序组件缺乏可观测性。
+ 在监控中，您只关注低级技术指标，而不关注业务指标。
**建立这种最佳实践的好处：**当您定期审核监控时，您可以预测潜在的问题，并验证自己是否有能力发现这些问题。它还可让您找出之前的审核中可能错过的盲点，从而进一步提高您发现问题的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在 [operational readiness review (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 过程中审核监控指标和范围。按照一致的时间表定期进行运营准备情况审查，以评估您当前的工作负载与您配置的监控之间是否存在任何差距。定期开展运营性能审查和知识共享，有助于增强运营团队提高绩效的能力。验证现有的警报阈值是否仍然适合，并检查运营团队是否收到误报的警报，或者是否未监控应用程序的应受监控的各个方面。
[Resilience Analysis Framework](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) 提供了有用的指导，有助于您驾驭整个过程。该框架的重点是确定潜在的故障模式，以及可用于减轻其影响的预防和纠正控制措施。这些知识有助于您确定要监控和发出警报的正确指标和事件。
### 实施步骤
1. 计划并执行工作负载控制面板常规检查。您可能对检查深度具有不同的安排。
1. 检查指标中的趋势。对比指标值与历史值，了解是否有趋势表明需要调查某些情况。这种情况的示例包括延迟增加、主要业务功能减少以及故障响应增加。
1. 检查指标中是否存在离群值和异常值，这些值可能会被平均值或中位数掩盖。查看时间范围内的最高值和最低值，并调查观测结果远超正常范围的原因。随着您持续消除这些原因，您可以收紧预期的指标范围，以提高工作负载性能的一致性。
1. 查找清晰的行为变化。指标数量或方向的立即更改可能表示应用程序已发生变化，或者出现了需要添加额外指标进行跟踪的外部因素。
1. 审核当前的监控策略是否仍然与应用程序保持相关。根据对先前事件的分析（或韧性分析框架），评测该应用程序中是否还有其它方面应纳入监控范围。
1. 查看您的真实用户监控（RUM）指标，以确定应用程序功能覆盖范围是否存在任何差距。
1. 审查您的更改管理流程。如有必要，请更新相关过程，来包括应在批准更改之前执行的监控分析步骤。
1. 实施监控审核，以此作为运营准备情况审查和错误更正流程的一部分。
## 资源
**相关最佳实践**
+ [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP02 定义与计算指标（聚合）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html)
+ [REL06-BP07 对系统中的请求进行端到端跟踪监控](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
+ [REL12-BP02 执行事后分析](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html)
+ [REL12-BP06 定期进行 GameDay 活动](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
**相关文档：**
+ [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
+ [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [构建控制面板以获取操作可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card)
+ [Advanced Multi-AZ Resilience Patterns - Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ [Resilience Analysis Framework](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)
+ [Resilience Analysis Framework - Observability](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html)
+ [Operational Readiness Review - ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
# REL06-BP07 对系统中的请求进行端到端跟踪监控
跟踪各个服务组件的请求处理情况，这样产品团队便能够更轻松地分析和调试问题并提高性能。
**期望结果：**针对所有组件全面跟踪工作负载，实现轻松调试，进而通过简化发现错误根本原因的过程，缩短错误的[平均解决时间](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)（MTTR）和延迟。采用端到端的跟踪方式，有助于更快地发现受影响的组件，并详细深入地了解造成错误或延迟的根本原因。
**常见反模式：**
+ 只针对部分组件而不是全部组件进行跟踪。例如，如果不跟踪 AWS Lambda，团队可能无法清楚地了解高峰工作负载中冷启动所造成的延迟。
+ Synthetics 金丝雀或真实用户监控（RUM）未配置跟踪功能。没有金丝雀或 RUM，跟踪分析中会忽略客户端交互遥测数据，这样得出的性能概况就不够完整。
+ 混合工作负载包括云原生跟踪工具和第三方跟踪工具，但尚未采取措施来选择并完全集成单个跟踪解决方案。根据所选跟踪解决方案，应使用云原生跟踪 SDK 来检测非云原生组件，或者应将第三方工具配置为摄取云原生跟踪遥测数据。
**建立此最佳实践的好处：**当开发团队收到问题提醒时，能够查看系统组件交互情况的全貌，包括各个组件在日志记录、性能和故障方面的相关性。由于跟踪有助于直观且轻松地找出根本原因，因此调查根本原因所花费的时间得以减少。在解决问题时，团队如果能详细了解组件的交互情况，就可以更快地做出更好的决策。分析系统跟踪数据有助于改进多种决策，例如何时调用灾难恢复（DR）失效转移，或者在何处实施自我修复策略最合适等，最终势必能够提高客户对服务的满意度。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
团队在运行分布式应用程序时，能够借助跟踪工具来建立关联标识符、收集请求跟踪数据，以及构建互联组件的服务地图。请求跟踪中应该涵盖所有应用程序组件，包括服务客户端、中间件网关和事件总线、计算组件以及存储（包括键/值存储和数据库）。在端到端跟踪配置中，纳入 Synthetics 金丝雀和真实用户监控来衡量远程客户端交互情况和延迟，这样您就能够根据服务水平协议和目标准确地评估系统性能。
您可以使用 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 和 [Amazon CloudWatch 应用程序监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)检测服务，在请求通过应用程序时提供请求的完整视图。X-Ray 会收集应用程序遥测，有助于跨有效负载、函数、跟踪、服务、API 对其进行可视化和筛选，并且可以通过无代码或低代码的方式系统组件启用。CloudWatch 应用程序监控包括 ServiceLens，可将跟踪与指标、日志和警报集成。CloudWatch 应用程序监控还包括用于监控端点和 API 的 Synthetics，以及用于检测 Web 应用程序客户端的真实用户监控。
## 实施步骤
+ 在所有支持的本机服务上使用 AWS X-Ray，例如 [Amazon S3、AWS Lambda 和 Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)。这些 AWS 服务可使用基础设施即代码、AWS SDK 或 AWS 管理控制台 来启用 X-Ray。
+ 检测应用程序（[适用于 OpenTelemetry 的 AWS Distro 和 X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)）或第三方收集代理。
+ 查看《[AWS X-Ray Developer Guide](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)》，了解编程语言特定的实施。这些文档部分详细介绍了如何检测 HTTP 请求、SQL 查询和应用程序编程语言特定的其他进程。
+ 使用适用于 [Amazon CloudWatch Synthetics 金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 和 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 的 X-Ray 追踪，对最终用户客户端通过下游 AWS 基础设施的请求路径进行分析。
+ 根据资源运行状况和金丝雀遥测数据来配置 CloudWatch 指标和警报，这样团队就能够快速收到问题提醒，然后使用 ServiceLens 深入探究跟踪数据和服务地图。
+ 如果使用第三方工具作为主要的追踪解决方案，则将 X-Ray 与 [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/)、[New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/) 或 [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) 等第三方追踪工具集成。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](rel_withstand_component_failures_monitoring_health.md)
**相关文档：**
+ [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch：应用程序监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Integrating AWS X-Ray with other AWS services](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry and AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [Amazon CloudWatch：使用综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch：使用 CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Set up Amazon CloudWatch synthetics canary and Amazon CloudWatch alarm](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
**相关视频：**
+ [AWS re:Invent 2022 – How to monitor applications across multiple accounts ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ How to Monitor your AWS Applications ](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**相关工具：**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon CloudWatch](https://aws.amazon.com/pm/cloudwatch/)
+ [Amazon Route 53](https://aws.amazon.com/route53/)