Resolver problemas do agente de operações

Observação: o endpoint localhost:2020/api/v1/metrics mencionado em 3:18 neste vídeo não está mais disponível no Agente de operações. Para outras opções, consulte O agente está em execução, mas os dados não foram ingeridos.

Neste documento, você aprende a diagnosticar problemas na instalação ou na execução do agente de operações.

Ferramenta de diagnóstico do agente para VMs

A ferramenta de diagnóstico do agente coleta informações essenciais de depuração local das VMs do Linux para todos os agentes a seguir: agente de operações, agente do Logging legado e agente do Monitoring legado. As informações de depuração incluem itens como informações do projeto, VMs, configuração do agente, registros do agente, status do serviço do agente e informações que normalmente exigem trabalho manual para serem coletadas. A ferramenta também verifica o ambiente da VM local para garantir que ela atenda a determinados requisitos para que os agentes funcionem corretamente, por exemplo, conectividade de rede e permissões necessárias.

Ao registrar um caso de cliente para um agente em uma VM do Linux, execute a ferramenta de diagnóstico do agente e anexe as informações coletadas ao caso. Antes de anexar as informações ao caso de suporte, edite as informações confidenciais, como senhas. Fornecer essas informações reduz o tempo necessário para resolver problemas no seu caso de suporte.

A ferramenta de diagnóstico do agente precisa ser executada dentro da VM do Linux. Portanto, você normalmente precisa executar o SSH na VM primeiro. O comando a seguir recupera e executa a ferramenta de diagnóstico do agente:

Linux

curl -sSO https://dl.google.com/cloudagents/diagnose-agents.sh
sudo bash diagnose-agents.sh

Windows

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/diagnose-agents.ps1", "${env:UserProfile}\diagnose-agents.ps1")
Invoke-Expression "${env:UserProfile}\diagnose-agents.ps1"

Siga a saída da execução do script para localizar os arquivos que incluem as informações coletadas. Normalmente, é possível encontrá-los no diretório /var/tmp/google-agents no Linux e no diretório $env:LOCALAPPDATA/Temp no Windows, a menos que você tenha personalizado o diretório de saída ao executar o script.

Para ver informações detalhadas, examine o script diagnose-agents.sh no Linux ou o script diagnose-agents.ps1 no Windows.

Falha na instalação do agente

É possível encontrar os seguintes erros ao executar o script de instalação.

O sistema operacional não é compatível. A mensagem de erro pode ser semelhante a esta:

Linux

https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el6-x86_64-all/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
Trying other mirror.
To address this issue please refer to the below wiki article

https://wiki.centos.org/yum-errors

If above article doesn't help to resolve this issue please use https://bugs.centos.org/.

Error: Cannot retrieve repository metadata (repomd.xml) for repository: google-cloud-ops-agent. Please verify its path and try again

A VM já tem o agente do Cloud Logging ou o agente do Cloud Monitoring instalado, e eles entram em conflito com o novo agente. A mensagem de erro pode ser semelhante a esta:

Linux
```
Error:
Problem: problem with installed package stackdriver-agent-6.0.5-1.el8.x86_64 - package google-cloud-ops-agent-0.1.0-1.el8.x86_64 conflicts with stackdriver-agent provided by stackdriver-agent-6.0.5-1.el8.x86_64
```
O agente de operações usa novos arquivos de configuração que não são compatíveis com os agentes antigos. Para mais informações, consulte o guia Configurar o agente de operações.

Para resolver esse erro, faça o seguinte:
1. Salve os arquivos de configuração personalizados do agente do Cloud Monitoring e do agente do Cloud Logging.
2. Desinstale o agente do Cloud Monitoring antigo e o agente do Cloud Logging.
  
  Depois de desinstalar o agente, o console do Google Cloud pode levar até uma hora para informar essa alteração.

O agente está instalado, mas não está em execução

Serviços de agente não estão em execução

Quando o serviço do agente estiver sendo executado conforme o esperado, você verá o seguinte status:

For Linux

computer@debian9:~$ sudo systemctl status google-cloud-ops-agent"*"
● google-cloud-ops-agent.service - Google Cloud Ops Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2240 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
  Process: 2214 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -in /etc/google-cloud-ops-agent/config.yaml (code=exited, status=0/SUCCESS)
 Main PID: 2240 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent.service

Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent.

● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
           └─directories.conf
   Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2234 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
  Process: 2216 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIRECTORY} (code=exited, status=0/SUCCESS)
 Main PID: 2247 (fluent-bit)
    Tasks: 22 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent-fluent-bit.service
           └─2247 /opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config /run/google-cloud-ops-agent-fluent-bit/fluent_bit_main.conf --parser /run/google-cloud-ops-agent-fluent-bit/fluent_bit_parser.conf --log_file /var/log/google-cloud-ops-agent/subagents/logging-module.log --storage_path /var/lib/google-cloud-ops-agent/fluent-bit/buffers

Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent - Logging Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent - Logging Agent.
Aug 05 20:33:44 debian9 fluent-bit[2247]: Fluent Bit v1.7.8
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2019-2021 The Fluent Bit Authors
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2015-2018 Treasure Data
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
Aug 05 20:33:44 debian9 fluent-bit[2247]: * https://fluentbit.io

● google-cloud-ops-agent-opentelemetry-collector.service - Google Cloud Ops Agent - Metrics Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service.d
           └─directories.conf
   Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2237 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
  Process: 2215 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=otel -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
 Main PID: 2251 (otelopscol)
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent-opentelemetry-collector.service
           └─2251 /opt/google-cloud-ops-agent/subagents/opentelemetry-collector/otelopscol --add-instance-id=false --config=/run/google-cloud-ops-agent-opentelemetry-collector/otel.yaml

Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        builder/pipelines_builder.go:51        Pipeline is starting...        {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        builder/pipelines_builder.go:62        Pipeline is started.        {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        service/service.go:192        Starting receivers...
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z        info        builder/receivers_builder.go:70        Receiver is starting...        {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z        info        builder/receivers_builder.go:75        Receiver started.        {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        builder/receivers_builder.go:70        Receiver is starting...        {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        discovery/manager.go:195        Starting provider        {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0", "subs": "[otel-collector]"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        builder/receivers_builder.go:75        Receiver started.        {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        service/collector.go:182        Everything is ready. Begin running and processing data.
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.256Z        info        discovery/manager.go:213        Discoverer channel closed        {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0"}

For Windows

Get-Service google-cloud-ops-agent*

Status   Name               DisplayName
------   ----               -----------
Running  google-cloud-op... Google Cloud Ops Agent
Running  google-cloud-op... Google Cloud Ops Agent - Logging Agent
Running  google-cloud-op... Google Cloud Ops Agent - Metrics Agent

Se o serviço do agente não estiver em execução, você verá o seguinte status:

Linux

$ sudo service google-cloud-ops-agent status
● google-cloud-ops-agent.service - Google Cloud Ops Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Wed 2021-06-30 21:20:43 UTC; 6s ago

Windows

Get-Service google-cloud-ops-agent

Status   Name                    DisplayName
------   ----                    -----------
Stopped  google-cloud-ops-agent  Google Cloud Ops Agent

Para corrigir esse erro, execute o seguinte comando para iniciar o serviço:

Linux

sudo service google-cloud-ops-agent start

Windows

Start-Service google-cloud-ops-agent

Se o serviço não for iniciado, a configuração poderá ser inválida.

Conflito com os agentes instalados atualmente

A VM já tem o agente do Cloud Logging ou o agente do Cloud Monitoring instalado, e a configuração deles entra em conflito com as configurações do novo agente. A mensagem de erro pode ser semelhante a esta:

Windows
```
We detected an existing Windows service for the StackdriverLogging agent,
which is not compatible with the Ops Agent when the Ops Agent configuration
has a non-empty logging section. Please either remove the logging section
from the Ops Agent configuration, or disable the StackdriverLogging agent,
and then retry enabling the Ops Agent.
```
Para corrigir esse erro, você tem duas opções:
1. Desativar a seção conflitante do arquivo de configuração do agente de operações. Para mais informações, consulte o guia Configurar o agente de operações.
2. Desative o agente do Cloud Logging ou o agente do Cloud Monitoring conflitante.
  1. Salve todos os arquivos de configuração personalizados para o agente do Cloud Logging.
  2. Desinstale o agente do Cloud Monitoring antigo e o agente do Cloud Logging.
  Depois de desinstalar o agente, o console do Google Cloud pode levar até uma hora para informar essa alteração.

Configuração inválida

Se a configuração for inválida, talvez você verá o seguinte erro ao tentar reiniciar o serviço do agente:

Linux

$ sudo service google-cloud-ops-agent restart \
    && sudo service google-cloud-ops-agent status
● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
           └─directories.conf
   Active: failed (Result: exit-code) since Wed 2021-06-30 22:21:08 UTC; 2s ago
  Process: 1141421 ExecStart=/opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config ${RUNTIME_DIRECTORY}/fluent_bit_main.conf --parser ${RUNTIME_DIRECTORY}/fluent_bit_parser.conf --log_>
  Process: 1141847 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIR>
 Main PID: 1141421 (code=exited, status=0/SUCCESS)

Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Control process exited, code=exited status=1
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Service RestartSec=100ms expired, scheduling restart.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Scheduled restart job, restart counter is at 5.
Jun 30 22:21:08 centos8-2 systemd[1]: Stopped Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Start request repeated too quickly.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.

Use journalctl para receber a mensagem de erro exata:

sudo journalctl -xe | grep "google_cloud_ops_agent_engine"

Você verá uma mensagem semelhante a esta:

Jun 30 22:00:26 centos8-2 google_cloud_ops_agent_engine[1141491]: 2021/06/30 22:00:26 the agent config file is not valid YAML. detailed error: yaml: line 21: did not find expected key

Windows

failed to generate config files: can't parse configuration: yaml: line 20: could not find expected ':'

Para corrigir o erro, corrija a configuração inválida e reinicie o agente. Para referência, consulte o guia Configurar o agente de operações.

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, selecione Monitoramento ou clique no botão a seguir:

Acessar Monitoring
No painel de navegação, selecione Metrics Explorer .
Selecione a guia 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?

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, 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.

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.

Inspecionar registros próprios do agente

Se o agente não ingerir registros no Cloud Logging, talvez seja necessário inspecionar os registros localmente na VM para resolver problemas.

Linux

Para inspecionar registros próprios gravados em Journald, execute o comando a seguir:

journalctl -u google-cloud-ops-agent*

Para inspecionar os registros próprios gravados no disco pelo módulo de geração de registros, execute o comando a seguir:

vim /var/log/google-cloud-ops-agent/subagents/logging-module.log

Windows

Para inspecionar registros próprios gravados em Windows Event Logs, execute o comando a seguir:

Get-WinEvent -FilterHashtable @{ Logname='Application'; ProviderName='google-cloud-ops-agent*' } | Format-Table -AutoSize -Wrap

Para inspecionar os registros próprios gravados no disco pelo módulo de geração de registros, execute o comando a seguir:

notepad "C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"

Para inspecionar os registros de Windows Service Control Manager dos serviços do Agente de operações, execute o comando a seguir:

Get-WinEvent -FilterHashtable @{ Logname='System'; ProviderName='Service Control Manager' } | Where-Object -Property Message -Match 'Google Cloud Ops Agent' | Format-Table -AutoSize -Wrap

Configurar a rotação de arquivos de registro próprios nas VMs do Linux

Para limitar o tamanho do registro do subagente de geração de registros em /var/log/google-cloud-ops-agent/subagents/logging-module.log, instale e configure o utilitário logrotate.

Instale o utilitário logrotate executando o seguinte comando:

No Debian e no Ubuntu
```
sudo apt install logrotate
```
No CentOS, no RHEL e no Fedora
```
sudo yum install logrotate
```

Crie um arquivo de configuração logrotate em /etc/logrotate.d/google-cloud-ops-agent.conf.

sudo tee /etc/logrotate.d/google-cloud-ops-agent.conf > /dev/null << EOF
# logrotate config to rotate Google Cloud Ops Agent self log file.
# See https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html for
# the full options.
/var/log/google-cloud-ops-agent/subagents/logging-module.log
{
    # Log files are rotated every day.
    daily
    # Log files are rotated this many times before being removed. This
    # effectively limits the disk space used by the Ops Agent self log files.
    rotate 30
    # Log files are rotated when they grow bigger than maxsize even before the
    # additionally specified time interval
    maxsize 256M
    # Skip rotation if the log file is missing.
    missingok
    # Do not rotate the log if it is empty.
    notifempty
    # Old versions of log files are compressed with gzip by default.
    compress
    # Postpone compression of the previous log file to the next rotation
    # cycle.
    delaycompress
}
EOF

Configure crontab ou systemd timer para acionar o utilitário logrotate periodicamente.

Depois que a rotação de registro entrar em vigor, você verá os arquivos rotacionados no diretório /var/log/google-cloud-ops-agent/subagents/. Os resultados são semelhantes à saída a seguir:

/var/log/google-cloud-ops-agent/subagents$ ls -lh
total 24K
-rw-r--r-- 1 root root  717 Sep  3 19:54 logging-module.log
-rw-r--r-- 1 root root 6.8K Sep  3 19:51 logging-module.log.1
-rw-r--r-- 1 root root  874 Sep  3 19:50 logging-module.log.2.gz
-rw-r--r-- 1 root root  873 Sep  3 19:50 logging-module.log.3.gz
-rw-r--r-- 1 root root 3.2K Sep  3 19:34 logging-module.log.4.gz

Para testar a rotação de registro, faça o seguinte:

Reduza temporariamente o tamanho do arquivo em que a rotação é acionada definindo o valor maxsize como 1k no arquivo /etc/logrotate.d/google-cloud-ops-agent.conf.
Para acionar o arquivo de registro próprio do agente para ser maior que 1 mil, reinicie o agente algumas vezes:
```
sudo service google-cloud-ops-agent restart
```
Aguarde até que crontab ou systemd timer entrem em vigor para acionar o utilitário logrotate ou acione o utilitário logrotate manualmente executando este comando:
```
sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.conf
```
Verifique se você está vendo arquivos de registro rotacionados no diretório /var/log/google-cloud-ops-agent/subagents/.
Redefina a configuração da rotação de registro restaurando o valor original de maxsize.

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

A seção a seguir contém problemas comuns conhecidos. Para as que já foram corrigidas ou mitigadas, siga as instruções específicas para solucionar o problema.

Registros não nocivos

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 eliminá-los, 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

Erros quando o primeiro ponto de dados de métricas cumulativas é 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"}

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 superior 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
`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.

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.

Os registros próprios do agente consomem muito CPU, memória e espaço em disco.

As versões antigas do agente de operações podem consumir muito CPU, memória e espaço em disco com arquivos /var/log/google-cloud-ops-agent/subagents/logging-module.log em VMs Linux ou arquivos 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 ou mais recente e redefina totalmente o estado do agente.

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

Os carimbos de data/hora do log de eventos estão errados no Windows

Os carimbos de data/hora associados aos logs de eventos do Windows no Cloud Logging podem estar incorretos, dependendo das configurações de fuso horário do seu sistema. Se isso acontecer, tente uma das soluções alternativas a seguir.

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