¿Qué deberías usar: el agente de Logging o la biblioteca cliente?

Cloud Logging proporciona varios mecanismos para interactuar con la v2 de API de Cloud Logging: los agentes de Logging y las bibliotecas cliente de Logging. Los agentes, el agente de operaciones y el agente de Logging heredado, y las bibliotecas cliente de Logging llaman a la API de Logging para gRPC. El agente de Logging heredado y las bibliotecas cliente para algunos lenguajes llaman a la API de Logging de REST.

Una de las principales diferencias entre estos mecanismos es la forma en que llaman a la API de Logging. Una aplicación que usa las bibliotecas cliente llama directamente a la API, pero un agente actúa como un proxy para tus aplicaciones. Si usas los agentes, tus aplicaciones pueden usar cualquier framework de registro establecido para emitir registros. En entornos de contenedores, como Google Kubernetes Engine o Container-Optimized OS, los agentes recopilan registros de stdout y stderr de forma predeterminada. En las VM, los agentes recopilan registros de ubicaciones de archivos o servicios de registro conocidos, como el registro de eventos de Windows, journald o syslogd.

En esta página, se proporciona información sobre los agentes de Logging y las bibliotecas cliente para ayudarte a decidir si envías registros a Cloud Logging mediante bibliotecas cliente o un agente.

Elige agentes o bibliotecas cliente

Cuando decidas entre un agente o las bibliotecas cliente, ten en cuenta las siguientes preguntas:

¿La aplicación se ejecuta fuera de Google Cloud?

Si tu aplicación no se ejecuta en Google Cloud, necesitas alguna forma de enviar registros a la API de Logging. En este caso, puedes enrutar registros a Logging directamente desde la aplicación mediante las bibliotecas cliente. Para entornos efímeros, como la computación sin servidores, debes usar bibliotecas cliente a fin de realizar llamadas directas a la API de Logging.

Para enrutar registros de sistemas locales a Logging, también puedes usar BindPlane de Blue Medora.

¿El servicio de Google Cloud que ejecuta tu aplicación admite la transferencia automática de registros a través de stdout y stderr?

Algunos servicios de Google Cloud están completamente administrados, por lo que no necesitas usar agentes para enrutar registros. Puedes usar cualquier framework de registro establecido en el lenguaje que elijas, como Go, Node.js y Python, para enrutar registros a Logging en productos compatibles con stdout y stderr de forma predeterminada. Una ventaja de transferir registros a través de stdout y stderr en lugar de usar bibliotecas cliente es que las fallas de la aplicación no interrumpirán la transferencia de registros. Para obtener información sobre la transferencia de registros estructurados a través de stdout y stderr, consulta la sección ¿Tu aplicación tiene la flexibilidad de cambiar el formato de registro?

Puedes usar las bibliotecas cliente de Logging, pero ten en cuenta que puede ingresar una dependencia en Logging para las pruebas locales, cuando no la necesites. El uso de las bibliotecas cliente también puede requerir una programación más compleja para controlar de forma explícita el almacenamiento en búfer y los reintentos. Además, cada uso de las bibliotecas cliente de Logging crea un flujo de conexión nuevo a la API. Estas conexiones nuevas presentan mayor complejidad, usan puertos adicionales y envían solicitudes separadas solo con los registros de la aplicación, lo que podría ser un desperdicio si no hay muchos registros.

¿Los registros de la aplicación deben ser accesibles en tu entorno local?

Si necesitas acceder a los registros de la aplicación en tu entorno local para la depuración y otros fines, puedes usar los módulos de registro en algunos lenguajes a fin de generar los resultados en stdout y stderr. Las bibliotecas cliente de Logging para algunos lenguajes admiten el enrutamiento de registros a stdout y stderr.

Cuando ejecutas tu aplicación en los servicios de Google Cloud que no admiten la transferencia automática de registros mediante stdout y stderr, puedes recopilar registros stdout y stderr en el disco. y configura el agente para recopilarlos y enviarlos a Logging. A fin de obtener más información, consulta la guía de configuración para el agente de operaciones o el agente de Logging.

¿El proceso de instalación del agente es manual o automático?

Algunos servicios instalan agentes de forma automática o te permiten instalarlos. Si el servicio que usas no te permite instalar agentes, debes usar las bibliotecas cliente para usar Logging.

¿Ya ejecutas Fluentd en tu sistema?

El agente de Logging heredado se basa en Fluentd.

Si ya tienes Fluentd en ejecución en tu sistema y deseas usar ese daemon para la transferencia de Logging también, usa el complemento de Google Cloud Logging para fluentd.

¿También recopilas métricas de aplicaciones para Cloud Monitoring?

En las VM de Compute Engine, el agente de operaciones puede recopilar registros y la mayoría de las métricas. Consulta las funciones del agente de operaciones para obtener más información.

Si el agente de operaciones no aborda tus casos de uso, puedes usar el agente heredado de Cloud Monitoring o las bibliotecas cliente de Monitoring para hacer lo siguiente: recopilan tus métricas.

¿Tu aplicación tiene la flexibilidad de cambiar el formato de registro?

Esta pregunta te ayuda a decidir si puedes transferir registros estructurados. Logging reconoce los registros estructurados si envías los registros a la API de Logging en el formato de registro estructurado. Las bibliotecas cliente proporcionan los métodos para manejar este formato.

Existen dos formas de escribir registros estructurados: una es establecer campos específicos en el sobre de LogEntry y la otra es configurar jsonPayload dentro del sobre de LogEntry. Cloud Logging determina el esquema para lo primero, mientras que el usuario determina el esquema para el último.

Debes configurar el agente para que reconozca los registros estructurados. De forma predeterminada, los agentes se configuran para detectar registros en formato JSON y controlarlos como registros estructurados. Si tu aplicación tiene su propio formato de registro que no puedes cambiar, pero deseas que los registros se reconozcan como registros estructurados, debes escribir los registros en el formato structured-logging, por lo general, JSON, en stdout y stderr, para que los agentes puedan reconocerlos como registros estructurados. De lo contrario, debes configurar el agente para que comprenda tu propio formato.

Resumen de cada opción

Diagrama de patrones de registro

  • Bibliotecas cliente de Cloud Logging

    • Ventajas

      • Puedes enrutar registros directamente a la API de Cloud Logging.
      • Algunos lenguajes pueden generar registros en stdout y stderr mediante la biblioteca.
    • Desventajas

      • Las aplicaciones hacen fallar la transferencia del registro.
  • Agente de operaciones

    • Ventajas
      • El agente de operaciones admite la transferencia de registros y métricas mediante tecnologías de código abierto estables: Bit fluido para la recopilación de registros y el colector de OpenTelemetry para la recopilación de métricas.
      • Puedes conservar registros en tu entorno local.
      • Es posible que puedas recuperar registros de fallas de la aplicación.
  • Agente de Logging heredado

    • Ventajas
      • El agente usa Fluentd para recopilar registros.
      • Puedes conservar registros en tu entorno local.
      • Es posible que puedas recuperar registros de fallas de la aplicación.
    • Desventajas
      • El agente es compatible actualmente, pero no está en desarrollo activo.
  • Transferencia de registros automática de stdout y stderr

    • Ventajas
      • Este proceso es una forma común de emitir registros a entornos locales.
      • Puedes usar bibliotecas de registro arbitrarias.
      • Es posible que puedas recuperar registros de fallas de la aplicación.
    • Desventajas
      • No todos los entornos enrutan los registros a Logging automáticamente.