View a markdown version of this page

ingressar - 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á.

ingressar

Combina eventos de registro de um grupo de registros de origem com eventos de outro grupo de registros ou resultado de consulta com base em um campo correspondente.

Use o join comando para correlacionar eventos de registro relacionados em diferentes fontes, como grupos de registros, usando chaves comuns entre eles, como identificadores de solicitação ou IDs de transação correspondentes.

Sintaxe

join type=<join_type> left=<left_alias> right=<right_alias> 
    where <left_alias>.<field>=<right_alias>.<field> 
    (SOURCE <right_log_group>)
Parâmetros

  • <right_log_group>— A fonte de dados secundária à qual se juntar.

  • <left_alias>e <right_alias> — Aliases para distinguir campos das fontes de dados esquerda (primária) e direita (secundária).

  • where <field>— Especifica o campo usado como chave de junção. O campo deve existir em ambas as fontes de dados.

  • type=<join_type>(opcional) — Especifica o tipo de união. Os valores válidos são:

    • inner(padrão) — Retorna somente registros correspondentes

    • left— Retorna todos os registros da fonte de dados primária e os registros correspondentes da fonte de dados secundária

Exemplos

exemplo Exemplo 1: correlacionar as solicitações do API Gateway com os registros de execução do Lambda

Este exemplo mostra como unir os registros de acesso do API Gateway aos registros de funções do Lambda para correlacionar as solicitações recebidas com o processamento de back-end. Isso é útil para solucionar problemas de fluxos de solicitação de ponta a ponta e identificar quais invocações do Lambda correspondem a solicitações de API específicas.

filter status >= 500
| join type=inner left=api right=lambda 
    where api.requestId=lambda.requestId 
    (SOURCE '/aws/lambda/my-function')
| fields api.requestId, api.status, api.latency, lambda.duration, lambda.memoryUsed
| sort api.latency desc

Essa consulta:

  1. Consulta registros de acesso e filtros do API Gateway em busca de erros no servidor (status >= 500)

  2. Une-se aos registros de funções do Lambda usando o requestId campo que aparece nas duas fontes de registro

  3. Usa aliases (apielambda) para distinguir campos de cada fonte

  4. Retorna informações combinadas que mostram a latência da API junto com a duração da execução do Lambda e o uso da memória

  5. Classifica os resultados por latência da API para identificar as solicitações mais lentas

exemplo Exemplo 2: Rastreie transações distribuídas em microsserviços

Ao depurar problemas em uma arquitetura de microsserviços, você geralmente precisa rastrear uma transação em vários serviços. Este exemplo mostra como unir registros de dois serviços diferentes usando um ID de transação comum.

filter eventType = "ORDER_CREATED"
| join type=left left=order right=payment 
    where order.transactionId=payment.transactionId 
    (SOURCE '/aws/lambda/payment-service')
| filter payment.eventType = "PAYMENT_PROCESSED" or !ispresent(payment.eventType)
| fields order.transactionId, order.orderId, order.customerId, 
    payment.paymentStatus, payment.amount
| filter payment.paymentStatus != "SUCCESS" or !ispresent(payment.paymentStatus)

Essa consulta:

  1. Começa com eventos de criação de pedidos a partir do serviço de pedidos

  2. Usa a left join para incluir todos os pedidos, mesmo aqueles sem registros de pagamento correspondentes

  3. Ingressa em eventos de processamento de pagamentos usando o campo compartilhado transactionId

  4. Filtra os resultados finais para mostrar somente pedidos com pagamentos falhados ou registros de pagamento ausentes

A junção à esquerda é importante aqui porque garante que você veja pedidos que foram criados, mas nunca tiveram um evento de pagamento correspondente, o que pode indicar uma falha no sistema.

Comportamento

  • A fonte de dados primária (lado esquerdo) é processada primeiro.

  • A fonte de dados secundária é avaliada e combinada usando a chave de junção especificada.

  • A correspondência é realizada usando a comparação de igualdade no campo de união.

  • Para uniões à esquerda, registros incomparáveis da fonte de dados primária são mantidos com valores nulos para campos secundários.

Observações e limitações

  • Somente condições de igualdade (=) são suportadas.

  • Somente um comando de junção é suportado por consulta.

  • As chaves de junção devem existir em ambas as fontes de dados e ser de tipos compatíveis.

  • As consultas usando join podem escanear mais dados e gerar custos mais altos.

  • O número de valores-chave exclusivos na fonte de dados secundária é limitado a 50.000 para garantir o desempenho da consulta.

  • As subconsultas no lado direito da junção não são suportadas.

Comandos relacionados