View a markdown version of this page

joindre - Amazon CloudWatch Logs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

joindre

Combine les événements de journal d'un groupe de journaux source avec les événements d'un autre groupe de journaux ou le résultat d'une requête en fonction d'un champ correspondant.

Utilisez la join commande pour corréler les événements de journal connexes provenant de différentes sources, telles que les groupes de journaux, à l'aide de clés communes, telles que des identifiants de demande ou de transaction correspondants. IDs

Syntaxe

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 source de données secondaire à laquelle se joindre.

  • <left_alias>et <right_alias> — Alias permettant de distinguer les champs des sources de données de gauche (principale) et de droite (secondaire).

  • where <field>— Spécifie le champ utilisé comme clé de jointure. Le champ doit exister dans les deux sources de données.

  • type=<join_type>(facultatif) — Spécifie le type de jointure. Les valeurs valides sont :

    • inner(par défaut) — Renvoie uniquement les enregistrements correspondants

    • left— Renvoie tous les enregistrements de la source de données principale et les enregistrements correspondants de la source de données secondaire

Exemples

Exemple Exemple 1 : Corréler les requêtes API Gateway avec les journaux d'exécution Lambda

Cet exemple montre comment associer les journaux d'accès d'API Gateway aux journaux des fonctions Lambda afin de corréler les demandes entrantes avec leur traitement principal. Cela est utile pour résoudre les problèmes liés aux flux de end-to-end demandes et identifier les invocations Lambda qui correspondent à des demandes d'API spécifiques.

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

Cette requête :

  1. Interroge les journaux d'accès et les filtres d'API Gateway pour détecter les erreurs du serveur (état >= 500)

  2. Se joint aux journaux de fonctions Lambda en utilisant le requestId champ qui apparaît dans les deux sources de journaux

  3. Utilise des alias (apietlambda) pour distinguer les champs de chaque source

  4. Renvoie des informations combinées indiquant la latence de l'API, la durée d'exécution de Lambda et l'utilisation de la mémoire

  5. Trie les résultats en fonction de la latence de l'API pour identifier les requêtes les plus lentes

Exemple Exemple 2 : suivre les transactions distribuées sur des microservices

Lorsque vous corrigez des problèmes dans une architecture de microservices, vous devez souvent suivre une transaction sur plusieurs services. Cet exemple montre comment joindre les journaux de deux services différents à l'aide d'un identifiant de transaction commun.

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)

Cette requête :

  1. Commence par les événements de création de commandes depuis le service de commande

  2. Utilise un left join pour inclure toutes les commandes, même celles dont les enregistrements de paiement ne correspondent pas

  3. Se joint aux événements de traitement des paiements à l'aide du transactionId champ partagé

  4. Filtre les résultats finaux pour n'afficher que les commandes dont le paiement a échoué ou dont les enregistrements de paiement sont manquants

La jointure gauche est importante à cet égard, car elle vous permet de voir les commandes créées mais qui n'ont jamais connu d'événement de paiement correspondant, ce qui pourrait indiquer une défaillance du système.

Comportement

  • La source de données principale (côté gauche) est traitée en premier.

  • La source de données secondaire est évaluée et mise en correspondance à l'aide de la clé de jointure spécifiée.

  • La mise en correspondance est effectuée à l'aide d'une comparaison d'égalité dans le champ de jointure.

  • Pour les jointures gauches, les enregistrements sans correspondance de la source de données principale sont conservés avec des valeurs nulles pour les champs secondaires.

Remarques et limitations

  • Seules les conditions d'égalité (=) sont prises en charge.

  • Une seule commande de jointure est prise en charge par requête.

  • Les clés de jointure doivent exister dans les deux sources de données et être de types compatibles.

  • Les requêtes utilisant la jointure peuvent analyser davantage de données et entraîner des coûts plus élevés.

  • Le nombre de valeurs clés uniques dans la source de données secondaire est limité à 50 000 afin de garantir les performances des requêtes.

  • Les sous-requêtes situées sur le côté droit de la jointure ne sont pas prises en charge.

Commandes connexes