View a markdown version of this page

Entendendo os conceitos de consultas agendadas - CloudWatch Registros da Amazon

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Entendendo os conceitos de consultas agendadas

Antes de criar consultas agendadas, entenda esses conceitos-chave que afetam a forma como suas consultas são executadas e onde os resultados são entregues.

Separação de funções do IAM

As consultas agendadas exigem duas funções separadas do IAM: uma para executar consultas e outra para entregar resultados a destinos como buckets do Amazon S3, barramentos de EventBridge eventos da Amazon ou tabelas de pesquisa. Entender por que essa separação existe ajuda você a configurar as permissões corretamente e a usar os benefícios operacionais e de segurança que ela oferece.

A arquitetura de duas funções divide as responsabilidades entre acesso e entrega de dados. A função de execução de consultas acessa seus dados de log e executa consultas, enquanto a função de entrega de destino grava os resultados no destino escolhido. Essa separação segue o princípio do menor privilégio — cada função tem somente as permissões necessárias para sua função específica.

Função de execução da consulta

Permite que o CloudWatch CloudWatch Logs execute consultas do Logs Insights em seu nome. Essa função precisa de permissões para acessar seus grupos de registros e executar consultas, mas não precisa acessar os recursos de destino. Permissões obrigatórias:

  • logs:StartQuery

  • logs:StopQuery

  • logs:GetQueryResults

  • logs:DescribeLogGroups

  • logs:Unmaskse for necessário desmascarar dados

Para grupos de KMS-encrypted registros: kms:Decrypt e kms:DescribeKey permissões para a chave KMS usada para criptografar os grupos de registros. Essas permissões também precisam ser adicionadas.

Requisito de relacionamento de confiança: a função de execução da consulta deve incluir uma política de confiança que permita que o serviço CloudWatch Logs (logs.amazonaws.com) assuma a função. Sem essa relação de confiança, as consultas agendadas falharão com erros de permissão.

Exemplo de política de confiança para a função de execução da consulta:

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

Exemplo de política de permissões para a função de execução da consulta:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults", "logs:DescribeLogGroups" ], "Resource": "*" } ] }
Função de entrega no destino

Permite que CloudWatch os registros entreguem os resultados da consulta ao destino escolhido. Essa função só precisa de permissões para o serviço de destino específico, seguindo o princípio do menor privilégio. As permissões necessárias variam de acordo com o tipo de destino.

Requisito de relacionamento de confiança: a função de entrega de destino também deve incluir uma política de confiança que permita que o serviço CloudWatch Logs (logs.amazonaws.com) assuma a função.

Exemplo de política de permissões para a função de entrega de destino do S3:

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

Exemplo de política de permissões para uma função de entrega de destino da tabela de pesquisa:

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

Essa separação oferece benefícios práticos para suas operações. Do ponto de vista da segurança, se você precisar alterar o local onde os resultados são entregues, modifique apenas a função de entrega de destino sem alterar as permissões de execução da consulta. Para fins de conformidade e auditoria, você pode rastrear claramente qual função acessa dados de registro confidenciais e qual função grava em sistemas externos. Isso facilita a demonstração de que sua infraestrutura de análise de registros segue as melhores práticas de segurança.

Cross-region e uso entre contas

Uma consulta agendada é criada em uma região específica e executada nessa região. No entanto, você pode consultar grupos de registros e fornecer resultados em todas as regiões e contas. Você precisa configurar uma ou mais AWS contas como contas de monitoramento e vinculá-las a várias contas de origem. Uma conta de monitoramento é uma AWS conta central que pode visualizar e interagir com os dados de observabilidade gerados pelas contas de origem. Uma conta de origem é uma AWS conta individual que gera dados de observabilidade para os recursos que residem nela. As contas de origem compartilham os dados de observabilidade com a conta de monitoramento. Assim, você pode configurar consultas agendadas a partir da conta de monitoramento usando os grupos de log de todas as contas vinculadas.

Consultando grupos de registros entre regiões

Sua consulta agendada pode acessar grupos de registros em qualquer região. Especifique grupos de log usando seu formato ARN completo:arn:aws:logs:region:account-id:log-group:log-group-name. As necessidades logs:StartQuery e logs:GetQueryResults permissões da função de execução da consulta para grupos de registros em todas as regiões de destino.

Importante

Ao consultar grupos de registros ou fornecer resultados entre regiões, os dados de registro ultrapassam os limites regionais. Considere o seguinte:

  • Requisitos de residência de dados - Garanta que a transferência de dados entre regiões esteja em conformidade com as políticas de governança de dados e os requisitos normativos da sua organização

  • Custos de transferência de Cross-region dados - a transferência de dados incorre em custos adicionais

  • Latência de rede - as consultas que acessam grupos de log em regiões distantes podem apresentar maior latência

Para otimizar o desempenho e a economia, crie consultas agendadas na mesma região dos seus grupos de registros primários.

Abordagem alternativa: use a centralização de CloudWatch registros para replicar dados de registro de várias contas e regiões em uma conta de monitoramento central. Isso permite que você crie consultas agendadas em uma única região que acesse todos os seus registros centralizados, evitando consultas entre regiões e simplificando o gerenciamento de permissões do IAM.

Expressões de cronograma e tratamento de fuso horário

A programação que você define determina quando sua consulta é executada e com que frequência ela é executada. Escolher a expressão de agendamento correta afeta o momento em que você recebe os resultados e a quantidade de dados que consulta. Compreender os tipos de expressão ajuda você a escolher entre simplicidade e precisão.

As expressões Cron fornecem controle preciso sobre o tempo, permitindo que você especifique horários, dias da semana ou dias do mês exatos. Use expressões cron quando precisar que as consultas sejam executadas em horários comerciais específicos ou se alinhem aos cronogramas operacionais. No console, você também pode agendar consultas usando opções fáceis de calendário.

Expressão cron

Execute consultas em horários específicos. Formato: cron(minute hour day-of-month month day-of-week year). Exemplos:

  • cron(0 9 * * ? *)- Todos os dias às 9:00 UTC

  • cron(0 18 ? * MON-FRI *)- Dias úteis às 18:00 UTC

  • cron(0 0 1 * ? *)- Primeiro dia de cada mês à meia-noite UTC

  • cron(0 12 ? * SUN *)- Todos os domingos ao meio-dia UTC

  • cron(30 8 1 1 ? *)- 1º de janeiro às 8:30 UTC

Todas as consultas agendadas são executadas em UTC, independentemente do fuso horário local ou da localização AWS dos recursos. Isso é particularmente importante quando você agenda consultas para horários comerciais ou análises urgentes. Por exemplo, se sua empresa opera no horário do leste dos EUA e você quer um relatório diário às 9h ET, você precisa considerar a diferença UTC (14:00 UTC durante o horário de verão, 13:00 UTC caso contrário). Planeje suas expressões de agendamento com o UTC em mente para garantir que as consultas sejam executadas nos horários pretendidos.

Escolhendo um idioma de consulta

As consultas agendadas suportam três linguagens de consulta diferentes, e sua escolha afeta a forma como você escreve as consultas e a facilidade com que sua equipe pode mantê-las. O idioma certo depende dos seus requisitos de análise e das habilidades existentes da sua equipe.

Se você está principalmente filtrando e agregando dados de log, a Linguagem de Consulta do CloudWatch Logs Insights oferece a sintaxe mais direta. Para transformações de dados complexas em que você precisa remodelar ou enriquecer dados em várias etapas, a abordagem de pipeline da PPL facilita o acompanhamento da lógica. Quando você precisa realizar uniões ou agregações complexas semelhantes às operações de banco de dados, o SQL fornece uma sintaxe familiar que equipes experientes em bancos de dados podem adotar rapidamente.

CloudWatch Linguagem de consulta do Logs Insights (CWLI)

Purpose-built para análise de registros com sintaxe intuitiva. Ideal para:

  • Text-based análise e filtragem de registros

  • Time-series agregações e estatísticas

  • Equipes novas na análise de registros

OpenSearch Linguagem de processamento por tubulação de serviço (PPL)

Pipeline-based linguagem de consulta com poderosos recursos de transformação de dados. Ideal para:

  • Enriquecimento e transformações de dados complexos

  • Multi-step fluxos de trabalho de processamento de dados

  • Equipes familiarizadas com o processamento baseado em pipeline

OpenSearch Linguagem de consulta estruturada de serviços (SQL)

Sintaxe SQL padrão para consultas familiares em estilo de banco de dados. Ideal para:

  • Junções e agregações complexas

  • Inteligência de negócios e relatórios

  • Equipes com forte experiência em SQL

Seleção de destinos e casos de uso

O local onde você envia os resultados da consulta determina o que você pode fazer com eles. Essa escolha molda todo o seu fluxo de trabalho posterior, esteja você criando análises de longo prazo, acionando respostas automatizadas ou ambos. Entender os pontos fortes de cada tipo de destino ajuda você a projetar a arquitetura certa para seu caso de uso.

Os destinos do Amazon S3 são otimizados para armazenamento e processamento em lote. Quando você precisa manter os resultados das consultas por meses ou anos, analisar tendências ao longo do tempo ou inserir dados em plataformas de análise, o Amazon S3 fornece armazenamento econômico com retenção ilimitada. EventBridge os destinos são otimizados para automação em tempo real. Quando os resultados da consulta devem acionar ações imediatas, como enviar alertas, iniciar fluxos de trabalho ou atualizar sistemas, os resultados EventBridge são apresentados como eventos aos quais seus aplicativos podem responder instantaneamente. Por padrão, todos os eventos de conclusão de consultas são enviados automaticamente como eventos para o barramento de eventos padrão, permitindo a integração com sistemas de processamento downstream, funções do Lambda ou outras arquiteturas orientadas por eventos. Os resultados só são publicados nos destinos quando a consulta é executada com êxito. Os destinos da tabela de pesquisa são otimizados para manter os dados de referência atualizados. O destino da tabela de pesquisa preenche ou atualiza automaticamente a tabela de pesquisa especificada com os resultados da consulta em cada execução agendada, para que outras consultas possam referenciar os dados mais recentes com o comando. lookup

Destinos do Amazon S3

Armazene os resultados da consulta como arquivos JSON para retenção a longo prazo e processamento em lote. Ideal para:

  • Análise histórica e arquivamento de dados

  • Integração com data lakes e plataformas de análise

  • Requisitos de conformidade e auditoria

  • Cost-effective armazenamento de grandes conjuntos de resultados

EventBridge destinos

Envie resultados de consultas como eventos para processamento e automação em tempo real. Você pode recuperar os resultados da consulta usando o QueryID enviado no evento por até 30 dias, pois armazenamos os resultados por 30 dias. Ideal para:

  • Acionando respostas automatizadas aos resultados da consulta

  • Integração com fluxos de trabalho sem servidor e funções do Lambda

  • Real-time sistemas de alerta e notificação

  • Event-driven arquiteturas e microsserviços

Destinos da tabela de pesquisa

Crie ou atualize automaticamente uma tabela de pesquisa com os resultados da consulta em cada execução agendada. Cada atualização é uma substituição completa do conteúdo da tabela. Ideal para:

  • Manter os dados de referência atualizados para o lookup comando em suas consultas de log

  • Manutenção de listas de permissões, listas de negação ou inventários de entidades derivados de dados de registro

  • Enriquecer consultas com resumos de atividades recentes, como listas ativas de usuários ou recursos

Formato e estrutura do resultado da consulta

Para destinos do Amazon S3, os resultados da consulta são entregues no formato JSON com a mesma estrutura da resposta da GetQueryResults API. Para a Amazon, EventBridge entender o formato dos resultados da consulta agendada ajuda você a projetar fluxos de trabalho de processamento e integração posteriores.

Os resultados da consulta são entregues no formato JSON com a seguinte estrutura:

{ "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 } } }

Os principais elementos incluem:

  • statistics- Métricas de desempenho de consultas, incluindo registros correspondidos, digitalizados, bytes processados e dados estimados ignorados

  • startTime- Quando a execução da consulta começou (timestamp Unix)

  • queryString- A consulta real que foi executada

  • queryId- ID de consulta da consulta usando o qual os resultados podem ser recuperados

  • logGroupIdentifiers- Lista de grupos de registros que foram consultados

  • status- Status de execução da consulta (Concluída, Falha etc.)