Soluciona problemas del agente de Logging

En esta página, se proporcionan instrucciones para solucionar problemas comunes que se encontraron al momento de instalar el agente de Logging o interactuar con él.

Lista de tareas

Si tienes problemas para instalar o usar el agente de Logging, ten en cuenta lo siguiente:

• Si los comandos de instalación de Linux dan como resultado errores, asegúrate de usar el prefijo sudo en los comandos de instalación.

• Verifica que el servicio del agente se esté ejecutando en tu instancia de VM:

  • Para una VM de Windows, usa el siguiente comando de PowerShell:

    Get-Service -Name StackdriverLogging
    

    Busca un servicio llamado Stackdriver Logging. Si el agente no se ejecuta, es posible que debas reiniciarlo.

  • Para una VM de Linux, usa el siguiente comando:

    sudo service google-fluentd status
    

    Si el agente no se ejecuta, es posible que debas reiniciarlo con el siguiente comando:

    sudo service google-fluentd restart
    

    Si el reinicio falla, y el resultado del registro muestra el mensaje “Disabled via metadata” (Inhabilitado mediante metadatos), es probable que se esté ejecutando una imagen de Google Cloud Marketplace en la que el agente de Logging está inhabilitado de forma predeterminada. La clave de metadatos de la instancia google-logging-enable controla el estado de habilitación del agente de Logging, en el que un valor 0 inhabilita al agente. Para volver a habilitar al agente, quita la clave google-logging-enable o configura su valor en 1. Para obtener más información, consulta Crea una instancia con el agente de Logging inhabilitado.

    Si el agente no se inhabilitó mediante los metadatos, vuelve a instalarlo. Consulta la siguiente sección: Vuelve a instalar el agente de Logging.

• Observa si el agente escribió mensajes de error en los registros.

  • En Windows, a partir de la versión v1-9, el agente de Logging guarda sus registros en C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

    No hay forma de obtener los registros de las versiones anteriores del agente.

  • En Linux, el agente de Logging es un paquete fluentd y registra los mensajes en /var/log/google-fluentd/google-fluentd.log:

    • Si ves errores HTTP 429, es posible que hayas excedido tus cuotas de API de Logging. Para ver la cuota disponible, selecciona API y servicios > Panel en la consola de Google Cloud. Elige la API de Logging.

    • Si observas problemas de acceso a la API o de autorización, ve a la sección sobre cómo verificar las credenciales de Compute Engine.

• Si el agente parece ejecutarse normalmente, pero no obtienes datos, entonces debes verificar que el agente esté enviando datos al proyecto correcto. Consulta la siguiente sección sobre cómo verificar las credenciales de Compute Engine.

• Si el agente no realiza la autorización, verifica si las credenciales de tu clave privada no están disponibles o no son válidas.

Verifica la instalación del agente

Nota: Si tu VM se inició como parte de un entorno flexible de App Engine o una implementación de Kubernetes Engine, no es necesario instalar el agente de Logging. Omite esta página.

Para comprobar que la instalación se haya realizado correctamente, busca la entrada de registro de prueba del agente en el Visor de registros.

1. En la consola de Google Cloud, ve a la página Explorador de registros.

   Ir al Explorador de registros

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

2. En la parte superior de la página, elige el proyecto que contiene tu instancia de VM:

   • Para las instancias de VM de Compute Engine, elige el proyecto de Google Cloud que contiene la instancia de VM.
   • Para las instancias de VM de Amazon EC2, elige el proyecto de Google Cloud a la que se envían los registros.

3. En las pestañas de ventanas, elige el recurso para tu instancia de VM:

   • Para Compute Engine, elige Instancia de VM en GCE.
   • Para Amazon EC2, elige instancia de AWS EC2.
   • Selecciona syslog (Linux), fluent.info (Windows) o Todos los registros.

Si ves una entrada de registro que muestre “gRPC se envió correctamente a la API de Logging”, entonces la instalación del agente finalizó. Este mensaje se genera una vez cuando se instala el agente y cada vez que se reinicia.

Para obtener más información sobre el explorador de registros, consulta Usa el explorador de registros.

Prueba el agente

Si sospechas que el agente no funciona, verifica que esté en ejecución y, luego, intenta enviar un mensaje de prueba a Logging:

Instancia de Linux

El siguiente procedimiento funciona en las instancias de VM de Amazon EC2 y Compute Engine que se ejecutan en Linux:

1. Verifica que el agente de Logging funcione mediante la ejecución de los siguientes comandos en tu instancia de VM:

   ps ax | grep fluentd
   

   Deberías ver un resultado similar al siguiente:

    2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
    2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
   

2. Envía un mensaje de registro de prueba con el siguiente comando en tu instancia de VM:

   logger "Some test message"
   

Instancia de Windows

El agente de Logging tiene los siguientes dos nombres de servicio de Windows:

• StackdriverLogging para las versiones v1-5 y posteriores
• fluentdwinsvc para las versiones anteriores

Debes ejecutar un servicio de agente. Ejecuta los siguientes comandos en tu instancia de VM con PowerShell:

1. Solicita el estado de ambos servicios. Si sabes cuál es el servicio que debería ejecutarse, puedes usar solo el nombre de ese servicio:

   Get-Service StackdriverLogging,fluentdwinsvc
   

2. Si un servicio no está en ejecución, verás un mensaje de error. Si lo está, verás una respuesta como la siguiente:

   Status    Name                DisplayName
   ------    ----                -----------
   Running  StackdriverLogging   Cloud Logging
   

3. Si consultas ambos servicios, deberías ver un mensaje de error y un estado Running:

   • Si no ves un estado Running, el agente de Logging no está en ejecución.
   • Si StackdriverLogging está en ejecución, estás ejecutando una versión reciente del agente. Para determinar la versión específica, consulta la sección sobre cómo obtener la versión.
   • Si fluentdwinsvc está en ejecución, deberías actualizar tu agente a la última versión.

4. Requiere privilegios de administrador: si una versión del agente está en ejecución, envía un mensaje de registro de prueba con los siguientes comandos de PowerShell:

   New-EventLog   -LogName Application -Source "Test Source"
   Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."
   

Busca el mensaje de prueba

Después de enviar un mensaje de prueba, búscalo en el Visor de registros:

1. En la consola de Google Cloud, ve a la página Explorador de registros.

   Ir al Explorador de registros

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

2. En la parte superior de la página, elige el proyecto que contiene tu instancia de VM:

   • Para las instancias de VM de Compute Engine, elige el proyecto de Google Cloud que contiene la instancia de VM.
   • Para las instancias de VM de Amazon EC2, elige el proyecto de Google Cloud a la que se envían los registros.

3. En las pestañas de ventanas, elige el recurso para tu instancia de VM:

   • Para Compute Engine, elige Instancia de VM en GCE.
   • Para Amazon EC2, elige instancia de AWS EC2.
   • Selecciona syslog (Linux), fluent.info (Windows) o Todos los registros.

4. Deberías ver una entrada de registro con tu mensaje de prueba. Si es así, significa que el agente de Logging funciona de manera correcta.

Verifica las credenciales de Compute Engine

Para que una instancia de VM de Compute Engine ejecute el agente sin credenciales de clave privada, la instancia debe tener permisos de acceso adecuados. Además, la identidad de la cuenta de servicio que usa la instancia debe tener los permisos de IAM adecuados.

Cuando creas una instancia de VM, la configuración predeterminada de la cuenta de servicio y el nivel es suficiente para ejecutar los agentes. Puede que las instancias muy antiguas o aquellas en las que cambiaste la configuración predeterminada no tengan las credenciales adecuadas.

No se pudieron cargar las credenciales predeterminadas

En caso de que haya errores Could not load the default credentials en el archivo de registro de Logging, esto implica que es posible que el agente no pueda conectarse al servidor de metadatos de Compute Engine.

El registro de errores se ve de la siguiente manera:

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

Una posible causa de esto es que la VM tenga una configuración de proxy personalizada. A fin de solucionarlo, consulta la instrucción de configuración del proxy para excluir el servidor de metadatos de Compute Engine (metadata.google.internal o 169.254.169.254) que pasa por el proxy. Si el error persiste, quita la cuenta de servicio predeterminada de Compute Engine de la VM y vuelve a agregarla.

Verifica los permisos de acceso

Para verificar los permisos de acceso, haz lo siguiente:

1. En la consola de Google Cloud, ve a la página Instancias de VM.

   Ir a Instancias de VM

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

2. Haz clic en el nombre de la instancia de VM. Se mostrará la página de detalles de tu instancia.

3. En la sección Permisos de acceso a la API de Cloud, haz clic en Detalles para ver la lista de API. Busca las siguientes entradas:

   1. Si lees “Esta instancia tiene acceso completo de API a todos los servicios de Google Cloud”, tus permisos de acceso son adecuados.
   2. Si junto a la API de Stackdriver Logging ves un nombre anterior de la API de Cloud Logging, para la que tienes permiso de Solo escritura o Completo, entonces, los permisos de acceso de tu instancia son adecuados para el agente de Cloud Logging.
   3. Si junto a la API de Stackdriver Monitoring ves un nombre anterior de la API de Cloud Monitoring, para la que tienes permiso de Solo escritura o Completo, entonces, los permisos de acceso de tu instancia son adecuados para el agente de Cloud Monitoring.

Corrige el problema

Si no tienes permisos de acceso adecuados en tu instancia de Compute Engine, agrega los permisos de acceso necesarios a tu instancia.

En la siguiente tabla, se muestran los permisos pertinentes para los agentes de Logging y Monitoring:

Permiso de acceso	Permisos de agente
https://www.googleapis.com/auth/logging.write	Adecuado para el agente de Logging
https://www.googleapis.com/auth/monitoring.write	Adecuado para el agente de Monitoring

Verifica el permiso para la cuenta de servicio predeterminada

Aun cuando los permisos de acceso de tu instancia de VM de Compute Engine sean adecuados, puede que la cuenta de servicio predeterminada de tu instancia no proporcione los permisos de IAM correctos para el agente.

Lo primero que debes hacer para verificar el permiso de la cuenta de servicio predeterminada es localizarla. Para ello, haz lo siguiente:

1. En la consola de Google Cloud, ve a la página Instancias de VM.

   Ir a Instancias de VM

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

2. Haz clic en el nombre de la instancia de VM. Se mostrará la página de detalles de tu instancia.

3. Busca el encabezado cuenta de servicio en la página. Se muestra la cuenta de servicio predeterminada para la instancia. Podría verse de la siguiente manera:

   [ID][e-mail]
   

4. En la consola de Google Cloud, ve a la página IAM:

   Ir a IAM

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

5. Selecciona Ver por: principales. Deberías ver una lista de personas, grupos y cuentas de servicio. En la columna Función, se muestran las funciones que tiene cada principal de tu proyecto.

6. En la fila de la cuenta de servicio predeterminada de tu instancia, deberías ver una o más de las siguientes funciones:

   • Si ves Editor, esa función es adecuada para todos los agentes. El rol de Editor se puede otorgar automáticamente a la cuenta de servicio predeterminada según la configuración de las políticas de tu organización.
   • Si ves Escritor de registros, esa función es suficiente para el agente de Logging. Para otras funciones de Logging que incluyen el permiso de escritura, consulta Control de acceso para Cloud Logging.
   • Si ves Escritor de métricas de Monitoring, esa función es suficiente para el agente de Monitoring. Para otras funciones de Monitoring que incluyen el permiso de escritura, consulta Control de acceso para Cloud Monitoring.

Corrige el problema

Si tu cuenta de servicio predeterminada no tiene funciones adecuadas, intenta editar las funciones para tu cuenta de servicio en la página IAM & admin > IAM. Agrega las funciones de Logging o Monitoring adecuadas para autorizar a los agentes: Logging > Escritor de registros o Monitoring > Escritor de métricas de Monitoring.

Verifica las credenciales de clave privada

En las instancias de VM de Compute Engine, puedes configurar el agente para usar una cuenta de servicio que no sea predeterminada y que tenga la autorización adecuada. En las instancias de VM de AWS EC2, debes configurar el agente para usar una cuenta de servicio como esa.

Si quieres configurar el agente de esta manera, debes crear credenciales de clave privada para la cuenta de servicio designada y otorgar esas credenciales al agente.

1. El agente busca una variable de entorno, GOOGLE_APPLICATION_CREDENTIALS, que conserva el nombre de un archivo que contiene las credenciales de clave privada.

2. Si la variable de entorno no está presente, el agente buscará las credenciales en una ubicación predeterminada:

   Linux

   /etc/google/auth/application_default_credentials.json
   

   Windows

   C:\ProgramData\Google\Auth\application_default_credentials.json
   

3. Si la ubicación predeterminada no contiene las credenciales, el agente usa las credenciales predeterminadas de la aplicación del servidor de metadatos.

Precaución: Puedes usar el sistema de archivos o algún otro control de acceso para garantizar que solo las aplicaciones que lo necesitan puedan acceder a la clave privada en tus instancias.

La siguiente información te ayudará a diagnosticar problemas de credenciales de clave privada:

1. ¿La clave privada está en su lugar?
2. ¿La clave privada aún es válida para la cuenta de servicio?
3. ¿La cuenta de servicio tiene las funciones necesarias para el agente?

Para verificar que las credenciales válidas de clave privada estén instaladas en tu instancia de VM, primero verifica que el archivo de credenciales existe en tu ubicación esperada y luego que la información en el archivo de credenciales sea válida.

¿Las credenciales están presentes?

Para ver si las credenciales de la cuenta de servicio de clave privada están en tu instancia, ejecuta los siguientes comandos de Linux en ella:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Si alguno de los comandos muestra un archivo como el que aparece a continuación, tu instancia podría tener credenciales de clave privada válidas. Si ambos comandos muestran un archivo, se usa el archivo indicado por GOOGLE_APPLICATION_CREDENTIALS.

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY]@developer.gserviceaccount.com",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Discrepancias entre las configuraciones de credenciales que pueden hacer que el agente use credenciales diferentes de las que requiere tu servicio. Por ejemplo, si estableces una ubicación de credenciales personalizada en GOOGLE_APPLICATION_CREDENTIALS en la shell de acceso, pero no estableces esa variable en la configuración del servicio del agente, el servicio buscará la ubicación predeterminada en lugar de tu ubicación personalizada.

Para revisar o cambiar la variable de entorno de tus credenciales, accede o configura GOOGLE_APPLICATION_CREDENTIALS en /etc/default/google-fluentd.

Si no hay archivos de credenciales presentes, consulta Agrega credenciales.

Precaución: Otros servicios, además de Logging, pueden usar credenciales de clave privada en tu instancia. Reemplazar las credenciales existentes puede impedir que funcionen otros servicios.

¿Las credenciales son válidas?

En el archivo de credenciales, project_id es tu proyecto de Google Cloud, client_email identifica la cuenta de servicio en el proyecto y private_key_id identifica la clave privada en la cuenta de servicio. Haz coincidir esta información con lo que se muestra en la sección IAM y administración > Cuentas de servicio de la consola de Google Cloud.

El archivo de credenciales no es válido si se cumplen algunas de las siguientes condiciones:

• Estás verificando una instancia de Compute Engine, pero el proyecto de Google Cloud del archivo de credenciales no es el proyecto que contiene tu instancia.
• Verificas una instancia de Amazon EC2, pero el proyecto de Google Cloud en el archivo de credenciales no es el proyecto de Google Cloud en el que envían registros.
• La cuenta de servicio de la lista no existe. Podría haber sido borrada.
• La cuenta de servicio de la lista no tiene las funciones correctas habilitadas: Escritor de registros para el agente de Cloud Logging y Escritor de métricas de Monitoring para el agente de Cloud Monitoring.
• La clave privada no existe. Podría haber sido revocada.

Las credenciales se pueden revocar en la sección IAM y administración > Cuentas de servicio de la consola de Google Cloud. Si las credenciales válidas no están presentes, consulta Agrega credenciales para reemplazar las credenciales existentes o agregar nuevas.

Si la cuenta de servicio es la correcta, pero la clave privada se revocó, puedes crear una clave privada nueva y copiarla en tu instancia. Consulta Crea claves de cuentas de servicio.

De lo contrario, debes crear una cuenta de servicio nueva como se describe en la sección Agrega credenciales.

Verifica las consultas de exclusión de registros

Visualiza tus consultas de exclusión actuales para asegurarte de que los registros que buscas no se excluyan de forma accidental.

Verifica firewall

Para ver si tu instancia tiene acceso a logging.googleapis.com, ejecuta el siguiente comando de Linux en tu instancia:

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

El comando puede tomar un tiempo en completarse cuando el firewall bloquea el tráfico saliente. Resultado de muestra que indica un problema de firewall:

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

Visita Reglas de firewall a fin de obtener información sobre cómo configurar las reglas para el tráfico saliente.

Reinstala el agente

Instalar la versión más reciente del agente puede resolver muchos problemas:

• Si estás seguro de que el problema no está relacionado con las credenciales, puedes pasar a Instala en Linux y Windows.

• Para una instalación completa del agente y las credenciales necesarias, consulta Instala el agente de Logging.

Otros problemas comunes

En la siguiente tabla, se enumeran algunos problemas comunes que pueden ocurrir con el agente de Cloud Logging y se indica cómo solucionarlos.

En Linux, el agente de Logging registra los errores en /var/log/google-fluentd/google-fluentd.log. En Windows, el agente de Logging registra los errores en C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log (a partir de la versión v1-9). La clase de error Google::APIClient::ClientError indica que hay un problema con los permisos o el acceso a la API.

Puede que comiences a ver los errores después de que el agente se haya ejecutado de manera correcta. Por ejemplo, puede que alguien haya revocado los permisos requeridos de tu proyecto o tu instancia de VM.

Error	Causa	Solución
El instalador del agente en Windows no se ejecuta de manera correcta	Puede que hayas descargado el instalador en un directorio del sistema.	Mueve el instalador a un directorio que no sea del sistema, como C:\Users\[USERID]\.
El proyecto no habilitó la API	No habilitaste la API de Cloud Logging en tu proyecto.	Ve a la Consola de API y cambia el estado de la API de Cloud Logging a ACTIVADO.
La solicitud tenía credenciales no válidas o No se puede recuperar el token de acceso (¿No hay permisos configurados?)	Tu instancia de VM no tiene credenciales adecuadas. Si usas Amazon EC2, debes instalar las credenciales en tus instancias de VM antes de instalar el agente.	Consulta Autoriza al agente de Logging para instalar credenciales.
No se pudo autorizar	Tus credenciales de autorización de clave privada para el agente de Logging no están configuradas de manera correcta.	Consulta Verifica las credenciales de clave privada.
El emisor no tiene permiso	La cuenta de servicio que se usó para la autorización en tu proyecto no tiene permisos suficientes. Puede ser la cuenta de servicio predeterminada que se usa en Compute Engine o App Engine, o una cuenta de servicio definida por el usuario para la autorización de clave privada. La cuenta debe tener la función de Editor.	Cambia el permiso de la cuenta de servicio en la página IAM de tu proyecto. Si es necesario, puedes modificar el permiso de acceso para una VM existente mediante los procedimientos Cambia la cuenta de servicio y los niveles de acceso para una instancia.
No se puede obtener el ID del proyecto	El agente de Cloud Logging no pudo obtener el ID del proyecto del archivo de credenciales de clave privada de una cuenta de servicio.	Si quieres agregar o anular un ID del proyecto para el agente, edita el archivo de configuración del agente, /etc/google-fluentd/google-fluentd.conf, en tu instancia de VM. En la sección <match **> agrega la siguiente línea: project_id [YOUR_PROJECT_ID] . De lo contrario, consulta Autoriza al agente de Logging para corregir o reemplazar las credenciales.
El agente de Logging de Window deja de transferir registros de eventos de algunos canales.	Es posible que el agente de Logging no transfiera de forma silenciosa los registros de eventos de ciertos canales, incluso si aún ejecuta y transfiere registros de agentes y registros de eventos de otros canales. El motivo es que el complemento windows_eventlog tiene algunos problemas, como se menciona en esta presentación. El uso de windows_eventlog2 resuelve este problema.	Nota: El formato de datos del complemento windows_eventlog2 no es retrocompatible con el complemento windows_eventlog. Si hay canalizaciones de exportación de BigQuery o Google Cloud Storage configuradas para estos registros, deben ajustarse según corresponda. Consulta esta comparación de entradas de registro que proporcionan windows_eventlog y windows_eventlog2. Para usar windows_eventlog2, primero debes detener el agente de Logging y, luego, reemplazar el archivo de configuración por uno similar a este archivo de configuración de muestra. Por último, inicia el agente de Logging.
El agente de Logging deja de transferir registros en presencia de logrotate	Es posible que el agente de Logging pierda de vista en qué parte de los archivos de entrada se encuentra cuando se configura logrotate con la configuración copytruncate.	Es aconsejable usar la configuración nocopytruncate para garantizar que logrotate mueva los archivos en lugar de truncarlos. Si deseas conservar la configuración copytruncate, reinicia el agente de forma periódica. O bien, puedes usar la configuración postrotate para reiniciar el agente.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231"	Hay varias instancias del agente de Logging en ejecución en la VM.	Usa ps -aux | grep "/usr/sbin/google-fluentd" para mostrar los procesos del agente en ejecución (solo debe haber dos: un supervisor y un trabajador) y sudo netstat -nltp | grep :24231 para mostrar los procesos en ejecución que ocupan el puerto. Elimina las instancias más antiguas si lo crees necesario.
No se pudo iniciar el agente de Logging debido a que se produjeron errores desde lib/fluent/config/types.rb	La configuración del agente de Logging usa una sección del analizador de regex que tiene una regex con formato incorrecto, lo que genera una llamada de subexp. no válida y errores como Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call.	Ubica y corrige la regex con formato incorrecto en el archivo de configuración del agente. Sugerencia: busca regex o parse.

Nota: Si los errores anteriores no se aplican y no ves tus entradas de registro, consulta Visualización de registros: Soluciona problemas.

Limitación en la capacidad de procesamiento de registros

La capacidad de procesamiento máxima de registros que el agente de Logging puede procesar está limitada por la CPU. El uso de CPU suele aumentar cuando aumenta la capacidad de procesamiento del registro. Sin embargo, el agente con la configuración predeterminada puede usar hasta un núcleo de CPU. Por lo tanto, cuando la capacidad de procesamiento del registro aumenta, el agente puede alcanzar un límite de uso de CPU. Si estos aumentos son temporales, el agente de Logging almacena los registros en búfer y, luego, los pone al día para procesarlos. Si la capacidad de procesamiento de registros se mantiene alta, los registros pueden desbordar el búfer y perderse.

Por lo general, cuando cada entrada de registro es de 1,000 bytes de texto sin procesar y no contiene procesamiento de formato adicional, el agente de Logging alcanza el límite de CPU principal en alrededor de 5,500 entradas de registro por segundo. Si las entradas de registro requieren procesamiento avanzado, por ejemplo, análisis JSON o de regex, la cantidad máxima de entradas de registro por segundo puede ser menor.

Si necesitas mayor capacidad de procesamiento de registros, puedes considerar usar el agente de operaciones. En Linux, para las entradas de registro que son textos sin procesar de 1,000 bytes y no implican ningún procesamiento adicional, el agente de operaciones puede procesar alrededor de 160,000 entradas de registro por segundo.

Se superó el tamaño máximo de registro

Si una o más entradas de registro superaron el límite de tamaño máximo, es posible que encuentres entradas en los registros fluentd similares a las siguientes:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"

o bien

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

A fin de resolver este error, recorta tus entradas de registro para que no excedan el límite de tamaño máximo. Por ejemplo, el siguiente código de muestra recorta los registros con la etiqueta mytag, con los datos en el campo message:

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

Se duplicaron los registros

LogEntry.insertID se agrega a la canalización de procesamiento dentro del agente. Si insertID es diferente entre los registros duplicados, esto indica que los registros se ponen en cola de los archivos de registro varias veces. Esto podría suceder en la presencia de la rotación del registro o cuando falta el archivo de publicación o está dañado. A fin de reducir las posibilidades de este problema, asegúrate de que los archivos de posición para cualquier entrada de in_tail no estén configurados en la carpeta /var/log ni en ninguna otra carpeta que pueda tener la rotación de registros habilitada.

La canalización de registros también se basa en el campo LogEntry.timestamp para anular registros duplicados. Asegúrate de que la marca de tiempo real de la entrada de registro se analice correctamente. Si Fluentd no está configurado para analizar la marca de tiempo original de la entrada de registro, usa la hora cuando procesa la entrada de registro. Por lo tanto, si la entrada se lee varias veces, aunque la marca de tiempo en la línea de registro es la misma, Fluentd puede tratarlas como entradas de registro diferentes con marcas de tiempo diferentes.

Errores reiterados del registro de auditoría: Data points cannot be written more than 24h in the past

Existe un problema conocido que afecta a las versiones desde la 1.8.5 a la 1.9.3 (incluida), que hace que los registros como los siguientes aparezcan de forma repetida en los registros de auditoría de acceso a los datos cuando el agente se ejecuta durante más de 24 horas:

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

La solución es actualizar el agente a la versión 1.9.4 o superior.

Los caracteres Unicode de los registros se reemplazan por espacios o '�'

De forma predeterminada, la entrada in_tail espera que los archivos de entrada estén codificados en ASCII, por lo que reemplaza cualquier carácter que no sea ASCII por un espacio. Para transferir archivos codificados en UTF-8, debes proporcionar dos opciones en la configuración in_tail:

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

Ambas opciones son necesarias. Si solo se proporciona la opción encoding, los caracteres que no sean ASCII en los registros transferidos se reemplazarán '�'.

Se quitó el agente que la consola de Google Cloud informó como instalado

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

El agente de Logging no aparece en la lista Desinstalar un programa de Windows

Para desinstalar el agente de Logging cuando no está en la lista Desinstalar un programa del panel de control de Windows, ejecuta uninstall.exe desde el directorio en el que lo instalaste.