Risoluzione dei problemi di un canary fallito

Se il canary fallisce, procedi come descritto di seguito per la risoluzione dei problemi.

Risoluzione dei problemi generali

Il canary presenta problemi dopo l'aggiornamento dell'ambiente Lambda

I canary CloudWatch Synthetics sono implementati come funzioni Lambda nel tuo account. Queste funzioni Lambda sono soggette a regolari aggiornamenti del runtime Lambda contenenti aggiornamenti di sicurezza, correzioni di bug e altri miglioramenti. Lambda fornisce aggiornamenti di runtime compatibili con le versioni precedenti delle funzioni esistenti. Tuttavia, come nel caso delle patch software, ci sono rari casi in cui un aggiornamento del runtime può influire negativamente su una funzione esistente. Se ritieni che il tuo canary sia stato penalizzato da un aggiornamento del runtime Lambda, puoi utilizzare la modalità manuale di gestione del runtime Lambda (nelle regioni supportate) per eseguire temporaneamente il rollback della versione del runtime Lambda. Ciò mantiene il canary funzionante e riduce al minimo le interruzioni, dando il tempo necessario per porre rimedio all'incompatibilità prima di tornare alla versione di runtime più recente.

Se il tuo canary non funziona dopo un aggiornamento del runtime Lambda, la soluzione migliore è eseguire l'aggiornamento a uno dei runtime Synthetics più recenti. Per ulteriori informazioni sui runtime più recenti, consulta Versioni di runtime Synthetics.

Come soluzione alternativa, nelle regioni in cui sono disponibili i controlli di gestione del runtime Lambda, puoi ripristinare un canary a un vecchio runtime gestito da Lambda, utilizzando la modalità manuale per i controlli di gestione del runtime. Puoi impostare la modalità manuale utilizzando la AWS CLI o la console Lambda, seguendo i passaggi riportati più avanti nelle sezioni di seguito.

Prerequisiti

Passaggio 1: ottieni l'ARN della funzione Lambda

Esegui il comando seguente per recuperare il campo EngineArn dalla risposta. Questo EngineArn è l'ARN della funzione Lambda associata al canary. Utilizzerai questo ARN nei passaggi successivi.

aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'

Output di esempio di EngingArn:

"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"

Passaggio 2: ottieni l'ARN dell'ultima versione valida del runtime Lambda

Per capire se il tuo canary è stato penalizzato da un aggiornamento del runtime Lambda, controlla se la data e l'ora in cui le modifiche all'ARN della versione del runtime Lambda nei tuoi log corrispondono alla data e all'ora in cui hai riscontrato il problema sul tuo canary. Se non corrispondono, probabilmente non è un aggiornamento del runtime Lambda a causare i problemi.

Se il tuo canary è stato penalizzato da un aggiornamento del runtime Lambda, è necessario identificare l'ARN della versione del runtime Lambda funzionante che stavi utilizzando in precedenza. Segui le istruzioni riportate in Identificazione delle modifiche alla versione di runtime per trovare l'ARN del runtime precedente. Registra l'ARN della versione di runtime e continua con il Passaggio 3 per impostare la configurazione della gestione del runtime.

Se il tuo canary non è ancora stato penalizzato da un aggiornamento dell'ambiente Lambda, puoi trovare l'ARN della versione del runtime Lambda che stai utilizzando attualmente. Esegui il comando seguente per recuperare il RuntimeVersionArn della funzione Lambda dalla risposta.

aws lambda get-function-configuration \
--function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8" | jq '.RuntimeVersionConfig.RuntimeVersionArn'

Output di esempio di RuntimeVersionArn:

"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Passaggio 3: aggiorna la configurazione di gestione del runtime Lambda

Puoi utilizzare la AWS CLI o la console Lambda per aggiornare la configurazione di gestione del runtime.

Per impostare la modalità manuale di configurazione della gestione del runtime Lambda utilizzando la AWS CLI

Inserisci il seguente comando per modificare la gestione del runtime della funzione Lambda in modalità manuale. Assicurati di sostituire il function-name e il qualifier rispettivamente con l'ARN della funzione Lambda e il numero di versione della funzione Lambda, utilizzando i valori trovati nel Passaggio 1. Sostituisci anche runtime-version-arn con la versione ARN che hai trovato nel Passaggio 2.

aws lambda put-runtime-management-config \
    --function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Il mio canary è bloccato da AWS WAF

Per consentire il passaggio del traffico del canary tramite AWS WAF, crea una condizione di corrispondenza della stringa AWS WAF che consenta una stringa personalizzata da te specificata. Per ulteriori informazioni, consulta Lavorare con le condizioni di corrispondenza delle stringhe nella documentazione AWS WAF.

Ti consigliamo vivamente di utilizzare una stringa user-agent personalizzata invece di utilizzare valori predefiniti. Ciò offre un migliore controllo sui filtri AWS WAF e migliora la sicurezza.

Per impostare una stringa user-agent personalizzata, effettua le seguenti operazioni:

Attesa della visualizzazione di un elemento

Dopo aver analizzato i log e gli screenshot, se vedi che il tuo script è in attesa che un elemento venga visualizzato sullo schermo e viene raggiunto il timeout, controlla lo screenshot pertinente per vedere se l'elemento appare nella pagina. Verifica il tuo xpath per assicurarti che sia corretto.

Per problemi relativi a Puppetteer, consulta la pagina GitHub di Puppeteer o forum su Internet.

Il nodo non è visibile oppure non è un elemento HTML per page.click()

Se un nodo non è visibile o non è un HTMLElement per page.click(), prima di tutto verifica l'xpath che stai utilizzando per fare clic sull'elemento. Inoltre, se l'elemento si trova nella parte inferiore dello schermo, regola l'area di visualizzazione. L'area di visualizzazione di default in CloudWatch Synthetics è 1920 * 1080. Puoi impostare un'area di visualizzazione diversa quando avvii il browser o utilizzando la funzione page.setViewport di Puppeteer.

Impossibile caricare artefatti su S3, Eccezione: impossibile recuperare la posizione del bucket S3: accesso negato

Se il tuo canary fallisce a causa di un errore di Amazon S3, CloudWatch Synthetics non è stato in grado di caricare screenshot, log o report creati per il canary a causa di problemi di autorizzazione. Verifica quanto segue:

Se il canary esegue il monitoraggio visivo, vedere Aggiornamento della posizione e della crittografia degli artifact quando si utilizza il monitoraggio visivo per ulteriori informazioni.

Errore: errore di protocollo (Runtime.callFunctionOn): destinazione chiusa.

Questo errore viene visualizzato se sono presenti alcune richieste di rete dopo la chiusura della pagina o del browser. Potresti aver dimenticato di attendere un'operazione asincrona. Dopo aver eseguito lo script, CloudWatch Synthetics chiude il browser. L'esecuzione di qualsiasi operazione asincrona dopo la chiusura del browser potrebbe causare un target closed error.

Canary non riuscito. Errore: nessun datapoint - Canary mostra errore di timeout

Significa che l'esecuzione del canary ha superato il timeout. L'esecuzione del canary si è arrestata prima che CloudWatch Synthetics potesse pubblicare la percentuale di successo dei parametri di CloudWatch o aggiornare artefatti ad esempio file HAR, log e screenshot. Se il timeout è troppo basso, puoi aumentarlo.

Per impostazione predefinita, un valore di timeout del canary è uguale alla sua frequenza. Puoi regolare manualmente il valore di timeout in modo che sia inferiore o uguale alla frequenza del canary. Se la frequenza del canary è bassa, è necessario aumentare la frequenza per aumentare il timeout. Puoi regolare sia la frequenza che il valore di timeout in Schedule (Pianifica) quando crei o aggiorni un canary utilizzando la console CloudWatch Synthetics.

Assicurati che il valore di timeout canary non sia inferiore a 15 secondi per consentire l'avvio a freddo Lambda e il tempo necessario per avviare la strumentazione canary.

Gli artefatti del canary non sono disponibili per la visualizzazione nella console CloudWatch Synthetics quando si verifica questo errore. Puoi utilizzare CloudWatch Logs per visualizzare i log del canary.

Tentativo di accedere a un endpoint interno

Se vuoi che il tuo canary acceda a un endpoint sulla tua rete interna, ti consigliamo di configurare CloudWatch Synthetics per l'utilizzo di VPC. Per ulteriori informazioni, consulta Esecuzione di un Canary su un VPC.

Problemi relativi all'aggiornamento e al downgrade della versione di runtime del canary

Se di recente è stato aggiornato il canary dalla versione di runtime syn-1.0 a una versione successiva, potrebbe trattarsi di un problema CORS (cross-origin resource sharing). Per ulteriori informazioni, consulta Problema CORS (Cross-Origin Request Sharing).

Se di recente è stato eseguito il downgrade del canary a una versione di runtime precedente, verifica che le funzioni CloudWatch Synthetics utilizzate siano disponibili nella versione di runtime precedente a cui è stato eseguito il downgrade. Ad esempio, la funzione executeHttpStep è disponibile per la versione di runtime syn-nodejs-2.2 e versioni successive. Per verificare la disponibilità delle funzioni, consulta Scrivere uno script canary.

Problema CORS (Cross-Origin Request Sharing)

In un canary dell'interfaccia utente, se alcune richieste di rete non vanno a buon fine con 403 o net::ERR_FAILED, verifica se il canary ha attivato il tracciamento attivo e utilizza anche la funzione page.setExtraHTTPHeaders di Puppeteer per aggiungere intestazioni. In tal caso, le richieste di rete non riuscite potrebbero essere causate da restrizioni CORS (Cross-Origin Request Sharing). Puoi confermare se questo è il caso disabilitando il tracciamento attivo o rimuovendo le intestazioni HTTP aggiuntive.

Perché succede?

Quando viene utilizzato il tracciamento attivo, viene aggiunta un'intestazione aggiuntiva a tutte le richieste in uscita per tracciare la chiamata. Modificare le intestazioni della richiesta aggiungendo un'intestazione di tracciamento o aggiungendo intestazioni aggiuntive utilizzando page.setExtraHTTPHeaders Attiva un controllo CORS per le richieste XMLHttpRequest (XHR).

Se non desideri disabilitare il tracciamento attivo o rimuovere le intestazioni aggiuntive, puoi aggiornare l'applicazione Web per consentire l'accesso multiorigine oppure disabilitare la protezione Web utilizzando il comando disable-web-security quando avvii il browser Chrome nello script.

Puoi sovrascrivere i parametri di avvio utilizzati da CloudWatch Synthetics e trasferire ulteriori flag disable-web-security utilizzando la funzione di avvio di CloudWatch Synthetics. Per ulteriori informazioni, consulta Funzioni di libreria disponibili per gli script canary Node.js utilizzando Puppeteer.

Problemi relativi alle condizioni dell'esecuzione del canary

Per una migliore esperienza di utilizzo di CloudWatch Synthetics, assicurati che il codice scritto per i canary sia idempotente. Altrimenti, in rari casi, le esecuzioni canary possono incontrare condizioni di conflitto quando il canary accede alla stessa risorsa durante esecuzioni diverse.

Risoluzione dei problemi di un Canary su un VPC

Se riscontri problemi dopo la creazione o l'aggiornamento di un Canary su un VPC, una delle sezioni seguenti potrebbe aiutarti a risolvere il problema.

Impossibile aggiornare il Canary o il nuovo Canary è in stato di errore

Se crei un Canary per l'esecuzione in un VPC e questo entra immediatamente in stato di errore oppure se non è possibile aggiornare un Canary per l'esecuzione su un VPC, è possibile che il ruolo del Canary non abbia le autorizzazioni corrette. Per l'esecuzione su un VPC, un canary deve disporre delle autorizzazioni ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces e ec2:DeleteNetworkInterface. Queste autorizzazioni sono tutte contenute nella policy AWSLambdaVPCAccessExecutionRole gestita. Per ulteriori informazioni, consulta Autorizzazioni del ruolo di esecuzione e dell'utente.

Se il problema si verifica quando crei un Canary, devi eliminare il Canary e crearne uno nuovo. Se usi la console CloudWatch per creare il nuovo canary, seleziona Create a new role (Crea un nuovo ruolo) in Access Permissions (Autorizzazioni di accesso). Viene creato un nuovo ruolo che include tutte le autorizzazioni necessarie per eseguire il canary.

Se il problema si verifica quando aggiorni un canary, puoi aggiornare nuovamente il canary e fornire un nuovo ruolo con le autorizzazioni necessarie.

Errore "Nessun risultato del test restituito"

Se un Canary visualizza l'errore "Nessun risultato del test restituito", la causa potrebbe una delle seguenti:

Per risolvere questi problemi, vedi i log per il Canary.

Risoluzione dei problemi relativi a un canary di tentativi automatici

Per capire perché il tuo canary non funziona o per analizzare specifici tentativi non riusciti, segui questi passaggi per la risoluzione dei problemi.