# Solucionar problemas de um canário
Se o canário falhar, verifique o seguinte para solucionar problemas.
**Solução de problemas gerais**
+ Use a página de detalhes do canário para encontrar mais informações. No console do CloudWatch, escolha **Canários** no painel de navegação e depois o nome do canário para abrir a página de detalhes do canário. Na guia **Disponibilidade**, marque a métrica **SuccessPercent** para ver se o problema é constante ou intermitente.
Ainda na guia **Availability** (Disponibilidade), escolha um ponto de dados com falha para ver capturas de tela, logs e relatórios de etapas (se disponível) para essa execução com falha.
Se um relatório de etapas estiver disponível porque as etapas fazem parte do script, verifique qual etapa falhou e veja as capturas de tela associadas para ver o problema que seus clientes estão vendo.
Também é possível verificar os arquivos HAR para ver se uma ou mais solicitações estão com falha. Você pode aprofundar usando logs para detalhar solicitações e erros com falha. Por fim, você pode comparar esses artefatos com os artefatos de uma execução bem-sucedida do canário para identificar o problema.
Por padrão, o CloudWatch Synthetics obtém capturas de tela para cada etapa em um canário de interface do usuário. Porém, seu script pode estar configurado para desabilitar capturas de tela. Durante a depuração, convém habilitar as capturas de tela novamente. Da mesma forma, para canaries de API, convém ver os cabeçalhos e o corpo da solicitação e da resposta HTTP durante a depuração. Para obter informações sobre como incluir dados no relatório de sessões, consulte [executeHttpStep(stepName, requestOptions, [callback], [stepConfig])](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_executeHttpStep).
+ Se você teve uma implantação recente em sua aplicação, reverta-a e a depure mais tarde.
+ Conecte-se ao endpoint manualmente para ver se você consegue reproduzir o mesmo problema.
**Topics**
+ [Há falha no canário após a atualização do ambiente Lambda](#Troubleshoot_upgradeLambda)
+ [Meu canário está bloqueado pelo AWS WAF](#Canary_Blocked_WAF)
+ [Aguardar que um elemento seja exibido](#CloudWatch_Synthetics_Canaries_Troubleshoot_waiting)
+ [O nó não é visível ou não é um HTMLElement para page.click()](#CloudWatch_Synthetics_Canaries_Troubleshoot_notvisible)
+ [Unable to upload artifacts to S3, Exception: Unable to fetch S3 bucket location: Access Denied (Não é possível carregar artefatos para o S3, Exceção: Não é possível buscar a localização do bucket do S3: Acesso negado)](#CloudWatch_Synthetics_Canaries_Troubleshoot_noupload)
+ [Erro: erro de protocolo (Runtime.callFunctionOn): destino fechado.](#CloudWatch_Synthetics_Canaries_Troubleshoot_protocolError)
+ [O canário falhou. Error: No datapoint (Erro: sem ponto de dados). O canário exibe erro de tempo limite](#CloudWatch_Synthetics_Canaries_Troubleshoot_nodatapoint)
+ [Tentar acessar um endpoint interno](#CloudWatch_Synthetics_Canaries_Troubleshoot_internalendpoint)
+ [Problemas de atualização e downgrade da versão do runtime do canário](#CloudWatch_Synthetics_Canaries_Troubleshoot_upgradeissues)
+ [Problema de compartilhamento de solicitações de origem cruzada (CORS)](#CloudWatch_Synthetics_Canaries_CORS)
+ [Problemas de condições de interferências para o canário](#CloudWatch_Synthetics_Canaries_RaceCondition)
+ [Solução de problemas de um canário em uma VPC](#CloudWatch_Synthetics_Canaries_VPC_troubleshoot)
+ [Solução de problemas em um canário com tentativas automáticas](#CloudWatch_Synthetics_Canaries_autoretry)
## Há falha no canário após a atualização do ambiente Lambda
Os canários do CloudWatch Synthetics são implementados como funções do Lambda na sua conta. Essas funções do Lambda estão sujeitas a atualizações periódicas de runtime do Lambda que contêm atualizações de segurança, correções de bugs e outras melhorias. O Lambda se empenha em fornecer atualizações de runtime compatíveis com as funções existentes. No entanto, como acontece com a aplicação de patches de software, há casos raros em que uma atualização de runtime pode afetar negativamente uma função existente. Se você acredita que seu canário foi afetado por uma atualização de runtime do Lambda, use o modo manual de gerenciamento de runtime do Lambda (em regiões com suporte) para reverter temporariamente a versão de runtime do Lambda. Isso mantém seu canário funcionando e minimiza as interrupções, fornecendo tempo para corrigir a incompatibilidade antes de retornar à versão de runtime mais recente.
Se houver falhas no canário após uma atualização de runtime do Lambda, a melhor solução é fazer o upgrade para um dos runtimes mais recentes do Synthetics. Para obter mais informações sobre os runtimes mais recentes, consulte [Versões do runtime do Synthetics](CloudWatch_Synthetics_Canaries_Library.md).
Como solução alternativa, nas regiões em que os controles de gerenciamento de runtime do Lambda estão disponíveis, você pode reverter um canário para um runtime gerenciado do Lambda mais antigo, usando o modo manual para controles de gerenciamento de runtime. Você pode definir o modo manual usando a AWS CLI ou o console do Lambda, seguindo as etapas abaixo nas seções a seguir.
**Atenção**
Quando você altera as configurações de runtime para o modo manual, a função do Lambda não recebe atualizações automáticas de segurança até que seja revertida para o modo automático. Durante esse período, a função do Lambda pode ficar suscetível a vulnerabilidades de segurança.
**Pré-requisitos**
+ Instalar o [jq](https://jqlang.github.io/jq/)
+ Instale a versão mais recente do AWS CLI. Para obter mais informações, consulte as [instruções de instalação e atualização da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#getting-started-install-instructions).
### Etapa 1: obter o ARN da função do Lambda
Execute o comando a seguir para recuperar o campo `EngineArn` da resposta. Esse `EngineArn` é o ARN da função do Lambda associada ao canário. Você usará esse ARN nas etapas a seguir.
```
aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'
```
Exemplo de saída para `EngingArn`:
```
"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"
```
### Etapa 2: obter o ARN da última versão de runtime válida do Lambda
Para ajudar a entender se o canário foi afetado por uma atualização de runtime do Lambda, verifique se a data e a hora em que o ARN da versão de runtime do Lambda foi alterado nos logs apareceram na data e hora em que você viu o impacto no canário. Se não houver uma correspondência, provavelmente não é uma atualização de runtime do Lambda que está causando os problemas.
Se o canário for afetado por uma atualização de runtime do Lambda, é necessário identificar o ARN da versão de runtime do Lambda em funcionamento que estava em uso anteriormente. Siga as instruções em [Identifying runtime version changes](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-identify.html) para encontrar o ARN do runtime anterior. Registre o ARN da versão de runtime e prossiga para a Etapa 3, a fim de definir a configuração de gerenciamento do runtime.
Se o canário ainda não foi afetado por uma atualização do ambiente Lambda, você pode encontrar o ARN da versão de runtime do Lambda que está usando atualmente. Execute o comando a seguir para recuperar o `RuntimeVersionArn` da função do Lambda da resposta.
```
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'
```
Exemplo de saída para `RuntimeVersionArn`:
```
"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"
```
### Etapa 3: atualizar a configuração de gerenciamento de runtime do Lambda
Você pode usar a AWS CLI ou o console do Lambda para atualizar a configuração de gerenciamento de runtime.
**Definir o modo manual de configuração do gerenciamento de runtime do Lambda usando a AWS CLI**
Insira o comando a seguir para alterar o gerenciamento de runtime da função do Lambda para o modo manual. Certifique-se de substituir *function-name* e *qualificador* pelo ARN da função do Lambda e pelo número da versão da função do Lambda, respectivamente, usando os valores encontrados na Etapa 1. Também substitua *runtime-version-arn* pelo ARN da versão encontrado na Etapa 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"
```
**Mudar um canário para o modo manual usando o console do Lambda**
1. Abra o console AWS Lambda em [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Escolha a guia **Versões**, selecione o link do número da versão correspondente ao seu ARN e a guia **Código**.
1. Role para baixo até **Configurações de runtime**, expanda **Configuração de gerenciamento de runtime** e copie o **ARN da versão de runtime**.
![\[Mostra a seção Configurações do runtime da tela e mostra onde o ARN da versão do runtime aparece nessa seção.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual1.png)
1. Escolha **Editar configuração de gerenciamento de runtime**, selecione **Manual** e cole o ARN da versão de runtime copiado anteriormente no campo **ARN da versão de runtime**. Em seguida, escolha **Salvar**.
![\[Mostra a tela Configuração de gerenciamento do runtime e mostra onde colar o ARN da versão do runtime que você copiou anteriormente.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual2.png)
## Meu canário está bloqueado pelo AWS WAF
Para permitir o tráfego do canário pelo AWS WAF, crie uma condição de correspondência de string do AWS WAF que permita uma string personalizada especificada por você. Para obter mais informações, consulte [Working with string match conditions](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-string-conditions.html) na documentação do AWS WAF.
Recomendamos fortemente que você use sua própria string personalizada de agente de usuário em vez de usar valores padrão. Isso proporciona melhor controle sobre a filtragem do AWS WAF e melhora a segurança.
Para definir uma string personalizada de agente de usuário, faça o seguinte:
+ Para runtimes do Playwright, é possível anexar sua string personalizada de agente de usuário aprovada do AWS WAF usando o arquivo de configuração do Synthetics. Para obter mais informações, consulte [Configurações do CloudWatch Synthetics](Synthetics_WritingCanary_Nodejs_Playwright.md#Synthetics_canary_configure_Playwright_script).
+ Para runtimes do Puppeteer ou Selenium, você pode adicionar sua string personalizada de agente de usuário usando as funções de biblioteca compatíveis. Para runtimes do Puppeteer, consulte [async addUserAgent(page, userAgentString);](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_addUserAgent). Para runtimes do Selenium, consulte [add\$1user\$1agent(user\$1agent\$1str)](CloudWatch_Synthetics_Canaries_Library_Python.md#CloudWatch_Synthetics_Library_add_user_agent).
## Aguardar que um elemento seja exibido
Depois de analisar seus logs e suas capturas de tela, se você perceber que seu script está aguardando que um elemento seja exibido na tela e ultrapassar o tempo limite, verifique a captura de tela relevante para ver se o elemento é exibido na página. Verifique o `xpath` para se certificar de que está correto.
Para problemas relacionados ao Puppeteer, consulte a [página do GitHub do Puppeteer](https://github.com/puppeteer/puppeteer/issues) ou fóruns da Internet.
## O nó não é visível ou não é um HTMLElement para page.click()
Se um nó não estiver visível ou não for um `HTMLElement` para `page.click()`, verifique primeiro o `xpath` que você está usando para clicar no elemento. Além disso, se o elemento estiver na parte inferior da tela, ajuste o visor. Por padrão, o CloudWatch Synthetics usa um visor de 1920 \$1 1080. Você pode definir um visor diferente ao iniciar o navegador ou usando a função do Puppeteer `page.setViewport`.
## Unable to upload artifacts to S3, Exception: Unable to fetch S3 bucket location: Access Denied (Não é possível carregar artefatos para o S3, Exceção: Não é possível buscar a localização do bucket do S3: Acesso negado)
Se o canário falha em decorrência de um erro do Amazon S3, significa que CloudWatch Synthetics não conseguiu carregar capturas de tela, logs ou relatórios criados para o canário devido a problemas de permissão. Verifique o seguinte:
+ Verifique se a função do IAM do canário tem a permissão `s3:ListAllMyBuckets`, a permissão `s3:GetBucketLocation` para o bucket correto do Amazon S3 e a permissão `s3:PutObject` para o bucket no qual o canário armazena seus artefatos. Se o canário realizar monitoramento visual, a função também precisa da permissão ` s3:GetObject` para o bucket. Essas mesmas permissões também são exigidas na política de endpoints de gateway da VPC para o Amazon S3, caso o canário seja implantado em uma VPC com um endpoint da VPC.
+ Se o canário usar uma chave do AWS KMS gerenciada pelo cliente para criptografia em vez da chave gerenciada pela AWS (padrão), a função do IAM do canário poderá não ter permissão para criptografar ou descriptografar usando essa chave. Para obter mais informações, consulte [Criptografar artefatos do canário](CloudWatch_Synthetics_artifact_encryption.md).
+ Sua política de bucket pode não permitir o mecanismo de criptografia usada pelo canário. Por exemplo, se a política de bucket exigir usar um mecanismo de criptografia específico ou uma chave do KMS, você deverá selecionar o mesmo modo de criptografia para o canário.
Se o canário realizar monitoramento visual, consulte [Atualizar a localização e a criptografia do artefato ao usar o monitoramento visual](CloudWatch_Synthetics_artifact_encryption.md#CloudWatch_Synthetics_artifact_encryption_visual) para obter mais informações.
## Erro: erro de protocolo (Runtime.callFunctionOn): destino fechado.
Esse erro aparecerá se houver algumas solicitações de rede depois que a página ou o navegador for fechado. Talvez você tenha se esquecido de aguardar uma operação assíncrona. Depois de executar seu script, o CloudWatch Synthetics fechará o navegador. A execução de qualquer operação assíncrona após o fechamento do navegador poderá causar `target closed error`.
## O canário falhou. Error: No datapoint (Erro: sem ponto de dados). O canário exibe erro de tempo limite
Siggnifica que a execução do canário excedeu o tempo limite. A execução do canário foi interrompida antes que o CloudWatch Synthetics pudesse publicar métricas de porcentagem de sucesso do CloudWatch ou atualizar artefatos como arquivos HAR, logs e capturas de tela. Se o tempo limite for muito baixo, é possível aumentá-lo.
Por padrão, o valor de tempo limite do canário é igual à frequência dele. É possível ajustar manualmente o valor de tempo limite para ser menor que ou igual à frequência do canário. Se sua frequência do canário for baixa, será necessário aumentar a frequência para aumentar o tempo limite. É possível ajustar a frequência e o valor de tempo limite em **Schedule** (Programar) ao criar ou atualizar um canário usando o console do CloudWatch Synthetics.
Certifique-se de que valor do tempo limite do canário não seja menos de 15 segundos para permitir que o Lambda seja iniciado a frio e que a instrumentação do canário seja inicializada.
Os artefatos do canário não estão disponíveis para exibição no console do CloudWatch Synthetics quando esse erro ocorre. É possível usar o CloudWatch Logs para ver os logs do canário.
**Para usar o CloudWatch Logs para ver os logs de um canário**
1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação esquerdo, escolha **Log groups** (Grupos de log).
1. Localize o grupo de logs inserindo o nome do canário na caixa de filtro. Os grupos de logs dos canários têm o nome **/aws/lambda/cwsyn-*canaryName*-randomId**.
## Tentar acessar um endpoint interno
Para que seu canário acesse um endpoint em sua rede interna, recomendamos configurar o CloudWatch Synthetics para usar a VPC. Para obter mais informações, consulte [Execução de um canário em uma VPC](CloudWatch_Synthetics_Canaries_VPC.md).
## Problemas de atualização e downgrade da versão do runtime do canário
Se você atualizou recentemente o canário da versão do runtime `syn-1.0` para uma versão posterior, pode ser um problema de compartilhamento de solicitação de origem cruzada (CORS). Para obter mais informações, consulte [Problema de compartilhamento de solicitações de origem cruzada (CORS)](#CloudWatch_Synthetics_Canaries_CORS).
Se você fez o downgrade do canário recentemente para uma versão de runtime mais antiga, verifique se as funções do CloudWatch Synthetics utilizadas estão disponíveis na versão de runtime mais antiga para a qual fez o downgrade. Por exemplo, a função `executeHttpStep` está disponível para a versão de runtime `syn-nodejs-2.2` e posteriores. Para conferir a disponibilidade de funções, consulte [Escrever um script do canário](CloudWatch_Synthetics_Canaries_WritingCanary.md).
**nota**
Ao planejar o upgrade ou downgrade da versão de runtime para um canário, recomendamos primeiro clonar o canário e atualizar a versão de runtime no canário clonado. Depois de verificar que o clone com a nova versão do runtime funciona, é possível atualizar a versão do runtime do canário original e excluir o clone.
## Problema de compartilhamento de solicitações de origem cruzada (CORS)
Em um canário de interface do usuário, se algumas solicitações de rede estiverem apresentando falha com `403` ou ` net::ERR_FAILED`, verifique se o canário tem o rastreamento ativo habilitado e também usa a função `page.setExtraHTTPHeaders` do Puppeteer para adicionar cabeçalhos. Nesse caso, as solicitações de rede com falha podem ser causadas por restrições de compartilhamento de solicitações de origem cruzada (CORS). Confirme se esse é o caso desabilitando o rastreamento ativo ou removendo os cabeçalhos HTTP excedentes.
**Por que isso acontece?**
Quando o rastreamento ativo é usado, adiciona-se um cabeçalho a mais a todas as solicitações de saída para rastrear a chamada. Modificar os cabeçalhos de solicitação adicionando um cabeçalho de rastreamento ou adicionando cabeçalhos a mais usando o `page.setExtraHTTPHeaders`do Puppeteer caus uma verificação CORS para solicitações XMLHttpRequest (XHR).
Se você não quiser desabilitar o rastreamento ativo ou remover os cabeçalhos excedentes, poderá atualizar sua aplicação Web para permitir acesso entre origens ou desabilitar a segurança da Web usando o sinalizador `disable-web-security` ao iniciar o navegador Chrome em seu script.
É possível substituir os parâmetros de inicialização usados pelo CloudWatch Synthetics e passar outros parâmetros de sinalização ` disable-web-security` usando a função de inicialização do CloudWatch Synthetics. Para obter mais informações, consulte [Funções de biblioteca disponíveis para scripts de canário Node.js usando o Puppeteer](CloudWatch_Synthetics_Canaries_Library_Nodejs.md).
**nota**
Você pode substituir os parâmetros de inicialização usados pelo CloudWatch Synthetics ao usar a versão `syn-nodejs-2.1` do runtime ou versões posteriores.
## Problemas de condições de interferências para o canário
Para obter a melhor experiência ao usar o CloudWatch Synthetics, certifique-se de que o código gravado para os canários seja idempotente. Caso contrário, em casos raros, as execuções do canário poderão encontrar condições de interferências quando o canário interagir com o mesmo recurso em execuções diferentes.
## Solução de problemas de um canário em uma VPC
Se tiver problemas após criar ou atualizar um canário em uma VPC, uma das seções a seguir poderá ajudar você a solucionar o problema.
### Novo canário em estado de erro ou não foi possível atualizar o canário
Se você criar um canário para ser executado em uma VPC, e ele imediatamente entrar em um estado de erro, ou você não conseguir atualizar um canário para ser executado em uma VPC, a função do canário pode não ter as permissões corretas. Para ser executado em uma VPC, um canário deve ter as permissões ` ec2:CreateNetworkInterface`, `ec2:DescribeNetworkInterfaces` e ` ec2:DeleteNetworkInterface`. Essas permissões estão todas contidas na política gerenciada ` AWSLambdaVPCAccessExecutionRole`. Para obter mais informações, consulte [Função de execução e permissões de usuário](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-permissions).
Se esse problema aconteceu quando você criou um canário, você deverá excluir o canário e criar um novo. Se você usar o console do CloudWatch para criar o canário, selecione **Access Permissions** (Permissões de acesso) e selecione **Create a new role** (Criar uma função). É criada uma nova função com todas as permissões necessárias para executar o canário.
Se o problema acontecer ao atualizar um canário, será possível atualizar o canário novamente e fornecer uma nova função com as permissões necessárias.
### Erro "Nenhum resultado de teste retornado"
Se um canário exibir um erro "nenhum resultado de teste retornado", um dos seguintes problemas pode ser a causa:
+ Se sua VPC não tiver acesso à Internet, você deverá usar endpoints da VPC para conceder ao canário acesso ao CloudWatch e o Amazon S3. Você deverá habilitar as opções **DNS resolution (Resolução DNS)** e **DNS hostname (Nome de host DNS)** na VPC para que esses endpoints ajam para resolver rapidamente. Para obter mais informações, consulte [Uso do DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) e [Usar o CloudWatch e o CloudWatch Synthetics com endpoints da VPC de interface](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html).
+ Os canaries devem ser executadas em sub-redes privadas dentro de uma VPC. Para verificar isso, abra a página **Sub-redes** no console da VPC. Verifique as sub-redes que você selecionou ao configurar o canário. Se elas tiverem um caminho para um gateway de Internet (**igw-**), não são sub-redes privadas.
Para ajudar a solucionar esses problemas, consulte os logs do canário.
**Como ver os eventos de log de um canário**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Grupos de logs**.
1. Escolha o nome do grupo de logs do canário. O nome do grupo de logs começa com ` /aws/lambda/cwsyn-canary-name`.
## Solução de problemas em um canário com tentativas automáticas
Para compreender o motivo da falha do seu canário ou para analisar tentativas específicas que não foram bem-sucedidas, siga as etapas para solução de problemas apresentadas a seguir.
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Application Signals**, **Canários do Synthetics**.
1. Selecione o **Canário**.
1. Na guia **Disponibilidade**, é possível examinar os detalhes da execução ao:
+ Selecionar um ponto específico no gráfico “Execuções do canário”
+ Em **Problemas**, selecionar um registro. Tenha em mente que as novas tentativas são marcadas e compartilham carimbos de data/hora com suas execuções programadas
Você pode visualizar informações adicionais em **Etapas**, **Captura de tela**, **Logs**, **Arquivo HAR** ou **Rastreamentos (caso o rastreamento ativo esteja habilitado)**.
1. Na seção **Artefatos do canário e localização no Amazon S3**, é possível acessar o artefato e navegar pelas pastas ou pelos buckets do Amazon S3 por meio dos links disponíveis.
1. O gráfico **Execuções do canário** usa pontos de cores diferentes para indicar diversos status:
+ Pontos azuis: indicam execuções programadas que obtiveram êxito, com valor constante de 100%
+ Pontos vermelhos: mostram falhas nas execuções programadas e em todas as novas tentativas, que são marcadas como 0%
+ Pontos laranjas: indicam valores de 0% ou 100%. O valor 0% representa uma nova tentativa em andamento após falhas anteriores; enquanto o valor 100% indica que a nova tentativa obteve êxito.