使用 Terraform 设置企业级规模的集中式日志记录 - AWS 规范指引
Summary先决条件和限制架构工具最佳实践操作说明问题排查相关资源

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

使用 Terraform 设置企业级规模的集中式日志记录

Aarti Rajput、Yashwant Patel 和 Nishtha Yadav，Amazon Web Services

Summary

集中式日志记录对于组织的云基础设施至关重要，因为它能让企业清晰掌握自身的运营状况、安全态势及合规情况。随着您的组织跨多个账户扩展其 AWS 环境，结构化的日志管理策略成为运行安全操作、满足审计要求和实现卓越运营的基础。

这种模式提供了一个可扩展的安全框架，用于集中来自多个 AWS 账户 和服务的日志，从而在复杂 AWS 的部署中实现企业级日志管理。该解决方案使用Terraform实现自动化，Terraform是一种基础设施即代码（IaC）工具，可 HashiCorp 确保一致和可重复的部署，并最大限度地减少手动配置。通过结合亚马逊 CloudWatch 日志、Amazon Data Firehose 和亚马逊简单存储服务 (Amazon S3) Service，您可以实施一个强大的日志聚合和分析管道，该管道可提供：

  • 在整个组织中集中管理日志 AWS Organizations

  • 自动日志收集，内置安全控件

  • 可扩展的日志处理和持久存储功能

  • 简化的合规报告和审计跟踪记录

  • 实时运营洞察和监控

该解决方案通过日志收集来自亚马逊 Elastic Kubernetes Service（Amazon EKS） AWS Lambda 容器、函数和亚马逊关系数据库服务（Amazon RDS）数据库实例的日志。 CloudWatch 它使用 CloudWatch 订阅过滤器自动将这些日志转发到专用的日志帐户。Firehose 管理高吞吐量的日志流传输管道，将日志数据传输至 Amazon S3 进行长期存储。将 Amazon Simple Queue Service（Amazon SQS）配置为在创建对象后接收 Amazon S3 事件通知。这样可实现与分析服务的集成，包括：

  • 用于日志搜索、可视化和实时分析的 Amazon OpenSearch 服务

  • Amazon Athena，用于基于 SQL 的查询操作

  • Amazon EMR，用于大规模数据处理

  • Lambda，用于自定义转换

  • 适用于仪表板的 Amazon Quick

所有数据均使用 AWS Key Management Service (AWS KMS) 进行加密，整个基础架构通过使用 Terraform 进行部署，以实现跨环境的一致配置。

这种集中式日志记录方法使组织能够改善其安全状况，保持合规性要求，并优化其 AWS 基础架构的运营效率。

先决条件和限制

先决条件

有关设置 AWS Control Tower、AFT 和应用程序账户的说明，请参阅 Epics 部分。

所需账户

您的组织中 AWS Organizations 应包括以下账户：

  • 应用程序账户 — AWS 服务 （Amazon EKS、Lambda 和 Amazon RDS）运行和生成日志的一个或多个源账户

  • 日志存档账户 - 用于集中存储和管理日志的专用账户

产品版本

架构

下图说明了一种 AWS 集中式日志架构，该架构提供了一种可扩展的解决方案，用于收集、处理来自多个应用程序帐户的日志，并将其存储到一个专用的日志存档帐户中。该架构可以有效地处理来自 AWS 服务 Amazon RDS、Amazon EKS 和 Lambda 的日志，并通过简化的流程将这些日志路由到日志存档账户中的区域 S3 存储桶。

AWS 集中式日志记录架构，用于从多个应用程序账户收集日志。

该工作流包括五个流程：

  1. 日志流流程

    • 日志流过程从应用程序账户开始，在那里 AWS 服务 生成各种类型的日志，例如来自 Amazon RDS 的常规日志、错误日志、审计日志、慢速查询日志、来自 Amazon EKS 的控制平面日志以及来自 Lambda 的函数执行和错误日志。

    • CloudWatch 用作初始收集点。它在每个应用程序账户中按日志组级别收集这些日志。

    • 在中 CloudWatch，订阅筛选器决定应将哪些日志转发到中央账户。这些筛选条件支持对日志转发进行精细控制，因此您可指定确切的日志模式或完整的日志流，以实现日志的集中管理。

  2. 跨账户日志传输

    • 日志将移至日志存档帐户。 CloudWatch 订阅过滤器便于跨账户转账并保留区域背景。

    • 该架构建立了多个并行流，以高效地处理不同的日志源，从而确保实现最佳性能和可扩展性。

  3. 日志存档账户中的日志处理

    • 在日志存档账户中，Firehose 处理传入的日志流。

    • 每个区域均维护专用 Firehose 传输流，可以根据需要转换或丰富日志。

    • 这些 Firehose 传输流会将处理后的日志传输至日志存档账户中的 S3 存储桶，该账户与源应用程序账户位于同一区域（图中的区域 A），以满足数据主权要求。

  4. 通知和其他工作流

    • 当日志到达目标 S3 存储桶后，该架构会通过 Amazon SQS 实现通知系统。

    • 区域 SQS 队列支持异步处理，并且可以根据存储的日志触发其他工作流、分析或提醒系统。

  5. AWS KMS 为了安全

    AWS KMS 为了安全起见，该架构包含在内。 AWS KMS 为 S3 存储桶提供加密密钥。这样可以确保所有存储的日志均实现静态加密，同时按区域进行加密以满足数据驻留要求。

工具

AWS 服务

  • Amazon CloudWatch 是一项监控和可观察性服务，它以日志、指标和事件的形式收集监控和操作数据。它提供了在 AWS 和本地服务器上运行的 AWS 资源、应用程序和服务的统一视图。

  • CloudWatch 日志订阅过滤器是匹配传入日志事件中的模式并将匹配的日志事件传送到指定 AWS 资源以供进一步处理或分析的表达式。

  • AWS Control Tower Account F@@ actory For Terraform (AFT) 设置了 Terraform 管道来帮助你在中配置和自定义账户。 AWS Control Tower AFT 提供基于 Terraform 的账户配置，同时允许您使用管理账户。 AWS Control Tower

  • Amazon Data Firehos e 向亚马逊 S3、亚马逊 Redshift 和亚马逊服务等目的地提供实时流数据。 OpenSearch 它可自动扩展以满足数据吞吐量要求，并且无需进行日常管理。

  • Amazon Elastic Kubernetes Service（Amazon EKS）是一项托管式容器编排服务，可让您轻松地使用 Kubernetes 部署、管理和扩展容器化应用程序。它会自动管理 Kubernetes 控制面板节点的可用性和可扩展性。

  • AWS Key Management Service (AWS KMS) 创建和控制用于加密数据的加密密钥。 AWS KMS 与其他服务集成 AWS 服务 ，以帮助您保护使用这些服务存储的数据。

  • AWS Lambda 是一项无服务器计算服务，使您无需预调配或管理服务器即可运行代码。它会通过响应每个触发器来运行代码，从而自动扩展应用程序，且仅按您使用的计算时间收费。

  • Amazon Relational Database Service（Amazon RDS）是一项托管式关系数据库服务，用户能够在云中轻松地设置、操作和扩展关系数据库。它提供经济高效且可调整的容量，同时自动执行耗时的管理任务。

  • Amazon Simple Queue Service（Amazon SQS）是一种消息队列服务，可解耦和扩展微服务、分布式系统和无服务器应用程序。它消除了管理和操作面向消息的中间件的复杂性。

  • Amazon Simple Storage Service（Amazon S3）是一种基于云的对象存储服务，可提供出色的可扩展性、数据可用性、安全性和性能。该服务可在 Web 上的任何位置存储和检索任意数量的数据。

其他工具

  • Terraform 是一款基础设施即代码 (IaC) 工具 HashiCorp ，可帮助您创建和管理云和本地资源。

代码

此模式的代码可在 GitHub集中式日志存储库中找到。

最佳实践

操作说明

Task说明所需技能

使用 AFT 设置 AWS Control Tower 环境。

  1. AWS Control Tower 按照AWS Control Tower 文档中的说明进行部署。

  2. 按照 AWS Control Tower 文档中的说明部署 AFT。

AWS 管理员

为组织启用资源共享。

  1. 使用管理账户凭据@@ 配置 AWS Command Line Interface (AWS CLI)，这些凭据提供管理权限进行管理 AWS Control Tower。

  2. 使用任意 AWS CLI 命令运行以下命令 AWS 区域：

    aws ram enable-sharing-with-aws-organization

    这样，您就可以 AWS Organizations 跨所有支持 AWS Resource Access Manager (AWS RAM) 的地区在您的组织内部共享资源。

AWS 管理员

验证或预调配应用程序账户。

要为您的使用案例预调配新的应用程序账户，请通过 AFT 创建这些账户。有关更多信息，请参阅 AWS Control Tower 文档中的向 AFT 开通新账户。

AWS 管理员
Task说明所需技能

将 Application_account 文件夹内容复制到 aft-account-customizations 存储库中。

  1. 在 aft-account-customizations 存储库的根路径中创建一个名为 Application_account 的文件夹。此存储库是在您设置 AFT 时自动创建的（参阅之前的操作说明）。

  2. 导航到 centralised-logging-at-enterprise-scale-using-terraform 存储库的根目录，复制该aft/account目录的内容，然后将其粘贴到您在aft-account-customizations存储库中步骤 1 中创建的Application_account目录中。

  3. 从 centralised-logging-at-enterprise-scale-using-terraform 存储库的根目录，将 Application_account 目录的内容复制到 aft-account-customizations 存储库中的 Application_account/terraform 目录中。

  4. 在 aft-account-customizations/Application_account/terraform.tfvars 文件中，确认所有参数均已作为参数传递到相应的 Terraform 配置文件中。

DevOps 工程师

查看并编辑用于设置应用程序账户的输入参数。

在此步骤中，您将设置用于在应用程序账户中创建资源的配置文件，包括 CloudWatch 日志组、 CloudWatch 订阅筛选条件、IAM 角色和策略以及 Amazon RDS、Amazon EKS 和 Lambda 函数的配置详细信息。

在 aft-account-customizations 存储库的 Application_account 文件夹中，根据组织的要求配置 terraform.tfvars 文件中的输入参数：

  • environment：将在其中部署资源的环境的名称（例如 prod、dev、staging）。

  • account_name：创建资源的 AWS 账户 位置的名称。

  • log_archive_account_id：将日志存档到的 AWS 账户 ID。

  • admin_role_name：将用于管理资源的管理角色的名称。

  • tags：键值对映射，该映射表示要应用于所有资源的通用标签。

  • rds_config：包含 Amazon RDS 实例的配置详细信息的对象。

  • allowed_cidr_blocks：允许访问资源的 CIDR 数据块列表。

  • destination_name:一个变量，用于创建流式传输日志的 CloudWatch 目标的 Amazon 资源名称 (ARN)。

  • rds_parameters:：包含 Amazon RDS 参数组设置的对象。

  • vpc_config：包含 VPC 配置详细信息的对象。

  • eks_config：包含 Amazon EKS 集群的配置详细信息的对象。

  • lambda_config：包含 Lambda 函数的配置详细信息的对象。

  • restrictive_cidr_range：安全组规则的限制性 CIDR 范围列表。

  • target_account_id：将在其中部署资源的目标日志存档账户的 AWS 账户 ID。

DevOps 工程师
Task说明所需技能

将 Log_archive_account 文件夹内容复制到 aft-account-customizations 存储库中。

  1. 在 aft-account-customizations 存储库的根路径中创建一个名为 Log_archive_account 的文件夹，此存储库是在您设置 AFT 时自动创建的。

  2. 导航到 centralised-logging-at-enterprise-scale-using-terraform 存储库的根目录，复制 aft/account 目录的内容，然后将其粘贴到 aft-account-customizations 存储库中您在上一步创建的 Log_archive_account 目录。

  3. 从 centralised-logging-at-enterprise-scale-using-terraform 存储库的根目录，将 Log_archive_account 目录的内容复制到 aft-account-customizations 存储库中的 Log_archive_account/terraform 目录中。

  4. 在 aft-account-customizations/Log_archive_account/terraform.tfvars 文件中，确认所有参数均已作为参数传递到相应的 Terraform 配置文件中。

DevOps 工程师

查看并编辑用于设置日志存档账户的输入参数。

在此步骤中，您需要设置用于在日志存档账户中创建资源的配置文件，包括 Firehose 传输流、S3 存储桶、SQS 队列以及 IAM 角色和策略。

在 aft-account-customizations 存储库的 Log_archive_account 文件夹中，根据组织的要求配置 terraform.tfvars 文件中的输入参数：

  • environment：将在其中部署资源的环境的名称（例如 prod、dev、staging）。

  • destination_name：用于创建流式传输日志的 CloudWatch 目标的 ARN 的变量。

  • source_account_ids：允许 AWS 账户 IDs 在日志目标上放置订阅过滤器的列表。您可以输入任意数量的帐户 IDs 以启用集中日志记录。

DevOps 工程师
Task说明所需技能

选项 1 - 从 AFT 部署 Terraform 配置文件。

在 AFT 中，AFT 管道是在您将包含配置更改的代码推送到 GitHub aft-account-customizations存储库后触发的。AFT 会自动检测更改并启动账户自定义流程。

对 Terraform（terraform.tfvars）文件进行更改后，提交更改并将其推送到 aft-account-customizations 存储库：

$ git add *
$ git commit -m "update message"
$ git push origin main
注意

如果您使用的是其他分支（例如 dev），请将 main 替换为分支名称。

DevOps 工程师

选项 2 - 手动部署 Terraform 配置文件。

如果您不使用 AFT 或想要手动部署解决方案，则可以使用 Application_account 和 Log_archive_account 文件夹中的以下 Terraform 命令：

  1. 克隆 GitHub 存储库并在terraform.tfvars文件中配置输入参数。

  2. 运行如下命令：

    $ terraform init

  3. 预览更改：

    $ terraform plan

    此命令会评估 Terraform 配置以确定资源的所需状态，并将其与基础设施的当前状态进行比较。

  4. 应用更改：

    $ terraform apply

  5. 查看计划的更改，并在出现提示时键入 yes 以继续执行应用程序操作。

DevOps 工程师
Task说明所需技能

验证订阅筛选条件。

要验证订阅筛选条件是否正确地将日志从应用程序账户日志组转发到日志存档账户，请执行以下操作：

  1. 在应用程序帐户中，打开CloudWatch 控制台。

  2. 在左侧的导航窗格中，选择日志组。

  3. 选择每个日志组（/aws/rds、/aws/eks、/aws/lambda），然后选择订阅筛选条件选项卡。

    根据您在 Terraform 配置文件中指定的名称，您应能看到指向目标 ARN 的有效订阅筛选条件。

  4. 选择任意一个订阅筛选条件，验证其配置和状态。

DevOps 工程师

验证 Firehose 流。

要验证日志存档账户中的 Firehose 流是否成功处理应用程序日志，请执行以下操作：

  1. 在日志存档账户中，打开 Firehose 控制台。

  2. 在左侧导航窗格中，选择 Firehose 流。

  3. 选择任意一个 Firehose 流，并验证以下内容：

    • 目标显示正确的 S3 存储桶。

    • 监控选项卡显示成功送达指标。

    • 最近的送达时间戳为当前时间。

DevOps 工程师

验证集中式 S3 存储桶。

要验证集中式 S3 存储桶是否正确接收并整理日志，请执行以下操作：

  1. 在日志存档账户中，打开 Amazon S3 控制台。

  2. 选择每个中央日志存储桶。

  3. 浏览文件夹结构:AWSLogs/AccountID/Region/Service.

    您应该会看到按时间戳 (YYYY/MM/DD/HH) 组织的日志文件。

  4. 选择任意一个近期的日志文件，验证其格式和数据完整性。

DevOps 工程师

验证 SQS 队列。

要验证 SQS 队列是否收到新日志文件的通知，请执行以下操作：

  1. 在日志存档账户中，打开 Amazon SQS 控制台。

  2. 在左侧导航窗格中，选择 Queues (队列)。

  3. 选择每个已配置的队列，然后选择发送和接收消息。

    您应能看到包含新日志文件的 S3 事件通知的消息。

  4. 选择任意一条消息，验证其是否包含正确的 S3 对象信息。

DevOps 工程师
Task说明所需技能

选项 1 - 从 AFT 停用 Terraform 配置文件。

当您删除 Terraform 配置文件并推送更改时，AFT 会自动启动资源删除流程。

  1. 导航到 aft-account-customizations 存储库。

  2. 转到 terraform 目录。

  3. 删除以下文件：

    • modules 目录

    • iam.tf

    • versions.tf

    • variables.tf

    • outputs.tf

    • terraform.tfvars

  4. 清除 main.tf 文件的内容。

  5. 将更改推送到存储库：

    # Stage all changes
$ git add *

# Commit cleanup changes
$ git commit -m "Remove AFT customizations"

# Push to repository
$ git push origin main
    注意

    如果您使用的是其他分支（例如 dev），请将 main 替换为分支名称。

DevOps 工程师

选项 2 – 手动清理 Terraform 资源。

如果您不使用 AFT 或想要手动清理资源，则可以使用 Application_account 和 Log_archive_account 文件夹中的以下 Terraform 命令：

  1. 初始化 Terraform 配置：

    $ terraform init

    该命令会初始化 Terraform，并确保能够访问当前状态。

  2. 预览清理更改：

    $ terraform destroy

    此命令评估哪些资源将被销毁，并将所需状态与基础设施的当前状态进行比较。

  3. 运行清理操作。出现提示时，输入 yes 确认并运行销毁计划。

DevOps 工程师

问题排查

问题解决方案

CloudWatch 日志目标未创建或处于非活动状态。

请验证以下内容：

  1. 在日志存档账户中，验证目标策略是否包括：

    • 正确的源账户主体。

    • 正确的操作（logs:PutSubscriptionFilter）。

    • 有效的目标 ARN。

  2. 确认 Firehose 流已存在且处于活动状态。

  3. 验证附加到该目标的 IAM 角色是否拥有 Firehose 相关权限。

订阅筛选条件失败或停留在待处理状态。

请检查以下事项：

  1. 在应用程序账户中，验证 IAM 角色是否具有：

    • 调用 PutSubscriptionFilter 的权限。

    • 与 L CloudWatch ogs 的信任关系。

  2. 确认目标 ARN 正确无误。

  3. 查看 CloudWatch 日志以获取特定的错误消息。

Firehose 传输流未显示任何传入记录。

请验证以下内容：

  1. 确认 Firehose IAM 角色是否具有：

    • 写入 Amazon S3 的 IAM 权限。

    • 如果启用了加密，则可以访问密 AWS KMS 钥。

  2. 查看以下 CloudWatch 指标：

    • IncomingRecords

    • DeliveryToS3.Records

  3. 验证缓冲区设置和传输配置。

相关资源