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 Logs Insights annidata che può essere utilizzata come input per un'altra query. Le sottoquery possono essere utilizzate per ricavare 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 downstream. Ciò è utile per la risoluzione dei problemi a cascata 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 hanno subito dei timeout di connessione

  2. La query esterna filtra i log del servizio principale per mostrare solo le richieste che corrispondono agli ID di richiesta soggetti a errori

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

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

Esempio Esempio 2: Identifica le richieste che spesso non vanno a buon fine per un'indagine mirata

Questo esempio dimostra l'utilizzo di una sottoquery con aggregazione per trovare le richieste che falliscono ripetutamente, il che spesso indica problemi sistematici piuttosto che 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 falliti e identifica gli ID delle richieste fallite più di 3 volte

  2. La query esterna recupera tutti gli eventi di registro per gli ID di richiesta problematici

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

Ciò consente di distinguere tra errori transitori (eventi singoli) e problemi persistenti (errori multipli) che richiedono un'indagine più approfondita.

Comportamento

  • Le sottoquery vengono eseguite indipendentemente dall'interrogazione esterna.

  • I risultati vengono materializzati prima di essere utilizzati dall'interrogazione esterna.

  • Solo i campi selezionati in modo esplicito nella sottoquery sono disponibili per l'interrogazione 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