Solucionar problemas del agente de operaciones

Nota: El extremo localhost:2020/api/v1/metrics que se menciona en el minuto 3:18 de este video ya no está disponible en el agente de operaciones. Para ver otras opciones, consulta El agente está en ejecución, pero los datos no se transfieren.

En este documento, encontrarás ayuda para diagnosticar problemas durante la instalación o la ejecución del agente de operaciones.

Herramienta de diagnóstico de agente para VMs

La herramienta de diagnóstico del agente recopila información crítica de depuración local de tus VMs para todos los agentes siguientes: agente de operaciones, agente de Logging heredado y agente de Monitoring heredado. La información de depuración incluye información como la información del proyecto, la información de VM, la configuración del agente, los registros del agente, el estado del servicio del agente, la información que suele requerir trabajo manual. La herramienta también verifica el entorno de VM local para garantizar que cumpla con ciertos requisitos a fin de que los agentes funcionen correctamente, por ejemplo, la conectividad de red y los permisos necesarios.

Cuando presentas un caso de cliente para un agente en una VM, ejecuta la herramienta de diagnóstico de agente y adjunta la información recopilada al caso. Antes de adjuntar la información al caso de asistencia, oculta cualquier información sensible, como contraseñas. Proporciona esta información para reducir el tiempo necesario a fin de solucionar problemas de tu caso de asistencia.

La herramienta de diagnóstico de agentes debe ejecutarse desde la VM, por lo que, por lo general, primero deberás establecer una conexión SSH a la VM. El siguiente comando recupera la herramienta de diagnóstico del agente y la ejecuta:

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"

Sigue el resultado de la ejecución de la secuencia de comandos para ubicar los archivos que incluyen la información recopilada. Por lo general, se pueden encontrar en el directorio /var/tmp/google-agents de Linux y en el directorio $env:LOCALAPPDATA/Temp de Windows, a menos que hayas personalizado el directorio de salida cuando ejecutas la secuencia de comandos.

Para obtener información detallada, examina la secuencia de comandos diagnose-agents.sh en Linux o la secuencia de comandos diagnose-agents.ps1 en Windows.

No se pudo instalar el agente

Es posible que surjan los siguientes errores durante la ejecución de la secuencia de comandos de instalación.

• El sistema operativo no es compatible. El mensaje de error será similar al siguiente:

  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
  

• La VM ya tiene el agente de Cloud Logging o el agente de Cloud Monitoring instalado, y esos agentes entran en conflicto con el agente nuevo. El mensaje de error será similar al siguiente:

  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
  

  El agente de operaciones usa archivos de configuración nuevos que no son compatibles con los agentes anteriores. Para obtener más información, consulta la guía Configura el agente de operaciones.

  Para resolver este error, haz lo siguiente:

  1. Guarda los archivos de configuración personalizados para el agente de Cloud Monitoring y el agente de Cloud Logging.

  2. Desinstala el agente de Cloud Monitoring anterior y el agente de Cloud Logging anteriores.

     Después de desinstalar el agente, Google Cloud Console puede tardar hasta una hora en informar este cambio.

El agente está instalado, pero no se ejecuta

Los servicios de agente no se están ejecutando

Cuando el servicio de agente se ejecuta según lo previsto, es posible que veas el siguiente estado:

Para 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"}

Para 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

Si el servicio de agente no se ejecuta, es posible que veas el siguiente estado:

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 corregir este error, ejecuta el siguiente comando a fin de iniciar el servicio:

Linux

sudo service google-cloud-ops-agent start

Windows

Start-Service google-cloud-ops-agent

Si el servicio no se inicia, es posible que la configuración no sea válida.

Conflicto con agentes instalados actualmente

• La VM ya tiene el agente de Cloud Logging o el agente de Cloud Monitoring instalado, y su configuración entra en conflicto con la configuración del agente nuevo. El mensaje de error será similar al siguiente:

  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 corregir este error, tiene dos opciones:

  1. Inhabilitar la sección de conflicto del archivo de configuración del agente de operaciones. Para obtener más información, consulta la guía Configura el agente de operaciones.

  2. Inhabilita el agente de Cloud Logging en conflicto o el agente de Cloud Monitoring.

     1. Guarda cualquier archivo de configuración personalizado para el agente de Cloud Logging.
     2. Luego, desinstala el agente de Cloud Monitoring y el agente de Cloud Logging anteriores.

     Después de desinstalar el agente, Google Cloud Console puede tardar hasta una hora en informar este cambio.

La configuración no es válida

Si la configuración no es válida, es posible que veas el siguiente error cuando intentes iniciar el servicio de 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.

Usa journalctl para obtener el mensaje de error exacto:

sudo journalctl -xe | grep "google_cloud_ops_agent_engine"

Deberías ver un mensaje similar al siguiente:

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 corregir el error, corrige la configuración no válida y reinicia el agente. Si deseas obtener más información, consulta la guía Configura el agente de operaciones.

El agente está en ejecución, pero los datos no se transfieren

Usa el Explorador de métricas para consultar la métrica uptime del agente y verifica que el componente del agente, google-cloud-ops-agent-metrics o google-cloud-ops-agent-logging, escriba en la métrica.

1. En la consola de Google Cloud, selecciona Monitoring o haz clic en el siguiente botón:
   

   Ir a Monitoring

2. En el panel de navegación, selecciona Explorador de métricas.

3. Selecciona la pestaña MQL.

4. Ingresa la siguiente consulta y, luego, haz clic en Ejecutar:

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

¿El agente envía registros a Cloud Logging?

Verifica las métricas locales

Nota: El servicio de métricas locales no está disponible en Windows.

En este paso, se requiere que establezcas una conexión SSH a la VM.

• ¿El módulo de registro está en ejecución? Usa los siguientes comandos para verificarlo:

Linux

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

Windows

Abre Windows PowerShell como administrador y ejecuta lo siguiente:

Get-Service google-cloud-ops-agent

También puedes verificar el estado del servicio en la app de Services y, también, inspeccionar los procesos en ejecución en la app de Task Manager.

Verifica el registro del módulo de registro

En este paso, se requiere que establezcas una conexión SSH a la VM.

Puedes encontrar los registros del módulo de registro en /var/log/google-cloud-ops-agent/subagents/*.log para Linux y C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log en Windows. Si no hay registros, esto indica que el servicio de agente no se ejecuta de forma correcta. Ve a la sección El agente está instalado, pero no se ejecuta primero para corregir esa condición.

• Pueden generarse errores de permiso 403 cuando escribes en la API de Logging. Por ejemplo:

  [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 corregir este error, habilita la API de Logging y configura la función de escritor de registros.

• Es posible que veas un problema de cuota para la API de Logging. Por ejemplo:

  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 corregir este error, aumenta la cuota o reduce la capacidad de procesamiento de registros.

• Es posible que veas los siguientes errores en el registro del módulo:

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

  o

  can't fetch token from the metadata server
  

  Estos errores pueden indicar que implementaste el agente sin una cuenta de servicio o credenciales especificadas. Si necesitas información para resolver este problema, consulta Autoriza el Agente de operaciones.

¿El agente envía métricas a Cloud Monitoring?

Verifica el registro del módulo de métricas

En este paso, se requiere que establezcas una conexión SSH a la VM.

Puedes buscar los registros del módulo de métricas en syslog. Si no hay registros, esto indica que el servicio de agente no se ejecuta de forma correcta. Ve a la sección El agente está instalado, pero no se ejecuta primero para corregir esa condición.

• Es posible que veas errores PermissionDenied cuando escribas en la API de Monitoring. Este error ocurre si los permisos para el agente de operaciones no están configurado de forma correcta. Por ejemplo:

  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 corregir este error, habilita la API de Monitoring y configura la función de escritor de métricas de Monitoring.

• Es posible que veas errores ResourceExhausted cuando escribas en la API de Monitoring. Este error se produce si el proyecto alcanza el límite de cualquier cuota de la API de Monitoring. Por ejemplo:

  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 corregir este error, aumenta la cuota o reduce la capacidad de procesamiento de las métricas.

• Es posible que veas los siguientes errores en el registro del módulo:

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

  o

  can't fetch token from the metadata server
  

  Estos errores pueden indicar que implementaste el agente sin una cuenta de servicio o credenciales especificadas. Si necesitas información para resolver este problema, consulta Autoriza el Agente de operaciones.

Inspecciona los registros propios del agente

Si el agente no puede transferir registros a Cloud Logging, es posible que debas inspeccionar los registros de forma local en la VM para solucionar problemas.

Linux

Nota: Todo en la sección Linux se automatiza como parte de la herramienta de diagnóstico. Para realizar la inspección de registros de forma manual, continúa con los siguientes pasos.

Para inspeccionar los registros propios que se escriben en Journald, ejecuta el siguiente comando:

journalctl -u google-cloud-ops-agent*

Para inspeccionar los registros propios que el módulo de registro escribe en el disco, ejecuta el siguiente comando:

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

Windows

Para inspeccionar los registros propios que se escriben en Windows Event Logs, ejecuta el siguiente comando:

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

Para inspeccionar los registros propios que el módulo de registro escribe en el disco, ejecuta el siguiente comando:

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

A fin de inspeccionar los registros de Windows Service Control Manager para los servicios del agente de operaciones, ejecuta el siguiente comando:

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

Configura la rotación de archivos de registro propio en las VM de Linux

Para limitar el tamaño del registro del agente secundario de registro en /var/log/google-cloud-ops-agent/subagents/logging-module.log, instala y configura la utilidad logrotate.

1. Instala la utilidad logrotate; para ello, ejecuta el siguiente comando:

   En Debian y Ubuntu

   sudo apt install logrotate
   

   En CentOS, RHEL y Fedora

   sudo yum install logrotate
   

2. Crea un archivo de configuración logrotate en /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
   

3. Configura crontab o systemd timer para activar la utilidad logrotate de forma periódica.

Una vez que la rotación del registro entra en vigor, verás los archivos rotados en el directorio /var/log/google-cloud-ops-agent/subagents/. Los resultados son similares a los siguientes:

/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 probar la rotación del registro, haz lo siguiente:

1. Para reducir de forma temporal el tamaño en el que se activa la rotación, configura el valor maxsize como 1k en el archivo /etc/logrotate.d/google-cloud-ops-agent.conf.

2. Activa el archivo de registro propio del agente para que sea mayor que 1K; para ello, reinicia el agente varias veces:

   sudo service google-cloud-ops-agent restart
   

3. Espera a que crontab o systemd timer se activen para activar la utilidad logrotate o activa la utilidad logrotate de forma manual si ejecutas este comando:

   sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.conf
   

4. Verifica que veas archivos de registro rotados en el directorio /var/log/google-cloud-ops-agent/subagents/.

5. Restablece la configuración de la rotación de registros mediante el restablecimiento del valor maxsize original.

Restablece por completo el estado del agente

Si el agente ingresa a un estado no recuperable, sigue estos pasos para restablecer el agente a un estado nuevo.

Nota: Este proceso quita todo el estado del búfer, lo que puede provocar la pérdida de registros. Para un proceso que no restablezca el estado del búfer, consulta Restablece, pero guarda los archivos del búfer.

Linux

Detén el servicio del agente:

sudo service google-cloud-ops-agent stop

Quita el paquete de 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

Quita los registros propios del agente en el disco:

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

Quita los búferes locales del agente en el disco:

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

Nota: El directorio /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ contiene los siguientes tipos de archivos:

• Archivos de búfer: Estos archivos son entradas de registro almacenadas en búfer que el agente de operaciones puso en cola y procesó, pero que aún no se transfirieron a Cloud Logging. Cuando hay fragmentos dañados, el agente de operaciones debe omitirlos en versiones >= 2.15.0. Sin embargo, en algunos casos, debe limpiarlos de forma manual. Estos archivos se almacenan en carpetas anidadas como las siguientes: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
• Archivos de posición de seguimiento de archivos de registro: Estos archivos registran la ubicación de los archivos de registro que el agente de operaciones ya realizó. Si se quitan estos archivos, el agente de operaciones comenzará desde la parte superior de los archivos que está configurado para poner en cola. Si borras estos archivos, es posible que se dupliquen los registros si esos registros se transfirieron correctamente. Estos archivos se almacenan directamente en el directorio como archivos como: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

La sintaxis .../buffers/*/ en el comando anterior garantiza que solo se borren los archivos de búfer. Los archivos de posición no se borran.

Reinstala y reinicia el agente:

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

Windows

Nota: Los comandos para Windows deben ejecutarse en Powershell como Administrador.

Detén el servicio del 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*";

Quita el paquete de 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"

Quita los registros propios del agente en el disco:

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

Quita los búferes locales del agente en el disco:

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

Nota: Al igual que con Linux, este comando borra solo los subdirectorios del directorio C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers para que se quiten los archivos del búfer sin modificar los archivos de posición.

Reinstala y reinicia el 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"

Restablece los archivos almacenados en búfer, pero guárdalos

Si la VM no tiene fragmentos de búfer dañados (es decir, no hay mensajes format check failed en el archivo de registro propio del agente de operaciones), puedes omitir los comandos anteriores que quitan los búferes locales cuando restableces el estado del agente.

Si la VM tiene fragmentos de búfer dañados, debes quitarlos. En las siguientes opciones, se describen diferentes formas de manejar los búferes. Aún se aplican los otros pasos descritos en Restablece por completo el estado del agente.

• Opción 1: Borra todo el directorio buffers. Esta es la opción más fácil, pero puede provocar la pérdida de los registros almacenados en búfer o la duplicación de registros no dañados debido a la pérdida de los archivos de posición.

  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";
  

• Opción 2: Borra los subdirectorios del búfer del directorio buffers, pero deja los archivos de posición. Este enfoque se describe en Restablece por completo el estado del agente.

• Opción 3: Si no deseas borrar todos los archivos de búfer, puedes extraer los nombres de los archivos de búfer dañados de los registros propios del agente y borrar solo los archivos de búfer dañados.

  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\' + $_)}
  };
  

• Opción 4: Si hay muchos búferes dañados y deseas volver a procesar todos los archivos de registro, puedes usar los comandos de la opción 3 y también borrar los archivos de posición (que almacenan el progreso del Agente de operaciones por archivo de registro). Borrar los archivos de posición puede provocar una duplicación de registro para cualquier registro que ya se haya transferido de forma correcta. Esta opción solo vuelve a procesar los archivos de registro actuales; No vuelve a procesar los archivos que ya se rotaron o los registros de otras fuentes, como un puerto TCP. Los archivos de posición se almacenan en el directorio buffers, pero se almacenan como archivos. Los búferes locales se almacenan como subdirectorios en el directorio 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 conocidos

La siguiente sección contiene problemas comunes conocidos. Para los que ya se solucionaron o mitigaron, sigue las instrucciones específicas a fin de recoger la solución.

Registros no dañinos

• Errores cuando se copian las métricas de seudoprocesos o procesos restringidos

  Los siguientes registros no son perjudiciales y pueden ignorarse de forma segura. Para borrarlos, actualiza el agente de operaciones a la versión 2.10.0 o superior.

  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
  

• Errores cuando se descarta el primer dato de métricas acumulativas:

  Los siguientes registros no son perjudiciales y pueden ignorarse de forma segura.

  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"}
  

Algunas de las métricas faltan o no son coherentes

Existe una pequeña cantidad de métricas que el agente de operaciones versión 2.0.0 y versiones posteriores manejan de manera diferente a las versiones de “vista previa” del agente de operaciones (versiones anteriores a la 2.0.0) o el agente de Monitoring.

En la siguiente tabla, se describen las diferencias en los datos que transfieren el agente de operaciones y el agente de Monitoring.

Tipo de métrica, no incluye agent.googleapis.com	Agente de operaciones (Google Analytics)^†	Agente de operaciones (vista previa)^†	Agente de supervisión
disk/bytes_used y disk/percent_used	Se transfirió con la ruta completa en la etiqueta device, por ejemplo, /dev/sda15. No se transfiere en dispositivos virtuales como tmpfs y udev.	Se transfirió sin /dev en la ruta de acceso en la etiqueta device, por ejemplo, sda15. Se transfirió para dispositivos virtuales, como tmpfs y udev.	Se transfirió sin /dev en la ruta de acceso en la etiqueta device, por ejemplo, sda15. Se transfirió para dispositivos virtuales, como tmpfs y udev.

^† La columna DG hace referencia a la versión 2.0.0 del agente de operaciones y las versiones posteriores. La columna Vista previa hace referencia a las versiones del agente de operaciones anteriores a la 2.0.0.

Se quitó el agente que Google Cloud Console informó como instalado

Después de desinstalar el agente, Google Cloud Console puede tardar hasta una hora en informar este cambio.

Los registros propios del agente consumen demasiada CPU, memoria y espacio en disco

Las versiones anteriores del agente de operaciones pueden consumir mucha memoria, CPU y espacio en disco con archivos /var/log/google-cloud-ops-agent/subagents/logging-module.log en VMs de Linux o C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log en VMs de Windows debido a fragmentos de búfer dañados. Cuando esto sucede, verás una gran cantidad de mensajes como los siguientes en el archivo logging-module.log.

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

Para resolver este problema, actualiza el Agente de operaciones a la versión 2.17 o una superior y Restablece por completo el estado del agente.

Contadores de rendimiento dañados en Windows

Si el agente secundario de las métricas no se inicia, es posible que veas uno de los siguientes errores en Cloud Logging:

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

Estos errores pueden ocurrir si los contadores de rendimiento de tu sistema se dañan. Puedes resolver los errores si vuelves a compilar los contadores de rendimiento. En PowerShell como administrador, ejecuta lo siguiente:

cd C:\Windows\system32
lodctr /R

En ocasiones, el comando anterior puede fallar. En ese caso, vuelve a cargar PowerShell y vuelve a intentarlo hasta que tenga éxito.

Después de que el comando se ejecute de forma correcta, reinicia el Agente de operaciones:

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

Las marcas de tiempo del registro de eventos son incorrectas en Windows

Las marcas de tiempo asociadas con los registros de eventos de Windows en Cloud Logging pueden ser incorrectas, según la configuración de zona horaria de tu sistema. Si notas que esto ocurre, puedes probar una de las siguientes soluciones.

Usa una zona horaria UTC

En PowerShell, ejecuta los siguientes comandos como administrador:

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

Anula la configuración de zona horaria solo para el servicio del agente secundario de registro

En PowerShell, ejecuta los siguientes comandos como administrador:

Precaución: Esto reemplazará el valor de registro Entorno para el servicio si ya existe.

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