Cosa dovresti utilizzare: agente Logging o libreria client?

Questo documento fornisce le informazioni necessarie per aiutarti a decidere se inviare in modo programmatico i log delle applicazioni a Cloud Logging utilizzando le librerie client o un agente di logging. Gli agenti Logging inviano i dati scritti a 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 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 dei file o servizi di logging noti, come Windows Event Log, journald o syslogd.

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

Scelta di un agente o di librerie client

Al momento di decidere 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 avere un modo per inviare i log all'API Logging. Per instradare i log da sistemi on-premise a Logging, ti consigliamo di utilizzare BindPlane by observIQ. Per ulteriori informazioni su BindPlane, consulta Informazioni su observIQ e BindPlane.

In alternativa, puoi eseguire il routing dei log su 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 l'applicazione supporta
come scrivere contenuti stdout e stderr nel progetto?

Alcuni servizi Google Cloud sono completamente gestiti, pertanto non è necessario utilizzare agenti per inviare log al progetto Google Cloud. Puoi utilizzare qualsiasi framework di logging stabilito nel linguaggio che preferisci, ad esempio Go, Node.js e Python, per inviare log a Logging nei prodotti in cui stdout e stderr sono supportati per impostazione predefinita. Un vantaggio nell'utilizzo di stdout e stderr anziché utilizzare le librerie client è che gli arresti anomali dell'applicazione non causano l'invio dei log al progetto. Per informazioni sull'invio di log strutturati tramite stdout e stderr, consulta la sezione La tua 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 necessario. L'utilizzo delle librerie client potrebbe anche richiedere una programmazione più complessa per gestire in modo esplicito 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 con solo i log dell'applicazione, il che potrebbe generare uno spreco di risorse se non ce ne sono molti.

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 il debug e altri scopi, puoi utilizzare i moduli di logging in alcune lingue per eseguire l'output su 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 nei servizi Google Cloud che non supportano l'invio automatico dei log scritti su stdout e stderr al tuo progetto Google Cloud, puoi raccogliere i log stdout e stderr nei file sul disco e configurare l'agente per eseguirne lo scraping e inviarli a Logging. Per ulteriori informazioni, consulta la guida alla configurazione dell'Ops Agent o dell'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 consente di installare gli agenti, devi utilizzare le librerie client per utilizzare Logging.

Stai già usando Fluentd nel tuo sistema?

L'agente Logging legacy è basato su Fluentd.

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

Stai raccogliendo metriche delle applicazioni anche per Cloud Monitoring?

Nelle VM di Compute Engine, Ops Agent può raccogliere i log e la maggior parte delle metriche. Per ulteriori informazioni, consulta 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 tue metriche.

La tua applicazione ha la flessibilità per 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 gestire questo formato.

Esistono due modi per scrivere log strutturati: uno è impostare campi specifici nella busta LogEntry, l'altro è impostare il campo jsonPayload all'interno della busta LogEntry. Lo schema per il primo è determinato da Cloud Logging, mentre lo schema per il 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 l'applicazione ha un proprio formato di log che non puoi modificare, ma vuoi che i log vengano riconosciuti come log strutturati, devi scrivere log nel 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 in modo che comprenda il tuo formato.

Riepilogo di ogni opzione

Diagramma dei pattern di logging

  • Librerie client di Cloud Logging

    • Vantaggi

      • Puoi eseguire il routing dei log direttamente sull'API Cloud Logging.
      • Alcune lingue possono eseguire l'output dei log su 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 log e metriche da molte delle applicazioni più 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.
      • L'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 stdout e stderr inviati automaticamente al tuo progetto Google Cloud

    • Vantaggi
      • Questo processo è un modo comune per emettere log in 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.