¿Qué deberías usar: el agente de Logging o la biblioteca cliente?
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se proporciona la información que necesitas para decidir si envías de manera programática los registros de las aplicaciones a Cloud Logging mediante bibliotecas cliente o un agente de registro. Los agentes de registro envían datos escritos en un archivo, como
stdout o un archivo, como registros a Cloud Logging. Servicios como Google Kubernetes Engine, el entorno flexible de App Engine y las funciones de Cloud Run contienen un agente de registro integrado. En Compute Engine, puedes instalar el
Agente de operaciones o el agente heredado de Cloud Logging.
Estos agentes recopilan registros de ubicaciones de archivos o servicios de registro conocidos, como Windows Event Log, journald o syslogd.
Cuando no puedes usar una biblioteca cliente o un agente de Logging, o cuando solo quieres experimentar, puedes escribir registros con el comando gcloud logging write o enviando comandos HTTP al extremo entries.write de la API de Cloud Logging.
La API de Cloud Logging admite llamadas HTTP y gRPC. El agente de operaciones y la mayoría de las bibliotecas cliente de Logging llaman a la API de Logging de gRPC. El agente de Logging heredado y las bibliotecas cliente para algunos lenguajes llaman a la API de Logging de REST.
Elige un agente 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. Para enrutar registros de sistemas locales a Logging, te recomendamos que uses Bindplane, que implementa y administra los recopiladores de OpenTelemetry para enviar telemetría a Google Cloud. Para obtener más información, consulta Acerca de Bindplane.
Como alternativa, 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 para realizar llamadas directas a la API de Logging.
¿El servicio Google Cloud que ejecuta tu aplicación admite
¿Estás escribiendo contenido de stdout y stderr en tu proyecto?
Algunos Google Cloud servicios están completamente administrados, por lo que no necesitas
usar agentes para enviar registros a tu Google Cloud proyecto. Puedes usar cualquier framework de registro establecido en el lenguaje que elijas, como Go, Node.js y Python, para enviar registros a Logging en productos compatibles con stdout y stderr de forma predeterminada. Una ventaja de usar stdout y stderr en lugar de bibliotecas cliente es que las fallas de la aplicación no interrumpen el envío de registros a tu proyecto. Para obtener información sobre el envío 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 Google Cloud servicios que no admiten
el envío automático de registros escritos en stdout y stderr a tu
proyectoGoogle Cloud , puedes recopilar
registros stdout y stderr en archivos en el disco y configurar el agente para
recuperarlos y enviarlos a Logging. Para obtener más información, consulta la guía de configuración del agente de operaciones o el agente de Logging heredado.
¿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.
¿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.
¿Tu aplicación tiene la flexibilidad de cambiar el formato de registro?
Esta pregunta te ayuda a decidir si tu aplicación puede generar 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.
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
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 fallas de la aplicación interrumpen el envío de registros a tu Google Cloud proyecto.
Agente de operaciones
Ventajas
El agente de operaciones puede enviar 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.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (UTC)"],[],[],null,["# Which should you use: Logging agent or client library?\n\nThis document provides the information that you need to help you decide whether\nto programmatically send application logs to Cloud Logging by using\n[client libraries](/logging/docs/reference/libraries) or by using a\nlogging agent. Logging agents send data written to a file, such as\n`stdout` or a file, as logs to Cloud Logging. Services such as\nGoogle Kubernetes Engine, App Engine flexible environment, and Cloud Run functions, contain an integrated\nlogging agent. For Compute Engine, you can install the\n[Ops Agent or the legacy Cloud Logging agent](/logging/docs/agent).\nThese agents collect logs from known file locations or logging\nservices like the `Windows Event Log`, `journald`, or `syslogd`.\n\nWhen you can't use a client library or a Logging agent, or when\nyou only want to experiment, you can write logs by using the\n[`gcloud logging write`](/sdk/gcloud/reference/logging/write)\ncommand or by sending HTTP commands to the Cloud Logging API endpoint\n[`entries.write`](/logging/docs/reference/v2/rest/v2/entries/write).\nThe [Cloud Logging API](/logging/docs/reference/api-overview) supports both\nHTTP and gRPC calls. The Ops Agent and most Logging client\nlibraries call the gRPC Logging API. The legacy Logging\nagent and client libraries for some languages call the REST\nLogging API.\n| **Note:** There will be no new feature development or support for new operating systems for the legacy Logging agent. We recommend that you use the [Ops Agent](/logging/docs/agent/ops-agent) for new workloads and eventually transition your existing VMs to use the Ops Agent.\n\nChoosing an agent or client libraries\n-------------------------------------\n\nWhen you're deciding between an agent or the client libraries, consider\nthe following questions:\n\nIs your application running outside of Google Cloud?\n\n: If your application isn't running on Google Cloud, you need\n some way to send logs to the Logging API. To route logs from\n on-premises systems to Logging, we recommend that you use\n [Bindplane](https://bindplane.com/google), which deploys and manages\n OpenTelemetry collectors to send telemetry to Google Cloud. For more\n information, see [About Bindplane](/stackdriver/bindplane).\n\n Alternatively, you can route logs to Logging directly from\n the application by using client libraries. For ephemeral environments,\n like Serverless computing, you must use client libraries to make direct\n calls to the Logging API.\n\nDoes the Google Cloud service running your application support\nwriting `stdout` and `stderr` content to your project?\n\n: Some Google Cloud services are fully managed, so you don't need\n to use agents to send logs to your Google Cloud project. You can use any\n established logging framework in\n the language of your choice, such as Go, Node.js, and Python, to send logs to\n Logging in products where `stdout` and `stderr` are supported\n by default. An advantage to relying on `stdout` and `stderr`\n instead of using client libraries is that application crashes don't break\n sending logs to your project. For information about sending\n [structured logs](/logging/docs/structured-logging) through `stdout` and\n `stderr`, see the section, [Does your application have the flexibility to\n change the log format?](#log-format).\n\n You can use Logging client libraries, but keep in mind that\n it might introduce a dependency on Logging for local testing,\n when you don't necessarily need it. Using the client libraries might also\n require more complex coding to explicitly handle buffering and retries.\n Also, each use of the Logging client libraries creates a new\n connection stream to the API. These new connections introduce more\n complexity, use additional ports, and send separate requests with only the\n logs from the application, which could be wasteful if there aren't many\n logs.\n\nDo the application logs need to be accessible in your local environment?\n\n: If you need to access the application logs in your local environment, for\n debugging and other purposes, then you can use the logging modules in some\n languages to output to `stdout` and `stderr`. Logging client\n libraries for some languages support routing logs to `stdout` and `stderr`.\n\n When running your application in Google Cloud services that don't support\n automatically sending logs written to `stdout` and `stderr` to your\n Google Cloud project, you can collect\n `stdout` and `stderr` logs in on-disk files and configure the agent to\n scrape those and send them to Logging. For more information,\n see the configuration guide for the [Ops Agent](/logging/docs/agent/ops-agent/configuration)\n or the legacy [Logging agent](/logging/docs/agent/logging/configuration).\n\nIs the agent-installation process manual or automatic?\n\n: Some services install agents automatically or allow you to install the agents\n yourself. If the service you are using doesn't allow you to install agents,\n then you must use the client libraries to use Logging.\n\nAre you running Fluentd in your system already?\n\n: The legacy Logging agent is based on Fluentd.\n\n If you already have Fluentd running in your system, and you would like to\n use that daemon to send your logs to Logging, then use the\n [Google Cloud Logging plugin for\n fluentd](https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud).\n\nAre you collecting application metrics for Cloud Monitoring as well?\n\n: In Compute Engine VMs, the Ops Agent can collect logs and most metrics. See\n [Ops Agent features](/stackdriver/docs/solutions/agents/ops-agent#features) for more information.\n\n If the Ops Agent doesn't address your use cases, then you can use the\n [legacy Monitoring agent](/monitoring/agent/monitoring) or the\n [Monitoring client libraries](/monitoring/docs/reference/libraries)\n to collect your metrics.\n\nDoes your application have the flexibility to change the log format?\n\n: This question helps you decide if your application can generate\n [structured logs](/logging/docs/structured-logging).\n Logging recognizes structured logs if you send the logs to the\n Logging API in [the structured-logging format](/logging/docs/reference/v2/rpc/google.logging.v2#google.logging.v2.WriteLogEntriesRequest).\n Client libraries provide the methods for handling this format.\n\n There are two way of writing structured logs: one is to set [specific fields\n in the `LogEntry` envelope](/logging/docs/structured-logging#special-payload-fields),\n and the other is to set the [`jsonPayload` field within the `LogEntry`\n envelope](/logging/docs/structured-logging#use-gcloud).\n The schema for the former is determined by Cloud Logging, while the\n schema for the latter is determined by the user.\n\n You must configure the agent to recognize [structured logs](/logging/docs/structured-logging).\n By default, the agents are configured to detect logs in JSON format and to\n handle them as structured logs. If your application has its own log format\n that you can't change, but you want the logs to be recognized as structured\n logs, then you must write logs in the structured-logging format, usually\n JSON, to `stdout` and `stderr`, so that the agents can recognize them as\n structured logs. Otherwise, you must configure your agent to understand your\n own format.\n\nSummary of each option\n----------------------\n\n- Cloud Logging client libraries\n\n - Advantages\n\n - You can route logs directly to Cloud Logging API.\n - Some languages can output logs to `stdout` and `stderr` by using the library.\n - Disadvantages\n\n - Application crashes break sending logs to your Google Cloud project.\n- Ops Agent\n\n - Advantages\n\n - The Ops Agent can send logs and metrics by using stable open source technologies: Fluent Bit for log collection and the OpenTelemetry Collector for metric collection.\n - You can collect both logs and metrics from many common applications; see [Monitor and collect logs from third-party\n applications](/stackdriver/docs/solutions/agents/ops-agent/third-party).\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - The Ops Agent is under active development.\n - Disadvantages\n\n - Fluent Bit only supports UTF-8 encoding. It doesn't support encoding conversion.\n- Legacy Logging agent\n\n - Advantages\n - The agent uses Fluentd to collect logs, which supports encoding conversion.\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - The agent is currently supported but is not under active development.\n- `stdout` and `stderr` logs automatically sent to your Google Cloud project\n\n - Advantages\n - This process is a common way to emit logs to local environments.\n - You can use arbitrary logging libraries.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - Not all environments automatically route logs to Logging."]]
