Quale metodo devi utilizzare: agente Logging o libreria client?

Questo documento fornisce le informazioni di cui hai bisogno per aiutarti a decidere per inviare in modo programmatico i log delle applicazioni a Cloud Logging utilizzando librerie client o mediante un di registrazione. 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 di Cloud Run contengono una di registrazione. 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 di logging o quando solo vuoi 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 di logging REST.

Scelta di un agente o delle librerie client

Quando devi decidere tra un agente e le librerie client, considera 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 eseguire il routing dei log da sistemi on-premise a Logging, ti consigliamo di utilizzare BindPlane per observIQ. Per ulteriori informazioni su BindPlane, vedi Informazioni su observIQ e BindPlane.

In alternativa, puoi inoltrare i log a Logging direttamente dall'applicazione utilizzando le librerie client. Per gli ambienti temporanei, come il serverless computing, devi usare le librerie client per rendere chiamate all'API Logging.

Il servizio Google Cloud che esegue la tua applicazione supporta
stai scrivendo contenuti stdout e stderr nel tuo progetto?

Alcuni servizi Google Cloud sono completamente gestiti, quindi non è necessario utilizzare agenti per inviare log al tuo 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 di poter contare su stdout e stderr anziché utilizzare le librerie client è che gli arresti anomali dell'applicazione non si interrompono e inviare log al tuo 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 complessità, utilizzare porte aggiuntive e inviare richieste separate solo con log dell'applicazione, il che potrebbe generare uno spreco se non logaritmi.

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. Client di logging le librerie per alcuni linguaggi supportano i log di routing a stdout e stderr.

Quando esegui la tua applicazione in servizi Google Cloud che non supportano inviando automaticamente i log scritti in stdout e stderr al tuo progetto Google Cloud, puoi raccogliere stdout e stderr accedono ai file su disco e configura l'agente per eseguirne lo scraping 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 installare gli agenti per te. Se il servizio che stai utilizzando non ti consente di installare gli agenti, devi utilizzare le librerie client per utilizzare Logging.

Esegui già Fluentd nel tuo sistema?

L'agente Logging legacy è basato su Fluentd.

Se Fluentd è già in esecuzione nel tuo sistema e vuoi usa quel daemon per inviare i tuoi log a Logging, quindi utilizza plug-in di Google Cloud Logging per fluentd.

Stai raccogliendo 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.

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 la gestione di 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 per comprendere le formato personalizzato.

Riepilogo di ciascuna opzione

Diagramma dei pattern di logging

  • Librerie client di Cloud Logging

    • Vantaggi

      • Puoi eseguire il routing dei log direttamente all'API Cloud Logging.
      • Alcune lingue possono generare log in stdout e stderr utilizzando la libreria.

    • Svantaggi

      • Gli arresti anomali dell'applicazione interrompono l'invio dei log al tuo 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 in caso di 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 in caso di arresti anomali dell'applicazione.
    • Svantaggi
      • L'agente è attualmente supportato, ma non è in fase di sviluppo attivo.

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

    • Vantaggi
      • Questo processo è un modo comune per inviare log ad ambienti locali.
      • Puoi utilizzare librerie di logging arbitrarie.
      • Potresti riuscire a recuperare i log in caso di arresti anomali dell'applicazione.
    • Svantaggi
      • Non tutti gli ambienti instradano automaticamente i log a Logging.