View a markdown version of this page

unirse - CloudWatch Registros de Amazon

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 diferentes fuentes, como los grupos de registros, mediante claves comunes entre ellos, como los identificadores de solicitud o los ID de transacción coincidentes.

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 (principal) y derecha (secundaria).

  • where <field>— Especifica el campo utilizado como clave de unió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: correlacione 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 fondo. Esto resulta útil para solucionar problemas relacionados con los flujos de solicitudes de extremo a extremo 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 a API Gateway y filtra los errores del servidor (estado >= 500)

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

  3. Usa 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 entre 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 los 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 a left join para incluir todos los pedidos, incluso aquellos sin 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 fallidos o con registros de pago faltantes

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

Comportamiento

  • La fuente de datos principal (lado izquierdo) se procesa primero.

  • 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 Join pueden escanear más datos e incurrir en costos 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