View a markdown version of this page

join - CloudWatch Registri Amazon

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

join

Combina gli eventi di registro di un gruppo di log di origine con gli eventi di un altro gruppo di log o il risultato della query in base a un campo corrispondente.

Usa il join comando per correlare gli eventi di registro correlati tra diverse fonti, ad esempio i gruppi di log, utilizzando chiavi comuni tra loro, come gli identificatori di richiesta corrispondenti o gli ID delle transazioni.

Sintassi

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 fonte di dati secondaria a cui partecipare.

  • <left_alias>e <right_alias> — Alias per distinguere i campi dalle origini dati sinistra (primaria) e destra (secondaria).

  • where <field>— Specifica il campo utilizzato come chiave di unione. Il campo deve esistere in entrambe le origini dati.

  • type=<join_type>(opzionale): specifica il tipo di join. I valori validi sono:

    • inner(impostazione predefinita): restituisce solo i record corrispondenti

    • left— Restituisce tutti i record dell'origine dati primaria e i record corrispondenti dell'origine dati secondaria

Esempi

Esempio Esempio 1: correlazione delle richieste API Gateway con i log di esecuzione di Lambda

Questo esempio mostra come unire i log di accesso di API Gateway con i log delle funzioni Lambda per correlare le richieste in entrata con la relativa elaborazione backend. Ciò è utile per risolvere i problemi dei flussi di richieste end-to-end e identificare quali invocazioni Lambda corrispondono a richieste API specifiche.

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

Questa query:

  1. Interroga i log di accesso e i filtri di API Gateway per individuare eventuali errori del server (stato >= 500)

  2. Si unisce ai log delle funzioni Lambda utilizzando il requestId campo che appare in entrambe le sorgenti di log

  3. Utilizza alias (apielambda) per distinguere i campi da ciascuna fonte

  4. Restituisce informazioni combinate che mostrano la latenza dell'API insieme alla durata dell'esecuzione di Lambda e all'utilizzo della memoria

  5. Ordina i risultati in base alla latenza dell'API per identificare le richieste più lente

Esempio Esempio 2: traccia le transazioni distribuite tra i microservizi

Quando si esegue il debug di problemi in un'architettura di microservizi, spesso è necessario tracciare una transazione tra più servizi. Questo esempio mostra come unire i log di due servizi diversi utilizzando un ID di transazione comune.

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)

Questa interrogazione:

  1. Inizia con gli eventi di creazione degli ordini dal servizio ordini

  2. Utilizza left join a per includere tutti gli ordini, anche quelli senza record di pagamento corrispondenti

  3. Si unisce agli eventi di elaborazione dei pagamenti utilizzando il campo condiviso transactionId

  4. Filtra i risultati finali per mostrare solo gli ordini con pagamenti non riusciti o con record di pagamento mancanti

Il left join è importante in questo caso perché consente di visualizzare gli ordini creati ma che non hanno mai avuto un evento di pagamento corrispondente, il che potrebbe indicare un errore del sistema.

Comportamento

  • L'origine dati primaria (lato sinistro) viene elaborata per prima.

  • L'origine dati secondaria viene valutata e confrontata utilizzando la chiave di join specificata.

  • La corrispondenza viene eseguita utilizzando il confronto di uguaglianza nel campo join.

  • Per i left join, i record non corrispondenti dell'origine dati primaria vengono mantenuti con valori nulli per i campi secondari.

Note e limitazioni

  • Sono supportate solo le condizioni di uguaglianza (=).

  • È supportato un solo comando join per query.

  • Le chiavi di join devono esistere in entrambe le origini dati ed essere di tipo compatibile.

  • Le query che utilizzano join possono scansionare più dati e comportare costi più elevati.

  • Il numero di valori chiave univoci nell'origine dati secondaria è limitato a 50.000 per garantire le prestazioni delle query.

  • Le sottoquery sul lato destro del join non sono supportate.

Comandi correlati