View a markdown version of this page

了解计划查询的概念 - 亚马逊 CloudWatch 日志

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

了解计划查询的概念

在创建计划查询之前,请了解这些关键概念,这些概念会影响查询的运行方式和结果的交付地点。

IAM 角色分离

计划查询需要两个独立的 IAM 角色:一个用于执行查询,另一个用于将结果传送到 Amazon S3 存储桶、Amazon EventBridge 事件总线或查询表等目的地。了解这种分离的原因有助于您正确配置权限并使用其提供的安全和运营优势。

双角色架构在数据访问和数据交付之间划分了责任。查询执行角色访问您的日志数据并运行查询,而目标交付角色将结果写入您选择的目的地。这种分离遵循最小权限的原则——每个角色仅拥有其特定功能所需的权限。

查询执行角色

允许 CloudWatch 日志代表您运行 CloudWatch 日志见解查询。此角色需要访问您的日志组和执行查询的权限,但不需要访问目标资源。所需权限:

  • logs:StartQuery

  • logs:StopQuery

  • logs:GetQueryResults

  • logs:DescribeLogGroups

  • logs:Unmask是否需要取消屏蔽数据

对于 KMS-encrypted 日志组:kms:Decrypt以及用于加密日志组的 KMS 密钥的kms:DescribeKey权限。还需要添加这些权限。

信任关系要求:查询执行角色必须包含允许 CloudWatch 日志服务 (logs.amazonaws.com) 代入该角色的信任策略。如果没有这种信任关系,计划查询将因权限错误而失败。

查询执行角色的信任策略示例:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "logs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

查询执行角色的权限策略示例:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults", "logs:DescribeLogGroups" ], "Resource": "*" } ] }
目的地配送角色

允许 CloudWatch 日志将查询结果传送到您选择的目的地。遵循最小权限原则,此角色只需要特定目标服务的权限。所需的权限因目的地类型而异。

信任关系要求:目标交付角色还必须包含允许 CloudWatch 日志服务 (logs.amazonaws.com) 代入该角色的信任策略。

S3 目标交付角色的权限策略示例:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::your-scheduled-query-results-bucket/*" } ] }

查找表目标交付角色的权限策略示例:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLookupTable", "logs:UpdateLookupTable", "logs:GetQueryResults" ], "Resource": "*" } ] }

这种分离为您的运营带来了实际好处。从安全角度来看,如果您需要更改结果的交付地点,则只需修改目标交付角色而不更改查询执行权限。对于合规性和审计,您可以清楚地跟踪哪个角色访问敏感日志数据以及哪个角色写入外部系统。这样可以更轻松地证明您的日志分析基础架构遵循安全最佳实践。

Cross-region 以及跨账户的使用

计划查询是在特定区域创建的,并在该区域运行。但是,您可以查询日志组并跨区域和跨账户提供结果。您需要将一个或多个 AWS 账户设置为监控账户,并将它们与多个来源账户关联起来。监控账户是一个中央账户,可以查看源 AWS 账户生成的可观测性数据并与之交互。源账户是一个个人 AWS 账户,它为其中的资源生成可观测性数据。源账户与监控账户共享其可观测性数据。因此,您可以使用所有关联账户的日志组设置来自监控账户的预定查询。

查询跨区域日志组

您的预定查询可以访问任何区域的日志组。使用其完整 ARN 格式指定日志组:arn:aws:logs:region:account-id:log-group:log-group-name。所有目标区域中日志组的查询执行角色需要logs:StartQuerylogs:GetQueryResults权限。

重要

在查询日志组或跨区域交付结果时,日志数据会跨越区域边界。请考虑以下事项:

  • 数据驻留要求 -确保跨区域数据传输符合贵组织的数据治理政策和监管要求

  • 数据传输成本 - Cross-region 数据传输会产生额外费用

  • 网络延迟 -访问远程区域日志组的查询可能会遇到更高的延迟

为了获得最佳性能和成本效益,请在与主日志组相同的区域中创建计划查询。

替代方法:使用CloudWatch 日志集中化将来自多个账户和地区的日志数据复制到中央监控账户。这使您可以在单个区域中创建计划查询以访问所有集中日志,从而避免跨区域查询并简化 IAM 权限管理。

调度表达式和时区处理

您定义的时间表决定了查询的运行时间和执行频率。选择正确的计划表达式会影响您何时收到结果以及查询的数据量。了解表达式类型有助于您在简单性和精确性之间做出选择。

Cron 表达式可以精确控制时间,允许您指定确切的时间、一周中的几天或一月中的某天。当您需要在特定工作时间运行查询或与运营计划保持一致时,请使用 cron 表达式。在控制台中,您还可以使用简易日历选项安排查询。

Cron 表达式

在特定时间运行查询。格式:cron(minute hour day-of-month month day-of-week year)。示例:

  • cron(0 9 * * ? *)-世界标准时间每天上午 9:00

  • cron(0 18 ? * MON-FRI *)-世界标准时间工作日下午 6:00

  • cron(0 0 1 * ? *)-世界标准时间每个月的第一天午夜

  • cron(0 12 ? * SUN *)-世界标准时间每周日中午

  • cron(30 8 1 1 ? *)-世界标准时间 1 月 1 日上午 8:30

所有计划查询均以 UTC 运行,无论您的本地时区如何,也无论您的 AWS 资源位于何处。当您为工作时间或时间敏感型分析安排查询时,这一点尤其重要。例如,如果您的企业在美国东部时间运营,并且您想在美国东部时间上午 9 点提交每日报告,则需要考虑 UTC 偏移量(夏令时为 14:00 UTC,否则为 13:00 UTC)。在规划日程表达式时要牢记 UTC,确保查询在预定时间运行。

选择查询语言

计划查询支持三种不同的查询语言,您的选择会影响您编写查询的方式以及团队维护查询的难易程度。正确的语言取决于您的分析要求和团队的现有技能。

如果您主要筛选和聚合日志数据, CloudWatch Logs Insights 查询语言可提供最直接的语法。对于需要通过多个步骤重塑或丰富数据的复杂数据转换,PPL 的流水线方法使逻辑更易于理解。当您需要执行类似于数据库操作的联接或复杂聚合时,SQL 会提供熟悉的语法,数据库经验丰富的团队可以快速采用这些语法。

CloudWatch 日志见解查询语言 (CWLI)

Purpose-built 使用直观的语法进行日志分析。最适合:

  • Text-based 日志分析和过滤

  • Time-series 汇总和统计

  • 刚接触日志分析的团队

OpenSearch 服务管道处理语言 (PPL)

Pipeline-based 具有强大数据转换功能的查询语言。最适合:

  • 复杂的数据转换和充实

  • Multi-step 数据处理工作流程

  • 熟悉基于管道的处理的团队

OpenSearch 服务结构化查询语言 (SQL)

熟悉的数据库式查询的标准 SQL 语法。最适合:

  • 复杂的连接和聚合

  • 商业智能和报告

  • 具有丰富的 SQL 经验的团队

目的地选择和用例

将查询结果发送到何处决定了您可以对它们做什么。无论您是在构建长期分析、触发自动响应,还是两者兼而有之,这种选择都会影响您的整个下游工作流程。了解每种目的地类型的优势有助于您为用例设计正确的架构。

Amazon S3 目的地针对存储和批处理进行了优化。当您需要将查询结果保存数月或数年、分析一段时间内的趋势或向分析平台提供数据时,Amazon S3 可提供具有无限保留期的经济实惠的存储。 EventBridge 目的地已针对实时自动化进行了优化。当查询结果应触发即时操作(例如发送警报、启动工作流程或更新系统)时,将结果作为事件EventBridge 提供,您的应用程序可以立即做出响应。默认情况下,所有查询完成事件都会自动作为事件发送到默认事件总线,从而可以与下游处理系统、Lambda 函数或其他事件驱动架构集成。只有成功执行查询后,结果才会发布到目的地。查询表目的地经过优化,可使参考数据保持最新状态。查找表目标会在每次计划执行时使用查询结果自动填充或刷新指定的查找表,因此其他查询可以使用该命令引用最新数据。lookup

Amazon S3 目标

将查询结果存储为 JSON 文件,以便长期保留和批处理。最适合:

  • 历史分析和数据存档

  • 与数据湖和分析平台集成

  • 合规和审计要求

  • Cost-effective 存储大型结果集

EventBridge 目的地

将查询结果作为事件发送,以进行实时处理和自动化。当我们将结果存储 30 天时,您最多只能使用事件中发送的 QueryID 检索查询结果。最适合:

  • 触发对查询结果的自动响应

  • 与无服务器工作流程和 Lambda 函数集成

  • Real-time 警报和通知系统

  • Event-driven 架构和微服务

查找表目的地

在每次计划执行时自动创建或刷新包含查询结果的查找表。每次刷新都是表格内容的完全替换。最适合:

  • 在日志查询中保持lookup命令的参考数据是最新的

  • 维护源自日志数据的许可名单、拒绝名单或实体清单

  • 使用最近的活动摘要(例如活跃用户或资源列表)丰富查询

查询结果的格式和结构

对于 Amazon S3 目的地-查询结果以 JSON 格式交付,其结构与 GetQueryResults API 响应相同。让亚马逊 EventBridge 了解预定查询结果的格式有助于您设计下游处理和集成工作流程。

查询结果以 JSON 格式交付,结构如下:

{ "version": "0", "id": "be72061b-eca2-e068-a7e1-83e01d6fe807", "detail-type": "Scheduled Query Completed", "source": "aws.logs", "account": "123456789012", "time": "2025-11-18T11:31:48Z", "region": "us-east-1", "resources": [ "arn:aws:logs:us-east-1:123456789012:scheduled-query:477b4380-b098-474e-9c5e-e10a8cc2e6e7" ], "detail": { "queryId": "2038fd57-ab4f-4018-bb2f-61d363f4a004", "queryString": "fields @timestamp, @message, @logStream, @log\n| sort @timestamp desc\n| limit 10000", "logGroupIdentifiers": [ "/aws/lambda/my-function" ], "status": "Complete", "startTime": 1763465460, "statistics": { "recordsMatched": 0, "recordsScanned": 0, "estimatedRecordsSkipped": 0, "bytesScanned": 0, "estimatedBytesSkipped": 0, "logGroupsScanned": 1 } } }

关键要素包括:

  • statistics-查询性能指标包括匹配的记录、扫描的记录、处理的字节数和估计的跳过的数据

  • startTime-开始执行查询的时间(Unix 时间戳)

  • queryString-执行的实际查询

  • queryId-查询的查询 ID,使用它可以检索结果

  • logGroupIdentifiers-查询的日志组列表

  • status-查询执行状态(完成、失败等)