Pattern di logging e monitoraggio per cloud ibrido e multi-cloud

Last reviewed 2023-03-29 UTC

Questo documento illustra le architetture di monitoraggio e logging per i deployment ibridi e multi-cloud e fornisce le best practice per implementarli utilizzando Google Cloud. Questo documento ti consente di identificare quali pattern e prodotti sono più adatti ai tuoi ambienti.

Ogni azienda ha un portafoglio unico di carichi di lavoro delle applicazioni che pone requisiti e vincoli nell'architettura di una configurazione ibrida o multi-cloud. Anche se devi progettare e personalizzare l'architettura per soddisfare questi vincoli e requisiti, puoi affidarti ad alcuni pattern comuni.

Gli schemi presentati in questo documento rientrano in due categorie:

  • Il monitoraggio e il logging sono centralizzati in un'unica architettura unica, con l'obiettivo di fornire un unico punto di accesso e controllo.
  • In un'architettura di applicazioni e operazioni separate, i dati sensibili delle applicazioni vengono separati da quelli delle operazioni meno sensibili, con l'obiettivo di soddisfare i requisiti di conformità per i dati sensibili.

Scegliere il modello di architettura

Puoi utilizzare la struttura decisionale nel seguente diagramma per identificare l'architettura migliore per il tuo caso d'uso.

Albero decisionale per la selezione di un'architettura di monitoraggio e logging.

I dettagli di ogni architettura vengono discussi più in dettaglio in questo documento ma, a livello generale, le scelte sono le seguenti:

  • Esporta da Monitoring alla soluzione legacy.
  • Esporta direttamente nella soluzione legacy.
  • Utilizza il monitoraggio con Prometheus e Fluentd o Fluent Bit.
  • Utilizza Monitoring con observIQ BindPlane.

Architettura centralizzata

Un obiettivo comune di un sistema ibrido è integrare le informazioni di monitoraggio e logging provenienti da varie origini, su più applicazioni e ambienti, in un'unica visualizzazione. Questo tipo di display viene chiamato singolo punto di osservazione.

Il seguente diagramma illustra questo pattern, in cui il monitoraggio e il logging dei dati di tutte le applicazioni, sia on-premise che nel cloud, sono centralizzati in un unico repository ospitato nel cloud.

Architettura di alto livello per il monitoraggio e il logging.

Questa architettura presenta i seguenti vantaggi:

  • Hai un'unica visualizzazione coerente per tutto il monitoraggio e il logging.
  • Hai un unico posto per gestire l'archiviazione e la conservazione dei dati.
  • Hai a disposizione controllo e controllo degli accessi centralizzati. Tuttavia, devi comunque garantire la sicurezza dei dati in transito nel repository centrale.

Monitoraggio come un pannello centralizzato

Cloud Monitoring è una soluzione di monitoraggio e gestione gestita da Google per servizi, container, applicazioni e infrastruttura. Utilizza l'osservabilità di Google Cloud per avere un pannello centralizzato e una solida soluzione di archiviazione per metriche, log, tracce ed eventi. La suite fornisce inoltre una suite completa di strumenti di osservabilità, come dashboard, report e avvisi.

Tutti i prodotti e i servizi Google Cloud supportano l'integrazione con Monitoring. Inoltre, esistono diversi strumenti integrati che puoi utilizzare per estendere Monitoring alle risorse ibride e on-premise.

Le seguenti best practice si applicano a tutte le architetture che utilizzano Monitoring come un pannello centralizzato:

Monitoraggio e logging ibridi con Monitoring e BindPlane per observIQ

Con BindPlane del partner di Google observIQ, puoi importare in Google Cloud i dati di monitoraggio e logging da VM on-premise e altri cloud provider, come Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud e IBM Cloud. Il seguente diagramma mostra come Monitoring e BindPlane possono fornire un pannello centralizzato per un cloud ibrido.

Architettura di alto livello per il monitoraggio e il logging con BindPlane e Monitoring.

Questa architettura presenta i seguenti vantaggi:

Per maggiori dettagli sull'implementazione di questo pattern, consulta Logging e monitoraggio delle risorse on-premise con BindPlane.

Monitoraggio ibrido di Google Kubernetes Engine con Prometheus e Monitoring

Con Google Cloud Managed Service per Prometheus, una popolare soluzione di monitoraggio open source completamente gestita da Google Cloud, puoi monitorare le applicazioni in esecuzione su più cluster Kubernetes mediante Monitoring. Questa architettura è utile durante l'esecuzione di carichi di lavoro Kubernetes distribuiti tra Google Kubernetes Engine (GKE) su Google Cloud e GKE su VMware nel tuo data center on-premise, perché fornisce un'interfaccia unificata su entrambi. Il seguente diagramma mostra come utilizzare Prometheus e i raccoglitori di Monitoring per la raccolta dei dati.

Architettura di alto livello per il monitoraggio di GKE con Prometheus e Monitoring.

Questa architettura presenta i seguenti vantaggi:

  • Metriche Kubernetes coerenti in ambienti cloud e on-premise.
  • Consente di monitorare e creare avvisi sui carichi di lavoro a livello globale utilizzando Prometheus, senza dover gestire e utilizzare manualmente Prometheus su larga scala.
  • Non sono previsti costi di licenza aggiuntivi per l'utilizzo di Prometheus. Le metriche di Prometheus vengono importate in Monitoring. Le importazioni sono addebitabili e il prezzo è determinato in base al numero di campioni importati.

Questa architettura presenta i seguenti svantaggi:

  • Prometheus supporta solo il monitoraggio, quindi il logging deve essere configurato separatamente. La seguente sezione illustra un'opzione comune per il logging utilizzando Fluentd o Fluent Bit.

Consigliamo la seguente best practice:

  • Per impostazione predefinita, Prometheus raccoglie tutte le metriche esposte, ognuna delle quali diventa una metrica addebitabile. Per evitare costi imprevisti, ti consigliamo di implementare il monitoraggio dei controlli dei costi.

Logging GKE ibrido con Fluentd o Fluent Bit e Cloud Logging

Con Fluentd o Fluent Bit, un noto agente di logging open source e Cloud Logging, puoi importare i log dalle applicazioni in esecuzione su più cluster GKE a Cloud Logging. Questa architettura è utile durante l'esecuzione di carichi di lavoro Kubernetes distribuiti tra GKE su Google Cloud e GKE su VMware nel tuo data center on-premise, perché fornisce un'interfaccia unificata su entrambi. Il seguente diagramma illustra il flusso dei log.

Architettura di alto livello per il monitoraggio di GKE con Fluentd o Fluent Bit, Monitoring e Logging.

Questa architettura presenta i seguenti vantaggi:

  • Puoi ottenere logging Kubernetes coerente in ambienti cloud e on-premise.
  • Puoi personalizzare Logging per filtrare le informazioni sensibili.
  • Non sono previsti costi di licenza aggiuntivi per l'utilizzo di Fluentd o Fluent Bit. I log importati in Logging utilizzando Fluentd o Fluent Bit sono addebitabili.

Questa architettura presenta i seguenti svantaggi:

  • Fluentd e Fluent Bit supportano solo il logging, quindi il monitoraggio deve essere configurato separatamente. La sezione precedente illustra un'opzione comune per il monitoraggio con Prometheus.

Per maggiori dettagli sull'implementazione di questo pattern, consulta Personalizzazione dei log di Logging per Google Kubernetes Engine con Fluentd o Personalizzazione dei log di Logging per Google Kubernetes Engine con Fluent Bit.

Servizi dei partner come singoli pannelli di vetro

Se utilizzi già un servizio di monitoraggio o logging di terze parti come Datadog o Splunk, ti consigliamo di non passare a Logging. In tal caso, puoi esportare i dati da Google Cloud a molti dei servizi di monitoraggio e logging comuni. Puoi scegliere di utilizzare un servizio integrato di monitoraggio e logging oppure selezionare servizi di monitoraggio e logging separati più adatti alle tue esigenze.

Esporta da Logging nei servizi partner

Con questo pattern, autorizzi il servizio di monitoraggio del partner, come Datadog, a connettersi all'API Cloud Monitoring. Questa autorizzazione consente al servizio di importare tutte le metriche disponibili per Logging, in modo che Datadog possa funzionare come un pannello centralizzato per il monitoraggio.

Per i dati di logging, Logging fornisce esportazioni (sink di log) in Pub/Sub. Queste esportazioni forniscono un metodo resiliente e dalle prestazioni elevate per i servizi di logging dei partner come Elastic e Splunk per importare grandi volumi di log da Logging in tempo reale, in modo che questi servizi partner possano gestire un pannello centralizzato per i log.

L'architettura combinata per il logging e il monitoraggio è mostrata nel seguente schema.

Architettura di alto livello per l'esportazione dei dati di monitoraggio e logging nei servizi dei partner.

Questa architettura presenta i seguenti vantaggi:

  • Puoi continuare a usare gli strumenti che già conosci.
  • L'assistenza Google Cloud continua ad avere accesso ai log di Logging per la risoluzione dei problemi.

Questa architettura presenta i seguenti svantaggi:

  • Le soluzioni dei partner sono generalmente ospitate esternamente, ossia potrebbero non essere disponibili né raccogliere dati in caso di interruzione delle connessioni di rete. A volte è possibile mitigare questo rischio con l'hosting autonomo, ma a scapito della necessità di mantenere personalmente l'infrastruttura per la soluzione.
  • Le dashboard ospitate esternamente non sono disponibili direttamente per l'assistenza Google Cloud. Questa mancanza di disponibilità può rallentare la risoluzione dei problemi e la mitigazione.
  • Le soluzioni dei partner commerciali potrebbero comportare costi aggiuntivi per la licenza.

Ecco alcuni esempi di integrazioni dettagliate:

Analizza le metriche di Prometheus e Logging con Grafana

Grafana è un popolare strumento di monitoraggio open source comunemente abbinato a Prometheus per la raccolta di metriche. In questa architettura, utilizzi Prometheus come livello di raccolta on-premise e Grafana come pannello centralizzato per le risorse Google Cloud e on-premise. Il seguente diagramma mostra un'architettura di esempio che analizza le metriche di Google Cloud e on-premise.

Architettura di alto livello per il monitoraggio utilizzando Grafana come un pannello centralizzato.

Questa architettura presenta i seguenti vantaggi:

  • È adatto per ambienti ibridi con VM e container.
  • Se la tua organizzazione utilizza già Prometheus e Grafana, i tuoi utenti possono continuare a utilizzarli.

Questa architettura presenta i seguenti svantaggi:

Per maggiori informazioni, consulta Risoluzione dei problemi migliorata con un plug-in Cloud Logging per Grafana.

Esporta i log utilizzando Fluentd

Un pattern precedente coperto da Fluentd o Fluent Bit come raccoglitore di log per Logging. La stessa architettura di base può essere utilizzata anche per altri sistemi di logging o analisi dei dati che supportano Fluentd o Fluent Bit, tra cui BigQuery, Elastic e Splunk. Il seguente diagramma illustra questo modello.

Architettura di alto livello dell'esportazione di log direttamente da Fluentd o Fluent Bit.

Questa architettura presenta i seguenti vantaggi:

  • È adatto per ambienti ibridi con VM e container.
  • Fluentd può leggere da molte origini dati, inclusi i log di sistema.
  • Fluentd offre plug-in di output per molti noti sistemi di analisi dei dati e di logging di terze parti.
  • Fluent Bit può anche leggere da molti input, inclusi i log di sistema.
  • Fluent Bit offre output per molti noti sistemi di analisi dei dati e di logging di terze parti.

Questa architettura presenta i seguenti svantaggi:

  • Fluentd e Fluent Bit supportano solo i log, quindi il monitoraggio deve essere configurato separatamente. La sezione precedente illustra le opzioni comuni per il monitoraggio con Prometheus e Grafana.
  • Fluentd e Fluent Bit sono strumenti di terze parti e non prodotti Google ufficiali. Google non offre assistenza in merito.
  • I log esportati non sono disponibili per la risoluzione dei problemi per l'assistenza Google Cloud. In particolare, Google non offre assistenza per cluster GKE su VMware senza Logging abilitato.

Separa i dati delle applicazioni e delle operazioni

Le architetture a pannello singolo richiedono il flusso di dati di monitoraggio e logging delle applicazioni nel cloud. Tuttavia, potresti avere requisiti normativi o di conformità che richiedono di mantenere i dati dei clienti on-premise o di imporre vincoli rigidi ai dati che possono essere archiviati nel cloud pubblico.

Un modello utile per questi ambienti ibridi è separare i dati sensibili delle applicazioni da quelli delle operazioni a basso rischio, come illustrato nel diagramma seguente.

Architettura di alto livello per la separazione dei dati delle applicazioni e delle operazioni.

Separa i dati dell'applicazione e del sistema con GKE Enterprise

GKE Enterprise su VMware, una parte della suite GKE Enterprise, include Grafana per il monitoraggio dei cluster on-premise. Inoltre, puoi scegliere di installare una soluzione partner come Elastic Stack o Splunk per il logging. Utilizzando queste soluzioni, puoi importare e visualizzare i dati sensibili delle applicazioni interamente on-premise, continuando a esportare i dati di sistema in Logging su Google Cloud. Il diagramma seguente illustra questa architettura.

Separazione dei dati dell'applicazione e del sistema con GKE Enterprise.

Questa architettura presenta i seguenti vantaggi:

  • I dati sensibili delle applicazioni vengono conservati interamente on-premise.
  • Il monitoraggio e il logging on-premise non hanno dipendenze cloud e rimangono disponibili anche se la connessione di rete viene interrotta.
  • Tutti i dati di sistema GKE, sia on-premise che su Google Cloud, sono centralizzati in Logging e sono anche accessibili all'Assistenza Google Cloud in base alle esigenze.

Per un esempio di implementazione utilizzando Elastic Stack come soluzione del partner, consulta Monitoraggio di GKE Enterprise con Elastic Stack.

Passaggi successivi