Resolva problemas de carregamento de dados do Ops Agent

Este documento fornece informações para ajudar a diagnosticar e resolver problemas de carregamento de dados, para registos e métricas, no agente de operações em execução. Se o agente de operações não estiver em execução, consulte o artigo Resolva problemas de instalação e início.

Antes de começar

Antes de tentar corrigir um problema, verifique o estado das verificações de funcionamento do agente.

Google Cloud A consola mostra a instalação do agente de operações bloqueada no estado "Pendente"

Mesmo depois de instalar com êxito o agente de operações, a Google Cloud consola pode continuar a apresentar o estado "Pendente". Use gcpdiag para confirmar a instalação do agente de operações e verificar se o agente está a transmitir registos e métricas da sua instância de VM.

Motivos comuns para a falha de instalação

A instalação do agente Ops pode falhar pelos seguintes motivos:

• A VM não tem uma conta de serviço anexada. Anexe uma conta de serviço à VM e, de seguida, reinstale o agente de operações.

• A VM já tem um dos agentes antigos instalados, o que impede a instalação do agente de operações. Desinstale os agentes antigos e, em seguida, reinstale o agente de operações.

Motivos comuns para falhas na transmissão de telemetria

Um agente de operações instalado e em execução pode não enviar registos, métricas ou ambos a partir de uma VM pelos seguintes motivos:

• A conta de serviço anexada à VM não tem a função roles/logging.logWriter ou roles/monitoring.metricWriter.
• O âmbito de acesso ao registo ou à monitorização não está ativado. Para obter informações sobre como verificar e atualizar os âmbitos de acesso, consulte o artigo Valide os seus âmbitos de acesso.
• A API Logging ou a API Monitoring não está ativada.

Use verificações do estado do agente para identificar a causa principal e a solução correspondente.

O agente está em execução, mas os dados não são carregados

Use o Explorador de métricas para consultar a métrica uptime do agente e verifique se o componente do agente, google-cloud-ops-agent-metrics ou google-cloud-ops-agent-logging, está a escrever na métrica.

1. Na Google Cloud consola, aceda à página  Explorador de métricas:

   Aceda ao Metrics Explorer

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

2. No botão Código do criador, selecione Código e, de seguida, defina o idioma como PromQL.

3. Introduza a seguinte consulta e, de seguida, clique em Executar:

   rate({"agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])
   

O agente está a enviar registos para o Cloud Logging?

Se o agente estiver em execução, mas não estiver a enviar registos, verifique o estado das verificações de funcionamento do tempo de execução do agente.

Erros de pipeline

Se vir o erro de tempo de execução LogPipelineErr ("Ops Agent logging pipeline failed"), significa que o subagente de registo encontrou um problema ao escrever registos. Verifique as seguintes condições:

• Verifique se os ficheiros de armazenamento do subagente de registo estão acessíveis. Estes ficheiros encontram-se nas seguintes localizações:
  • Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
  • Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
• Verifique se o disco da VM não está cheio.
• Verifique se a configuração de registo está correta.

Estes passos requerem que aceda à VM através de SSH.

Se alterar a configuração de registo ou se os ficheiros de buffer estiverem acessíveis e o disco da VM não estiver cheio, reinicie o agente de operações:

Linux

1. Para reiniciar o agente, execute o seguinte comando na sua instância:

   sudo systemctl restart google-cloud-ops-agent
   

2. Para confirmar que o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente de registo" foram iniciados:

   sudo systemctl status "google-cloud-ops-agent*"
   

Windows

1. Estabeleça ligação à sua instância através do RDP ou de uma ferramenta semelhante e inicie sessão no Windows.
2. Abra um terminal do PowerShell com privilégios de administrador: clique com o botão direito do rato no ícone do PowerShell e selecione Executar como administrador
3. Para reiniciar o agente, execute o seguinte comando do PowerShell:

   Restart-Service google-cloud-ops-agent -Force
   

4. Para confirmar que o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente de registo" foram iniciados:

   Get-Service google-cloud-ops-agent*
   

Erros de análise de registos

Se vir o erro de tempo de execução LogParseErr ("O agente de operações não conseguiu analisar os registos"), o problema mais provável está na configuração de um processador de registo. Para resolver este problema, faça o seguinte:

• Verifique se a configuração de todos os parse_json processadores está correta.
• Verifique se a configuração de todos os parse_regex processadores está correta.
• Se não tiver processadores parse_json ou parse_regex, verifique a configuração de quaisquer outros processadores de registo.

Estes passos requerem que aceda à VM através de SSH.

Se alterar a configuração de registo, reinicie o agente de operações:

Linux

1. Para reiniciar o agente, execute o seguinte comando na sua instância:

   sudo systemctl restart google-cloud-ops-agent
   

2. Para confirmar que o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente de registo" foram iniciados:

   sudo systemctl status "google-cloud-ops-agent*"
   

Windows

1. Estabeleça ligação à sua instância através do RDP ou de uma ferramenta semelhante e inicie sessão no Windows.
2. Abra um terminal do PowerShell com privilégios de administrador: clique com o botão direito do rato no ícone do PowerShell e selecione Executar como administrador
3. Para reiniciar o agente, execute o seguinte comando do PowerShell:

   Restart-Service google-cloud-ops-agent -Force
   

4. Para confirmar que o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente de registo" foram iniciados:

   Get-Service google-cloud-ops-agent*
   

Verifique as métricas locais

Nota: o serviço de métricas locais não está disponível no Windows.

Estes passos requerem que aceda à VM através de SSH.

• O módulo de registo está em execução? Use os seguintes comandos para verificar:

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

Abra o Windows PowerShell como administrador e execute:

Get-Service google-cloud-ops-agent

Também pode verificar o estado do serviço na app Serviços e inspecionar os processos em execução na app Gestor de tarefas.

Verifique o registo do módulo de registo

Este passo requer que entre na VM através de SSH.

Pode encontrar os registos do módulo de registo em /var/log/google-cloud-ops-agent/subagents/*.log para Linux e C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log para Windows. Se não existirem registos, significa que o serviço do agente não está a ser executado corretamente. Aceda primeiro à secção O agente está instalado, mas não está em execução para corrigir essa condição.

• Pode ver erros de autorização 403 ao escrever na API Logging. Por exemplo:

  [2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
  {
  "error": {
    "code": 403,
    "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google developers console API activation",
            "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
          }
        ]
      }
    ]
  }
  }
  

  Para corrigir este erro, ative a API Logging e defina a função Logs Writer.

• Pode ver um problema de quota para a API Logging. Por exemplo:

  error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
  

  Para corrigir este erro, aumente a quota ou reduza o débito do registo.

• Pode ver os seguintes erros no registo do módulo:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  ou

  can't fetch token from the metadata server
  

  Estes erros podem indicar que implementou o agente sem uma conta de serviço ou credenciais especificadas. Para obter informações sobre como resolver este problema, consulte o artigo Autorize o agente de operações.

O agente está a enviar métricas para o Cloud Monitoring?

Verifique o registo do módulo de métricas

Este passo requer que entre na VM através de SSH.

Pode encontrar os registos do módulo de métricas no syslog. Se não existirem registos, isto indica que o serviço do agente não está a ser executado corretamente. Aceda primeiro à secção O agente está instalado, mas não está em execução para corrigir essa condição.

• Pode ver erros PermissionDenied ao escrever na API Monitoring. Este erro ocorre se a autorização do agente de operações não estiver configurada corretamente. Por exemplo:

  Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}
  

  Para corrigir este erro, ative a API Monitoring e defina a função Monitoring Metric Writer.

• Pode ver erros ResourceExhausted ao escrever na API Monitoring. Este erro ocorre se o projeto atingir o limite de quaisquer quotas da API Monitoring. Por exemplo:

  Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}
  

  Para corrigir este erro, aumente a quota ou reduza o débito das métricas.

• Pode ver os seguintes erros no registo do módulo:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  ou

  can't fetch token from the metadata server
  

  Estes erros podem indicar que implementou o agente sem uma conta de serviço ou credenciais especificadas. Para obter informações sobre como resolver este problema, consulte o artigo Autorize o agente de operações.

Problemas de conetividade de rede

Se o agente estiver em execução, mas não enviar registos nem métricas, pode ter um problema de rede. Os tipos de problemas de conetividade de rede que pode encontrar variam consoante a topologia da sua aplicação. Para uma vista geral das redes do Compute Engine, consulte o artigo Vista geral das redes para VMs.

As causas comuns de problemas de conetividade incluem o seguinte:

• Regras de firewall que interferem com o tráfego recebido. Para obter informações sobre as regras de firewall, consulte o artigo Use as regras de firewall da VPC.
• Problemas na configuração do proxy HTTP.
• Configuração de DNS.

O agente de operações executa verificações de estado que detetam erros de conetividade de rede. Consulte a documentação de verificações de estado para ver as ações sugeridas a tomar em caso de erros de conetividade.

Compreender as mensagens de erro "failed to flush chunk"

A partir da versão 2.28.0 do agente de operações, o agente de operações limita a quantidade de espaço em disco que pode usar para armazenar blocos de buffer. O agente de operações cria blocos de buffer quando não é possível enviar dados de registo para a API Cloud Logging. Sem um limite, estes blocos podem consumir todo o espaço disponível, interrompendo outros serviços na VM. Quando uma falha de rede faz com que os fragmentos do buffer sejam escritos no disco, o agente de operações usa uma quantidade de espaço no disco específica da plataforma para armazenar os fragmentos. Uma mensagem como no exemplo seguinte também aparece em /var/log/google-cloud-ops-agent/subagents/logging-module.log em VMs Linux ou C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log em VMs Windows quando a VM não consegue enviar os fragmentos de buffer para a API Cloud Logging:

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

Problemas no proxy HTTP

Um problema com a configuração do proxy HTTP pode gerar erros. Por exemplo, os erros de flb_upstream com o termo context indicam um problema com a configuração do proxy:

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

Para corrigir este problema, confirme que o proxy HTTP foi configurado corretamente. Para obter instruções sobre como configurar o proxy HTTP, consulte o artigo Configure um proxy HTTP.

Para ver as especificações de formato do proxy HTTP, consulte o manual oficial do Fluent Bit.

Quero recolher apenas métricas ou registos, e não ambos

Por predefinição, o agente de operações recolhe métricas e registos. Para desativar a recolha de métricas ou registos, use o ficheiro config.yaml do agente de operações para substituir o serviço logging ou metrics predefinido, de modo que o pipeline predefinido não tenha recetores. Para mais informações, consulte o seguinte:

• Exemplos de configurações de service registo.
• Exemplos de configurações de service métricas.

A interrupção da ingestão de dados através da desativação dos serviços de subagentes do agente de operações "Agente de registo" ou "Agente de monitorização" resulta numa configuração inválida e não é suportada.

As métricas estão a ser recolhidas, mas algo parece estar errado

O agente está a registar "Exporting failed. Vai ser feita uma nova tentativa"

Vê entradas de registo "Falha na exportação" quando o primeiro ponto de dados de uma métrica cumulativa é ignorado. Os seguintes registos não são prejudiciais e podem ser ignorados com segurança:

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}
  

O agente está a registar mensagens "TimeSeries could not be written: Points must be written in order."

Se atualizou para o agente de operações a partir do agente de monitorização antigo e vir a seguinte mensagem de erro ao escrever métricas cumulativas, a solução é reiniciar a VM. O agente de operações e o agente de monitorização calculam as horas de início das métricas cumulativas de forma diferente, o que pode levar a que os pontos apareçam fora de ordem. O reinício da VM repõe a hora de início e corrige este problema.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}
  

O agente está a registar mensagens "O token tem de ser um token de curta duração (60 minutos) e estar dentro de um prazo razoável"

Se vir a seguinte mensagem de erro quando o agente escreve métricas, significa que o relógio do sistema não está sincronizado corretamente:

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.
  

Para obter informações sobre a sincronização dos relógios do sistema, consulte o artigo Configure o NTP numa VM.

O agente está a registar "metrics receiver with type "nvml" is not supported" (o recetor de métricas com o tipo "nvml" não é suportado)

Se estiver a recolher métricas de GPU da NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) através do recetor nvml, está a usar uma versão do agente de operações com suporte de pré-visualização para as métricas da NVML. O suporte para estas métricas ficou disponível de forma geral na versão 2.38.0 do agente de operações. Na versão de disponibilidade geral, a recolha de métricas feita pelo recetor nvml foi unida no recetor hostmetrics, e o recetor nvml foi removido.

Vê a mensagem de erro "metrics receiver with type "nvml" is not supported" (o recetor de métricas com o tipo "nvml" não é suportado) após instalar a versão 2.38.0 ou mais recente do agente de operações quando estava a usar o recetor de pré-visualização nvml e substituiu o intervalo de recolha predefinido no ficheiro de configuração especificado pelo utilizador. O erro ocorre porque o recetor nvml já não existe, mas o ficheiro de configuração especificado pelo utilizador ainda faz referência ao mesmo.

Para corrigir este problema, atualize o ficheiro de configuração especificado pelo utilizador para substituir o intervalo de recolha no recetor hostmetrics.

Faltam métricas da GPU

Se o agente Ops estiver a recolher algumas métricas, mas algumas ou todas as métricas da GPU (agent.googleapis.com/gpu) da NVIDIA Management Library (NVML) estiverem em falta, pode ter um problema de configuração ou não ter processos a usar a GPU.

Se não estiver a recolher métricas de GPU, verifique o controlador da GPU. Para recolher métricas de GPU, o agente de operações requer que o controlador de GPU esteja instalado e configurado na VM. Para verificar o condutor, faça o seguinte:

1. Para verificar se o controlador está instalado e a ser executado corretamente, siga os passos para validar a instalação do controlador da GPU.

2. Se o controlador não estiver instalado, faça o seguinte:

   1. Instale o controlador da GPU.

   2. Reinicie o Ops Agent.

      Tem de reiniciar o agente de operações após instalar ou atualizar o controlador da GPU.

   3. Verifique os registos do agente de operações para confirmar que a comunicação foi iniciada com êxito. As mensagens de registo são semelhantes às seguintes:

      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.
      

Se o controlador da GPU estiver instalado e os registos do agente de operações indicarem que o agente de operações está a comunicar com o controlador, mas não estiver a ver nenhuma métrica da GPU, o problema pode estar relacionado com o gráfico que está a usar. Para obter informações sobre a resolução de problemas de gráficos, consulte o artigo O gráfico não apresenta dados.

Se estiver a recolher algumas métricas de GPU, mas não tiver as métricas processes —processes/max_bytes_used e processes/utilization, significa que não tem processos em execução nas GPUs. As métricas da GPU processes não são recolhidas se não existirem processos em execução na GPU.

Algumas das métricas estão em falta ou são inconsistentes

Existe um pequeno número de métricas que a versão 2.0.0 e mais recentes do agente Ops são processadas de forma diferente das versões "de pré-visualização" do agente Ops (versões inferiores a 2.0.0) ou do agente de monitorização.

A tabela seguinte descreve as diferenças nos dados carregados pelo agente de operações e pelo agente de monitorização.

Tipo de métrica, omitindo agent.googleapis.com	Ops Agent (GA)^†	Ops Agent (pré-visualização)^†	Agente de monitorização
cpu_state	Os valores possíveis para o Windows são idle, interrupt, system e user.	Os valores possíveis para o Windows são idle, interrupt, system e user.	Os valores possíveis para o Windows são idle e used.
disk/bytes_used e disk/percent_used	Carregado com o caminho completo na etiqueta device; por exemplo, /dev/sda15. Não ingerido para dispositivos virtuais, como o tmpfs e o udev.	Carregado sem /dev no caminho na etiqueta device; por exemplo, sda15. Carregados para dispositivos virtuais como o tmpfs e o udev.	Carregado sem /dev no caminho na etiqueta device; por exemplo, sda15. Carregados para dispositivos virtuais como o tmpfs e o udev.

^† A coluna GA refere-se às versões 2.0.0 e superiores do agente de operações. A coluna Pré-visualização refere-se a versões do agente de operações inferiores a 2.0.0.

Problemas específicos do Windows

As secções seguintes aplicam-se apenas ao agente de operações em execução no Windows.

Contadores de desempenho danificados no Windows

Se o subagente de métricas não for iniciado, pode ver um dos seguintes erros no Cloud Logging:

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

Estes erros podem ocorrer se os contadores de desempenho do sistema ficarem danificados. Pode resolver os erros recriando os contadores de desempenho. No PowerShell como administrador, execute:

cd C:\Windows\system32
lodctr /R

O comando anterior pode falhar ocasionalmente. Nesse caso, recarregue o PowerShell e tente novamente até ter êxito.

Depois de o comando ser executado com êxito, reinicie o agente de operações:

Restart-Service -Name google-cloud-ops-agent -Force

Repor completamente o estado do agente

Se o agente entrar num estado não recuperável, siga estes passos para restaurar o agente para um estado novo.

Nota: este processo remove todo o estado do buffer, o que pode resultar na perda de registos. Para um processo que não repõe o estado do buffer, consulte Reponha, mas guarde os ficheiros do buffer.

Linux

Pare o serviço do agente:

sudo service google-cloud-ops-agent stop

Remova o pacote do agente:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

Remova os registos automáticos do agente no disco:

sudo rm -rf /var/log/google-cloud-ops-agent

Remova as memórias intermédias locais do agente no disco:

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

Nota: o diretório /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ contém os seguintes tipos de ficheiros:

• Ficheiros de buffer: estes ficheiros são entradas de registo em buffer que foram processadas pelo agente de operações, mas ainda não foram carregadas no Cloud Logging. Quando existem blocos danificados, o agente de operações deve ignorá-los nas versões >= 2.15.0. Em alguns casos, têm de ser limpos manualmente. Estes ficheiros são armazenados nas pastas aninhadas, como: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
• Ficheiros de posição de seguimento de ficheiros de registo: estes ficheiros registam a localização nos ficheiros de registo que o agente de operações já seguiu. Se estes ficheiros forem removidos, o agente de operações começa a partir da parte superior dos ficheiros que está configurado para seguir. A eliminação destes ficheiros pode levar à duplicação de registos se esses registos tiverem sido carregados com êxito anteriormente. Estes ficheiros são armazenados diretamente no diretório como ficheiros como: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

A sintaxe .../buffers/*/ no comando anterior garante que apenas os ficheiros de buffer são eliminados. Os ficheiros de posição não são eliminados.

Reinstale e reinicie o agente:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

Nota: os comandos para o Windows têm de ser executados no Powershell como administrador.

Pare o serviço do agente:

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

Remova o pacote do agente:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

Remova os registos automáticos do agente no disco:

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

Remova as memórias intermédias locais do agente no disco:

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

Nota: semelhante ao Linux, este comando elimina apenas os subdiretórios no diretório C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers, pelo que os ficheiros de buffer são removidos, mas os ficheiros de posição permanecem intactos.

Reinstale e reinicie o agente:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

Reponha, mas guarde os ficheiros de buffer

Se a VM não tiver blocos de buffer danificados (ou seja, não existirem mensagens format check failed no ficheiro de registo automático do agente Ops), pode ignorar os comandos anteriores que removem os buffers locais quando repõe o estado do agente.

Se a VM tiver partes de buffer danificadas, tem de as remover. As seguintes opções descrevem diferentes formas de processar os buffers. Os outros passos descritos em Reponha completamente o estado do agente continuam a ser aplicáveis.

• Opção 1: elimine todo o diretório buffers. Esta é a opção mais fácil, mas pode resultar na perda dos registos em buffer não danificados ou na duplicação de registos devido à perda dos ficheiros de posição.

  Linux

  sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
  

  Windows

  rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
  

• Opção 2: elimine os subdiretórios de buffer do diretório buffers, mas deixe os ficheiros de posição. Esta abordagem é descrita no artigo Reponha completamente o estado do agente.

• Opção 3: se não quiser eliminar todos os ficheiros de buffer, pode extrair os nomes dos ficheiros de buffer danificados dos registos automáticos do agente e eliminar apenas os ficheiros de buffer danificados.

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  

• Opção 4: se existirem muitos buffers danificados e quiser voltar a processar todos os ficheiros de registo, pode usar os comandos da Opção 3 e também eliminar os ficheiros de posição (que armazenam o progresso do agente de operações por ficheiro de registo). A eliminação dos ficheiros de posição pode resultar na duplicação de registos para todos os registos que já tenham sido carregados com êxito. Esta opção apenas processa novamente os ficheiros de registo atuais. Não processa novamente ficheiros que já foram substituídos nem registos de outras fontes, como uma porta TCP. Os ficheiros de posição são armazenados no diretório buffers , mas são armazenados como ficheiros. Os buffers locais são armazenados como subdiretórios no diretório buffers.

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
  

Problemas conhecidos em versões recentes do agente de operações

As secções seguintes descrevem problemas conhecidos em lançamentos recentes do agente de operações.

A versão 2.56.0 do agente de operações não envia métricas do Prometheus

Se estiver a usar a versão 2.56.0 do agente Ops em conjunto com o recetor do Prometheus e se o seu destino de recolha estiver a emitir métricas com *_created métricas adicionais para contadores (para suportar a nova funcionalidade experimental de datas/horas de criação), o agente pode não conseguir escrever métricas e comunicar erros que as horas de início têm de ser positivas. As mensagens de registo são semelhantes às seguintes:

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

Este é um problema com o OpenTelemetry a montante. Para resolver o erro até que seja possível corrigi-lo numa nova versão do agente de operações, use a versão 2.55.0, que não é afetada. Se estiver a usar políticas de agente, também pode fixar a versão 2.55.0 para impedir atualizações. Para mais informações, consulte o artigo Instalar uma versão específica do agente.

Ciclo de falhas da versão 2.47.0, 2.48.0 ou 2.49.0 do Ops Agent

As versões 2.47.0, 2.48.0 e 2.49.0 incorporaram um componente FluentBit com falhas para registo. Este componente falha em linhas de registo específicas e faz com que o agente do Google Cloud Operations Suite entre num ciclo de falhas.

Este problema foi resolvido na versão 2.50.0 do agente do Google Cloud Operations.

O espaço de nomes das métricas do Prometheus inclui o nome da instância, além do ID da instância, a partir da versão 2.46.0 do agente de operações

A partir da versão 2.46.0, o agente de operações inclui o nome da VM como parte da etiqueta namespace quando carrega métricas no formato de carregamento do Prometheus. Nas versões anteriores, as métricas do Prometheus usavam apenas o ID da instância da VM como parte da etiqueta namespace, mas, a partir da versão 2.46.0, namespace está definido como INSTANCE_ID/INSTANCE_NAME.

Se tiver gráficos, painéis de controlo ou políticas de alerta que usem a etiqueta namespace , pode ter de atualizar as suas consultas depois de atualizar o agente de operações para a versão 2.46.0 ou posterior. Por exemplo, se a sua consulta PromQL tiver o seguinte aspeto: http_requests_total{namespace="123456789"}, tem de a alterar para http_requests_total{namespace=~"123456789.*"}, uma vez que a etiqueta namespace tem o formato INSTANCE_ID/INSTANCE_NAME.

As métricas não tipadas do Prometheus alteram o tipo de métrica a partir da versão 2.39.0 do agente de operações

A partir da versão 2.39.0, o agente de operações suporta a carregamento de métricas do Prometheus com tipos desconhecidos. Nas versões anteriores, estas métricas são tratadas pelo agente de operações como indicadores, mas a partir da versão 2.39.0, as métricas não tipadas são tratadas como indicadores e contadores. Agora, os utilizadores podem usar operações cumulativas nestas métricas como resultado.

Se usar o PromQL, pode aplicar operações cumulativas a métricas do Prometheus sem tipo após atualizar o agente de operações para a versão 2.39.0 ou posterior.

Utilização elevada da memória em VMs do Windows (versões 2.27.0 a 2.29.0)

No Windows, nas versões 2.27.0 a 2.29.0 do agente de operações, um erro que fazia com que o agente, por vezes, perdesse tomadas, levou a um aumento da utilização de memória e a um elevado número de identificadores detidos pelo processo fluent-bit.exe.

Para mitigar este problema, atualize o Ops Agent para a versão 2.30.0 ou superior e reinicie o agente.

Os fusos horários do registo de eventos estão incorretos no Windows (versões 2.15.0 a 2.26.0)

As datas/horas associadas aos registos de eventos do Windows no Cloud Logging podem estar incorretas se alterar o fuso horário da sua VM a partir do UTC. Este problema foi corrigido no agente de operações 2.27.0, mas, devido ao problema conhecido de memória elevada do Windows, recomendamos que atualize para, pelo menos, o agente de operações 2.30.0 se estiver a ter este problema. Se não conseguir atualizar, pode experimentar uma das seguintes soluções alternativas.

Use um fuso horário UTC

No PowerShell, execute os seguintes comandos como administrador:

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Substitua a definição do fuso horário apenas para o serviço de subagente de registo

No PowerShell, execute os seguintes comandos como administrador:

Aviso: isto vai substituir o valor de registo do ambiente para o serviço se já existir.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

As indicações de tempo analisadas no Windows têm um fuso horário incorreto (qualquer versão anterior à 2.27.0)

Se usar um processador de registos que analise uma data/hora, o valor do fuso horário não é analisado corretamente no Windows. Este problema foi corrigido no agente Ops 2.27.0, mas, devido ao problema conhecido de memória elevada do Windows, recomendamos que atualize para, pelo menos, o agente Ops 2.30.0 se estiver a ter este problema.

Problemas conhecidos em versões mais antigas do agente de operações

As secções seguintes descrevem problemas conhecidos que ocorrem com versões mais antigas do agente de operações.

Registos não prejudiciais (versões 2.9.1 e anteriores)

Pode ver erros ao extrair métricas de pseudoprocessos ou processos restritos. Os seguintes registos não são prejudiciais e podem ser ignorados em segurança. Para eliminar estas mensagens, atualize o agente de operações para a versão 2.10.0 ou mais recente.

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186
  

Os registos automáticos do agente consomem demasiada CPU, memória e espaço em disco (versões 2.16.0 e anteriores)

As versões do agente de operações anteriores à 2.17.0 podem consumir muita CPU, memória e espaço em disco com ficheiros /var/log/google-cloud-ops-agent/subagents/logging-module.log em VMs Linux ou ficheiros C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log em VMs Windows devido a blocos de buffer corrompidos. Quando isto acontece, vê um grande número de mensagens como as seguintes no ficheiro logging-module.log.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb
  

Para resolver este problema, atualize o Ops Agent para a versão 2.17.0 ou mais recente e reponga completamente o estado do agente.

Se o seu sistema continuar a gerar um grande volume de registos automáticos de agentes, considere usar a rotação de registos. Para mais informações, consulte o artigo Configure a rotação de registos.