Solucionar problemas de ingestión de datos del agente de operaciones

Este documento proporciona información para ayudarle a diagnosticar y resolver problemas de ingesta de datos (registros y métricas) en el agente de Ops en ejecución. Si el agente de Ops no se está ejecutando, consulta la sección Solucionar problemas de instalación y de inicio.

Antes de empezar

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

La consola deGoogle Cloud muestra que la instalación del agente de operaciones se ha quedado en el estado "Pendiente"

Aunque hayas instalado correctamente el Agente de operaciones, es posible que la consola siga mostrando el estado "Pendiente". Google Cloud Usa gcpdiag para confirmar la instalación del agente de operaciones y verificar que el agente transmite registros y métricas desde tu instancia de VM.

Motivos habituales por los que no se puede completar la instalación

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

• La máquina virtual no tiene ninguna cuenta de servicio asociada. Vincula una cuenta de servicio a la máquina virtual y, a continuación, vuelve a instalar el agente de operaciones.

• La VM ya tiene instalado uno de los agentes antiguos, lo que impide la instalación del Agente de operaciones. Desinstala los agentes antiguos y, a continuación, vuelve a instalar el Agente de operaciones.

Motivos habituales de los errores de transmisión de 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 vinculada a la VM le falta el rol roles/logging.logWriter o roles/monitoring.metricWriter.
• El ámbito de acceso de registro o monitorización no está habilitado. Para obtener información sobre cómo comprobar y actualizar los ámbitos de acceso, consulta Verificar los ámbitos de acceso.
• La API Logging o la API Monitoring no están habilitadas.

Usa las comprobaciones del estado del agente para identificar la causa principal y la solución correspondiente.

El agente se está ejecutando, pero no se ingieren datos

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

1. En la Google Cloud consola, ve a la página  Explorador de métricas:

   Ve al explorador de métricas.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

2. En el interruptor Código del creador, selecciona Código y, a continuación, define el idioma como PromQL.

3. Introduce la siguiente consulta y haz clic en Ejecutar:

   rate({"agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])
   

¿El agente envía registros a Cloud Logging?

Si el agente se está ejecutando, pero no envía registros, comprueba el estado de las comprobaciones de estado del tiempo de ejecución del agente.

Errores de la canalización

Si ves el error de tiempo de ejecución LogPipelineErr ("Ops Agent logging pipeline failed"), significa que el subagente de Logging ha detectado un problema al escribir registros. Comprueba las siguientes condiciones:

• Verifica que se pueda acceder a los archivos de almacenamiento del subagente de registro. 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\
• Comprueba que el disco de la VM no esté lleno.
• Verifica que la configuración de registro sea correcta.

Para seguir estos pasos, debes conectarte a la VM mediante SSH.

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

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 ha reiniciado, ejecuta el siguiente comando y verifica que los componentes "Metrics Agent" y "Logging Agent" se han iniciado:

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

Windows

1. Conéctate a tu instancia mediante RDP o una herramienta similar e inicia sesión en Windows.
2. Abre un terminal de PowerShell con privilegios de administrador haciendo clic con el botón derecho en el icono de PowerShell y seleccionando Ejecutar como 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 ha reiniciado, ejecuta el siguiente comando y verifica que los componentes "Metrics Agent" y "Logging Agent" se han iniciado:

   Get-Service google-cloud-ops-agent*
   

Errores de análisis de registros

Si aparece el error de tiempo de ejecución LogParseErr ("Ops Agent failed to parse logs"), lo más probable es que el problema esté en la configuración de un procesador de registro. Para solucionar este problema, sigue estos pasos:

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

Para seguir estos pasos, debes conectarte a la VM mediante SSH.

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 ha reiniciado, ejecuta el siguiente comando y verifica que los componentes "Metrics Agent" y "Logging Agent" se han iniciado:

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

Windows

1. Conéctate a tu instancia mediante RDP o una herramienta similar e inicia sesión en Windows.
2. Abre un terminal de PowerShell con privilegios de administrador haciendo clic con el botón derecho en el icono de PowerShell y seleccionando Ejecutar como 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 ha reiniciado, ejecuta el siguiente comando y verifica que los componentes "Metrics Agent" y "Logging Agent" se han iniciado:

   Get-Service google-cloud-ops-agent*
   

Consultar las métricas locales

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

Para seguir estos pasos, debes conectarte a la VM mediante SSH.

• ¿Está ejecutándose el módulo de registro? Usa los siguientes comandos para comprobarlo:

Linux

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

Windows

Abre Windows PowerShell como administrador y ejecuta el siguiente comando:

Get-Service google-cloud-ops-agent

También puedes consultar el estado de los servicios en la aplicación Servicios e inspeccionar los procesos en ejecución en la aplicación Administrador de tareas.

Comprobar el registro del módulo de registro

Para completar este paso, debes conectarte a la VM mediante SSH.

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 para Windows. Si no hay registros, significa que el servicio del agente no se está ejecutando correctamente. Primero, vaya a la sección El agente está instalado, pero no se está ejecutando para solucionar ese problema.

• Es posible que veas errores de permiso 403 al escribir en la API 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 solucionar este error, habilita la API Logging y asigna el rol Escritor de registros.

• Puede que tengas un problema con la cuota de la API 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 solucionar este error, aumenta la cuota o reduce el volumen de registro.

• Es posible que aparezcan 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 has implementado el agente sin una cuenta de servicio o sin credenciales especificadas. Para obtener información sobre cómo solucionar este problema, consulta Autorizar el agente de Ops.

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

Consultar el registro del módulo de métricas

Para completar este paso, debes conectarte a la VM mediante SSH.

Puedes encontrar los registros del módulo de métricas en syslog. Si no hay registros, significa que el servicio del agente no se está ejecutando correctamente. Primero, ve a la sección El agente está instalado, pero no se está ejecutando para solucionar ese problema.

• Es posible que veas errores PermissionDenied al escribir en la API Monitoring. Este error se produce si los permisos del agente de Ops no están configurados correctamente. 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 solucionar este error, habilita la API Monitoring y asigna el rol Escritor de métricas de Monitoring.

• Es posible que veas errores ResourceExhausted al escribir en la API Monitoring. Este error se produce si el proyecto alcanza el límite de alguna cuota de la API 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 solucionar este error, aumenta la cuota o reduce el volumen de métricas.

• Es posible que aparezcan 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 has implementado el agente sin una cuenta de servicio o sin credenciales especificadas. Para obtener información sobre cómo solucionar este problema, consulta Autorizar el agente de Ops.

Problemas de conectividad de red

Si el agente se está ejecutando, pero no envía registros ni métricas, puede que tengas un problema de red. Los tipos de problemas de conectividad de red que puedes encontrar varían según la topología de tu aplicación. Para obtener información general sobre las redes de Compute Engine, consulta la información general sobre las redes de las máquinas virtuales.

Estas son algunas de las causas habituales de los problemas de conectividad:

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

El agente de Ops ejecuta comprobaciones del estado que detectan errores de conectividad de red. Consulta la documentación sobre comprobaciones de estado para ver las acciones que puedes llevar a cabo si se producen errores de conectividad.

Información sobre los mensajes de error "failed to flush chunk"

A partir de la versión 2.28.0 de Ops Agent, este limita la cantidad de espacio en disco que puede usar para almacenar fragmentos de búfer. El agente de Ops crea fragmentos de búfer cuando no se pueden enviar datos de registro a la API Cloud Logging. Si no se establece un límite, estos fragmentos podrían consumir todo el espacio disponible e interrumpir otros servicios de la VM. Cuando se produce una interrupción de la red que provoca que los fragmentos del 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. También aparece un mensaje como el del siguiente ejemplo en /var/log/google-cloud-ops-agent/subagents/logging-module.log en máquinas virtuales Linux o C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log en máquinas virtuales Windows cuando la máquina virtual no puede enviar los fragmentos de búfer a la API Cloud Logging:

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

Problemas en el proxy HTTP

Si hay un problema con la configuración del proxy HTTP, pueden producirse errores. Por ejemplo, los errores de flb_upstream con el término context indican un problema con la configuración del proxy:

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

Para solucionar este problema, compruebe que el proxy HTTP se haya configurado correctamente. Para obtener instrucciones sobre cómo configurar el proxy HTTP, consulta el artículo Configurar un proxy HTTP.

Para consultar las especificaciones del formato de proxy HTTP, consulta el manual oficial de Fluent Bit.

Solo quiero recoger métricas o registros, no ambos

De forma predeterminada, el agente de operaciones recoge tanto métricas como registros. Para inhabilitar la recogida de métricas o registros, usa el archivo config.yaml del agente de Ops para anular el servicio logging o metrics predeterminado, de modo que la canalización predeterminada no tenga receptores. Para obtener más información, consulta lo siguiente:

• Ejemplos de configuraciones de service registro.
• Ejemplos de configuraciones de servicemétricas.

Si detiene la ingestión de datos inhabilitando los servicios de subagente "Agente de registro" o "Agente de monitorización" del agente de operaciones, la configuración no será válida y no se admitirá.

Se están recogiendo métricas, pero parece que hay algún problema

El agente está registrando "Exporting failed. Se volverá a intentar"

Aparecen entradas de registro "Exporting failed" (No se ha podido exportar) cuando se elimina el primer punto de datos de una métrica acumulada. Los siguientes registros no son perjudiciales y se pueden ignorar sin problemas:

  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 mensajes de error "TimeSeries could not be written: Points must be written in order" (No se ha podido escribir TimeSeries: los puntos deben escribirse en orden).

Si has actualizado a Ops Agent desde el agente de monitorización antiguo y ves el siguiente mensaje de error al escribir métricas acumulativas, la solución es reiniciar tu VM. El agente de operaciones y el agente de Monitoring calculan los tiempos de inicio de las métricas acumulativas de forma diferente, lo que puede provocar que los puntos aparezcan desordenados. Si reinicias la VM, se restablecerá la hora de inicio y se solucionará el 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 mensajes del tipo "El token debe ser un token de corta duración (60 minutos) y tener un plazo razonable"

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

  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 cómo sincronizar los relojes del sistema, consulta Configurar NTP en una VM.

El agente registra el mensaje "metrics receiver with type "nvml" is not supported" (El receptor de métricas con el tipo "nvml" no se admite)

Si recoges métricas de GPU de la biblioteca de gestión de NVIDIA (NVML) (agent.googleapis.com/gpu) mediante el receptor nvml, has estado usando una versión del agente de Ops con compatibilidad de vista previa para las métricas de NVML. La compatibilidad con estas métricas está disponible de forma general desde la versión 2.38.0 del agente de Ops. En la versión de GA, la recogida de métricas que realizaba el receptor nvml se combinó con el receptor hostmetrics y se eliminó el receptor nvml.

Aparece el mensaje de error "metrics receiver with type "nvml" is not supported" (el receptor de métricas de tipo "nvml" no es compatible) después de instalar la versión 2.38.0 o una posterior del agente de operaciones cuando usabas el receptor nvml de vista previa y habías anulado el intervalo de recogida predeterminado en el archivo de configuración especificado por el usuario. El error se produce porque el receptor nvml ya no existe, pero tu archivo de configuración especificado por el usuario sigue haciendo referencia a él.

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

Faltan métricas de GPU

Si el agente de operaciones recoge algunas métricas, pero faltan algunas o todas las métricas de GPU de la biblioteca de gestión de NVIDIA (NVML) (agent.googleapis.com/gpu), puede que tengas un problema de configuración o que no haya ningún proceso que utilice la GPU.

Si no recoges ninguna métrica de GPU, comprueba el controlador de la GPU. Para recoger métricas de GPU, el agente de operaciones requiere que el controlador de GPU esté instalado y configurado en la VM. Para comprobar el controlador, haz lo siguiente:

1. Para comprobar que el controlador está instalado y funciona correctamente, sigue los pasos para verificar la instalación del controlador de la GPU.

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

   1. Instala el controlador de la GPU.

   2. Reinicia el agente de operaciones.

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

   3. Consulta los registros del agente de Ops para verificar que la comunicación se ha iniciado correctamente. Los mensajes de registro son similares 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 la GPU está instalado y los registros del agente de operaciones indican que el agente de operaciones se comunica con el controlador, pero no ve ninguna métrica de la GPU, puede que el problema esté relacionado con el gráfico que está usando. Para obtener información sobre cómo solucionar problemas con los gráficos, consulta el artículo No se muestran datos en el gráfico.

Si recoges algunas métricas de GPU, pero te faltan las métricas processes processes/max_bytes_used y processes/utilization, significa que no tienes ningún proceso en ejecución en las GPUs. Las métricas de la GPU processes no se recogen si no hay procesos en ejecución en la GPU.

Faltan algunas métricas o no son coherentes

Hay un pequeño número de métricas que la versión 2.0.0 y posteriores del agente de operaciones gestionan de forma diferente a las versiones de vista previa del agente de operaciones (versiones anteriores a la 2.0.0) o al agente de Monitoring.

En la siguiente tabla se describen las diferencias en los datos ingeridos por el agente de Ops y el agente de Monitoring.

Tipo de métrica, omitiendo agent.googleapis.com	Agente de operaciones (disponibilidad general)^†	Agente de operaciones (vista previa)^†	Agente de monitorización
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	Ingerido con la ruta completa en la etiqueta device. Por ejemplo, /dev/sda15. No se ingiere en dispositivos virtuales como tmpfs y udev.	Se ha insertado sin /dev en la ruta de la etiqueta device. Por ejemplo, sda15. Ingerido para dispositivos virtuales como tmpfs y udev.	Se ha insertado sin /dev en la ruta de la etiqueta device. Por ejemplo, sda15. Ingerido para dispositivos virtuales como tmpfs y udev.

^† La columna GA hace referencia a las versiones 2.0.0 y posteriores del agente de operaciones. 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 solo se aplican al agente de Ops que se ejecuta en Windows.

Contadores de rendimiento dañados en Windows

Si el subagente de 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 producirse 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 el siguiente comando:

cd C:\Windows\system32
lodctr /R

El comando anterior puede fallar ocasionalmente. En ese caso, vuelve a cargar PowerShell y prueba de nuevo hasta que se complete correctamente.

Una vez que el comando se haya ejecutado correctamente, reinicia el agente de Ops:

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

Restablecer por completo el estado del agente

Si el agente entra en un estado no recuperable, sigue estos pasos para restaurarlo a un estado inicial.

Nota: Este proceso elimina todo el estado del búfer, lo que puede provocar la pérdida de registros. Para ver un proceso que no restablece el estado del búfer, consulta Restablecer, pero guardar los archivos del búfer.

Linux

Detén el servicio del agente:

sudo service google-cloud-ops-agent stop

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

Elimina los registros automáticos del agente del disco:

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

Elimina 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: se trata de entradas de registro almacenadas en búfer que el agente de Ops ha leído y procesado, pero que aún no se han insertado en Cloud Logging. Si hay fragmentos dañados, el agente de operaciones debe omitirlos en las versiones >= 2.15.0. En algunos casos, sin embargo, es necesario limpiarlos manualmente. Estos archivos se almacenan en carpetas anidadas como: /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 ya ha seguido el agente de operaciones. Si se eliminan estos archivos, el agente de operaciones empezará por la parte superior de los archivos que esté configurado para seguir. Si se eliminan estos archivos, se pueden duplicar los registros si se habían insertado correctamente anteriormente. Estos archivos se almacenan directamente en el directorio como archivos de este tipo: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

La sintaxis .../buffers/*/ del comando anterior asegura que solo se eliminen los archivos de búfer. Los archivos de posición no se eliminan.

Vuelve a instalar el agente y reinícialo:

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 de 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 del 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"

Elimina los registros automáticos del agente del disco:

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

Elimina 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 en Linux, este comando solo elimina los subdirectorios del directorio C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers, por lo que se eliminan los archivos de búfer, pero los archivos de posición no se modifican.

Vuelve a instalar el agente y reinícialo:

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

Restablecer, pero guardar los archivos de búfer

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

Si la máquina virtual tiene fragmentos de búfer dañados, debes eliminarlos. Las siguientes opciones describen diferentes formas de gestionar los búferes. Los demás pasos descritos en Restablecer por completo el estado del agente siguen siendo aplicables.

• Opción 1: Elimina todo el directorio buffers. Esta es la opción más sencilla, pero puede provocar la pérdida de los registros almacenados en búfer que no estén dañados o la duplicación de registros 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: Elimina los subdirectorios del búfer del directorio buffers, pero deja los archivos de posición. Este enfoque se describe en la sección Restablecer por completo el estado del agente.

• Opción 3: Si no quieres eliminar todos los archivos de búfer, puedes extraer los nombres de los archivos de búfer dañados de los registros automáticos del agente y eliminar 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 quieres volver a procesar todos los archivos de registro, puedes usar los comandos de la opción 3 y también eliminar los archivos de posición (que almacenan el progreso del agente de operaciones por archivo de registro). Si se eliminan los archivos de posición, se pueden duplicar los registros que ya se hayan insertado correctamente. Esta opción solo vuelve a procesar los archivos de registro actuales. No vuelve a procesar los archivos que ya se han rotado ni los registros de otras fuentes, como un puerto TCP. Los archivos de posición se almacenan en el directorio buffers pero 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 los problemas conocidos de las versiones recientes del agente de Ops.

La versión 2.56.0 del agente de operaciones no envía métricas de Prometheus

Si usas la versión 2.56.0 del agente de Ops junto con el receptor de Prometheus y tu destino de raspado emite métricas con *_created métricas adicionales para los contadores (para admitir la nueva función experimental de marcas de tiempo de creación), es posible que el agente no pueda escribir métricas e informe de errores que indiquen que las horas de inicio deben ser positivas. Los mensajes de registro son similares a los siguientes:

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

Se trata de un problema con OpenTelemetry upstream. Para resolver el error hasta que se pueda corregir en una nueva versión del agente de operaciones, usa la versión 2.55.0, que no se ve afectada. Si usas políticas de agente, también puedes fijar la versión 2.55.0 para evitar que se actualice. Para obtener más información, consulta Instalar una versión específica del agente.

El agente de operaciones versión 2.47.0, 2.48.0 o 2.49.0 entra en un bucle de fallos

Las versiones 2.47.0, 2.48.0 y 2.49.0 incorporaron un componente de FluentBit defectuoso para el registro. Este componente falla en líneas de registro específicas y provoca que el agente de operaciones entre en un bucle de fallos.

Este problema se ha resuelto en la versión 2.50.0 del agente de operaciones.

El espacio de nombres de las 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 Ops.

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 al ingerir métricas en el formato de ingestión 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 define como INSTANCE_ID/INSTANCE_NAME.

Si tienes gráficos, paneles de control o políticas de alertas que usan la etiqueta namespace , es posible que tengas que actualizar tus consultas después de actualizar tu agente de Ops a la versión 2.46.0 o posterior. Por ejemplo, si tu consulta de PromQL era http_requests_total{namespace="123456789"}, tienes que 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 de tipo 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 ingestión 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. Ahora los usuarios pueden usar operaciones acumulativas en estas métricas.

Si usas PromQL, puedes aplicar operaciones acumulativas a métricas de Prometheus sin tipo después de actualizar tu agente de operaciones a la versión 2.39.0 o a una posterior.

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

En Windows, en las versiones 2.27.0 a 2.29.0 del agente de Ops, un error que provocaba que el agente a veces perdiera sockets provocó un aumento del uso de memoria y un gran número de identificadores retenidos por el proceso fluent-bit.exe.

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

Las zonas horarias del registro de eventos son incorrectas en Windows (versiones de 2.15.0 a 2.26.0)

Las marcas de tiempo asociadas a los registros de eventos de Windows en Cloud Logging pueden ser incorrectas si cambias la zona horaria de tu máquina virtual desde UTC. Este problema se solucionó en la versión 2.27.0 del agente de operaciones, pero, debido al problema conocido de alto consumo de memoria en Windows, te recomendamos que actualices al menos a la versión 2.30.0 del agente de operaciones si te encuentras con este problema. Si no puedes actualizar, prueba una de las siguientes soluciones alternativas.

Usar 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

Anular la configuración de la zona horaria solo para el servicio de subagente de registro

En PowerShell, ejecuta los siguientes comandos como administrador:

Precaución: Se sobrescribirá el valor del registro Environment del 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. Este problema se solucionó en la versión 2.27.0 del agente de Ops, pero, debido al problema conocido de alto consumo de memoria en Windows, te recomendamos que actualices al menos a la versión 2.30.0 del agente de Ops si te encuentras con este problema.

Problemas conocidos en versiones anteriores del agente de operaciones

En las siguientes secciones se describen los problemas que se han detectado en versiones anteriores del agente de Ops.

Registros no dañinos (versión 2.9.1 y anteriores)

Es posible que veas errores al extraer métricas de pseudoprocesos o procesos restringidos. Los siguientes registros no son perjudiciales y se pueden ignorar sin problemas. Para eliminar estos mensajes, actualiza el agente de Ops a la versión 2.10.0 o a una 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 automáticos del agente consumen demasiada CPU, memoria y espacio en disco (versiones 2.16.0 y anteriores)

Las versiones del agente de Ops anteriores a la 2.17.0 pueden consumir mucha CPU, memoria y espacio en disco con archivos /var/log/google-cloud-ops-agent/subagents/logging-module.log en VMs Linux o archivos C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log en VMs Windows debido a fragmentos de búfer dañados. Cuando esto ocurre, verás un gran número de mensajes como el siguiente 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 solucionar este problema, actualice el agente de Ops a la versión 2.17.0 o a una más reciente y restablezca por completo el estado del agente.

Si tu sistema sigue generando un gran volumen de registros automáticos de agentes, plantéate usar la rotación de registros. Para obtener más información, consulta Configurar la rotación de registros.