Quale metodo devi utilizzare: agente Logging o libreria client?

Questo documento fornisce le informazioni di cui hai bisogno per decidere se inviare in modo programmatico i log delle applicazioni a Cloud Logging mediante le librerie client o un agente di logging. Gli agenti Logging inviano dati scritti in un file, ad esempio stdout o in un file, come log a Cloud Logging. Servizi quali Google Kubernetes Engine, l'ambiente flessibile di App Engine e Cloud Functions contengono un agente di logging integrato. Per Compute Engine, puoi installare Ops Agent o l'agente Cloud Logging legacy. Questi agenti raccolgono i log da posizioni di file o servizi di logging noti come Windows Event Log, journald o syslogd.

Se non puoi utilizzare una libreria client o un agente Logging, o se vuoi solo sperimentare, puoi scrivere i log utilizzando il comando gcloud logging write o inviando comandi HTTP all'endpoint dell'API Cloud Logging entries.write. L'API Cloud Logging supporta le chiamate HTTP e gRPC. Ops Agent e la maggior parte delle librerie client di Logging chiamano l'API gRPC Logging. Le librerie client e l'agente Logging legacy per alcuni linguaggi chiamano l'API REST Logging.

Scelta di un agente o delle librerie client

Quando devi decidere tra un agente e le librerie client, rispondi alle seguenti domande:

La tua applicazione è in esecuzione al di fuori di Google Cloud?

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

In alternativa, puoi eseguire il routing dei log a Logging direttamente dall'applicazione utilizzando le librerie client. Per gli ambienti temporanei, come il serverless computing, devi utilizzare le librerie client per effettuare chiamate dirette 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 gli 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 log ad Logging nei prodotti in cui stdout e stderr sono supportati per impostazione predefinita. Un vantaggio di fare affidamento su stdout e stderr invece di utilizzare le librerie client è che gli arresti anomali dell'applicazione non interrompono l'invio dei log al tuo progetto. Per informazioni sull'invio di log strutturati tramite stdout e stderr, consulta la sezione L'applicazione ha la flessibilità di modificare il formato dei log?.

Puoi utilizzare le librerie client di Logging, ma tieni presente che potrebbe introdurre una dipendenza su Logging per i test locali quando non ti serve necessariamente. L'uso delle librerie client potrebbe anche richiedere una programmazione più complessa per gestire esplicitamente il buffering e i nuovi tentativi. Inoltre, ogni utilizzo delle librerie client di Logging crea un nuovo flusso di connessione all'API. Queste nuove connessioni introducono una maggiore complessità, utilizzano porte aggiuntive e inviano richieste separate solo con i log dell'applicazione, il che potrebbe essere uno spreco se non ci sono molti log.

I log delle applicazioni devono essere accessibili nel tuo ambiente locale?

Se hai bisogno di accedere ai log dell'applicazione nel tuo ambiente locale per eseguire il debug e per altri scopi, puoi utilizzare i moduli di logging in alcuni linguaggi per inviare l'output a stdout e stderr. Le librerie client di Logging per alcune lingue supportano il routing dei log a stdout e stderr.

Quando esegui la tua 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 su disco e configurare l'agente per eseguire lo scraping dei log e inviarli a Logging. Per ulteriori informazioni, consulta la guida alla configurazione per Ops Agent o per l'agente Logging legacy.

Il processo di installazione dell'agente è manuale o automatico?

Alcuni servizi installano gli agenti automaticamente o ti consentono di installarli autonomamente. Se il servizio che stai utilizzando non ti consente di installare gli agenti, devi utilizzare le librerie client per utilizzare Logging.

Usi già Fluentd nel tuo sistema?

L'agente Logging legacy è basato su Fluentd.

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

Stai raccogliendo anche le metriche delle applicazioni per Cloud Monitoring?

Nelle VM di Compute Engine, Ops Agent può raccogliere i log e la maggior parte delle metriche. Per ulteriori informazioni, consulta le funzionalità di Ops Agent.

Se Ops Agent non si occupa dei tuoi casi d'uso, puoi utilizzare l'agente Monitoring legacy o le librerie client di Monitoring per raccogliere le metriche.

La tua applicazione ha la flessibilità di modificare il formato di 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 consiste nell'impostare campi specifici nella busta LogEntry, l'altro nel 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 in modo da 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 in formato di logging strutturato, di solito JSON, in stdout e stderr, in modo che gli agenti possano riconoscerli come log strutturati. In caso contrario, devi configurare l'agente per comprendere il tuo formato.

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.
      • Alcuni linguaggi possono inviare 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.