Soluciona problemas de transferencia de datos del Agente de operaciones

En este documento, se proporciona información para ayudarte a diagnosticar y resolver problemas de transferencia de datos, para registros y métricas, en el Agente de operaciones en ejecución. Si el Agente de operaciones no se ejecuta, consulta Soluciona problemas de instalación y de inicio.

Antes de comenzar

Antes de intentar solucionar un problema, comprueba el estado de las verificaciones de estado del agente.

La consola de Google Cloud muestra la instalación del Agente de operaciones detenida en “Pendiente”

Incluso después de instalar de forma correcta el Agente de operaciones, es posible que la consola de Google Cloud muestre el estado “Pendiente”. Usa gcpdiag para confirmar la instalación del Agente de operaciones y verificar que el agente sí transmite registros y métricas desde tu instancia de VM.

Motivos comunes de los errores de instalación

La instalación del agente de operaciones puede fallar por los siguientes motivos:

• La VM no tiene una cuenta de servicio conectada. Conecta una cuenta de servicio a la VM y, luego, reinstala el Agente de operaciones.

• La VM ya tiene uno de los agentes heredados instalados, lo que evita la instalación del Agente de operaciones. Desinstala los agentes heredados y, luego, vuelve a instalar el Agente de operaciones.

Motivos comunes de las fallas de transmisión por telemetría

Un Agente de operaciones instalado y en ejecución puede no enviar registros, métricas o ambos desde una VM por los siguientes motivos:

• A la cuenta de servicio conectada a la VM le falta el rol roles/logging.logWriter o roles/monitoring.metricWriter.
• El permiso de acceso de registro o supervisión no está habilitado. Para obtener más información sobre cómo verificar y actualizar los permisos de acceso, consulta Verifica tus permisos de acceso.
• La API de Logging o la API de Monitoring no están habilitadas.

Usa las verificaciones de estado del agente para identificar la causa raíz y la solución correspondiente.

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, ve a la página  Explorador de métricas:

   Dirígete al Explorador de métricas

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.

2. En el botón de activación Code Code, selecciona Code y, luego, establece el lenguaje en MQL.

3. 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?

Si el agente está en ejecución, pero no envía registros, verifica el estado de las verificaciones de estado del entorno de ejecución del agente.

Errores de canalización

Si ves el error del entorno de ejecución LogPipelineErr (“la canalización de registro del agente de operaciones falló”), el subagente de Logging tuvo un problema con la escritura de los registros. Verifica estas condiciones:

• Verifica que se pueda acceder a los archivos de almacenamiento del agente secundario de Logging. Estos archivos se encuentran en las siguientes ubicaciones:
  • Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
  • Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
• Verifica que el disco de la VM no esté lleno.
• Verifica que la configuración de registro sea correcta.

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

Si cambias la configuración de registro o si se puede acceder a los archivos del búfer y el disco de la VM no está lleno, reinicia el agente de operaciones:

Linux

1. Para reiniciar el agente, ejecuta el siguiente comando en tu instancia:

   sudo systemctl restart google-cloud-ops-agent
   

2. Para confirmar que el agente se reinició, ejecuta el siguiente comando y verifica que los componentes “Agente de métricas” y “Agente de Logging” se iniciaron:

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

Windows

1. Conéctate a tu instancia con RDP o una herramienta similar y accede a Windows.
2. Haz clic con el botón derecho en el ícono de PowerShell y selecciona Ejecutar como administrador para abrir una terminal de PowerShell con privilegios de administrador.
3. Para reiniciar el agente, ejecuta el siguiente comando de PowerShell:

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

4. Para confirmar que el agente se reinició, ejecuta el siguiente comando y verifica que los componentes “Agente de métricas” y “Agente de Logging” se iniciaron:

   Get-Service google-cloud-ops-agent*
   

Errores de análisis de registros

Si ves el error del entorno de ejecución LogParseErr (“el agente de operaciones no pudo analizar los registros”), el problema más probable es la configuración de un procesador de registro. Para solucionar este problema, haz lo siguiente:

• Verifica que la configuración de cualquier procesador parse_json sea correcta.
• Verifica que la configuración de cualquier procesador parse_regex sea correcta.
• Si no tienes procesadores parse_json o parse_regex, verifica la configuración de cualquier otro procesador de registro.

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

Si cambias la configuración de registro, reinicia el agente de operaciones:

Linux

1. Para reiniciar el agente, ejecuta el siguiente comando en tu instancia:

   sudo systemctl restart google-cloud-ops-agent
   

2. Para confirmar que el agente se reinició, ejecuta el siguiente comando y verifica que los componentes “Agente de métricas” y “Agente de Logging” se iniciaron:

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

Windows

1. Conéctate a tu instancia con RDP o una herramienta similar y accede a Windows.
2. Haz clic con el botón derecho en el ícono de PowerShell y selecciona Ejecutar como administrador para abrir una terminal de PowerShell con privilegios de administrador.
3. Para reiniciar el agente, ejecuta el siguiente comando de PowerShell:

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

4. Para confirmar que el agente se reinició, ejecuta el siguiente comando y verifica que los componentes “Agente de métricas” y “Agente de Logging” se iniciaron:

   Get-Service google-cloud-ops-agent*
   

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, significa que el servicio del agente no se está ejecutando adecuadamente. 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.

Problemas con la conectividad de red

Si el agente está en ejecución, pero no envía registros ni métricas, es posible que tengas un problema de redes. Los tipos de problemas de conectividad de red que puedes encontrar varían con la topología de tu aplicación. Para obtener una descripción general de las herramientas de redes de Compute Engine, consulte Descripción general de la red para las VMs.

Entre las causas comunes de los problemas de conectividad, se incluyen las siguientes:

• Reglas de firewall que interfieren con el tráfico entrante. Para obtener información sobre las reglas de firewall, consulta Usa reglas de firewall de VPC.
• Problemas en la configuración de un proxy HTTP
• Configuración de DNS.

El Agente de operaciones ejecuta verificaciones de estado que detectan errores de conectividad de red. Consulta la documentación de las verificaciones de estado para conocer las acciones sugeridas para los errores de conectividad.

A partir de la versión 2.28.0 del agente de operaciones, el agente de operaciones limita la cantidad de espacio en disco que puede usar para almacenar fragmentos de búfer. El agente de operaciones crea fragmentos de búfer cuando los datos de registro no se pueden enviar a la API de Cloud Logging. Sin un límite, estos fragmentos pueden consumir todo el espacio disponible, lo que interrumpe otros servicios en la VM. Cuando una interrupción de red hace que los fragmentos de búfer se escriban en el disco, el agente de operaciones usa una cantidad de espacio en disco específica de la plataforma para almacenar los fragmentos. Un mensaje como el siguiente ejemplo también aparece en /var/log/google-cloud-ops-agent/subagents/logging-module.log en las VM de Linux o en C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log en las VM de Windows cuando la VM no puede enviar los fragmentos de búfer a la API de Cloud Logging:

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

Quiero recopilar solo métricas o registros, no ambos

De forma predeterminada, el Agente de operaciones recopila métricas y registros. Para inhabilitar la recopilación de métricas o registros, usa el archivo config.yaml del Agente de operaciones a fin de anular el servicio predeterminado logging o metrics, de modo que la canalización predeterminada no tenga receptores. Para obtener más información, consulta lo siguiente:

• Ejemplos de opciones de configuración de registros de service
• Ejemplos de opciones de configuración de métricas de service

Detener la transferencia de datos mediante la inhabilitación de los servicios del agente secundario del Agente de operaciones “Agente de Logging” o “Agente de Monitoring” genera una configuración no válida y no es compatible.

Se están recopilando las métricas, pero parece que hay un problema

El agente registra mensajes “La exportación falló. Se volverán a intentar"

Verás las entradas de registro “La exportación falló” cuando se descarta el primer dato de una métrica acumulativa. 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"}
  

El agente registra “Las TimeSeries no se pudieron escribir: los puntos deben estar escritos en orden”. mensajes

Si actualizaste al agente de operaciones desde el agente de Monitoring heredado y ves el siguiente mensaje de error cuando escribes métricas acumulativas, la solución es reiniciar la VM. El Agente de operaciones y el Agente de Monitoring calculan las horas de inicio para las métricas acumulativas de manera diferente, lo que puede provocar que los puntos aparezcan desordenados. Reiniciar la VM restablece la hora de inicio y corrige este problema.

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

El agente registra los mensajes “El token debe ser de corta duración (60 minutos) y en un período razonable”

Si ves el siguiente mensaje de error cuando el agente escribe métricas, indica que el reloj del sistema no está sincronizado de forma correcta:

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

Para obtener información sobre la sincronización de relojes del sistema, consulta Configura NTP en una VM.

El agente registra “el receptor de métricas con el tipo “nvml” no es compatible”

Si recopilas métricas de GPU de la biblioteca de administración de NVIDIA (NVML) (agent.googleapis.com/gpu) mediante el receptor nvml, eso significa que usaste una versión del agente de operaciones con compatibilidad de vista previa para las métricas NVML. La asistencia para estas métricas está disponible para el público en general en la versión 2.38.0 del Agente de operaciones. En la versión de Google Analytics, la recopilación de métricas que realizó el receptor nvml se fusionó en el receptor hostmetrics y se quitó el receptor nvml.

Verás el mensaje de error “El receptor de métricas con el tipo “nvml” no es compatible” después de instalar la versión 2.38.0 o posterior del Agente de operaciones cuando usabas el receptor nvml de vista previa y anulaste el intervalo de recopilación predeterminado en tu archivo de configuración especificado por el usuario. El error se produce porque el receptor nvml ya no existe, pero el archivo de configuración especificado por el usuario aún hace referencia a él.

Para corregir este problema, actualiza el archivo de configuración especificado por el usuario para anular el intervalo de recopilación en el receptor hostmetrics.

Faltan métricas de GPU

Si el agente de operaciones recopila algunas métricas, pero faltan algunas o todas las métricas de GPU de la GPU de la biblioteca de administración de NVIDIA (NVML) (agent.googleapis.com/gpu), es posible que tengas un problema de configuración o que no tengas procesos que usen la GPU.

Si no recopilas métricas de GPU, verifica el controlador de GPU. Para recopilar métricas de GPU, el Agente de operaciones requiere que el controlador de GPU se instale y configure en la VM. Para verificar el controlador, haz lo siguiente:

1. Para verificar que el controlador esté instalado y se ejecute de forma correcta, sigue los pasos para verificar la instalación del controlador de GPU.

2. Si el controlador no está instalado, haz lo siguiente:

   1. Instala el controlador de GPU.

   2. Reinicia el Agente de operaciones.

      Debes reiniciar el agente de operaciones después de instalar o actualizar el controlador de GPU.

   3. Revisa los registros del agente de operaciones para verificar que la comunicación se inició de forma correcta. Los mensajes de registro se parecen a los siguientes:

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

Si el controlador de GPU está instalado y los registros del Agente de operaciones indican que el Agente de operaciones se está comunicando con el controlador, pero no ves ninguna métrica de GPU, el problema puede ser un problema con el gráfico que usas. Para obtener información sobre la solución de problemas de gráficos, consulta El gráfico no muestra ningún dato.

Si recopilas algunas métricas de GPU, pero te faltan las métricas processes (processes/max_bytes_used y processes/utilization), no tienes procesos en ejecución en las GPU. Las métricas processes de GPU no se recopilan si no hay procesos en ejecución en la GPU.

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 más recientes 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 Monitoring
cpu_state	Los valores posibles para Windows son idle, interrupt, system y user.	Los valores posibles para Windows son idle, interrupt, system y user.	Los valores posibles para Windows son idle y used.
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.

Problemas específicos de Windows

Las siguientes secciones se aplican solo al Agente de operaciones que se ejecuta en Windows.

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. Para resolver los errores, vuelve a crear los contadores de rendimiento. En PowerShell como administrador, ejecuta lo siguiente:

cd C:\Windows\system32
lodctr /R

El comando anterior puede fallar ocasionalmente; en ese caso, vuelve a cargar PowerShell y, luego, 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

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 archivo:

• 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 en versiones recientes del agente de operaciones

En las siguientes secciones, se describen problemas conocidos con las versiones recientes del Agente de operaciones.

El espacio de nombres de métricas de Prometheus incluye el nombre de la instancia, además del ID de la instancia a partir de la versión 2.46.0 del Agente de operaciones

A partir de la versión 2.46.0, el Agente de operaciones incluye el nombre de la VM como parte de la etiqueta namespace cuando se transfieren métricas en el formato de transferencia de Prometheus. En versiones anteriores, las métricas de Prometheus solo usaban el ID de instancia de la VM como parte de la etiqueta namespace, pero a partir de la versión 2.46.0, namespace se establece en INSTANCE_ID/INSTANCE_NAME.

Si tienes gráficos, paneles o políticas de alertas que usan la etiqueta namespace, es posible que debas actualizar las consultas después de actualizar el Agente de operaciones a la versión 2.46.0 o una posterior. Por ejemplo, si tu consulta de PromQL se ve de la siguiente manera: http_requests_total{namespace="123456789"}, debes cambiarla a http_requests_total{namespace=~"123456789.*"}, ya que la etiqueta namespace tiene el formato INSTANCE_ID/INSTANCE_NAME.

Las métricas sin tipo de Prometheus cambian el tipo de métrica a partir de la versión 2.39.0 del Agente de operaciones.

A partir de la versión 2.39.0, el agente de operaciones admite la transferencia de métricas de Prometheus con tipos desconocidos. En versiones anteriores, el agente de operaciones trata estas métricas como indicadores, pero a partir de la versión 2.39.0, las métricas sin tipo se tratan como indicadores y contadores. Como resultado, los usuarios ahora pueden usar operaciones acumulativas en estas métricas.

Si tienes gráficos, paneles o políticas de alertas que usan MQL para consultar métricas de Prometheus sin tipo, debes actualizar las consultas de MQL después de actualizar el Agente de operaciones a la versión 2.39.0 o una posterior. En lugar de consultar métricas sin tipo como prometheus.googleapis.com/metric_name/gauge, cambia los tipos de métricas de la siguiente manera:

• Usa prometheus.googleapis.com/metric_name/unknown para la versión de indicador de la métrica.
• Usa prometheus.googleapis.com/metric_name/unknown:counter para la versión de contador de la métrica.

No tienes que realizar ningún cambio en los gráficos, los paneles o las políticas de alertas que usan PromQL para consultar métricas de Prometheus sin tipo, pero puedes aplicar operaciones acumulativas a esas métricas después de actualizar tu Agente de operaciones a la versión 2.39.0 o una posterior.

Uso alto de memoria en VMs de Windows (versiones 2.27.0 a 2.29.0)

En las versiones 2.27.0 a 2.29.0 del Agente de operaciones en Windows, un error que causó que el agente a veces filtre sockets, provocó un mayor uso de memoria y una gran cantidad de controladores retenidos por el proceso fluent-bit.exe.

Para mitigar este problema, actualiza el Agente de operaciones a la versión 2.30.0 o una superior y reinicia el agente.

Las zonas horarias de los registros de eventos son incorrectas en Windows (versiones 2.15.0 a 2.26.0)

Las marcas de tiempo asociadas con los registros de eventos de Windows en Cloud Logging pueden ser incorrectas si cambias la zona horaria de tu VM de UTC. Esto se solucionó en el Agente de operaciones 2.27.0, pero debido al problema conocido de alto uso de memoria de Windows, te recomendamos que actualices a, al menos, el agente de operaciones 2.30.0 si tienes este problema. Si no puedes actualizar, 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

Las marcas de tiempo analizadas en Windows tienen una zona horaria incorrecta (cualquier versión anterior a la 2.27.0)

Si usas un procesador de registros que analiza una marca de tiempo, el valor de la zona horaria no se analizará correctamente en Windows. Esto se solucionó en el Agente de operaciones 2.27.0, pero debido al problema conocido de alto uso de memoria de Windows, te recomendamos que actualices a, al menos, el agente de operaciones 2.30.0 si tienes este problema.

Problemas conocidos en versiones anteriores del agente de operaciones

En las siguientes secciones, se describen problemas que se sabe que ocurren con versiones anteriores del Agente de operaciones.

Registros no dañinos (versiones 2.9.1 y anteriores)

Es posible que veas errores cuando recopiles métricas de seudoprocesos o procesos restringidos. Los siguientes registros no son perjudiciales y pueden ignorarse de forma segura. Para eliminar estos mensajes, actualiza el agente de operaciones a la versión 2.10.0 o posterior.

    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
  

Los registros propios del agente consumen demasiada CPU, memoria y espacio en disco (versiones 2.16.0 y anteriores)

Las versiones del agente de operaciones anteriores a la 2.17.0 pueden consumir mucha memoria, CPU y espacio en disco con archivos /var/log/google-cloud-ops-agent/subagents/logging-module.log en VM de Linux o archivos 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.0 o una superior y Restablece por completo el estado del agente.

Si tu sistema aún genera un gran volumen de registros propios de agentes, considera usar la rotación de registros. Para obtener más información, consulta Configura la rotación de registros.