Quale strumento utilizzare: agente Logging o libreria client?
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento fornisce le informazioni necessarie per aiutarti a decidere se inviare i log delle applicazioni a Cloud Logging in modo programmatico utilizzando le librerie client o un agente di logging. Gli agenti di logging inviano i dati scritti in un file, ad esempio stdout o un file, come log a Cloud Logging. Servizi come Google Kubernetes Engine, l'ambiente flessibile di App Engine e le funzioni Cloud Run contengono un agente di logging integrato. Per Compute Engine, puoi installare Ops Agent o l'agente Cloud Logging precedente.
Questi agenti raccolgono i log da posizioni dei file note o da servizi di registrazione come Windows Event Log, journald o syslogd.
Quando non puoi utilizzare una libreria client o un agente Logging o quando
vuoi solo fare esperimenti, puoi scrivere log utilizzando il
comando gcloud logging write
o inviando comandi HTTP all'endpoint API Cloud Logging
entries.write.
L'API Cloud Logging supporta sia le chiamate HTTP sia quelle gRPC. L'agente Ops e la maggior parte delle librerie client di Logging chiamano l'API gRPC Logging. L'agente di logging e le librerie client precedenti per alcuni linguaggi chiamano l'API Logging REST.
Scegliere un agente o librerie client
Quando devi scegliere tra un agente o le librerie client, poniti le seguenti domande:
La tua applicazione viene eseguita al di fuori di Google Cloud?
Se la tua applicazione non viene eseguita su Google Cloud, devi trovare un modo per inviare i log all'API Logging. Per instradare i log dai sistemi on-premise a Logging, ti consigliamo di utilizzare Bindplane, che esegue il deployment e la gestione dei collector OpenTelemetry per inviare la telemetria a Google Cloud. Per ulteriori informazioni, consulta Informazioni su Bindplane.
In alternativa, puoi inoltrare i log a Logging direttamente dall'applicazione utilizzando le librerie client. Per gli ambienti effimeri, come il serverless computing, devi utilizzare le librerie client per effettuare chiamate dirette all'API Logging.
Il servizio che esegue la tua applicazione supporta Google Cloud
scrivere contenuti stdout e stderr per il tuo progetto?
Alcuni Google Cloud servizi sono completamente gestiti, quindi non è necessario
utilizzare agenti per inviare i log al tuo Google Cloud progetto. Puoi utilizzare qualsiasi framework di logging consolidato nel linguaggio che preferisci, ad esempio Go, Node.js e Python, per inviare i log alla funzionalità di logging nei prodotti in cui stdout e stderr sono supportati per impostazione predefinita. Un vantaggio dell'utilizzo di stdout e stderr
invece di utilizzare le librerie client è che gli arresti anomali dell'applicazione non interrompono
l'invio dei log al progetto. Per informazioni sull'invio di
log strutturati tramite stdout e
stderr, consulta la sezione La tua applicazione è in grado di
modificare il formato dei log?.
Puoi utilizzare le librerie client di logging, ma tieni presente che potrebbe essere introdotta una dipendenza da Logging per i test locali, anche se non è necessariamente necessaria. L'utilizzo delle librerie client potrebbe anche richiedere un codice più complesso per gestire esplicitamente il buffering e i tentativi di nuovo invio.
Inoltre, ogni utilizzo delle librerie client di Logging crea un nuovo stream di connessione all'API. Queste nuove connessioni introducono più complessità, utilizzano porte aggiuntive e inviano richieste separate contenenti solo i log dell'applicazione, il che potrebbe essere uno spreco se i log non sono molti.
I log dell'applicazione devono essere accessibili nel tuo ambiente locale?
Se devi accedere ai log dell'applicazione nel tuo ambiente locale, per il debugging e altri scopi, puoi utilizzare i moduli di logging in alcuni linguaggi per l'output in stdout e stderr. Le librerie client per la registrazione per alcune lingue supportano l'instradamento dei log a stdout e stderr.
Quando esegui l'applicazione in Google Cloud servizi che non supportano
l'invio automatico dei log scritti in stdout e stderr al tuo
Google Cloud progetto, puoi raccogliere
i log stdout e stderr in file su disco e configurare l'agente in modo da
estrapolare i log e inviarli a Logging. Per ulteriori informazioni, consulta la guida alla configurazione di Ops Agent o dell'agente Logging precedente.
La procedura di installazione dell'agente è manuale o automatica?
Alcuni servizi installano gli agenti automaticamente o ti consentono di installarli autonomamente. Se il servizio che utilizzi non ti consente di installare agenti,
devi utilizzare le librerie client per utilizzare Logging.
Raccogli anche le metriche delle applicazioni per Cloud Monitoring?
Nelle VM Compute Engine, Ops Agent può raccogliere i log e la maggior parte delle metriche. Per ulteriori informazioni, consulta la sezione Funzionalità di Ops Agent.
La tua applicazione ha la flessibilità di modificare il formato del log?
Questa domanda ti aiuta a decidere se la tua applicazione può generare
log strutturati.
Logging riconosce i log strutturati se li invii all'API Logging nel formato di logging strutturato.
Le librerie client forniscono i metodi per gestire questo formato.
Devi configurare l'agente in modo che riconosca i log strutturati.
Per impostazione predefinita, gli agenti sono configurati per rilevare i log in formato JSON e gestirli come log strutturati. Se la tua applicazione ha un proprio formato dei log
che non puoi modificare, ma vuoi che i log vengano riconosciuti come log
strutturati, devi scrivere i log nel formato di registrazione strutturata, solitamente
JSON, in stdout e stderr, in modo che gli agenti possano riconoscerli come
log strutturati. In caso contrario, devi configurare l'agente in modo che comprenda il tuo formato.
Riepilogo di ogni opzione
Librerie client di Cloud Logging
Vantaggi
Puoi instradare i log direttamente all'API Cloud Logging.
Alcune lingue possono generare log in stdout e stderr utilizzando la biblioteca.
Svantaggi
Gli arresti anomali dell'applicazione interrompono l'invio dei log al tuo Google Cloud progetto.
Ops Agent
Vantaggi
Ops Agent può inviare log e metriche utilizzando tecnologie open source stabili: Fluent Bit per la raccolta dei log e OpenTelemetry Collector per la raccolta delle metriche.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
