Esta página foi traduzida pela API Cloud Translation.

Resolver problemas de ingestão de dados no agente de operações

Neste documento, fornecemos informações para ajudar a diagnosticar e resolver problemas de ingestão de dados, para registros e métricas, no Agente de operações em execução. Se o Agente de operações não estiver em execução, consulte Resolver problemas de instalação e inicialização.

Antes de começar

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

O console do Google Cloud mostra a instalação do agente de operações travada em "Pendente"

Mesmo após a instalação bem-sucedida do agente de operações, o console do Google Cloud ainda poderá exibir o status "Pendente". Use gcpdiag para confirmar a instalação do agente de operações e verificar se o agente está transmitindo registros e métricas da sua instância de VM.

Razões comuns para falha na instalação

A instalação do Agente de operações pode falhar pelos seguintes motivos:

A VM não tem uma conta de serviço anexada. Anexe uma conta de serviço à VM e reinstale o agente de operações.
A VM já tem um dos agentes legados instalados, o que impede a instalação do agente de operações. Desinstale os agentes legados e reinstale o agente de operações.

Razões comuns para falhas na transmissão de telemetria

Um agente de operações instalado e em execução pode falhar ao enviar logs, métricas ou ambos de uma VM pelos seguintes motivos:

A conta de serviço anexada à VM não tem o papel roles/logging.logWriter ou roles/monitoring.metricWriter.
O escopo de acesso de criação de log ou monitoramento não está ativado. Para informações sobre como verificar e atualizar escopos de acesso, consulte Verificar seus escopos de acesso.
A API Logging ou a API Monitoring não estão ativadas.

Use verificações de integridade do agente para identificar a causa raiz e a solução correspondente.

O agente está em execução, mas os dados não foram ingeridos

Use o Metrics Explorer para consultar a métrica uptime do agente e verificar se o componente do agente, google-cloud-ops-agent-metrics ou google-cloud-ops-agent-logging, está gravando na métrica.

No Console do Google Cloud, acesse a página do Metrics Explorer:
Acesse o Metrics explorer

Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
Na alternância do Builder Code rotulado, selecione Código e defina a linguagem como MQL.

Digite a seguinte consulta e clique em Executar:

fetch gce_instance
| metric 'agent.googleapis.com/agent/uptime'
| align rate(1m)
| every 1m

O agente está enviando registros para o Cloud Logging?

Se o agente estiver em execução, mas não enviar registros, cheque o status das verificações de integridade do ambiente de execução do agente.

Erros do pipeline

Se você vir o erro de ambiente de execução LogPipelineErr ("Falha no pipeline de geração de registros do agente de operações"), o subagente de geração de registros encontrou um problema ao gravar os registros. Verifique as seguintes condições:

Verifique se os arquivos de armazenamento do subagente de geração de registros estão acessíveis. Esses arquivos são encontrados nos seguintes locais:
- 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 geração de registros está correta.

Para seguir as etapas de processo, use o SSH na VM.

Se você alterar a configuração da geração de registros ou se os arquivos do buffer estiverem acessíveis e o disco da VM não estiver cheio, reinicie o agente de operações:

Linux

Para reiniciar o agente, execute o seguinte comando na instância:
```
sudo systemctl restart google-cloud-ops-agent
```
Para confirmar se o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Conecte-se à sua instância usando o RDP ou uma ferramenta semelhante e faça login no Windows.
Abra um terminal do PowerShell com privilégios de administrador. Para isso, clique com o botão direito do mouse no ícone do PowerShell e selecione Executar como administrador
Para reiniciar o agente, execute o seguinte comando do PowerShell:
```
Restart-Service google-cloud-ops-agent -Force
```
Para confirmar se o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
```
Get-Service google-cloud-ops-agent*
```

Erros de análise de registros

Se você vir o erro de ambiente de execução LogParseErr ("O agente de operações não conseguiu analisar os registros"), o problema mais provável está na configuração de um operador de geração de registros. Para resolver esse problema, faça o seguinte:

Verifique se a configuração de qualquer processador parse_json está correta.
Verifique se a configuração de qualquer processador parse_regex está correta.
Se você não tiver processadores parse_json ou parse_regex, verifique a configuração de todos os outros processadores de geração de registros.

Para seguir as etapas de processo, use o SSH na VM.

Se você alterar a configuração da geração de registros, reinicie o agente de operações:

Linux

Para reiniciar o agente, execute o seguinte comando na instância:
```
sudo systemctl restart google-cloud-ops-agent
```
Para confirmar se o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Conecte-se à sua instância usando o RDP ou uma ferramenta semelhante e faça login no Windows.
Abra um terminal do PowerShell com privilégios de administrador. Para isso, clique com o botão direito do mouse no ícone do PowerShell e selecione Executar como administrador
Para reiniciar o agente, execute o seguinte comando do PowerShell:
```
Restart-Service google-cloud-ops-agent -Force
```
Para confirmar se o agente foi reiniciado, execute o seguinte comando e verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
```
Get-Service google-cloud-ops-agent*
```

Verifique as métricas locais

Para seguir as etapas de processo, use o SSH na VM.

O módulo de geração de registros 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 é possível verificar o status do serviço no app "Serviços" e inspecionar os processos em execução no app "Gerenciador de tarefas".

Verifique o registro do módulo de geração de registro

Nesta etapa, é necessário usar o SSH na VM.

Para encontrar os registros do módulo de geração de registros, acesse /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 houver registros, o serviço do agente não está sendo executado corretamente. Primeiro, acesse a seção O agente está instalado, mas não está em execução para corrigir essa condição.

Erros de permissão 403 podem ser exibidos ao gravar na API Logging. 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 esse erro, ative a API Logging e defina o papel Gravador de registros.

Um problema de cota para a API Logging poderá ser exibido. 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 esse erro, aumente a cota ou reduza a capacidade do registro.

Talvez você veja os seguintes erros no registro do módulo:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
ou
```
can't fetch token from the metadata server
```
Esses erros podem indicar que você implantou o agente sem uma conta de serviço ou credenciais especificadas. Para informações sobre como resolver esse problema, consulte Autorizar o agente de operações.

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

Verifique o registro do módulo de métricas

Nesta etapa, é necessário usar o SSH na VM.

Você encontra os registros do módulo de métricas no syslog. Se não houver registros, isso indicará que o serviço do agente não está sendo executado corretamente. Primeiro, acesse a seção O agente está instalado, mas não está em execução para corrigir essa condição.

É possível ver erros PermissionDenied ao gravar na API Monitoring. Esse erro ocorrerá se a permissão do agente de operações não estiver configurada corretamente. 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 esse erro, ative a API Monitoring e defina o papel Gravador de métricas do Monitoring.

É possível ver erros ResourceExhausted ao gravar na API Monitoring. Esse erro ocorrerá se o projeto atingir o limite de cotas da API Monitoring. 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 esse erro, aumente a cota ou reduza a capacidade das métricas.

Talvez você veja os seguintes erros no registro do módulo:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
ou
```
can't fetch token from the metadata server
```
Esses erros podem indicar que você implantou o agente sem uma conta de serviço ou credenciais especificadas. Para informações sobre como resolver esse problema, consulte Autorizar o agente de operações.

Problemas de conectividade de rede

Se o agente estiver em execução, mas não enviar registros nem métricas, talvez você tenha um problema de rede. Os tipos de problemas de conectividade de rede que você pode encontrar variam com a topologia do aplicativo. Para ter uma visão geral da rede do Compute Engine, consulte este link.

Veja algumas causas comuns de problemas de conectividade:

Regras de firewall que interferem no tráfego de entrada. Veja informações sobre regras de firewall em Usar regras de firewall da VPC.
Problemas na configuração de um proxy HTTP.
Configuração do DNS.

O Agente de operações executa verificações de integridade que detectam erros de conectividade de rede. Consulte a documentação das verificações de integridade para ver as ações sugeridas para erros de conectividade.

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

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

Quero coletar apenas métricas ou registros, não ambos

Por padrão, o Agente de operações coleta métricas e registros. Para desativar a coleta de métricas ou registros, use o arquivo config.yaml do Agente de operações para substituir o serviço logging ou metrics padrão para que o pipeline padrão não tenha receptores. Para ver mais informações, consulte os tópicos a seguir:

A interrupção da ingestão de dados desativando os serviços do subagente do agente de operações "Agente de geração de registros" ou "Agente de monitoramento" resulta em uma configuração inválida e não é compatível.

As métricas estão sendo coletadas, mas algo parece errado

O agente está registrando mensagens "Falha na exportação. Nova tentativa"

Você verá entradas de registro "Falha na exportação" quando o primeiro ponto de dados de uma métrica cumulativa for descartado. Os registros a seguir não são nocivos 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á registrando "Não foi possível gravar a série temporal: os pontos devem ser escritos em ordem". mensagens

Se você fez upgrade para o agente de operações a partir do agente do Monitoring legado e está recebendo a seguinte mensagem de erro ao gravar métricas cumulativas, a solução é reinicializar a VM. O agente de operações e o agente do Monitoring calculam os horários de início de métricas cumulativas de maneira diferente, o que pode levar a pontos que aparecem fora de ordem. A reinicialização da VM redefine o horário de início e corrige esse 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á registrando mensagens "O token deve ser um token de curta duração (60 minutos) e em um período razoável"

Se a mensagem de erro a seguir for exibida quando o agente gravar métricas, isso indica 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 informações sobre como sincronizar os relógios do sistema, consulte Configurar o NTP em uma VM.

O agente está registrando "o receptor de métricas com o tipo "nvml" não é compatível"

Se estiver coletando métricas da GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) usando o receptor nvml, você está usando uma versão das Operações Agente compatível com visualização para as métricas NVML. O suporte para essas métricas foi disponibilizado para todos na versão 2.38.0 do Agente de operações. Na versão do GA, a coleta de métricas feita pelo receptor nvml foi mesclada no receptor hostmetrics, e o receptor nvml foi removido.

Você vê a mensagem de erro "O receptor de métricas com o tipo nvml não é compatível" depois de instalar o Agente de operações versão 2.38.0 ou mais recente quando você estava usando o receptor de visualização nvml e substituiu o intervalo de coleções padrão no arquivo de configuração especificado pelo usuário. O erro ocorre porque o receptor nvml não existe mais, mas o arquivo de configuração especificado pelo usuário ainda se refere a ele.

Para corrigir esse problema, atualize o arquivo de configuração especificado pelo usuário para modificar o intervalo de coleta no receptor hostmetrics.

As métricas da GPU estão ausentes

Se o Agente de operações estiver coletando algumas métricas, mas algumas ou todas as métricas GPU da biblioteca de gerenciamento (NVML, na sigla em inglês) (agent.googleapis.com/gpu) estão ausentes, pode haver um problema de configuração ou ausência de processos usando a GPU.

Se você não estiver coletando métricas da GPU, verifique o driver da GPU. Para coletar métricas da GPU, o Agente de operações exige que o driver da GPU esteja instalado e configurado na VM. Para verificar o driver, faça o seguinte:

Para verificar se o driver está instalado e sendo executado corretamente, siga as etapas para verificar a instalação do driver da GPU.

Se o driver não estiver instalado, faça o seguinte:

Instale o driver da GPU.
Reinicie o Agente de operações.

É necessário reiniciar o Agente de operações depois de instalar ou fazer upgrade do driver da GPU.

Verifique os registros do Agente de operações para confirmar se a comunicação foi iniciada com sucesso. As mensagens de registro serão parecidas com estas:

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 driver da GPU estiver instalado e os registros do Agente de operações indicarem que o Agente de operações está se comunicando com o driver, mas você não estiver vendo nenhuma métrica da GPU, o problema pode ser um problema com o gráfico que você está usando. Para saber como solucionar problemas com gráficos, consulte O gráfico não exibe nenhum dado.

Se você estiver coletando algumas métricas da GPU, mas não tiver as métricas processes (processes/max_bytes_used e processes/utilization), você não terá processos em execução nas GPUs. As métricas processes da GPU não estão coletados se não houver processos em execução na GPU.

Algumas das métricas estão ausentes ou são inconsistentes

Há um pequeno número de métricas que o agente de operações versão 2.0.0 ou mais recente processa de maneira diferente das versões de "visualização" do agente de operações (versões anteriores ao 2.0.0) ou do agente do Monitoring de dados.

Na tabela a seguir, descrevemos as diferenças nos dados ingeridos pelo agente de operações e pelo agente do Monitoring.

Tipo de métrica, omitindo `agent.googleapis.com`	Agente de operações (disponibilidade geral)^†	Agente de operações (visualização)^†	Agente do Monitoring
`cpu_state`	Os valores possíveis para Windows são `idle`, `interrupt,` `system` e `user`.	Os valores possíveis para Windows são `idle`, `interrupt,` `system` e `user`.	Os valores possíveis para Windows são `idle` e `used`.
`disk/bytes_used` e `disk/percent_used`	Ingestão com o caminho completo no rótulo `device`. Por exemplo, `/dev/sda15`. Não ingerido para dispositivos virtuais, como `tmpfs` e `udev`.	Processado sem `/dev` no caminho no rótulo `device`; por exemplo, `sda15`. Ingestão para dispositivos virtuais, como `tmpfs` e `udev`.	Processado sem `/dev` no caminho no rótulo `device`; por exemplo, `sda15`. Ingestão para dispositivos virtuais, como `tmpfs` e `udev`.

^† A coluna GA refere-se às versões 2.0.0 e posteriores do agente de operações. A coluna Prévia refere-se às versões do Agente de operações anteriores à 2.0.0.

Problemas específicos do Windows

As seções a seguir se aplicam apenas ao agente de operações em execução no Windows.

Contadores de desempenho corrompidos no Windows

Se o subagente de métricas não for iniciado, você poderá 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"

Esses erros podem ocorrer se os contadores de desempenho do sistema forem corrompidos. Para resolver os erros, recrie os contadores de desempenho. No PowerShell como administrador, execute:

cd C:\Windows\system32
lodctr /R

O comando anterior pode falhar de vez em quando. Nesse caso, atualize o PowerShell e tente novamente até conseguir.

Depois que o comando for bem-sucedido, reinicie o agente de operações:

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

Redefinir completamente o estado do agente

Se o agente entrar em um estado não recuperável, siga estas etapas para restaurá-lo em um novo estado.

Linux

Interrompa 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 registros próprios do agente no disco:

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

Remova os buffers locais do agente no disco:

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

Observação: o diretório /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ contém os seguintes tipos de arquivos:

Arquivos de buffer: esses arquivos são entradas de registro armazenadas em buffer que foram rastreadas e processadas pelo agente de operações, mas ainda não foram ingeridas no Cloud Logging. Quando há blocos corrompidos, o agente de operações precisa ignorá-los nas versões >= 2.15.0. Em alguns casos, eles precisam ser limpos manualmente. Esses arquivos são armazenados em pastas aninhadas como: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
Arquivos de posição de arquivo de cauda do arquivo de registros: esses arquivos registram em qual local nos arquivos de registros o agente de operações já monitorou. Se esses arquivos forem removidos, o agente de operações começará pela parte superior dos arquivos que está configurado para monitorar. A exclusão desses arquivos poderá levar à duplicação de registros se esses registros tiverem sido ingeridos anteriormente. Esses arquivos são armazenados diretamente no diretório como arquivos como: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

A sintaxe .../buffers/*/ no comando anterior garante que somente os arquivos de buffer sejam excluídos. Os arquivos de posição não são excluídos.

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

Interrompa 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 registros próprios do agente no disco:

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

Remova os buffers locais do agente no disco:

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

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"

Redefinir, mas salvar os arquivos de buffer

Se a VM não tiver blocos de buffer corrompidos, ou seja, não há mensagens format check failed no arquivo de registro do agente de operações), ignore os comandos anteriores que removem os buffers locais ao redefinir o estado do agente.

Se a VM tiver blocos de buffer corrompidos, será necessário removê-los. As opções a seguir descrevem maneiras diferentes de lidar com os buffers. As outras etapas descritas em Redefinir o estado do agente completamente ainda são aplicáveis.

Opção 1: exclua todo o diretório buffers. Essa é a opção mais fácil, mas pode resultar na perda dos registros em buffer não corrompidos ou da duplicação de registro devido à perda dos arquivos 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: exclua os subdiretórios de buffer do diretório buffers, mas deixe os arquivos de posição. Essa abordagem é descrita em Redefinir completamente o estado do agente.

Opção 3: se você não quiser excluir todos os arquivos de buffer, poderá extrair os nomes dos arquivos de buffer corrompidos dos registros próprios do agente e excluir apenas o buffer corrompido.

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 houver muitos buffers corrompidos e você quiser reprocessar todos os arquivos de registro, use os comandos da Opção 3 e exclua os arquivos de posição (que armazenam operações o progresso do agente por arquivo de registros). Excluir os arquivos de posição pode resultar na duplicação de registro para qualquer registro que já tenha sido ingerido. Esta opção só reprocessa os arquivos de registro atuais. Ele não reprocessa arquivos que já foram substituídos ou registros de outras origens, como uma porta TCP. Os arquivos de posição são armazenados no diretório buffers, mas como arquivos. 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 mais recentes do Agente de operações

As seções a seguir descrevem problemas conhecidos de versões recentes do agente de operações.

Loop de falhas do Agente de operações versão 2.47.0, 2.48.0 ou 2.49.0

As versões 2.47.0, 2.48.0 e 2.49.0 incorporaram um componente com defeito do FluentBit. para geração de registros. Este componente falha em linhas de registro específicas e faz com que o o Agente de operações para fazer um loop de falhas.

Esse problema foi resolvido na versão 2.50.0 do Agente de operações.

O namespace de métricas do Prometheus inclui o nome e o 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 do rótulo namespace ao ingerir métricas no formato de ingestão do Prometheus. Nas versões anteriores, as métricas do Prometheus usavam apenas o ID da instância da VM como parte de namespace. No entanto, a partir da versão 2.46.0, namespace está definido como INSTANCE_ID/INSTANCE_NAME.

Se você tiver gráficos, painéis ou políticas de alertas que usam o rótulo namespace, talvez seja necessário atualizar suas consultas após o upgrade do Agente de operações para a versão 2.46.0 ou mais recente. Por exemplo, se sua consulta do PromQL tiver esta aparência: http_requests_total{namespace="123456789"}, será necessário mudá-la para http_requests_total{namespace=~"123456789.*"}, já que o rótulo namespace tem o formato INSTANCE_ID/INSTANCE_NAME.

O tipo de métrica de mudança de métricas sem tipo do Prometheus começa com a versão 2.39.0 do Agente de operações

A partir da versão 2.39.0, o Agente de operações oferece suporte à ingestão de métricas do Prometheus com tipos desconhecidos. Nas versões anteriores, essas métricas são tratadas pelo Agente de operações como medidores, mas a partir da versão 2.39.0, as métricas sem tipo são tratadas como medidores e contadores. Como resultado, os usuários podem usar operações cumulativas nessas métricas.

Se você tiver gráficos, painéis ou políticas de alertas que usam o MQL para consultar métricas sem tipo do Prometheus, atualize suas consultas MQL depois de fazer upgrade do Agente de operações para a versão 2.39.0 ou mais recente. Em vez de consultar métricas sem tipo como prometheus.googleapis.com/METRIC_NAME/gauge, mude os tipos de métrica da seguinte maneira:

Use prometheus.googleapis.com/METRIC_NAME/unknown para a versão do medidor da métrica.
Use prometheus.googleapis.com/METRIC_NAME/unknown:counter para a versão de contador da métrica.

Não é necessário fazer alterações nos gráficos, painéis ou políticas de alertas que usam o PromQL para consultar métricas sem tipo do Prometheus, mas é possível aplicar operações cumulativas a essas métricas depois de fazer upgrade do Agente de operações para a versão 2.39.0 ou posterior.

Uso elevado 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 bug que às vezes vazava os soquetes levava ao aumento do uso de memória e a um grande número de identificadores retidos pelo processo fluent-bit.exe.

Para atenuar esse problema, faça upgrade do agente de operações para a versão 2.30.0 ou mais recente e reinicie o agente.

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

Os carimbos de data/hora associados aos logs de eventos do Windows no Cloud Logging podem estar incorretos se você alterar o fuso horário da sua VM de UTC. Isso foi corrigido no Agente de operações 2.27.0, mas devido ao problema conhecido de memória alta do Windows, recomendamos que você faça upgrade para pelo menos o Agente de operações 2.30.0 se estiver executando para esse problema. Se não for possível fazer upgrade, tente uma das seguintes soluções alternativas.

Usar um fuso horário UTC

No PowerShell, execute os comandos a seguir como administrador:

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

Substituir a configuração de fuso horário apenas para o serviço do subagente da geração de registros

No PowerShell, execute os comandos a seguir como administrador:

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

Os carimbos de data/hora analisados no Windows têm fuso horário incorreto (qualquer versão anterior à 2.27.0)

Se você usar um processador de registros que analise um carimbo de data/hora, o valor do fuso horário não será analisado corretamente no Windows. Isso foi corrigido no Agente de operações 2.27.0, mas devido ao problema conhecido de alta memória do Windows, recomendamos que você faça upgrade para pelo menos o Agente de operações 2.30.0 se estiver executando nesse problema.

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

As seções abaixo descrevem problemas que ocorrem com as versões mais antigas do agente de operações.

Registros não nocivos (versões 2.9.1 e mais antigas)

É possível ver erros ao extrair métricas de pseudoprocessos ou processos restritos. Os registros a seguir não são nocivos e podem ser ignorados com segurança. Para eliminar essas mensagens, faça upgrade do 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 registros próprios do agente consomem muita CPU, memória e espaço em disco (versão 2.16.0 e mais antigas)

As versões do agente de operações anteriores à 2.17.0 podem consumir muito espaço de CPU, memória e disco com arquivos /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 do Windows devido a blocos de buffer corrompidos. Quando isso acontecer, você verá um grande número de mensagens como esta no arquivo 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 esse problema, faça upgrade do agente de operações para a versão 2.17.0 ou mais recente e redefina totalmente o estado do agente.

Se o sistema ainda gerar um grande volume de registros próprios do agente, considere usar a rotação de registros. Para mais informações, consulte Configurar a rotação de registros.