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 log de um grupo de log de origem com eventos de outro grupo de log ou resultado de consulta com base em um campo correspondente.

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

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 nas duas fontes de dados.

  • type=<join_type>(opcional) — Especifica o tipo de junçã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 solicitações do API Gateway com 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 end-to-end solicitações 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 do servidor (status >= 500)

  2. Une-se aos registros da função Lambda usando requestId o campo que aparece em ambas as 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 do serviço de pedidos

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

  3. Associa-se a 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 junção.

  • Para junçõ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 digitalizar 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.

  • Não há suporte para subconsultas no lado direito da junção.

Comandos relacionados