View a markdown version of this page

unirse - Amazon CloudWatch Logs

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

unirse

Combina los eventos de registro de un grupo de registros de origen con los eventos de otro grupo de registros o el resultado de una consulta en función de un campo coincidente.

Utilice el join comando para correlacionar los eventos de registro relacionados entre distintas fuentes, como los grupos de registros, utilizando claves comunes entre ellos, como los identificadores de solicitudes o transacciones coincidentes. IDs

Sintaxis

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

  • <right_log_group>— La fuente de datos secundaria a la que unirse.

  • <left_alias>y <right_alias> — Alias para distinguir los campos de las fuentes de datos izquierda (primaria) y derecha (secundaria).

  • where <field>— Especifica el campo utilizado como clave de combinación. El campo debe existir en ambas fuentes de datos.

  • type=<join_type>(opcional): especifica el tipo de unión. Los valores válidos son los siguientes:

    • inner(predeterminado): devuelve solo los registros coincidentes

    • left— Devuelve todos los registros de la fuente de datos principal y los registros coincidentes de la fuente de datos secundaria

Ejemplos

ejemplo Ejemplo 1: correlacionar las solicitudes de API Gateway con los registros de ejecución de Lambda

En este ejemplo, se muestra cómo unir los registros de acceso de API Gateway con los registros de funciones de Lambda para correlacionar las solicitudes entrantes con su procesamiento de backend. Esto resulta útil para solucionar problemas de flujos de end-to-end solicitudes e identificar qué invocaciones de Lambda corresponden a solicitudes 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

Esta consulta:

  1. Consulta los registros de acceso y los filtros de API Gateway para detectar errores en el servidor (estado >= 500)

  2. Se une a los registros de funciones Lambda mediante el requestId campo que aparece en ambas fuentes de registro

  3. Utiliza alias (apiylambda) para distinguir los campos de cada fuente

  4. Devuelve información combinada que muestra la latencia de la API junto con la duración de la ejecución de Lambda y el uso de memoria

  5. Ordena los resultados por latencia de la API para identificar las solicitudes más lentas

ejemplo Ejemplo 2: Realice un seguimiento de las transacciones distribuidas en los microservicios

Al depurar problemas en una arquitectura de microservicios, a menudo es necesario rastrear una transacción en varios servicios. En este ejemplo, se muestra cómo unir registros de dos servicios diferentes mediante un identificador de transacción común.

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)

Esta consulta:

  1. Comienza con los eventos de creación de pedidos desde el servicio de pedidos

  2. Utiliza left join a para incluir todos los pedidos, incluso los que no tienen registros de pago coincidentes

  3. Se une a los eventos de procesamiento de pagos mediante el transactionId campo compartido

  4. Filtra los resultados finales para mostrar solo los pedidos con pagos faltantes o con registros de pago faltantes

La combinación de la izquierda es importante en este caso porque permite ver los pedidos que se crearon pero que nunca tuvieron el evento de pago correspondiente, lo que podría indicar un fallo del sistema.

Comportamiento

  • Primero se procesa la fuente de datos principal (lado izquierdo).

  • La fuente de datos secundaria se evalúa y compara mediante la clave de unión especificada.

  • La coincidencia se realiza mediante la comparación de igualdad en el campo de unión.

  • En el caso de las uniones por la izquierda, los registros no coincidentes de la fuente de datos principal se conservan con valores nulos para los campos secundarios.

Notas y limitaciones

  • Solo se admiten las condiciones de igualdad (=).

  • Solo se admite un comando de unión por consulta.

  • Las claves de unión deben existir en ambas fuentes de datos y ser de tipos compatibles.

  • Las consultas que utilizan la combinación pueden escanear más datos e incurrir en costes más altos.

  • El número de valores clave únicos en la fuente de datos secundaria está limitado a 50 000 para garantizar el rendimiento de las consultas.

  • No se admiten las subconsultas del lado derecho de la unión.

Comandos relacionados