View a markdown version of this page

joindre - CloudWatch Journaux Amazon

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 associés à différentes sources, comme les groupes de journaux, à l'aide de clés communes, telles que les identifiants de demande ou les ID de transaction correspondants.

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>— Source de données secondaire à laquelle vous pouvez vous connecter.

  • <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 joindre 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 dépanner les flux de requêtes de bout en bout et identifier les appels Lambda qui correspondent à des requêtes 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 à API Gateway et filtre les erreurs de serveur (état >= 500)

  2. Se connecte aux journaux de la fonction Lambda à l'aide du 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 ainsi que 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 les microservices

Lorsque vous déboguez 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 ID 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 commande 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 pour lesquelles des paiements ont échoué ou des enregistrements de paiement manquants

La jointure gauche est importante ici car elle vous permet de voir les commandes qui ont été créées mais qui n'ont jamais eu 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.

  • L'appariement est effectué à l'aide d'une comparaison d'égalité dans le champ de jointure.

  • Pour les jointures gauches, les enregistrements sans correspondance provenant 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 scanner 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 pour garantir les performances des requêtes.

  • Les sous-requêtes situées à droite de la jointure ne sont pas prises en charge.

Commandes connexes