Resolver problemas no agente do Monitoring

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, reinicie-o usando o seguinte comando:

      sudo service stackdriver-agent restart

      Se a reinicialização falhar e a saída do registro mostrar "Desativada por metadados", é provável que você esteja executando uma imagem do Google Cloud Marketplace, em que o agente do Logging 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 de metadados, reinstale-o. Para informações sobre esse processo, consulte Como reinstalar o agente do Monitoring.

  • 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. Veja sua cota disponível selecionando APIs e serviços > Painel no console do Google 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 ao Monitoring, considere convertê-las em métricas definidas pelo usuário.

        • 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 parece que o agente está sendo executado normalmente, mas você não está recebendo dados ou que suas políticas de alertas não estão funcionando como deveria, verifique se o agente está enviando dados ao projeto correto. de dados. Consulte a seção a seguir Como verificar o projeto e as credenciais.

Verificar o projeto e as credenciais

Quando o agente do Monitoring informa erros de acesso ou de autorização ou quando parece que o agente está em execução normalmente, mas não há dados, ou quando as políticas de alertas não funcionam como esperado, verifique se as credenciais da instância de VM estão corretas, inclusive se elas especificam o projeto certo:

  • 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 informações sobre credenciais, consulte Autorizar o agente do Monitoring. Para verificar as credenciais, consulte Como verificar credenciais do Compute Engine.

  • Se estiver usando uma instância de VM do Amazon EC2 ou credenciais de chave privada na instância do Google Compute Engine, pode ser que as credenciais sejam inválidas ou provenientes do projeto errado. Para contas da AWS, o projeto usado pelo agente deve ser o projeto do Google Cloud em que você está como enviar as métricas. Para informações sobre credenciais, consulte Autorizar o agente do Monitoring. Consulte Como verificar credenciais de chave privada para verificar as credenciais.

Se você ainda não resolveu seu problema, consulte Como reinstalar o agente do Monitoring.

Como verificar credenciais do Compute Engine

Use a página de Instâncias de VM do Compute Engine, do console do Google Cloud, para verificar se a instância de VM do Compute Engine tem credenciais adequadas 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.

No Console do Google Cloud, acesse a página Instâncias de VM.

Acessar Instâncias de VM

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

  1. Se necessário, altere o projeto atual do Google Cloud para ser associado à instância de VM do Compute Engine. Por exemplo, se for solicitado que você ative o faturamento, isso significa que o projeto atual não tem nenhuma instância de VM do Compute Engine.
  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:
    • Suas credenciais serão adequadas se a mensagem "Permitir acesso completo a todas as Cloud APIs" for exibida.
    • Se aparecer ao lado de API Stackdriver Monitoring, um nome mais antigo para a API Cloud Monitoring, você tem Somente gravação ou Total, você terá as credenciais adequadas.
    • Caso contrário, a conta de serviço padrão da instância não terá 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 Google 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, o campo 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 Google Cloud.

O arquivo de credenciais não será válido se uma 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 projeto que contém a instância.
  • Você está verificando uma instância do Amazon EC2, mas o projeto do Google Cloud na de credenciais não é o projeto do Google Cloud para o qual você enviar as métricas da sua 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 a coleta de métricas e roles/logging.logWriter (Gravador de registros) para registros de gravação.
  • 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, siga estas etapas:

  1. Para cada projeto conectado que contém instâncias que precisam ser autorizadas com uma chave privada (Cada projeto que contém instâncias do Compute Engine que foram criadas sem incluir o escopo de acesso https://www.googleapis.com/auth/monitoring.write), crie uma conta de serviço e gere uma chave privada, se ela ainda não existir. Siga as etapas abaixo:

    1. No console do Google Cloud, abra a página  Configurações:

      Acessar Configurações

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

    2. Selecione a guia Escopo Netric.
    3. Identifique o projeto que contém os recursos do Compute Engine em questão e navegue para o console do Google Cloud.
    4. Acesse a página Contas de serviço do IAM do console do Google Cloud, selecione seu projeto do Google Cloud, crie uma nova conta de serviço e gere uma nova chave privada para essa conta de serviço.

      Para executar essas etapas, siga um destes procedimentos:

      • Acesse a página Contas de serviço do IAM, selecione seu projeto do Google Cloud e siga as etapas em Criar uma conta de serviço:

        Acessar as contas de serviço do IAM

      • Clique no botão a seguir e selecione seu projeto do Google Cloud:

        Crie uma conta de serviço e faça o download da chave

        O botão anterior automatiza o processo de criação e download de uma chave do sistema local para a conta de serviço específica do agente. Se necessário, o processo também cria a conta de serviço necessária e garante que ela tenha as permissões corretas. As contas de serviço específicas do agente têm um nome semelhante a stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Você será notificado sobre a conclusão dessas ações com uma caixa de diálogo semelhante a esta:

        Um banner notificando o usuário de que uma conta de serviço e uma chave foram criadas.

  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 obter mais informações, consulte Copiar a chave privada na sua instância.

  3. Reinicie o agente.

    • No Linux, execute sudo service stackdriver-agent restart.
    • No Windows, acesse o console de gerenciamento de serviço 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?. Especificamente:

  • 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 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. Você pode chamar o método usando o APIs Explorer na página de documentação do método. Se não houver dados, talvez 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.

    • Amazon EC2: o código 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 do APIs 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].

    2. Defina filter como a linha a seguir para escolher uma métrica do agente recebida da instância de VM. Copie essa métrica e cole-a no APIs Explorer. Em seguida, altere o código 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": "[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.

Caso não veja os dados de série temporal, verifique o seguinte:

  • Se a chamada da API resultar em uma mensagem de erro, isso não indicará um problema com o agente. Verifique se os campos das APIs Explorer estão preenchidos corretamente.

    • Os erros de "argumento inválido" provavelmente indicam um problema de digitação e de formato do ID do projeto, do filtro ou dos 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 parecer correto, e ainda assim você não receber os dados, isso significa que o agente não está enviando os 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 reinstalar o agente do Monitoring

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

As seções a seguir descrevem problemas conhecidos pelo agente do Monitoring.

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 inofensivos e não são uma indicação de perda de dados. Essas mensagens são geradas pela implementação do plug-in de processos atuais 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 falta de cota da API Monitoring (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 de cota da API Monitoring foi atingido. Consulte o guia Cota para informações sobre como gerenciar seu 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.

Problema de estouro de buffer de token (Linux)

Talvez você veja uma mensagem de erro no arquivo de registro do sistema (/var/log/syslog no Debian/Ubuntu ou /var/log/messages no Red Hat/CentOS/GiB) semelhante a esta:

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Essas mensagens indicam que é preciso fazer upgrade do agente do Monitoring para a versão 6.1.2 ou mais recente.

O repositório mudou o valor de "Origin" (Linux)

Talvez você veja uma mensagem de erro semelhante à seguinte ao fazer upgrade do agente, instalá-lo ou executar apt-get update no Debian/Ubuntu Linux:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Essa mensagem indica que o cache do repositório de pacotes pode ter divergente da origem. Para isso, execute este comando: .

apt-get --allow-releaseinfo-change update

Em seguida, execute o upgrade ou instale novamente.

Agente removido informado pelo console do Google Cloud como instalado

Depois de desinstalar o agente, o console do Google Cloud pode levar até uma hora para informar essa alteração.

O agente do Monitoring não aparece na lista "Desinstalar um programa" do Windows

Para desinstalar o agente do Monitoring quando ele não estiver na lista Desinstalar um programa do Painel de Controle do Windows, execute uninstall.exe no diretório em que você o instalou.