Resolver problemas de monitores sintéticos e verificações de tempo de atividade

Este documento traz informações sobre como encontrar dados de registros solucionar problemas de monitoramento sintético e verificação de tempo de atividade:

• Como encontrar registros
• Resolver problemas de notificações
• Resolver problemas de verificações de tempo de atividade públicas
• Resolver problemas de verificações de tempo de atividade privadas
• Resolver problemas de monitores sintéticos

Observação :os cabeçalhos de solicitação HTTP(S) incluem um campo chamado Check-Id, que armazena o identificador do monitor sintético ou da verificação de tempo de atividade associado à solicitação.

Encontrar registros

Esta seção fornece informações sobre como encontrar registros para seus monitores sintéticos e verificações de tempo de atividade:

1. No console do Google Cloud, acesse a página Análise de registros:

   Acessar a Análise de registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Execute um dos seguintes procedimentos:

   • Para encontrar todos os registros associados aos monitores sintéticos ou às verificações de tempo de atividade, faça uma consulta por tipo de recurso. Você pode usar o menu Resource ou inserir uma consulta.

     Para verificações de disponibilidade, no menu Recurso, selecione URL da verificação de disponibilidade ou insira a consulta a seguir no editor de consultas e clique em Executar consulta:

     resource.type="uptime_url"
     

     Para monitores sintéticos, no menu Recurso, selecione Revisão do Cloud Run ou insira a seguinte consulta na consulta e clique em Executar consulta:

     resource.type="cloud_run_revision"
     

   • Os registros de localização que contêm informações sobre a resposta recebida durante a execução de um monitor sintético ou de verificação de tempo de atividade, realize qualquer uma das seguintes:

     • Para consultar usando o ID do monitor sintético ou da verificação de tempo de atividade, use o seguinte formato ao inserir o ID no editor de consultas e clique em Executar consulta.

       labels.check_id="my-check-id"
       

     • Consultar registros que contenham dados de resposta para solicitações emitidos por monitores sintéticos e verificações de tempo de atividade, insira a consulta a seguir no editor de consultas e clique em Executar consulta

       "UptimeCheckResult"
       

       A consulta anterior corresponde a todas as entradas de registro que incluem a string "UptimeCheckResult".

     Esses registros incluem:

     • O ID do monitor sintético ou da verificação de tempo de atividade, que é armazenado em o campo labels.check_id.

     • Para monitores sintéticos, o nome da função do Cloud Run, que é armazenado no campo resource.labels.service_name.

     • Quando os dados de trace são coletados, o ID de um trace associado, que é armazenado no campo trace.

   • Para verificar se o serviço recebeu solicitações dos servidores do Google Cloud, copie a consulta a seguir no editor de consultas e depois clique em Executar consulta:

     "GoogleStackdriverMonitoring-UptimeChecks"
     

     O campo protoPayload.ip contém um dos endereços usados pelos servidores de verificação de tempo de atividade. Para informações sobre como listar todos os endereços IP, consulte Listar endereços IP.

Resolver problemas com notificações

Esta seção descreve alguns erros que podem ocorrer ao configurar políticas de alerta e fornece informações para resolvê-los.

Um verificador falhou, mas outros não

Você está revisando suas métricas de verificação de tempo de atividade e percebe que de segurança reportou uma falha quando todos os outros verificadores relataram sucesso.

Nenhuma ação é necessária para resolver essa situação.

Quando apenas um verificador relata uma falha, ela pode ser resultado do o tempo limite do comando do verificador se esgote devido a um problema na rede. Ou seja, em vez de falhar, o comando não é concluído dentro do tempo limite especificado.

As políticas de alertas que usam a configuração padrão exigem falhas pelo menos dois verificadores antes de criarem um incidente e enviarem uma notificação. Uma falha relatada por um único verificador não gera uma notificação.

Você recebeu uma notificação e quer depurar a falha

1. Para identificar quando a falha começou, faça o seguinte:

   • Para determinar quando a falha ocorreu nas verificações de tempo de atividade, consulte a página Detalhes do tempo de atividade:

     1. No console do Google Cloud, acesse a página  Verificações de tempo de atividade:

        Acesse Verificações de tempo de atividade

        Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

     2. Encontre e selecione a verificação de tempo de atividade.

        O gráfico Verificações aprovadas mostra o histórico de verificações. Para identificar quando a verificação de tempo de atividade falhou pela primeira vez, talvez seja necessário modificar o período do gráfico. O seletor de intervalo de tempo localizado na barra de ferramentas da página Detalhes do tempo de atividade.

   • Para determinar quando a falha ocorreu em monitores sintéticos, consulte a página Detalhes do tempo de atividade:

     1. No console do Google Cloud, acesse a página  Monitoramento sintético:

        Acessar Monitoramento sintético

        Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

     2. Encontre e selecione o monitor sintético.

2. Para saber como encontrar dados de registros associados, consulte a seção desta página intitulada Registros de descobertas.

Você não vai receber uma notificação de que uma verificação de tempo de atividade falhou

Você configurou uma verificação de tempo de atividade e está visualizando a página Detalhes do tempo de atividade dela. Você percebe que o gráfico Verificações aprovadas mostra que pelo menos um verificador falhou. No entanto, você não recebeu uma notificação.

Por padrão, a política de alertas é configurada para criar um incidente e enviar uma notificação quando os verificadores em pelo menos duas regiões não recebem uma resposta à verificação de tempo de atividade. Essas falhas precisam ocorrer simultaneamente.

É possível editar a condição da política de alertas para receber uma notificação quando uma única região não receber uma resposta. No entanto, recomendamos usar a configuração padrão, que reduz o número de notificações que você pode receber devido a falhas temporárias.

Para visualizar ou editar uma política de alertas, faça o seguinte:

1. No console do Google Cloud, acesse a página  Alertas:

   Acessar Alertas

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

2. Clique em Ver todas as políticas no painel Políticas.

3. Encontre a política que você quer consultar ou editar e clique no nome dela.

   É possível visualizar e editar a política na página Detalhes da política.

Resolver problemas de verificações de tempo de atividade públicas

Esta seção descreve alguns erros que você pode encontrar ao usar verificações de tempo de atividade públicas e fornece informações para resolvê-las.

Suas verificações de tempo de atividade públicas estão falhando

Você configura uma verificação de tempo de atividade pública, mas recebe um erro ao realize a etapa de verificação.

Veja a seguir algumas possíveis causas de falha na verificação de tempo de atividade:

• Connection Error - Refused: se você usa o tipo de conexão padrão HTTP, verifique se há um servidor da Web instalado que esteja respondendo a solicitações HTTP. Um erro de conexão pode acontecer em uma nova instância se você não tiver instalado um servidor da Web. Consulte o Guia de início rápido do Compute Engine. Se você usa um tipo de conexão HTTPS, talvez tenha que executar mais algumas etapas de configuração. Se tiver problemas de firewall, consulte Listar endereços IP do servidor de verificação de tempo de atividade.
• Nome ou serviço não encontrado: o nome do host pode estar incorreto.
• 403 Proibido: o serviço está retornando um código de erro para o verificador de tempo de atividade. Por exemplo, a configuração do servidor da Web Apache padrão retorna esse código no Amazon Linux, mas retorna 200 (Success) em algumas outras versões do Linux. Consulte o Tutorial de LAMP para Amazon Linux (em inglês) ou a documentação do servidor da Web.
• 404 Não encontrado: o caminho pode estar incorreto.
• 408 Request timeout ou sem resposta: o número da porta pode estar incorreto, o serviço pode não estar em execução ou estar inacessível, ou o tempo limite pode estar muito baixo. Verifique se o firewall permite o tráfego dos servidores de tempo de atividade, ver Listar endereços IP do servidor de verificação de tempo de atividade. O tempo limite é especificado como parte das opções de Validação de resposta.

Para ajudar a resolver problemas de falhas nas verificações de tempo de atividade públicas, é possível configurar as verificações de tempo de atividade para enviar até três pings ICMP durante a verificação. Os pings podem ajudar a distinguir entre falhas causadas, por exemplo, por problemas de conectividade de rede e por tempo limite no aplicativo. Para mais informações, consulte Use pings ICMP.

Resolver problemas de verificações de tempo de atividade particulares

Esta seção descreve alguns erros que você pode encontrar ao usar verificações de tempo de atividade particulares e fornece informações para resolvê-las.

Falha na criação da verificação de tempo de atividade

As configurações do projeto do Google Cloud podem impedir a modificação das funções atribuídas à conta de serviço que as verificações de tempo de atividade usam para gerenciar interações com o serviço do Diretório de serviços. Nessa situação, a criação da verificação de tempo de atividade falha.

Nesta seção, descrevemos como conceder os papéis aos quais a conta de serviço requer:

Console do Google Cloud

Ao usar o console do Google Cloud para criar a verificação de tempo de atividade particular, o console do Google Cloud emite os comandos para conceder do Diretório de serviços à conta de serviço.

Para mais informações sobre como conceder papéis a uma conta de serviço, consulte Autorizar a conta de serviço.

API: projeto do escopo

Na primeira vez que você cria uma verificação de disponibilidade privada para um serviço do diretório de serviços e recursos privados em um único projeto do Google Cloud, a solicitação pode ser bem-sucedida ou não. O resultado depende se você desativou as concessões automáticas de papéis para contas de serviço no seu projeto:

• A primeira criação da verificação de tempo de atividade é bem-sucedida se o projeto permitir concessões automáticas de papéis para contas de serviço. Uma conta de serviço é criado para você e recebe os papéis necessários.

• A primeira criação de verificação de tempo de atividade falha se o projeto não permitir concessões automáticas de papéis para contas de serviço. Uma conta de serviço é criada, mas nenhum papel é concedido.

Se a criação da verificação de tempo de atividade falhar, faça o seguinte:

1. Autorize a conta de serviço.
2. Aguarde alguns minutos até que as permissões sejam propagadas.
3. Tente criar a verificação de tempo de atividade privada novamente.

API: projeto monitorado

Na primeira vez que você cria uma verificação de disponibilidade privada que tem como destino um serviço do Diretório de serviços em um projeto monitorado ou recursos privados em um projeto diferente do Google Cloud, a solicitação falha e resulta na criação de uma conta de serviço do Monitoring.

A forma de autorizar a conta de serviço depende do número de projetos do Google Cloud que você está usando e das relações deles. Você pode ter até quatro projetos envolvidos:

• O projeto em que você definiu a verificação de tempo de atividade particular.
• O projeto monitorado em que você configurou o serviço do diretório de serviços.
• O projeto em que você configurou a rede VPC.
• O projeto em que os recursos de rede, como VMs ou balanceadores de carga, são configurados. Este projeto não tem papel na autorização de conta de serviço discutida aqui.

Quando a criação da primeira verificação de tempo de atividade falhar, faça o seguinte:

1. Autorize a conta de serviço.
2. Aguarde alguns minutos até que as permissões sejam propagadas.
3. Tente criar a verificação de tempo de atividade particular novamente.

Acesso negado

Suas verificações de tempo de atividade estão falhando com resultados VPC_ACCESS_DENIED. Esse resultado significa que algum aspecto da configuração de rede ou da autorização da conta de serviço não está correto.

Verifique se a autorização da conta de serviço usa um projeto de delimitação ou um projeto monitorado, conforme descrito em A criação da verificação de tempo de atividade falhou.

Para mais informações sobre como acessar redes privadas, consulte Configure o projeto de rede.

Resultados anormais das verificações de tempo de atividade particulares

Você tem um serviço do diretório de serviço com várias VMs, e a configuração do serviço contém vários endpoints. Quando você encerra uma das VMs, a verificação de tempo de atividade ainda indica sucesso.

Quando a configuração do serviço contém vários endpoints, um deles é escolhido aleatoriamente. Se a VM associada ao endpoint escolhido estiver em execução, a verificação de tempo de atividade vai ser bem-sucedida, mesmo que uma das VMs esteja inativa.

Cabeçalhos padrão

As verificações de tempo de atividade estão retornando erros ou resultados inesperados. Isso pode se você tiver substituído os valores padrão do cabeçalho.

Quando uma solicitação é enviada para uma verificação de disponibilidade particular em um endpoint de destino, ela inclui os seguintes cabeçalhos e valores:

Cabeçalho	Valor
HTTP_USER_AGENT	GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION	keep-alive
HTTP_HOST	IP do endpoint do Diretório de serviços
HTTP_ACCEPT_ENCODING	gzip, deflate, br
CONTENT_LENGTH	Calculado com base nos dados de postagem de tempo de atividade

Se você tentar substituir esses valores, o seguinte poderá acontecer:

• A verificação de tempo de atividade informa erros
• Os valores de substituição são descartados e substituídos pelos valores na tabela.

Nenhum dado visível

Nenhum dado é mostrado no painel de verificação de tempo de atividade quando a verificação está em um projeto do Google Cloud diferente do serviço do Service Directory.

Verifique se o projeto do Google Cloud que contém a verificação de tempo de atividade monitora o projeto do Google Cloud que contém o serviço do Service Directory.

Para mais informações sobre como listar projetos monitorados e adicionar outros, consulte Configurar um escopo de métricas para vários projetos.

Resolver problemas de monitores sintéticos

Esta seção fornece informações que podem ser usadas para ajudar na solução de problemas seus monitores sintéticos.

Mensagem de erro após ativar as APIs

Você abre o fluxo de criação de um monitor sintético e precisa ativar ter pelo menos uma API. Depois de ativar as APIs, uma mensagem semelhante à seguinte é exibido:

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

A mensagem de erro recomenda que você verifique se a API está ativada e, em seguida, aconselha que você aguarde e tente a ação novamente.

Para verificar se a API está ativada, acesse a página APIs e Serviços do seu projeto:

Acessar APIs e serviços

Depois de verificar se a API está ativada, você pode continuar com o fluxo de criação. A condição é resolvida automaticamente depois que a ativação da API é propagada pelo back-end.

As solicitações HTTP de saída não estão sendo rastreadas

Você configura o monitor sintético para coletar dados de trace para saída de solicitações HTTP. Os dados de trace mostram apenas um período, semelhante à captura de tela a seguir:

Para resolver essa situação, verifique se sua conta de serviço recebeu o papel de Agente do Cloud Trace (roles/cloudtrace.agent). Um papel de Editor (roles/editor) também é suficiente.

Para conferir os papéis concedidos à sua conta de serviço, faça o seguinte:

1. No console do Google Cloud, abra a página IAM.

   Acesse o IAM

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.

2. Selecione Incluir concessões de papel fornecidas pelo Google.

3. Se a conta de serviço usada pelo monitor sintético não estiver listada ou se ela não recebeu um papel que inclua as permissões na função de Agente do Cloud Trace (roles/cloudtrace.agent) e depois conceda esse papel ao conta de serviço.

   Se você não souber o nome da sua conta de serviço, selecione Contas de serviço no menu de navegação.

Status em andamento

A página Monitores sintéticos lista um monitor sintético com o status In progress. O status In progress significa que o monitor sintético foi criado recentemente e não há dados para exibir, ou que houve falha na implantação da função.

Para determinar se a função falhou na implantação, tente o seguinte:

• Verifique se o nome da função do Cloud Run não contém um sublinhado. Se houver um sublinhado, remova-o e reimplantar a função do Cloud Run.

• Abra a página Detalhes do monitor sintético no monitor.

  Se você receber a mensagem a seguir, exclua o monitor sintético.

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

  A mensagem de erro indica que a função foi excluída e, portanto, o monitor sintético não pode executar a função.

• Abra a página de funções do Cloud Run para a função. Para abrir essa página na página Detalhes do monitor sintético, clique em Código e, em seguida, no nome da função.

  Se você receber uma mensagem semelhante à seguinte, a função não foi implantada.

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

  Para resolver essa falha, revise o código da função e corrija os erros que impedem a criação ou implantação da função.

Quando você cria um monitor sintético, pode levar vários minutos para que o a ser implantada e executada.

Status de alerta

A página Monitores sintéticos lista um monitor sintético com o status Warning. O status Warning significa que a execução e os resultados forem inconsistentes. Isso pode indicar um problema de design com seu teste ou pode indicar que o que está sendo testado tem um comportamento inconsistente.

Status de falha

A página Monitores sintéticos lista um monitor sintético com o status Failing. Para saber mais sobre o motivo da falha, exibir o histórico de execução mais recente.

• Se a mensagem de erro Request failed with status code 429 for exibida, o alvo da solicitação HTTP rejeitou o comando. Para resolver isso, altere o destino do monitor sintético.

  O endpoint https://www.google.com rejeita solicitações feitas por monitores sintéticos.

• Se a falha estiver retornando um tempo de execução de 0ms, então o A função do Cloud Run pode estar ficando sem memória. Para resolver essa falha, edite a função do Cloud Run, aumente a memória para pelo menos 2 GiB e defina o campo de CPU como 1.

Falha na exclusão de um monitor sintético

A API Cloud Monitoring é usada para excluir um monitor sintético, mas a API falha com uma resposta semelhante à seguinte:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Para resolver a falha, exclua as políticas de alerta que monitorar os resultados e excluir o monitor sintético.

Não é possível editar a configuração de um verificador de links quebrados.

Você criou um verificador de links corrompidos usando o console do Google Cloud e quer para alterar os elementos HTML que são testados ou que você deseja modificar tempo limite do URI, novas tentativas, espera do seletor e opções por link. No entanto, quando você edita o verificador de links corrompidos, o console do Google Cloud não exibir os campos de configuração.

Para resolver essa falha, faça o seguinte:

1. No console do Google Cloud, acesse Página  Monitoramento sintético:

   Acessar Monitoramento sintético

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

2. Localize o monitor sintético que você quer editar, clique em Mais opções e selecione Editar.
3. Clique em Editar função.

4. Edite o objeto options no arquivo index.js e, em seguida, Clique em Aplicar função.

   Para obter informações sobre os campos e a sintaxe desse objeto, consulte broken-links-ok/index.js

5. Clique em Salvar.

Telas do console do Google Cloud que falham ao salvar capturas de tela

Observação: um monitor sintético que não salva capturas de tela continua testar os links contidos em um URI.

Você criou um verificador de links corrompidos e o configurou para salvar capturas de tela. No entanto, o console do Google Cloud está exibindo um dos seguintes avisos: junto com informações mais detalhadas:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Para resolver essas falhas, tente o seguinte:

• Se você vir a mensagem InvalidStorageLocation, verifique a existência do bucket do Cloud Storage especificado no campo options.screenshot_options.storage_location.

• Confira os registros relacionados à função do Cloud Run. Para mais informações, consulte Como encontrar registros.

• Verifique se a conta de serviço usada na função correspondente do Cloud Run tem um papel de Identity and Access Management que permite criar, acessar e gravar em buckets do Cloud Storage.