Solução de problemas da instalação do agente

Nesta página, você aprende a diagnosticar problemas na instalação ou na execução do agente do Monitoring.

Lista de verificação

Se você tiver problemas para instalar ou usar o agente do Monitoring, siga estas etapas:

  • Se os comandos de instalação do Linux resultarem em erros, certifique-se de prefixar os comandos de instalação com sudo.

  • Confira se o serviço do agente está em execução na instância da VM:

    • Para VMs do Windows, use o seguinte comando do PowerShell:

      Get-Service -Name StackdriverMonitoring
      

      Pesquise um serviço chamado Stackdriver Monitoring. Se o agente não estiver em execução, talvez seja necessário reiniciá-lo.

    • Para VMs do Linux, use o seguinte comando:

      sudo service stackdriver-agent status
      

      Se o agente não estiver em execução, talvez seja necessário reiniciá-lo com o seguinte comando:

      sudo service stackdriver-agent restart
      

      Se a reinicialização falhar e a saída do registro mostrar "Desativado por meio de metadados", é provável que você esteja executando uma imagem do Google Cloud Marketplace, em que o agente do Monitoring está desativado por padrão. Isso é controlado pela chave de metadados da instância google-monitoring-enable, com o valor 0. Para reativar o agente, remova essa chave ou defina o valor como 1. Consulte Como configurar metadados de instância.

      Se o agente não estiver desativado por meio dos metadados, reinstale-o. Para mais informações sobre esse processo, consulte Como reinstalar o agente.

  • Verifique se o agente tem mensagens de erro gravadas nos registros.

    • No Windows, o agente do Monitoring grava mensagens no log de eventos do Windows.

    • No Linux, o agente do Monitoring é um pacote collectd e registra mensagens em /var/log/syslog ou /var/log/messages. As mensagens de registro são prefixadas por collectd ou stackdriver-agent:

      • Se forem exibidos erros HTTP 429, talvez você tenha excedido as cotas da API Monitoring. É possível ver sua cota disponível selecionando APIs e serviços > Painel no Console do Cloud. Escolha a API Monitoring.

      • Se houver problemas de proxy, verifique se o proxy HTTP foi configurado corretamente. As instruções estão incluídas em Como instalar no Linux e no Windows.

      • Se houver problemas de autorização e de acesso à API ou mensagens de erro como "Impossível determinar o endpoint chamado", consulte a seção Como verificar o projeto e as credenciais a seguir .

      • Se forem exibidos os erros "Combinação de tipo/plug-in collectd incompatível" ou "Código de collectd incompatível" nos registros, talvez você esteja enviando métricas de agentes incompatíveis. Isso pode acontecer nos seguintes cenários:

        • Você modificou uma das configurações de aplicativos de terceiros do agente. Para reverter as alterações, reinstale a configuração do plug-in específico seguindo as instruções na página de documentação relevante. Se você quiser usar o agente para enviar essas métricas para o Monitoring, converta-as em métricas personalizadas.

        • Um dos plug-ins de aplicativos de terceiros está enviando novas métricas que são desconhecidas do Monitoring. Consulte a página de suporte para detalhes sobre como enviar uma solicitação para que essas métricas sejam analisadas e categorizadas.

  • Se o agente está sendo executado normalmente, mas você não está recebendo dados, ou as políticas de alertas não estão funcionando como esperado, é recomendável verificar se o agente está enviando dados ao projeto correto para começar. Consulte a seção a seguir Como verificar o projeto e as credenciais.

Verificar o projeto e as credenciais

Se o agente estiver informando erros de acesso ou autorização, ou se o agente aparentemente estiver sendo executado normalmente, mas não houver dados ou as políticas de alertas não estiverem funcionando conforme o esperado, verifique se as credenciais da instância de VM estão corretas, incluindo se especificam o projeto correto:

  • Para verificar se os dados estão chegando ao Monitoring, tente ler alguns dos dados da série temporal. Consulte Como verificar a conexão entre o agente e o projeto para ver mais instruções. Se você consegue ver os dados, o problema não é com o agente.

  • Se estiver usando uma instância de VM do Compute Engine com credenciais padrão, e não uma chave privada, é pouco provável que os dados estejam indo para o projeto errado. Talvez suas credenciais ainda estejam incompletas. Para ver informações sobre credenciais, consulte Como autorizar o agente. Para verificar as credenciais, consulte Como verificar credenciais do Compute Engine.

  • Se você estiver usando uma instância de VM do Amazon EC2 ou credenciais de chave privada na instância do Compute Engine, as credenciais poderão ser inválidas ou provenientes do projeto errado. Em contas da AWS, o projeto usado pelo agente precisa ser o projeto de conector da AWS. Para informações sobre credenciais, consulte Como autorizar o agente. Consulte Como verificar credenciais de chave privada para verificar as credenciais.

Se ainda não tiver resolvido o problema, consulte Como reinstalar o agente.

Como verificar os dados do agente

Para verificar se o agente está enviando as métricas corretamente, use o método timeSeries.list da API Monitoring para procurar dados recentes da série temporal recebidos da instância de VM. Chame o método usando a API Explorer na página de documentação do método. Se nenhum dado for exibido, é possível que o agente esteja enviando dados para o projeto errado. Para conferir isso, consulte Como verificar o projeto e as credenciais.

Veja instruções detalhadas sobre o uso do método timeSeries.list:

  1. Determine o código da instância de VM em que o agente foi instalado:

    • Instâncias do Compute Engine: acesse a página de detalhes da instância. Na parte inferior da página, clique em REST equivalente. O código é um número de 19 dígitos.

    • Instâncias do Amazon EC2: o ID de cada instância é mostrado na lista de instâncias. O código se parece com i-1a2b3c4d.

  2. Acesse a página de documentação do método timeSeries.list.

  3. Preencha o formulário da API Explorer:

    1. Defina um nome para o projeto que contém sua instância de VM, com o prefixo projects/. Por exemplo, projects/[YOUR_PROJECT_ID]. Para instâncias do Amazon EC2, use o projeto do conector da AWS da conta da Amazon.

    2. Defina filter como a linha a seguir para escolher uma métrica do agente recebida da instância de VM. Copie e cole-o no APIs Explorer e, em seguida, altere o ID da instância de VM:

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
      
    3. Defina o período da pesquisa. Recomendamos um intervalo de aproximadamente cinco minutos:

      • Defina interval.endTime como o horário GMT atual, que pode ser encontrado em time.is/GMT. A hora precisa ser formatada como no exemplo a seguir. Não coloque o horário entre aspas:

        2016-10-31T14:10:00Z
        
      • Defina interval.startTime como aproximadamente cinco minutos antes do horário de término usando o mesmo formato.

    4. Deixe todos os outros campos em branco.

  4. Clique em Executar.

O resultado será assim:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[GCP-OR-AWS-INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Se a chamada à API retornar dados da série temporal da instância de VM, como mostrado acima, isso significa que o agente está funcionando corretamente e você concluiu o processo.

Se nenhum dado da série temporal for mostrado, verifique o seguinte:

  • Se a chamada de API resultar em uma mensagem de erro, isso não indica um problema no agente. Verifique se os campos do API Explorer estão preenchidos corretamente:

    • Erros de "argumento inválido" provavelmente indicam um problema com a ortografia e o formato do ID do projeto, filtro ou os dois carimbos de data/hora.

      Os requisitos para os argumentos do carimbo de data/hora dependem do tipo de métrica especificado. Um tipo de métrica registra dados GAUGE, DELTA ou CUMULATIVE. Consulte MetricKind para mais informações.

      Para as métricas DELTA e CUMULATIVE, os horários de início e término são obrigatórios, e o horário de término precisa ser posterior ao horário de início. Esses tipos de métricas gravam alterações medidas ao longo do tempo. Portanto, os horários de início e de término precisam definir um intervalo diferente de zero.

    • A mensagem de erro "Não autorizado" pode significar que você escreveu o ID do projeto errado.

    • A mensagem de erro "Não encontrado" pode indicar que você omitiu o prefixo projects/ obrigatório no campo "nome".

    Corrija os problemas e teste a chamada à API novamente.

  • Se a chamada de API for bem-sucedida, mas você ainda receber apenas uma resposta vazia, { }, verifique se o filtro e o período estão corretos. Alguns erros na formatação dos carimbos de data/hora impedem o recebimento de dados. Se tudo estiver correto, mas você não estiver recebendo dados, o agente não está enviando dados de métricas ou pelo menos não para o projeto esperado. Isso pode indicar um problema com as credenciais. Consulte Como verificar credenciais de chave privada.

Como verificar as credenciais do Compute Engine

Use a página Instâncias de VM do Compute Engine no Console do Cloud para verificar se a instância de VM do Compute Engine tem uma credencial adequada para o agente do Monitoring. Normalmente, as credenciais são adicionadas à conta de serviço padrão de todas as novas instâncias de VM do Compute Engine, mas é possível substituir esses padrões ao criar uma instância.

Ir para a página de instâncias do Compute Engine

  1. Se necessário, altere o projeto atual do Google Cloud para associá-lo à sua instância de VM do Compute Engine. Por exemplo, se você for solicitado a Ativar faturamento, significa que o projeto atual não tem nenhuma instância de VM do {compute_name}}.
  2. Na página Instâncias de VM, clique no nome da instância. A página de detalhes dela é exibida.
  3. Na página Detalhes da instância de VM, verifique o cabeçalho Escopos de acesso à API Cloud:
    1. Você tem as credenciais adequadas se a mensagem "Permitir acesso completo a todas as Cloud APIs" for exibida.
    2. Se aparecer a permissão Somente gravação ou Total ao lado de API Cloud Monitoring, você tem as credenciais adequadas.
    3. Caso contrário, a conta de serviço padrão da instância não tem as credenciais necessárias para o agente. Para usar o agente na instância, você precisa adicionar as credenciais da conta de serviço da chave privada. Para ver instruções, consulte Como adicionar credenciais.

Se você tiver as credenciais padrão corretas, prossiga para Como instalar no Linux e Windows.

Como verificar credenciais de chave privada

Para verificar se as credenciais de chave privada válidas estão instaladas na instância de VM, confirme primeiro se o arquivo de credenciais está na localização esperada e se as informações nele são válidas. As credenciais anteriormente válidas podem ser revogadas por meio da seção IAM e Administrador > Contas de serviço do Console do Cloud. Se não houver credenciais válidas, consulte Como adicionar credenciais para substituir as existentes ou adicionar novas.

As credenciais estão presentes?

Para ver se as credenciais da conta de serviço de chave privada estão na instância, execute os seguintes comandos do Linux na instância:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Se um dos comandos exibir um arquivo conforme mostrado a seguir, pode ser que a instância tenha credenciais de chave privada válidas. Se ambos os comandos exibirem um arquivo, será usado o arquivo indicado por GOOGLE_APPLICATION_CREDENTIALS.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Se não houver arquivos de credenciais presentes, consulte Como adicionar credenciais.

As credenciais são válidas?

No arquivo de credenciais, project_id é o projeto do Google Cloud, client_email identifica a conta de serviço no projeto e private_key_id identifica a chave privada na conta de serviço. Combine essas informações com o que é exibido na seção IAM e Administrador > Contas de serviço do Console do Cloud.

O arquivo de credenciais não é válido se alguma das seguintes condições for verdadeira:

  • Você está verificando uma instância de VM do Compute Engine, mas o projeto do Google Cloud no arquivo de credenciais não é o que contém a instância.
  • Você está verificando uma instância do Amazon EC2, mas o projeto do Google Cloud no arquivo de credenciais não é o projeto de conector da AWS da conta da AWS.
  • A conta de serviço listada não existe. Ela pode ter sido excluída.
  • A conta de serviço listada não tem os papéis certos ativados. Ela deve ter pelo menos roles/monitoring.metricWriter (Gravador de métricas do Monitoring) para o agente do Monitoring e roles/logging.logWriter (Gravador de registros) para o agente do Logging.
  • A chave privada não existe. Ela pode ter sido revogada.

Se a conta de serviço está correta, mas a chave privada foi revogada, você pode criar uma nova chave privada e copiá-la na sua instância. Caso contrário, você precisa criar uma nova conta de serviço, conforme descrito na seção Como adicionar credenciais.

Como gerar novas credenciais

Se as credenciais não forem válidas, realize as seguintes etapas:

  1. Para cada projeto conectado que contém instâncias que precisam ser autorizadas com uma chave privada (projetos de conector da AWS e =projetos que contêm instâncias do Compute Engine criadas sem incluir o escopo).monitoring.write ), crie uma conta de serviço e gere uma chave privada, se elas ainda não existirem. Siga as etapas abaixo:

    1. Para ver a lista de projetos conectados ao escopo de métricas, acesse o Monitoring:

      Acessar o Monitoramento

    2. Se estiver no painel de navegação do Monitoring, selecione Configurações e, em seguida, selecione a guia Resumo.

      • Na AWS, use o link para navegar diretamente para o projeto em questão no Console do Google Cloud.
      • Para o Google Cloud, identifique o projeto que contém os recursos do Compute Engine em questão e navegue até o Console do Google Cloud.
    3. No Console do Google Cloud, acesse a página Contas de serviço do IAM.

    4. Crie uma nova conta de serviço e gere uma nova chave privada para ela.

      O jeito mais simples é fazer o download de uma chave privada com a configuração correta. Essa chave pode ser obtida modificando o URL da página atual: acrescente &createStackdriverServiceAccount no final do URL. Para mais informações, consulte Como criar uma conta de serviço.

  2. Substitua a chave privada pelas instâncias que correspondem à conta de serviço em questão.

    • No Linux, substitua a chave privada localizada em /etc/google/auth/application_default_credentials.json
    • No Windows, substitua a chave privada localizada em C:\ProgramData\Google\Auth\application_default_credentials.json. Para mais detalhes, consulte Como copiar a chave privada para a instância.
  3. Reinicie o agente.

    • No Linux, execute sudo service stackdriver-agent restart.
    • No Windows, acesse o console de gerenciamento de serviços e reinicie o serviço Cloud Monitoring.

Se você tiver vários projetos que precisam de novas chaves privadas, repita esse processo para cada um deles.

Para verificar se a chave privada está correta, consulte As credenciais estão presentes?. Em especial:

  • Leia o arquivo JSON da chave privada na instância. Por exemplo (no Linux): sudo cat /etc/google/auth/application_default_credentials.json
  • Verifique se o valor de project-id corresponde ao valor do projeto monitorado para o qual você acabou de gerar credenciais.

Como reinstalar o agente

A instalação da versão mais recente do agente soluciona muitos problemas:

Como determinar quais VMs do Linux têm o agente instalado

  • Execute uma das seguintes consultas para ver quais VMs do Linux estão executando o agente:

    Para cada consulta, é necessário inserir o nome do projeto e ajustar os limites de tempo.

Como reiniciar o agente automaticamente

Configure um script para verificar se o agente está em execução. Depois, reinicie o agente em caso de falha.

Por exemplo, no Linux, é possível criar a seguinte entrada crontab para verificar o status do agente a cada cinco minutos:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Problemas conhecidos

  • Problema de acesso a dados do processo (Windows):

    Pode ser que você veja uma mensagem de erro do agente de eventos do Windows semelhante a esta:

    Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)
    

    Essa mensagem indica que o agente não tem acesso a esses dados no sistema. Para deixar de ver essa mensagem, forneça permissões suficientes ao usuário SYSTEM para ler os dados dos processos e serviços listados nas mensagens de erro. Se você não precisar desses dados, poderá ignorar essas mensagens informativas com segurança.

  • Problemas de cache de metadados (Linux):

    Pode ser que você veja uma mensagem de erro no arquivo de registro do sistema Linux (/var/log/syslog no Debian e Ubuntu ou /var/log/messages no Red Hat, CentOS e SLES) semelhante a esta:

    collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
    value time = 1511345468.180; last cache update = 1511345468.180;
    write_gcm: wg_update_stats failed.
    write_gcm: uc_update returned an error.
    

    Essas mensagens são avisos inofensivas e não são uma indicação da perda de dados. Essas mensagens são geradas pela implementação atual do plug-in de processos quando há uma incompatibilidade de carimbo de data/hora.

  • Problema de ponto de dados de valor infinito descartado (Linux):

    Pode ser que você veja uma mensagem de erro no arquivo de registro do sistema Linux (/var/log/syslog no Debian e Ubuntu ou /var/log/messages no Red Hat, CentOS e SLES) semelhante a esta:

    write_gcm: can not take infinite value
    

    Essa mensagem indica que um único ponto de dados malformado foi descartado. Isso normalmente é inofensivo e pode ser ignorado.

  • Problema de limitação da chave de metadados (Linux):

    Pode ser que você veja uma mensagem de erro no arquivo de registro do sistema Linux (/var/log/syslog no Debian e Ubuntu ou /var/log/messages no Red Hat, CentOS e SLES) semelhante a esta:

    collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
    collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed
    

    Essa mensagem indica que a atualização de status da limitação de memória falhou uma vez. Normalmente, é inofensivo, mas pode ser um sinal de que o agente está ficando sem memória, especialmente se ocorrer com frequência.

  • Problema de cota da API Cloud Monitoring fora do Linux (Linux):

    Pode ser que você veja uma mensagem de erro no arquivo de registro do sistema Linux (/var/log/syslog no Debian e Ubuntu ou /var/log/messages no Red Hat, CentOS e SLES) semelhante a esta:

    collectd[25198]: write_gcm: Unsuccessful HTTP request 429
    

    Esta mensagem indica que o limite da cota da API Cloud Monitoring foi atingido. Consulte o guia Cota para informações sobre como gerenciar o limite de cota.

  • Uso elevado da memória devido ao baixo COLLECTD_INTERVAL (Linux):

    Talvez você veja o alto uso da memória do agente quando o COLLECTD_INTERVAL estiver configurado para ser menor do que o 60 seconds padrão, por exemplo, 10 seconds. Essa é uma limitação conhecida do agente porque envia solicitações em série a partir de uma única linha de execução. Para atenuar isso, considere reduzir o COLLECTD_INTERVAL apenas para um subconjunto de métricas necessárias e deixe o restante das métricas no intervalo padrão.