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
- Há falha no canário após a atualização do ambiente Lambda
- Meu canário está bloqueado pelo AWS WAF
- Aguardar que um elemento seja exibido
- O nó não é visível ou não é um HTMLElement para page.click()
- 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)
- Erro: erro de protocolo (Runtime.callFunctionOn): destino fechado.
- O canário falhou. Error: No datapoint (Erro: sem ponto de dados). O canário exibe erro de tempo limite
- Tentar acessar um endpoint interno
- Problemas de atualização e downgrade da versão do runtime do canário
- Problema de compartilhamento de solicitações de origem cruzada (CORS)
- Problemas de condições de interferências para o canário
- Solução de problemas de um canário em uma VPC
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 evitar que o AWS WAF bloqueie o canário, configure uma condição de correspondência de string do AWS WAF que permita a string CloudWatchSynthetics
. Para obter mais informações, consulte Working with string match conditions na documentação do AWS WAF.
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 ter 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 ter 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 ter 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 ter 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.