View a markdown version of this page

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

subqueries

Une sous-requête est une requête Logs Insights imbriquée qui peut être utilisée comme entrée dans une autre requête. Les sous-requêtes peuvent être utilisées pour obtenir des ensembles de résultats intermédiaires qui sont ensuite consommés par les commandes suivantes.

Syntaxe

Sous-requête dans le filtre

filter <field> in (
    <subquery>
)
Parameters

  • <subquery>— Requête Logs Insights valide qui renvoie un jeu de résultats. La sous-requête doit produire des champs référencés par la requête externe.

Exemples

Exemple Exemple 1 : Rechercher les demandes qui ont rencontré des erreurs dans les services en aval

Cet exemple montre comment utiliser une sous-requête pour identifier les demandes de votre service principal qui ont entraîné des erreurs dans un service en aval. Ceci est utile pour résoudre les défaillances en cascade dans les systèmes distribués.

filter requestId in (
    SOURCE '/aws/lambda/database-service'
    | filter errorType = "DatabaseConnectionTimeout"
    | fields requestId
)
| fields @timestamp, requestId, endpoint, userId, responseTime
| sort @timestamp desc

Cette requête :

  1. La sous-requête trouve toutes les requestId valeurs du service de base de données qui a connu des délais de connexion

  2. La requête externe filtre les journaux de votre service principal pour n'afficher que les demandes qui correspondent à ces ID de demande sujets aux erreurs

  3. Les résultats montrent le contexte complet des demandes qui ont échoué en aval, y compris les terminaux et les utilisateurs concernés

Ce modèle vous permet de comprendre l'impact en amont des défaillances en aval.

Exemple Exemple 2 : Identifier les demandes d'investigation ciblée qui échouent fréquemment

Cet exemple montre comment utiliser une sous-requête avec agrégation pour rechercher les demandes qui échouent de manière répétée, ce qui indique souvent des problèmes systématiques plutôt que des erreurs transitoires.

filter requestId in (
    SOURCE '/aws/lambda/payment-processor'
    | filter status = "FAILED"
    | stats count(*) as failureCount by requestId
    | filter failureCount > 3
    | fields requestId
)
| fields @timestamp, requestId, customerId, amount, failureReason
| sort @timestamp asc

Cette requête :

  1. La sous-requête regroupe les tentatives de paiement ayant échoué et identifie les identifiants de demande qui ont échoué plus de 3 fois

  2. La requête externe récupère tous les événements du journal pour ces ID de demande problématiques

  3. Les résultats sont triés par ordre chronologique pour montrer la progression des nouvelles tentatives

Cela permet de faire la distinction entre les défaillances transitoires (occurrence unique) et les problèmes persistants (défaillances multiples) qui nécessitent une investigation plus approfondie.

Comportement

  • Les sous-requêtes sont exécutées indépendamment de la requête externe.

  • Les résultats sont matérialisés avant d'être consommés par la requête externe.

  • Seuls les champs explicitement sélectionnés dans la sous-requête sont disponibles pour la requête externe.

Remarques et limitations

  • Les sous-requêtes doivent renvoyer des champs référencés par la requête externe.

  • Les sous-requêtes imbriquées ne sont pas prises en charge.

  • Les sous-requêtes peuvent augmenter le temps et le coût d'exécution des requêtes.

  • Les sous-requêtes corrélées ne sont pas prises en charge.

  • L'exécution des requêtes internes est limitée à 30 secondes.

Commandes connexes