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 di una query in base a un campo corrispondente.

Utilizzate 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 la corrispondenza degli identificatori di richiesta o della transazione IDs.

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 unirsi.

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

  • where <field>— specifica il campo utilizzato come chiave di unione. Il campo deve esistere in entrambe le fonti di 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 dall'origine dati principale e i record corrispondenti dall'origine dati secondaria

Esempi

Esempio Esempio 1: correlazione delle richieste API Gateway con i log di esecuzione 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 loro elaborazione in backend. Ciò è utile per la risoluzione dei problemi dei flussi di end-to-end richieste e per identificare quali chiamate 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 interrogazione:

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

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

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

  4. Restituisce informazioni combinate che mostrano la latenza dell'API insieme alla durata dell'esecuzione 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: monitora le transazioni distribuite tra microservizi

Quando si eseguono il debug di problemi in un'architettura di microservizi, spesso è necessario tracciare una transazione su 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. Partecipa 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 record di pagamento mancanti

L'unione a sinistra è importante in questo caso perché consente di visualizzare gli ordini che sono stati creati ma che non hanno mai avuto un evento di pagamento corrispondente, il che potrebbe indicare un errore di sistema.

Comportamento

  • La fonte di dati principale (lato sinistro) viene elaborata per prima.

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

  • La corrispondenza viene eseguita utilizzando il confronto delle uguaglianze nel campo di unione.

  • Per i left join, i record non corrispondenti dell'origine dati primaria vengono conservati 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 fonti di dati ed essere di tipi compatibili.

  • 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 di join non sono supportate.

Comandi correlati