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:
Salve os arquivos de configuração personalizados do agente do Cloud Monitoring e do agente do Cloud Logging.
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:
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.
Desative o agente do Cloud Logging ou o agente do Cloud Monitoring conflitante.
- Salve todos os arquivos de configuração personalizados para o agente do Cloud Logging.
- 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:
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
ousystemd timer
para acionar o utilitáriologrotate
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
como1k
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
ousystemd timer
entrem em vigor para acionar o utilitáriologrotate
ou acione o utilitáriologrotate
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/*/
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óriobuffers
,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, omitindoagent.googleapis.com |
Agente de operações (disponibilidade geral)† | Agente de operações (visualização)† | Agente do Monitoring |
---|---|---|---|
disk/bytes_used edisk/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 . |
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