Solucionar problemas del agente de Logging

En esta página se proporcionan instrucciones para solucionar problemas habituales que se producen al instalar o interactuar con el agente de Logging.

Lista de comprobación

Si tienes problemas para instalar o usar el agente de Logging, comprueba lo siguiente:

• Si los comandos de instalación de Linux dan como resultado errores, asegúrate de prefijar los comandos de instalación con sudo.

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

  • En una máquina virtual Windows, usa el siguiente comando de PowerShell:

    Get-Service -Name StackdriverLogging
    

    Busca un servicio llamado Stackdriver Logging. Si el agente no se está ejecutando, es posible que tengas que reiniciarlo.

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

    sudo service google-fluentd status
    

    Si el agente no se está ejecutando, es posible que tengas que reiniciarlo con el siguiente comando:

    sudo service google-fluentd restart
    

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

    Si el agente no se inhabilita mediante metadatos, vuelve a instalarlo. Consulta la sección Reinstalar el agente de Logging.

• Comprueba si el agente ha escrito mensajes de error en los registros.

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

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

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

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

    • Si tienes problemas con el acceso a la API o con la autorización, consulta el artículo Verificar las credenciales de Compute Engine.

• Si parece que el agente funciona con normalidad, pero no recibe datos, compruebe que el agente está enviando datos al proyecto correcto. Consulta la sección Verificar las credenciales de Compute Engine.

• Si el agente no puede autorizar, comprueba si las credenciales de tu clave privada faltan o no son válidas.

Verificar la instalación del agente

Nota: Si tu VM se ha iniciado como parte de un despliegue del entorno flexible de App Engine o de Kubernetes Engine, no es necesario que instales el agente de Logging. Salta esta página.

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

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

   Ve al Explorador de registros.

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

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

   • En el caso de las instancias de VM de Compute Engine, elige el Google Cloud proyecto que contenga la instancia de VM.
   • En instancias de VM de Amazon EC2, elige el Google Cloud proyecto al que vas a enviar los registros.

3. En las pestañas de la ventana, elija el recurso de su instancia de VM:

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

Si ves la entrada de registro "Successfully sent gRPC to Logging API" (Se ha enviado correctamente gRPC a la API Logging), la instalación del agente se ha completado. Este mensaje se genera una vez cuando se instala el agente y también cada vez que se reinicia.

Para obtener más información sobre el Explorador de registros, consulta el artículo Usar el Explorador de registros.

Probar el agente

Si sospechas que el agente no funciona, comprueba que se está ejecutando e intenta enviar un mensaje de prueba a Logging:

Instancia de Linux

El siguiente procedimiento funciona tanto en instancias de máquinas virtuales de Compute Engine como de Amazon EC2 que ejecutan Linux:

1. Para comprobar que el agente de Logging se está ejecutando, ejecuta los siguientes comandos en tu instancia de VM:

   ps ax | grep fluentd
   

   Debería aparecer lo 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 ejecutando el siguiente comando en tu instancia de VM:

   logger "Some test message"
   

Instancia de Windows

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

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

Deberías ejecutar un servicio de agente. Ejecuta los siguientes comandos en tu instancia de máquina virtual con PowerShell:

1. Pregunta por el estado de ambos servicios. Si sabes qué servicio debería estar en ejecución, puedes usar solo el nombre de ese servicio:

   Get-Service StackdriverLogging,fluentdwinsvc
   

2. Si un servicio no se está ejecutando, verás un mensaje de error. Si está en ejecución, verás un resultado como el 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 ningún estado Running, significa que el agente de registro no se está ejecutando.
   • Si ves que StackdriverLogging está en ejecución, significa que estás usando una versión reciente del agente. Para determinar la versión específica, consulta Obtener la versión.
   • Si ves que fluentdwinsvc está en ejecución, debes actualizar tu agente a la última versión.

4. Requiere privilegios de administrador: si se está ejecutando alguna versión del agente, envía un mensaje de registro de prueba ejecutando 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."
   

Buscar el mensaje de prueba

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

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

   Ve al Explorador de registros.

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

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

   • En el caso de las instancias de VM de Compute Engine, elige el Google Cloud proyecto que contenga la instancia de VM.
   • En instancias de VM de Amazon EC2, elige el Google Cloud proyecto al que vas a enviar los registros.

3. En las pestañas de la ventana, elija el recurso de su instancia de VM:

   • En Compute Engine, elige Instancia de VM de GCE.
   • En 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 el mensaje de prueba. Si es así, el agente de registro funciona correctamente.

Verificar 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 ámbitos de acceso adecuados y la identidad de la cuenta de servicio que utilice la instancia debe tener permisos de IAM adecuados.

Cuando creas una instancia de VM, los ajustes predeterminados de ámbito y cuenta de servicio son suficientes para ejecutar los agentes. Es posible que las instancias muy antiguas o aquellas en las que hayas cambiado la configuración predeterminada no tengan las credenciales adecuadas.

No se han podido cargar las credenciales predeterminadas

Si hay Could not load the default credentials errores en el archivo de registro Logging, significa que es posible que el agente no pueda conectarse al servidor de metadatos de Compute Engine.

El registro de errores tiene el siguiente aspecto:

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 es que la VM tenga una configuración de proxy personalizada. Para solucionar este problema, consulta las instrucciones de configuración del proxy para excluir el servidor de metadatos de Compute Engine (metadata.google.internal o 169.254.169.254) del proxy. Si el error persiste, elimina la cuenta de servicio predeterminada de Compute Engine de la VM y vuelve a añadirla.

Verificar los permisos de acceso

Para verificar los ámbitos de acceso, haz lo siguiente:

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

   Ve a Instancias de VM.

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

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

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

   1. Si ves el mensaje "Esta instancia tiene acceso completo a la API de todos los servicios de Google Cloud", significa que tus permisos de acceso son adecuados.
   2. Si ves API Stackdriver Logging, un nombre antiguo de la API Cloud Logging, y tienes permiso Solo escritura o Completo, los ámbitos de acceso de tu instancia son adecuados para el agente de Cloud Logging.
   3. Si ves junto a API de Stackdriver Monitoring, un nombre antiguo de la API Cloud Monitoring, que tienes permiso Solo escritura o Completo, los permisos de acceso de tu instancia son adecuados para el agente de Cloud Monitoring.

Corregir el problema

Si no tienes los ámbitos de acceso adecuados en tu instancia de Compute Engine, añade los ámbitos de acceso necesarios a tu instancia.

En la siguiente tabla se muestran los ámbitos relevantes 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

Verificar el permiso de la cuenta de servicio predeterminada

Aunque los permisos de acceso de tu instancia de VM de Compute Engine sean adecuados, es posible que la cuenta de servicio predeterminada de tu instancia no proporcione los permisos de gestión de identidades y accesos adecuados para el agente.

Para verificar el permiso de la cuenta de servicio predeterminada, empieza por localizarla:

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

   Ve a Instancias de VM.

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

2. Haz clic en el nombre de tu instancia de VM. Se muestra 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 de la instancia. Podría tener un aspecto similar al siguiente:

   [ID][e-mail]
   

4. En la Google Cloud consola, ve a la página Gestión de identidades y accesos:

   Ve a Gestión de identidades y accesos.

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

5. Selecciona Ver por: directores. Debería aparecer una lista de personas, grupos y cuentas de servicio. En la columna Rol se muestran los roles que tiene cada principal en tu proyecto.

6. En la fila de la cuenta de servicio predeterminada de tu instancia, deberías ver uno o varios roles:

   • Si ve Editor, ese rol es adecuado para todos los agentes. Es posible que el rol Editor se asigne automáticamente a la cuenta de servicio predeterminada en función de la configuración de la política de organización.
   • Si ves Escritor de registros, ese rol es suficiente para el agente de Logging. Para ver otros roles de Logging que incluyen el permiso de escritura, consulta Control de acceso de Cloud Logging.
   • Si ves Escritor de métricas de monitorización, ese rol es suficiente para el agente de monitorización. Para ver otros roles de Monitoring que incluyan el permiso de escritura, consulta Control de acceso de Cloud Monitoring.

Corregir el problema

Si tu cuenta de servicio predeterminada no tiene los roles adecuados, prueba a editar los roles de tu cuenta de servicio en la página Gestión de identidades y accesos > Gestión de identidades y accesos. Añade los roles de Logging o Monitoring adecuados para autorizar a los agentes: Logging > Logs Writer (Logging > Escritor de registros) o Monitoring > Monitoring Metric Writer (Monitoring > Escritor de métricas de Monitoring).

Verificar las credenciales de clave privada

En las instancias de VM de Compute Engine, puedes configurar el agente para que use una cuenta de servicio no predeterminada que tenga la autorización adecuada. En las instancias de VM de AWS EC2, debes configurar el agente para que use una cuenta de servicio de este tipo.

Para configurar el agente de esta forma, debes crear credenciales de clave privada para la cuenta de servicio designada y proporcionárselas al agente.

1. El agente busca una variable de entorno, GOOGLE_APPLICATION_CREDENTIALS, que contiene 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: Usa el sistema de archivos u otro control de acceso para asegurarte de que la clave privada solo sea accesible para las aplicaciones que la necesiten en tus instancias.

La siguiente información le ayudará a diagnosticar problemas con las credenciales de clave privada:

1. ¿Está la clave privada en su sitio?
2. ¿La clave privada sigue siendo válida para la cuenta de servicio?
3. ¿Tiene la cuenta de servicio los roles necesarios para el agente?

Para verificar que las credenciales de clave privada válidas están instaladas en tu instancia de VM, primero comprueba que el archivo de credenciales se encuentra en la ubicación esperada y, a continuación, verifica que la información del archivo de credenciales es válida.

¿Están presentes las credenciales?

Para comprobar si tu instancia tiene credenciales de cuenta de servicio con clave privada, ejecuta los siguientes comandos de Linux en tu instancia:

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 se muestra a continuación, es posible que tu instancia tenga credenciales de clave privada válidas. Si ambos comandos muestran un archivo, se usará 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}"
}

Las discrepancias entre las configuraciones de las credenciales pueden provocar que el agente use credenciales diferentes a las que requiere tu servicio. Por ejemplo, si defines una ubicación de credenciales personalizada en GOOGLE_APPLICATION_CREDENTIALS en el shell de inicio de sesión, pero no defines esa variable en la configuración del servicio del agente, el servicio buscará en la ubicación predeterminada en lugar de en la ubicación personalizada.

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

Si no hay ningún archivo de credenciales, consulta la sección Añadir credenciales.

Precaución: Es posible que otros servicios además de Logging usen credenciales de clave privada en tu instancia. Si sustituyes las credenciales actuales, es posible que otros servicios dejen de funcionar.

¿Son válidas las credenciales?

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

El archivo de credenciales no es válido si se cumple alguna de las siguientes condiciones:

• Estás comprobando una instancia de Compute Engine, pero el Google Cloud proyecto del archivo de credenciales no es el proyecto que contiene tu instancia.
• Estás comprobando una instancia de Amazon EC2, pero el Google Cloud proyecto del archivo de credenciales no es el Google Cloud proyecto al que estás enviando los registros.
• La cuenta de servicio indicada no existe. Es posible que se haya eliminado.
• La cuenta de servicio indicada no tiene habilitados los roles correctos: Escritor de registros para el agente de Cloud Logging y Escritor de métricas de monitorización para el agente de Cloud Monitoring.
• La clave privada no existe. Es posible que se haya revocado.

Las credenciales se pueden revocar en la sección IAM y administración > Cuentas de servicio de la consola de Google Cloud . Si no hay credenciales válidas, consulte la sección Añadir credenciales para sustituir las credenciales actuales o añadir nuevas.

Si la cuenta de servicio es la correcta, pero la clave privada se ha revocado, puedes crear una clave privada nueva y copiarla en tu instancia. Consulta el artículo sobre cómo crear claves de cuentas de servicio.

De lo contrario, debes crear una cuenta de servicio, tal como se describe en la sección Añadir credenciales.

Verificar consultas de exclusión de registros

Consulta las consultas de exclusión actuales para asegurarte de que los registros que buscas no se hayan excluido por error.

Verificar cortafuegos

Para comprobar 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 tardar un tiempo en completarse si el cortafuegos bloquea el tráfico saliente. Salida de ejemplo que indica un problema con el cortafuegos:

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

Consulte Reglas de cortafuegos para obtener información sobre cómo configurar reglas para el tráfico saliente.

Reinstalar el agente

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

• Si tienes la certeza de que el problema no está relacionado con las credenciales, puedes saltar a la sección Instalación en Linux y Windows.

• Para obtener información completa sobre cómo instalar el agente y las credenciales necesarias, consulta Instalar el agente de Logging.

Otros problemas habituales

En la siguiente tabla se enumeran algunos problemas habituales que puede encontrar 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.

Es posible que empieces a ver errores después de que el agente se haya ejecutado correctamente. Por ejemplo, es posible que alguien haya revocado los permisos necesarios de tu proyecto o de tu instancia de VM.

Error	Causa	Solución
El instalador del agente en Windows no se ejecuta	Es posible 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 ha habilitado la API	No has habilitado la API Cloud Logging en tu proyecto.	Ve a la consola de APIs y cambia el estado de la API Cloud Logging a ACTIVADO.
La solicitud tenía credenciales no válidas o No se ha podido obtener el token de acceso (¿no se ha configurado ningún ámbito?)	Tu instancia de VM no tiene las credenciales adecuadas. Si usas Amazon EC2, debes instalar las credenciales en tus instancias de VM antes de instalar el agente.	Consulta Autorizar al agente de Logging para instalar credenciales.
Error de autorización	Las credenciales de autorización de clave privada del agente de Logging no están configuradas correctamente.	Consulta Verificar las credenciales de clave privada.
El método llamador no tiene permiso	La cuenta de servicio que se usa 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 bien una cuenta de servicio definida por el usuario que se usa para la autorización de claves privadas. La cuenta debe tener el rol de Editor.	Cambia el permiso de la cuenta de servicio en la página Gestión de identidades y accesos de tu proyecto. Si es necesario, puedes modificar el ámbito de acceso de una máquina virtual que ya tengas siguiendo los procedimientos de la sección Cambiar la cuenta de servicio y los ámbitos de acceso de una instancia.
No se puede obtener el ID del proyecto	El agente de Cloud Logging no ha podido obtener el ID del proyecto del archivo de credenciales de clave privada de una cuenta de servicio.	Para añadir o anular un ID de proyecto del 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 **>, añada la siguiente línea: project_id [YOUR_PROJECT_ID] De lo contrario, consulte Autorizar al agente de Logging para corregir o sustituir las credenciales.
El agente de registro de Windows deja de ingerir registros de eventos de algunos canales	Es posible que el agente de registro no pueda ingerir de forma silenciosa los registros de eventos de determinados canales, aunque siga ejecutándose e ingiriendo registros de agentes y registros de eventos de otros canales. Esto se debe a que el complemento windows_eventlog tiene algunos problemas, como se menciona en esta presentación. Si usas windows_eventlog2 , se solucionará este problema.	Nota: El formato de datos del complemento windows_eventlog2 no es compatible con el complemento windows_eventlog. Si hay alguna canalización de exportación de BigQuery o Google Cloud Storage configurada para estos registros, debe ajustarse en consecuencia. Consulta esta comparación de entradas de registro proporcionada por windows_eventlog y windows_eventlog2. Para usar windows_eventlog2, primero debes detener el agente de Logging y, a continuación, sustituir el archivo de configuración por uno similar a este archivo de configuración de ejemplo. Por último, inicia el agente de Logging.
El agente de Logging deja de ingerir registros cuando se produce una rotación de registros	Es posible que el agente de Logging pierda la pista de dónde se encuentra en los archivos de entrada cuando se configura logrotate con el ajuste copytruncate.	Es mejor usar el ajuste nocopytruncate para asegurarse de que logrotate mueve los archivos en lugar de truncarlos. Si quieres mantener el ajuste copytruncate, la solución alternativa es reiniciar el agente periódicamente. También puedes usar el ajuste 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 ejecutándose en la máquina virtual.	Usa ps -aux | grep "/usr/sbin/google-fluentd" para mostrar los procesos del agente en ejecución (debe haber solo dos: uno de supervisor y otro de trabajador) y sudo netstat -nltp | grep :24231 para mostrar los procesos en ejecución que ocupan el puerto. Elimina las instancias más antiguas según sea necesario.
El agente de registro no se inicia debido a errores de lib/fluent/config/types.rb	La configuración del agente de Logging usa una sección del analizador de expresiones regulares que tiene una expresión regular mal formada, lo que da lugar a una llamada a subexp no válida y a 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.	Busca y corrige la expresión regular mal formada en el archivo de configuración del agente. Nota: Busca regex o parse.

Nota: Si los errores anteriores no se aplican a tu caso y no ves las entradas de registro, consulta Ver registros: solución de problemas.

Limitación del volumen de registro

El rendimiento máximo de los registros que puede procesar el agente de Logging está limitado por la CPU. El uso de la CPU tiende a aumentar cuando lo hace el rendimiento de los registros. Sin embargo, el agente, con la configuración predeterminada, solo puede usar un núcleo de CPU. Por lo tanto, cuando el rendimiento de los registros aumenta, el agente puede alcanzar un límite de uso de la CPU. Si estos picos son solo temporales, el agente de registro almacena los registros en un búfer y, más adelante, se pone al día para procesarlos. Si el rendimiento de los registros se mantiene alto de forma constante, es posible que los registros desborden el búfer y, finalmente, se pierdan.

Normalmente, cuando cada entrada de registro es texto sin formato de 1000 bytes y no contiene ningún procesamiento de formato adicional, el agente de Logging alcanza el límite de una CPU de un solo núcleo a unas 5500 entradas de registro por segundo. Si las entradas de registro requieren un procesamiento avanzado, como el análisis de JSON o de expresiones regulares, el número máximo de entradas de registro por segundo puede ser inferior.

Si necesitas un mayor rendimiento de los registros, puedes usar Ops Agent. En Linux, el agente de operaciones puede procesar unas 160.000 entradas de registro por segundo si las entradas de registro son texto sin formato de 1000 bytes y no requieren ningún procesamiento adicional.

Se ha superado el tamaño máximo del registro

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

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

o

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

Para solucionar este error, recorte las entradas de registro de forma que no superen el límite de tamaño máximo. Por ejemplo, el siguiente código de muestra recorta los registros con la etiqueta mytag y los datos del 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>

Los registros están duplicados

LogEntry.insertID se añade en el canal de procesamiento del agente. Si insertID es diferente entre los registros duplicados, esto indica que los registros se han obtenido de los archivos de registro varias veces. Esto puede ocurrir si se produce una rotación de registros o si falta el archivo pos o está dañado. Para reducir las probabilidades de que se produzca este problema, asegúrate de que los archivos de posición de cualquier entrada de in_tail no estén configurados para estar en la carpeta /var/log ni en ninguna otra carpeta que pueda tener habilitada la rotación de registros.

La canalización de registro también se basa en el campo LogEntry.timestamp para eliminar los 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, Fluentd usará la hora en la que procese la entrada de registro. Por lo tanto, si la entrada se lee varias veces, aunque la marca de tiempo de la línea de registro sea la misma, Fluentd puede tratarla como entradas de registro diferentes con marcas de tiempo distintas.

Errores repetidos en el registro de auditoría: Data points cannot be written more than 24h in the past

Hay un problema conocido que afecta a las versiones de la 1.8.5 a la 1.9.3 (ambas incluidas) que provoca que aparezcan registros como el siguiente repetidamente en los registros de auditoría de acceso a datos cuando el agente se ha ejecutado 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 posterior.

Los caracteres Unicode de los registros se sustituyen por espacios o por "�"

De forma predeterminada, la entrada in_tail espera que los archivos de entrada estén codificados en ASCII, por lo que sustituye cualquier carácter que no sea ASCII por un espacio. Para ingerir archivos codificados en UTF-8, debes proporcionar dos opciones en la configuración de 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 no ASCII de los registros insertados se sustituirán por "�".

Se ha quitado el agente que la consola Google Cloud indicaba que estaba instalado

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

El agente de Logging no aparece en la lista de desinstalación de programas de Windows

Para desinstalar el agente de registro cuando no aparece en la lista Desinstalar un programa del Panel de control de Windows, ejecuta uninstall.exe desde el directorio en el que lo instalaste.