subqueries

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

Syntaxe

Sous-requête dans le filtre

filter <field> in (
    <subquery>
)

Parameters

• <subquery>— Une 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 ayant rencontré des erreurs dans les services en aval

Cet exemple montre comment utiliser une sous-requête pour identifier les demandes dans votre service principal qui ont entraîné des erreurs dans un service en aval. Cela 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 dont le délai de connexion a expiré

2. La requête externe filtre les journaux de votre service principal pour afficher uniquement les demandes qui correspondent à ces demandes sujettes aux erreurs IDs

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

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

Exemple Exemple 2 : Identifier les demandes d'enquête ciblée qui échouent fréquemment

Cet exemple montre comment utiliser une sous-requête avec agrégation pour détecter 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 infructueuses et identifie les demandes IDs qui ont échoué plus de 3 fois

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

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

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

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 les 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 de la requête interne est limitée à 30 secondes.

Commandes connexes

• champs

• filtre

• analyser

• statistiques

• trier

• limit