Quale strumento utilizzare: agente Logging o libreria client?

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 esempiostdout 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 Logging gRPC. L'agente di logging precedente e le librerie client 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 è in esecuzione al di fuori di Google Cloud?

Se la tua applicazione non è in esecuzione 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 di observIQ. Per ulteriori informazioni su BindPlane, consulta Informazioni su observIQ e BindPlane.

In alternativa, puoi inoltrare i log a Logging direttamente dall'applicazione utilizzando le librerie client. Per gli ambienti effimeri, come l'elaborazione serverless, devi utilizzare le librerie client per effettuare chiamate dirette all'API Logging.

Il servizio Google Cloud su cui è in esecuzione la tua applicazione supporta
scrivere contenuti stdout e stderr per il tuo progetto?

Alcuni servizi Google Cloud sono completamente gestiti, quindi non è necessario utilizzare agenti per inviare log al progetto Google Cloud. 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 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 cambiare 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 non ci sono molti log.

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 servizi Google Cloud che non supportano l'invio automatico dei log scritti in stdout e stderr al tuo progetto Google Cloud, puoi raccogliere i log stdout e stderr in file on-disk e configurare l'agente in modo che li estragga e li invii 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.

Esegui già Fluentd nel tuo sistema?

L'agente Logging legacy si basa su Fluentd.

Se Fluentd è già in esecuzione nel tuo sistema e vuoi utilizzarlo per inviare i log a Logging, utilizza il plug-in di Google Cloud Logging per Fluentd.

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 saperne di più, consulta la sezione Funzionalità di Ops Agent.

Se Ops Agent non soddisfa i tuoi casi d'uso, puoi utilizzare l'agente di monitoraggio precedente o le librerie client di monitoraggio per raccogliere le metriche.

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.

Esistono due modi per scrivere log strutturati: uno è impostare campi specifici nella busta LogEntry, e l'altro è impostare il campo jsonPayload all'interno della busta LogEntry. Lo schema del primo è determinato da Cloud Logging, mentre lo schema del secondo è determinato dall'utente.

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 di log che non puoi modificare, ma vuoi che i log vengano riconosciuti come log strutturati, devi scrivere i log nel formato di log strutturato, 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

Diagramma dei pattern di logging

  • 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 progetto Google Cloud.

  • 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.
      • Puoi raccogliere sia i log sia le metriche da molte applicazioni comuni. Consulta Monitorare e raccogliere i log da applicazioni di terze parti.
      • Puoi conservare i log nel tuo ambiente locale.
      • Potresti riuscire a recuperare i log dagli arresti anomali dell'applicazione.
      • Ops Agent è in fase di sviluppo attivo.

  • Agente Logging legacy

    • Vantaggi
      • L'agente utilizza Fluentd per raccogliere i log.
      • Puoi conservare i log nel tuo ambiente locale.
      • Potresti riuscire a recuperare i log dagli arresti anomali dell'applicazione.
    • Svantaggi
      • L'agente è attualmente supportato, ma non è in fase di sviluppo attivo.

  • Log stdout e stderr inviati automaticamente al tuo progetto Google Cloud

    • Vantaggi
      • Questa procedura è un modo comune per emettere log in ambienti locali.
      • Puoi utilizzare librerie di logging arbitrarie.
      • Potresti riuscire a recuperare i log dagli arresti anomali dell'applicazione.
    • Svantaggi
      • Non tutti gli ambienti inviano automaticamente i log a Logging.