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

Este documento fornece informações sobre como encontrar dados de registro e como resolver problemas de monitoração sintética e falhas de verificação de tempo de atividade:

• Como encontrar registros
• Resolver problemas com 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 rotulado como Check-Id, que armazena o identificador do monitor sintético ou da verificação de tempo de atividade associada à 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 consulta a seguir no editor de consultas e clique em Executar consulta:

     resource.type="cloud_run_revision"
     

   • Os registros de pesquisa que contêm informações sobre a resposta recebida durante a execução de um monitor sintético ou de uma verificação de tempo de atividade fazem o seguinte:

     • 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"
       

     • Para consultar registros que contêm dados de resposta para solicitações emitidas 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, armazenado no 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 de Google Cloud servidores, copie a consulta a seguir no editor de consultas e 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.

Uma verificação falhou, mas outras não

Você está analisando as métricas de verificação de tempo de atividade e percebe que uma verificação relatou uma falha quando todas as outras informaram sucesso.

Não é preciso fazer nada para resolver essa situação.

Quando apenas um verificador informa uma falha, ela pode ser resultado do tempo limite do comando do verificador devido a um problema de rede. Em vez de falhar, o comando não é concluído dentro do tempo limite especificado.

As políticas de alerta que usam a configuração padrão exigem falhas de pelo menos dois verificadores antes de criar um incidente e enviar uma notificação. Uma falha informada por um único verificador não resulta em 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 concluídas mostra o histórico das 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 está 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 registro associados, consulte a seção desta página intitulada Encontrar registros.

Você não recebe 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 conferir 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 podem ocorrer ao usar verificações de tempo de atividade pública e fornece informações para resolvê-los.

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 realizar 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 tráfego proveniente dos servidores de tempo de atividade. Consulte 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 tempos limite no aplicativo. Para mais informações, consulte Usar pings ICMP.

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

Esta seção descreve alguns erros que podem ocorrer ao usar verificações de tempo de atividade privadas e fornece informações para resolvê-los.

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.

Esta seção descreve como conceder os papéis necessários para a conta de serviço:

Console do Google Cloud

Quando você usa o Console do Google Cloud para criar a verificação de disponibilidade privada, o console emite os comandos para conceder as funções do diretório de serviço à conta de serviço.

Para saber como conceder papéis a uma conta de serviço, consulte Autorizar a conta de serviço.

API: projeto de 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 falhar. 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 de verificação de tempo de atividade vai ser bem-sucedida se o projeto permitir concessões automáticas de papéis para contas de serviço. Uma conta de serviço é criada 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 privada 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 particulares, consulte Configurar 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ê desliga 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 ocorrer se você tiver substituído os valores de cabeçalho padrão.

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 post 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 ajudar a resolver problemas com os monitores sintéticos.

Mensagem de erro após ativar as APIs

Você abre o fluxo de criação de um monitor sintético e é solicitado que ative pelo menos uma API. Depois de ativar as APIs, uma mensagem semelhante a esta será exibida:

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

Para resolver essa situação, verifique se a conta de serviço recebeu o papel de agente do Cloud Trace (roles/cloudtrace.agent). O 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 tiver recebido um papel que inclua as permissões no papel de Agente do Cloud Trace (roles/cloudtrace.agent), conceda esse papel à sua 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. Um status de In progress significa que o monitor sintético foi criado recentemente e não há dados para exibir ou que a função não foi implantada.

Para determinar se a função não foi implantada, 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 reimplante a função do Cloud Run.

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

  Se você receber a mensagem abaixo, 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 consegue executá-la.

• 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 estão impedindo a criação ou implantação da função.

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

Status de alerta

A página Monitores sintéticos lista um monitor sintético com o status Warning. Um status de Warning significa que os resultados da execução são inconsistentes. Isso pode indicar um problema de design com seu teste ou 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, confira o histórico de execução mais recente.

• Se a mensagem de erro Request failed with status code 429 for mostrada, o destino da solicitação HTTP rejeitou o comando. Para resolver essa falha, mude o destino do monitor sintético.

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

• Se a falha retornar um tempo de execução de 0ms, a função do Cloud Run pode estar 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

Você usa a API Cloud Monitoring para excluir um monitor sintético, mas a chamada da API falha com uma resposta semelhante a esta:

{
  "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 monitoram os resultados do monitor sintético e, em seguida, exclua o monitor sintético.

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

Você criou um verificador de links quebrados usando o console do Google Cloud e quer mudar os elementos HTML que são testados ou modificar o tempo limite do URI, as tentativas, a espera pelo seletor e as opções por link. No entanto, ao editar o verificador de links quebrados, o console do Google Cloud não mostra os campos de configuração.

Para resolver esse problema, faça o seguinte:

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. 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 clique em Aplicar função.

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

5. Clique em Salvar.

O console do Google Cloud mostra que o salvamento de capturas de tela falhou

Observação: um monitor sintético que não pode salvar capturas de tela continua testando 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á mostrando uma das seguintes mensagens de aviso com informações mais detalhadas:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Para resolver essas falhas, tente o seguinte:

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

• Acesse 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.