本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 规划您的 CloudWatch 部署
<a name="planning-cloudwatch-deployment"></a>

日志和监控解决方案的复杂性和范围取决于多个因素，包括：
+ 使用了多少环境、区域和账户，以及这个数字可能如何增加。
+ 现有工作负载和架构的种类和类型。
+ 必须记录和监控 OSs 的计算类型。
+ 是否既有本地位置又有 AWS 基础架构。
+ 多个系统和应用程序的聚合和分析需求。
+ 防止未经授权泄露日志和指标的安全要求。
+ 必须与您的日志和监控解决方案集成以支持操作流程的产品和解决方案。

您必须使用新的或更新的工作负载部署定期检查和更新您的日志记录和监控解决方案。当发现问题时，应识别并应用对日志、监控和警报的更新。然后，可以主动发现这些问题，并在将来加以预防。

您必须确保始终如一地安装和配置用于捕获和摄取日志和指标的软件和服务。成熟的日志和监控方法使用多个 AWS 或独立的软件供应商 (ISV) 服务和解决方案来处理不同的领域（例如安全、性能、网络或分析）。每个域都有自己的部署和配置要求。

我们建议使用 CloudWatch 来捕获和摄取多种计算类型的日志 OSs 和指标。许多 AWS 服务 CloudWatch 用于记录、监控和发布日志和指标，无需进一步配置。 CloudWatch 提供了可以针对不同 OSs 环境进行安装和配置的[软件代理](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)。以下各节概述了如何为多个账户、区域和配置部署、安装和配置 CloudWatch 代理：

**Topics**
+ [

# CloudWatch 在集中式或分布式账户中使用
](cloudwatch-centralized-distributed-accounts.md)
+ [

# 管理 CloudWatch 代理配置文件
](create-store-cloudwatch-configurations.md)

# CloudWatch 在集中式或分布式账户中使用
<a name="cloudwatch-centralized-distributed-accounts"></a>

尽管 CloudWatch 旨在监控一个账户和区域中的 AWS 服务或资源，但您可以使用中央账户来捕获来自多个账户和地区的日志和指标。如果您使用多个账户或区域，则应评估是使用集中账户方法还是使用个人账户来捕获日志和指标。通常，多账户和多区域部署需要采用混合方法，以支持安全、分析、运营和工作负载所有者的需求。

下表提供了选择使用集中式、分布式或混合方法时需要考虑的方面。


****  

|  |  | 
| --- |--- |
| 账户结构 | 您的组织可能有多个单独的帐户（例如，用于非生产和生产工作负载的帐户），或者在特定环境中为单个应用程序设置数千个帐户。我们建议您在运行工作负载的账户中维护应用程序日志和指标，这样工作负载所有者就可以访问日志和指标。这使他们能够在日志和监控中发挥积极作用。我们还建议您使用单独的日志记录帐户来汇总所有工作负载日志，以进行分析、聚合、趋势和集中操作。单独的日志帐户也可以用于安全、存档和监控以及分析。 | 
| 访问要求 | 团队成员（例如工作负载所有者或开发人员）需要访问日志和指标才能进行故障排除和改进。应将日志保存在工作负载的帐户中，以便于访问和故障排除。如果日志和指标保存在与工作负载不同的账户中，则用户可能需要定期在账户之间切换。使用集中式帐户可向授权用户提供日志信息，而无需授予工作负载帐户访问权限。这可以简化分析工作负载的访问要求，在这些工作负载中，需要对在多个账户中运行的工作负载进行聚合。集中式日志账户还可以有其他搜索和聚合选项，例如 Amazon S OpenSearch ervice 集群。Amazon [S OpenSearch ervice 为您的日志提供精细的访问控制](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html)，直至字段级别。当您的敏感或机密数据需要专门的访问权限和权限时，精细的访问控制非常重要。 | 
| 操作 | 许多组织都有集中的运营和安全团队或外部组织来提供运营支持，需要访问日志进行监控。集中式日志和监控可以更轻松地识别所有账户和工作负载的趋势、搜索、汇总和执行分析。如果您的组织使用 “[你构建，你运行](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)” 的方法 DevOps，那么工作负载所有者需要在其账户中记录和监控信息。除了分布式工作负载所有权外，可能需要采用混合方法来满足中央运营和分析需求。 | 
| 环境 |  根据安全要求和账户架构，您可以选择将生产账户的日志和指标托管在中心位置，并将其他环境（例如开发或测试）的日志和指标保存在相同或单独的账户中。这有助于防止生产过程中创建的敏感数据被更广泛的受众访问。   | 

CloudWatch 提供了[多个选项](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html)，可使用 CloudWatch 订阅过滤器实时处理日志。您可以使用订阅过滤器将日志实时流式传输到 AWS 服务，以进行自定义处理、分析和加载到其他系统。如果您采用混合方法，除了集中式账户和区域外，还可以在个人账户和区域中查看日志和指标，这可能特别有用。以下列表提供了可用于此目的的 AWS 服务示例：
+ [Amazon Data Firehos](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) e — Firehose 提供了一种流媒体解决方案，可根据生成的数据量自动扩展和调整大小。您无需管理 Amazon Kinesis 数据流中的分片数量，无需额外编码即可直接连接到亚马逊简单存储服务 (Amazon S3) OpenSearch 、亚马逊服务或 Amazon Redshift。如果您想将日志集中在这些服务中，Firehose 是一个有效的解决方案。 AWS 
+ [Amazon Kinesis Data](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) Streams — Kinesis Data Streams — 如果你需要与 Firehose 不支持的服务集成并实现额外的处理逻辑，那么Kinesis Data Streams是一个合适的解决方案。您可以在您的账户和区域中创建 Amazon CloudWatch Logs 目标，在中央账户中指定 Kinesis 数据流，并指定一个 AWS Identity and Access Management (IAM) 角色，该角色授予其在流中放置记录的权限。Kinesis Data Streams 为您的日志数据提供了一个灵活的开放式着陆区，然后可以通过不同的选项使用这些数据。您可以将 Kinesis Data Streams 日志数据读入您的账户，执行预处理，然后将数据发送到您选择的目的地。

  但是，您必须为流配置分片，使其大小适合生成的日志数据。Kinesis Data Streams 充当日志数据的临时中介或队列，您可以在 Kinesis 流中将数据存储一到 365 天。Kinesis Data Streams 还支持重播功能，这意味着你可以重播未消耗的数据。
+ [Amazon S OpenSearch ervic](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) e — CloudWatch 日志可以将日志组中的日志流式传输到个人账户或集中账户中的 OpenSearch 集群。当您将日志组配置为将数据流式传输到 OpenSearch 集群时，将在与您的日志组相同的账户和区域中创建 Lambda 函数。Lambda 函数必须与集群建立网络连接。 OpenSearch 您可以自定义 Lambda 函数以执行额外的预处理，此外还可以对 Amazon Service 进行自定义提取。 OpenSearch 使用 Amazon S OpenSearch ervice 进行集中日志记录可以更轻松地分析、搜索和解决云架构中多个组件的问题。
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) — 如果您使用 Kinesis Data Streams，则需要预配置和管理使用流中数据的计算资源。为避免这种情况，您可以将日志数据直接流式传输到 Lambda 进行处理，然后根据您的逻辑将其发送到目的地。这意味着您无需预置和管理计算资源即可处理传入的数据。[如果您选择使用 Lambda，请确保您的解决方案与 Lambda 配额兼容。](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)

您可能需要以文件格式处理或共享存储在 CloudWatch 日志中的日志数据。您可以创建导出任务，将特定日期或时间范围内的[日志组导出到 Amazon S3](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html)。例如，您可以选择每天将日志导出到 Amazon S3 以进行分析和审计。Lambda 可用于自动执行此解决方案。您还可以将此解决方案与 Amazon S3 复制相结合，将您的日志从多个账户和区域传送并集中到一个集中账户和区域。

 CloudWatch 代理配置还可以在该部分中指定一个`credentials`字[`agent`段](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection)。这指定了向其他账户发送指标和日志时要使用的 IAM 角色。如果指定，则此字段包含`role_arn`参数。当您只需要在特定的集中式账户和地区进行集中记录和监控时，可以使用此字段。

您还可以使用 [AWS SDK](https://aws.amazon.com/developer/tools/) 以自己选择的语言编写自己的自定义处理应用程序，读取账户中的日志和指标，并将数据发送到中央账户或其他目标以进行进一步处理和监控。

# 管理 CloudWatch 代理配置文件
<a name="create-store-cloudwatch-configurations"></a>

我们建议您创建标准的亚马逊 CloudWatch 代理配置，其中包括您要在所有亚马逊弹性计算云 (Amazon EC2) 实例和本地服务器上捕获的系统日志和指标。您可以使用 CloudWatch 代理[配置文件向导](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html)来帮助您创建配置文件。您可以多次运行配置向导，为不同的系统和环境生成唯一的配置。您也可以[使用配置文件架构](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html)修改配置文件或创建变体。 CloudWatch 代理配置文件可以存储在 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) 参数中。 如果您有[多个 CloudWatch 代理配置文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)，则可以创建单独的参数存储参数。如果您使用多个 AWS 账户或 AWS 区域，则必须管理和更新每个账户和区域中的参数存储参数。或者，您可以在 Amazon S3 中将 CloudWatch 配置作为文件或您选择的版本控制工具进行集中管理。 

 CloudWatch 代理附带的`amazon-cloudwatch-agent-ctl`脚本允许您指定配置文件、参数存储参数或代理的默认配置。默认配置与基本的预定义指标集保持一致，并将代理配置为向其报告内存和磁盘空间指标。 CloudWatch但是，它不包括任何日志文件配置。如果您对 CloudWatch 代理使用 S [ystems Manager 快速设置](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html)，则也会应用默认配置。

由于默认配置不包括日志记录，也不是根据您的要求进行自定义的，因此我们建议您创建和应用自己的 CloudWatch 配置，并根据您的要求进行自定义。

## 管理 CloudWatch 配置
<a name="store-cloudwatch-configuration-s3"></a>

默认情况下， CloudWatch 配置可以作为参数存储参数或 CloudWatch 配置文件进行存储和应用。最佳选择将取决于您的要求。在本节中，我们将讨论这两个选项的优缺点。还详细介绍了用于管理多个 AWS 账户和 AWS 区域的 CloudWatch 配置文件的代表性解决方案。

**Systems Manager 参数存储区参数**

如果您想在一小部分 AWS 账户和区域中应用和管理 CloudWatch 单个标准 CloudWatch 代理配置文件，则使用 Parameter Store 参数管理配置效果很好。当您将 CloudWatch 配置存储为 Parameter Store 参数时，您可以使用 CloudWatch 代理配置工具（`amazon-cloudwatch-agent-ctl`在 Linux 上）从 Parameter Store 读取和应用配置，而无需将配置文件复制到您的实例。您可以使用 **AmazonCloudWatch-** S ManageAgent ystems Manager 命令文档在一次运行中更新多个 EC2 实例的 CloudWatch 配置。由于参数存储参数是区域性的，因此您必须在每个 AWS 区域和 AWS 账户中更新和维护您的 CloudWatch参数存储参数。如果您要将多个 CloudWatch配置应用于每个实例，则必须自定义 **AmazonCloudWatch-** C ManageAgent ommand 文档****以包含这些参数。

**CloudWatch 配置文件**

如果您有许多 AWS 账户和区域，并且要管理多个 CloudWatch 配置文件，那么将您的 CloudWatch 配置作为文件进行管理可能效果很好。使用这种方法，您可以在文件夹结构中浏览、组织和管理它们。  您可以对单个文件夹或文件应用安全规则，以限制和授予访问权限，例如更新和读取权限。您可以将它们共享并转移到 AWS 以外进行协作。您可以对文件进行版本控制以跟踪和管理更改。您可以通过将 CloudWatch 配置文件复制到 CloudWatch 代理配置目录来集中应用配置，而不必单独应用每个配置文件。对于 Linux， CloudWatch 配置目录位于中`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`。对于 Windows，配置目录位于以下网址`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`。

启动代理时， CloudWatch 代理会自动附加在这些目录中找到的每个文件以创建 CloudWatch 复合配置文件。配置文件应存储在中央位置（例如，S3 存储桶），您的所需账户和区域可以访问该位置。提供了使用这种方法的示例解决方案。

**组织 CloudWatch 配置**

无论使用哪种方法来管理您的 CloudWatch 配置，都要整理您的 CloudWatch 配置。您可以使用以下方法将配置组织到文件或参数存储路径中。


|  |  | 
| --- |--- |
| */config/standard/windows/ec2* | 存储适用于亚马逊 EC2 的 Windows 专用标准 CloudWatch 配置文件。您可以在此文件夹下进一步对不同 Windows 版本、EC2 实例类型和环境的标准操作系统 (OS) 配置进行分类。 | 
| */config/standard/windows/onpremises* | 为本地服务器存储特定于 Windows 的标准 CloudWatch 配置文件。您还可以在此文件夹下对不同 Windows 版本、服务器类型和环境的标准操作系统配置进行进一步分类。 | 
| */config/standard/linux/ec2* | 存储适用于亚马逊 EC2 的标准 Linux 专用 CloudWatch 配置文件。您可以在此文件夹下进一步对不同 Linux 发行版、EC2 实例类型和环境的标准操作系统配置进行分类。 | 
| */config/standard/linux/onpremises* | 存储本地服务器的标准 Linux 专用 CloudWatch 配置文件。您可以在此文件夹下进一步对不同 Linux 发行版、服务器类型和环境的标准操作系统配置进行分类。 | 
| */config/ecs* | 如果您使用亚马逊 ECS 容器实例，请存储特定于亚马逊弹性容器服务 (Amazon ECS) 的 CloudWatch 配置文件。这些配置可以附加到标准的 Amazon EC2 配置中，用于特定于 Amazon ECS 的系统级日志记录和监控。 | 
| */config/* <application\$1name> | 存储应用程序特定的 CloudWatch 配置文件。您可以使用环境和版本的其他文件夹和前缀对应用程序进行进一步分类。 | 

## 示例：将 CloudWatch 配置文件存储在 S3 存储桶中
<a name="example"></a>

本节提供了一个使用 Amazon S3 存储 CloudWatch 配置文件的示例，以及使用自定义 Systems Manager 运行手册来检索和应用 CloudWatch 配置文件。这种方法可以解决使用 Systems Manager 参数存储参数进行大规模 CloudWatch 配置的一些挑战：
+ 如果您使用多个区域，则必须在每个区域的参数存储中同步 CloudWatch 配置更新。Parameter Store 是一项区域服务，在使用 CloudWatch 代理的每个区域中必须更新相同的参数。
+ 如果您有多个 CloudWatch 配置，则必须启动每个参数存储配置的检索和应用。您必须从 Parameter Store 中单独检索每个 CloudWatch 配置，并在添加新配置时更新检索方法。相比之下， CloudWatch 提供了用于存储配置文件的配置目录，并应用该目录中的每个配置，而无需单独指定它们。
+ 如果您使用多个账户，则必须确保每个新账户在其 Parameter Store 中都具有所需的 CloudWatch 配置。您还需要确保将来对这些账户及其区域进行任何配置更改。

您可以将 CloudWatch 配置存储在 S3 存储桶中，您的所有账户和区域均可访问该存储桶。然后，您可以使用 Systems Manager Automation 运行手册和 Systems Manager 状态管理器将这些 CloudWatch 配置从 S3 存储桶复制到配置目录。您可以使用 [cloudwatch-config-s3 bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) AW CloudFormation S 模板创建 S3 存储桶，该存储桶可从 AWS Organizations 中一个组织内的多个账户进行访问。该模板包含一个`OrganizationID`参数，该参数授予[组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)内所有账户的读取权限。

本指南的 “为[ CloudWatch 代理部署和配置设置状态管理器和分发服务器” 部分提供的增强示例 Systems Manager 运行手册配置为](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor)使用 [cloudwatch-config-s3-bucket.y](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) aml AWS 模板创建的 S3 存储桶检索文件。 CloudFormation 

或者，您可以使用版本控制系统（例如 GitHub）来存储配置文件。如果要自动检索存储在版本控制系统中的配置文件，则必须管理或集中凭据存储，并更新 Systems Manager Automation 运行手册，该操作手册用于检索您的账户和的凭据。 AWS 区域