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

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

Canary fallisce dopo l'aggiornamento dell'ambiente Lambda

CloudWatch I canarini 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 si impegna a fornire aggiornamenti di runtime retrocompatibili con le 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 canarino sia stato influenzato da un aggiornamento del runtime Lambda, puoi utilizzare la modalità manuale di gestione del runtime Lambda (nelle regioni supportate) per ripristinare temporaneamente la versione runtime Lambda. Ciò mantiene attiva la funzione Canary e riduce al minimo le interruzioni, lasciando il tempo necessario per porre rimedio all'incompatibilità prima di tornare all'ultima versione di runtime.

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 AWS CLI o utilizzando la console Lambda, seguendo i passaggi riportati di seguito nelle sezioni seguenti.

Prerequisiti

Fase 1: Ottenere la funzione Lambda ARN

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

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

Esempio di output diEngingArn:

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

Fase 2: Ottenere l'ultima versione di runtime Lambda valida (ARN)

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

Se il tuo canary è interessato da un aggiornamento del runtime Lambda, devi identificare l'ARN della versione di 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. Registrare l'ARN della versione di runtime e continuare con il passaggio 3 per impostare la configurazione della gestione del runtime.

Se il tuo canary non è ancora stato interessato da un aggiornamento dell'ambiente Lambda, puoi trovare l'ARN della versione di runtime Lambda che stai utilizzando attualmente. Esegui il comando seguente per recuperare RuntimeVersionArn la 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'

Esempio di output di: RuntimeVersionArn

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

Fase 3: Aggiornamento della configurazione di gestione del runtime Lambda

È possibile utilizzare la console 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 AWS CLI

Immettere il comando seguente per modificare la gestione del runtime della funzione Lambda in modalità manuale. Assicurati di sostituire la function-name funzione Lambda qualifier con l'ARN e il numero di versione della funzione Lambda rispettivamente, utilizzando i valori trovati nel passaggio 1. Sostituisci anche il 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 canarino è bloccato da AWS WAF

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

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

Per impostare una stringa user-agent personalizzata, procedi come segue:

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 Puppeteer, consulta la pagina di Puppeteer o i forum su Internet. GitHub

Il nodo non è visibile o non è visibile per page.click () HTMLElement

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 il tuo elemento si trova nella parte inferiore dello schermo, regola la visualizzazione. CloudWatch Synthetics per impostazione predefinita utilizza una finestra di 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 è stata in grado di caricare schermate, log o report creati per il canarino 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): Obiettivo chiuso.

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 di Canary si è interrotta prima CloudWatch che Synthetics potesse pubblicare metriche sulla CloudWatch percentuale di successo o aggiornare artefatti come file HAR, registri e schermate. 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 quando crei o aggiorni un canarino utilizzando la console Synthetics CloudWatch .

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 Canary non sono disponibili per la visualizzazione nella console Synthetics quando si verifica CloudWatch questo errore. Puoi usare CloudWatch Logs per vedere i registri del canarino.

Tentativo di accedere a un endpoint interno

Se desideri che il tuo canary acceda a un endpoint sulla tua rete interna, ti consigliamo di configurare CloudWatch Synthetics per utilizzare 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 hai recentemente effettuato il downgrade di Canary a una versione di runtime precedente, assicurati che le funzioni Synthetics CloudWatch che stai utilizzando siano disponibili nella versione di runtime precedente a cui hai effettuato 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. La modifica delle intestazioni della richiesta aggiungendo un'intestazione trace o aggiungendo altre intestazioni utilizzando Puppeteer causa una verifica CORS delle richieste XHR (Check for Request). page.setExtraHTTPHeaders XMLHttp

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.

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

Problemi relativi alle condizioni della gara delle Canarie

Per una migliore esperienza di utilizzo di CloudWatch Synthetics, assicurati che il codice scritto per i canarini sia idempotente. Altrimenti, in rari casi, i canarini possono incontrare condizioni di gara quando il canarino interagisce con la stessa risorsa su piste 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 CloudWatch console per creare il nuovo canarino, in Autorizzazioni di accesso, seleziona Crea un nuovo ruolo. 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 sistema di riavvio automatico

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