View a markdown version of this page

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

subqueries

Una sottoquery è una query annidata di Logs Insights che può essere utilizzata come input per un'altra query. Le sottoquery possono essere utilizzate per derivare set di risultati intermedi che vengono poi utilizzati dai comandi successivi.

Sintassi

Sottoquery nel filtro

filter <field> in (
    <subquery>
)
Parameters

  • <subquery>— Una query Logs Insights valida che restituisce un set di risultati. La sottoquery deve produrre campi a cui fa riferimento la query esterna.

Esempi

Esempio Esempio 1: trova le richieste che hanno riscontrato errori nei servizi a valle

Questo esempio mostra come utilizzare una sottoquery per identificare le richieste nel servizio principale che hanno provocato errori in un servizio a valle. Ciò è utile per la risoluzione dei problemi a catena nei sistemi distribuiti.

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

Questa interrogazione:

  1. La sottoquery trova tutti i requestId valori del servizio di database che ha subito dei timeout di connessione

  2. La query esterna filtra i log del servizio principale per mostrare solo le richieste che corrispondono a quelle richieste soggette a errori IDs

  3. I risultati mostrano il contesto completo delle richieste non riuscite a valle, inclusi gli endpoint e gli utenti interessati

Questo modello consente di comprendere l'impatto a monte dei guasti a valle.

Esempio Esempio 2: Identifica le richieste di indagini mirate che spesso non vanno a buon fine

Questo esempio dimostra l'utilizzo di una sottoquery con aggregazione per trovare le richieste che falliscono ripetutamente, il che spesso indica problemi sistematici anziché errori transitori.

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

Questa interrogazione:

  1. La sottoquery aggrega i tentativi di pagamento non riusciti e identifica le richieste IDs che hanno avuto esito negativo più di 3 volte

  2. La query esterna recupera tutti gli eventi di registro per quelle richieste problematiche IDs

  3. I risultati vengono ordinati cronologicamente per mostrare la progressione dei tentativi di nuovo tentativo

Questo aiuta a distinguere tra errori transitori (singola occorrenza) e problemi persistenti (errori multipli) che richiedono un'indagine più approfondita.

Comportamento

  • Le sottoquery vengono eseguite indipendentemente dalla query esterna.

  • I risultati vengono materializzati prima di essere utilizzati dalla query esterna.

  • Solo i campi selezionati in modo esplicito nella sottoquery sono disponibili per la query esterna.

Note e limitazioni

  • Le sottoquery devono restituire i campi a cui fa riferimento la query esterna.

  • Le sottoquery annidate non sono supportate.

  • Le sottoquery possono aumentare i tempi e i costi di esecuzione delle query.

  • Le sottoquery correlate non sono supportate.

  • L'esecuzione della query interna è limitata a 30 secondi.

Comandi correlati