Solucionar problemas de um canário

Se o canário falhar, verifique o seguinte para solucionar problemas.

Solução de problemas gerais

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.

Pré-requisitos

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" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

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:

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 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 * 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:

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.

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.

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

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:

Para ajudar a solucionar esses problemas, consulte os logs do canário.

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.