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**
+ Utilizza la pagina dei dettagli del canary per trovare maggiori informazioni. Nella CloudWatch console, scegli **Canarie** nel pannello di navigazione, quindi scegli il nome del canarino per aprire la pagina dei dettagli del canarino. Nella scheda **Disponibilità**, controlla la ** SuccessPercent**metrica per vedere se il problema è costante o intermittente.
Mentre ancora nella scheda **Availability** (Disponibilità), scegli un punto dati non riuscito per visualizzare schermate, log e report delle fasi (se disponibili) per l'esecuzione non riuscita.
Se è disponibile un report di passaggio perché le fasi fanno parte dello script, verifica quale fase non è riuscita e consulta gli screenshot associati per verificare il problema riscontrato dai clienti.
È inoltre possibile controllare i file HAR per vedere se una o più richieste non vanno a buon fine. Puoi esaminare ulteriori dettagli utilizzando i log per analizzare richieste ed errori non andati a buon fine. Infine, puoi confrontare questi artefatti con gli artefatti di un'esecuzione di un canary andato a buon fine per individuare il problema.
Per impostazione predefinita, CloudWatch Synthetics acquisisce schermate per ogni passaggio in un'interfaccia utente canary. Tuttavia, lo script potrebbe essere configurato per disabilitare gli screensot. Durante il debug, potrai voler abilitare nuovamente gli screenshot. Allo stesso modo, per i canary dell'API potresti voler vedere le intestazioni e il corpo della richiesta HTTP e della risposta durante il debug. Per informazioni su come includere questi dati nel report, consulta [executeHttpStep(StepName, RequestOptions, [callback], [StepConfig])](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_executeHttpStep).
+ Se disponi di un'implementazione recente per l'applicazione, esegui il rollback e quindi esegui il debug in un secondo momento.
+ Connettiti manualmente all'endpoint per verificare se è possibile riprodurre lo stesso problema.
**Topics**
+ [Il canary presenta problemi dopo l'aggiornamento dell'ambiente Lambda](#Troubleshoot_upgradeLambda)
+ [Il mio canarino è bloccato da AWS WAF](#Canary_Blocked_WAF)
+ [Attesa della visualizzazione di un elemento](#CloudWatch_Synthetics_Canaries_Troubleshoot_waiting)
+ [Il nodo non è visibile o non è visibile per page.click () HTMLElement](#CloudWatch_Synthetics_Canaries_Troubleshoot_notvisible)
+ [Impossibile caricare artefatti su S3, Eccezione: impossibile recuperare la posizione del bucket S3: accesso negato](#CloudWatch_Synthetics_Canaries_Troubleshoot_noupload)
+ [Errore: errore di protocollo (Runtime). callFunctionOn): Obiettivo chiuso.](#CloudWatch_Synthetics_Canaries_Troubleshoot_protocolError)
+ [Canary non riuscito. Errore: nessun datapoint - Canary mostra errore di timeout](#CloudWatch_Synthetics_Canaries_Troubleshoot_nodatapoint)
+ [Tentativo di accedere a un endpoint interno](#CloudWatch_Synthetics_Canaries_Troubleshoot_internalendpoint)
+ [Problemi relativi all'aggiornamento e al downgrade della versione di runtime del canary](#CloudWatch_Synthetics_Canaries_Troubleshoot_upgradeissues)
+ [Problema CORS (Cross-Origin Request Sharing)](#CloudWatch_Synthetics_Canaries_CORS)
+ [Problemi relativi alle condizioni dell'esecuzione del canary](#CloudWatch_Synthetics_Canaries_RaceCondition)
+ [Risoluzione dei problemi di un Canary su un VPC](#CloudWatch_Synthetics_Canaries_VPC_troubleshoot)
+ [Risoluzione dei problemi relativi a un canary di tentativi automatici](#CloudWatch_Synthetics_Canaries_autoretry)
## Il canary presenta problemi 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 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](CloudWatch_Synthetics_Canaries_Library.md).
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.
**avvertimento**
Quando modifichi le impostazioni di runtime in modalità manuale, la funzione Lambda non riceverà aggiornamenti di sicurezza automatici finché non tornerà alla modalità Auto. Durante questo periodo, la tua funzione Lambda potrebbe essere soggetta a vulnerabilità di sicurezza.
**Prerequisiti**
+ Installazione di [jq](https://jqlang.github.io/jq/)
+ Installazione della versione più recente della AWS CLI. Per ulteriori informazioni, consulta le [istruzioni di installazione e aggiornamento della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#getting-started-install-instructions).
### 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](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-identify.html) 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
È 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 la AWS CLI**
Inserisci il seguente comando per modificare la gestione del runtime della funzione Lambda in modalità manuale. Assicurati di sostituire la funzione *function-name* e * qualifier* con l'ARN della funzione Lambda 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"
```
**Per cambiare un canary in modalità manuale utilizzando la console Lambda**
1. Apri la AWS Lambda console all'indirizzo [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Scegli la scheda **Versioni**, scegli il collegamento al numero di versione che corrisponde al tuo ARN e scegli la scheda **Codice**.
1. Scorri verso il basso fino alle **Impostazioni di runtime**, espandi la **Configurazione di gestione del runtime** e copia l'**ARN della versione del runtime**.
![\[Mostra la sezione delle Impostazioni di runtime della schermata e mostra dove appare l'ARN della versione del runtime in questa sezione.\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual1.png)
1. Scegli **Modifica configurazione di gestione del runtime**, scegli **Manuale**, incolla l'ARN della versione di runtime che hai copiato in precedenza nel campo **ARN della versione** di runtime. Quindi scegli **Save** (Salva).
![\[Mostra la schermata di Configurazione della gestione del runtime e mostra dove incollare l'ARN della versione del runtime copiata in precedenza.\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual2.png)
## 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](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-string-conditions.html) 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 filtri AWS WAF e migliora la sicurezza.
Per impostare una stringa user-agent personalizzata, effettua le seguenti operazioni:
+ Per i runtime di Playwright, puoi aggiungere la stringa user-agent personalizzata AWS WAF approvata utilizzando il file di configurazione Synthetics. Per ulteriori informazioni, consulta [CloudWatch Configurazioni Synthetics](Synthetics_WritingCanary_Nodejs_Playwright.md#Synthetics_canary_configure_Playwright_script).
+ Per i runtime Puppeteer o Selenium, puoi aggiungere la tua stringa user-agent personalizzata utilizzando le funzioni di libreria supportate. Per i runtime di Puppeteer, consulta [async addUserAgent (pagina,); userAgentString](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_addUserAgent). Per i runtime di Selenium, consulta [add\$1user\$1agent(user\$1agent\$1str)](CloudWatch_Synthetics_Canaries_Library_Python.md#CloudWatch_Synthetics_Library_add_user_agent).
## 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 di Puppeteer o i forum su Internet. GitHub ](https://github.com/puppeteer/puppeteer/issues)
## 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 \$1 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:
+ Controlla che il ruolo IAM del canary abbia autorizzazione `s3:ListAllMyBuckets`, l'autorizzazione `s3:GetBucketLocation` per il bucket Amazon S3 corretto e autorizzazione `s3:PutObject` per il bucket dove il canary immagazzina i suoi artefatti. Se il canary esegue il monitoraggio visivo, per il ruolo è necessaria anche l'autorizzazione ` s3:GetObject` per il bucket. Queste stesse autorizzazioni sono richieste anche nella policy degli endpoint gateway Amazon VPC S3, se il canary viene distribuito in un VPC con un endpoint VPC.
+ Se il canarino utilizza una chiave gestita AWS KMS dal cliente per la crittografia anziché la chiave AWS gestita standard (impostazione predefinita), il ruolo IAM del canarino potrebbe non avere l'autorizzazione per crittografare o decrittografare utilizzando tale chiave. Per ulteriori informazioni, consulta [Crittografia di artefatti canary](CloudWatch_Synthetics_artifact_encryption.md).
+ La tua policy del bucket potrebbe non permettere il meccanismo di crittografia utilizzato da Canary. Ad esempio, se la policy del bucket richiede di utilizzare un meccanismo di crittografia specifico o una chiave KMS, è necessario selezionare la stessa modalità di crittografia per il canary.
Se il canary esegue il monitoraggio visivo, vedere [Aggiornamento della posizione e della crittografia degli artifact quando si utilizza il monitoraggio visivo](CloudWatch_Synthetics_artifact_encryption.md#CloudWatch_Synthetics_artifact_encryption_visual) 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.
**Usare CloudWatch Logs per visualizzare i tronchi di un canarino**
1. Apri la console all' CloudWatch indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione a sinistra, scegli **Log groups** (Gruppi di log).
1. Individua il gruppo di log digitando il nome del canary nella casella filtro. I gruppi di log per i canarini hanno il nome**/aws/lambda/cwsyn- *canaryName* -RandomID**.
## 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](CloudWatch_Synthetics_Canaries_VPC.md).
## 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)](#CloudWatch_Synthetics_Canaries_CORS).
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](CloudWatch_Synthetics_Canaries_WritingCanary.md).
**Nota**
Quando prevedi di eseguire l'upgrade o il downgrade della versione di runtime per un canary, ti consigliamo prima di clonare il canary e aggiornare la versione di runtime nel canary clonato. Una volta verificato che il clone con la nuova versione di runtime funziona, puoi aggiornare la versione di runtime del canary originale ed eliminare il clone.
## 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 di traccia o l'aggiunta di intestazioni aggiuntive utilizzando Puppeteer provoca un controllo CORS delle richieste di richiesta (XHR). `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 Node.js utilizzando Puppeteer](CloudWatch_Synthetics_Canaries_Library_Nodejs.md).
**Nota**
È possibile sovrascrivere i parametri di avvio utilizzati da CloudWatch Synthetics quando si utilizza la versione runtime o successiva. `syn-nodejs-2.1`
## Problemi relativi alle condizioni dell'esecuzione del canary
Per una migliore esperienza di utilizzo di CloudWatch Synthetics, assicurati che il codice scritto per i canarini 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](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-permissions).
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:
+ Se il tuo VPC non dispone di accesso a Internet, devi utilizzare gli endpoint VPC per consentire a Canary di accedere ad Amazon S3. CloudWatch Devi abilitare le opzioni **DNS resolution** (Risoluzione DNS) e **DNS hostname** (Hostname DNS) nel VPC affinché questi indirizzi di endpoint vengano risolti correttamente. Per ulteriori informazioni, consulta [Utilizzo del DNS con il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) e Utilizzo [ CloudWatch e CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html) con gli endpoint VPC dell'interfaccia.
+ I Canary devono essere eseguiti in sottoreti private all'interno di un VPC. Per verificarlo, apri la pagina **Subnet** nella console VPC. Controlla le sottoreti selezionate durante la configurazione del Canary. Se hanno un percorso per un gateway Internet (**igw-**), non sono sottoreti private.
Per risolvere questi problemi, vedi i log per il Canary.
**Per visualizzare gli eventi di log da un Canary**
1. Apri la console all' CloudWatch indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, seleziona **Log groups** (Gruppi di log).
1. Scegli il nome del gruppo di log del Canary. Il nome del gruppo di log inizia con ` /aws/lambda/cwsyn-canary-name`.
## 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.
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Application Signals**, **Canary di Synthetics**.
1. Scegli la scheda **canary**.
1. Nella scheda **Disponibilità**, puoi esaminare i dettagli dell'esecuzione in uno dei seguenti modi:
+ Selezione di un punto specifico nel grafico esecuzioni canary
+ In **Problemi**, seleziona un record. Tieni presente che i nuovi tentativi sono contrassegnati e condividono i timestamp con le rispettive esecuzioni pianificate
È possibile visualizzare informazioni aggiuntive in **Steps**, **Screenshot**, **Logs**, **File HAR** o **Traces (se la traccia attiva è** abilitata).
1. Su **Artefatti del canary e posizioni Amazon S3**, puoi accedere all'artefatto e navigare verso le cartelle o i bucket Amazon S3 tramite i link disponibili.
1. Il grafico delle **esecuzioni canary** utilizza punti colorati diversi per indicare vari stati:
+ Punti blu: indicano le esecuzioni programmate riuscite con un valore costante del 100%
+ Punti rossi: mostrano gli errori sia nelle esecuzioni programmate che in tutti i nuovi tentativi, contrassegnati con lo 0%
+ Punti arancioni: mostrano lo 0% o il 100%. Lo 0% indica un nuovo tentativo in corso dopo i tentativi precedenti non riusciti e il 100% indica che è stato raggiunto un esito positivo dopo un nuovo tentativo