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 Canaries (Canários) no painel de navegação e escolha o nome do canário para abrir a página de detalhes do canário. Na guia Availability (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]).
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.
Tópicos
O nó não é visível ou não é um HTMLElement para page.click()
Erro: erro de protocolo (Runtime.callFunctionOn): destino fechado.
Problemas de atualização e downgrade da versão do runtime do canário
Problema de compartilhamento de solicitações de origem cruzada (CORS)
Solução de problemas em um canário com tentativas automáticas
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.
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
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.
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 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
" \ --qualifier8
\ --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
Abra o console AWS Lambda em https://console.aws.amazon.com/lambda/
. Escolha a guia Versões, selecione o link do número da versão correspondente ao seu ARN e a guia Código.
Role para baixo até Configurações de runtime, expanda Configuração de gerenciamento de runtime e copie o ARN da versão de runtime.
Escolha Editar configuração de gerenciamento de runtime, selecione Manual, cole o ARN da versão de runtime copiada anteriormente no campo ARN da versão de runtime. Em seguida, escolha Salvar.
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 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.
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);. Para runtimes do Selenium, consulte add_user_agent(user_agent_str).
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
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 * 1080. Você pode definir um visor diferente ao iniciar o navegador ou usando a função page.setViewport
do Puppeteer.
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ãos3:GetBucketLocation
para o bucket correto do Amazon S3 e a permissãos3: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ãos3: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.
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 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
Abra o console do CloudWatch em https://console.aws.amazon.com/cloudwatch/
. No painel de navegação esquerdo, escolha Log groups (Grupos de log).
Localize o grupo de logs inserindo o nome do canário na caixa de filtro. Os grupos de log para 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.
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).
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.
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.
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.
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 e Uso do CloudWatch e do CloudWatch Synthetics com endpoints da VPC de interface.
Os canaries devem ser executadas em sub-redes privadas dentro de uma VPC. Para verificar isso, abra a página Subnets (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
Abra o console do CloudWatch, em https://console.aws.amazon.com/cloudwatch/
. -
No painel de navegação, escolha Grupos de logs.
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.
Abra o console do CloudWatch, em https://console.aws.amazon.com/cloudwatch/
. No painel de navegação, escolha Application Signals, Canários do Synthetics.
Selecione o Canário.
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).
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.
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.