Questo documento illustra le architetture di monitoraggio e logging per deployment ibridi e multi-cloud e fornisce le best practice per implementarle utilizzando Google Cloud. Questo documento ti consente di identificare i pattern e i prodotti più adatti ai tuoi ambienti.
Ogni azienda dispone di un portafoglio unico di carichi di lavoro applicativi che impongono requisiti e vincoli all'architettura di una configurazione ibrida o multi-cloud. Sebbene sia necessario progettare e personalizzare l'architettura per soddisfare questi vincoli e requisiti, puoi affidarti ad alcuni pattern comuni.
Gli schemi trattati in questo documento rientrano in due categorie:
- In un'architettura a singolo punto di osservazione, tutte le attività di monitoraggio e logging sono centralizzate, con l'obiettivo di fornire un unico punto di accesso e controllo.
- In un'architettura separata per le applicazioni e le operazioni, i dati sensibili delle applicazioni vengono separati dai dati delle operazioni meno sensibili, allo scopo di soddisfare i requisiti di conformità per i dati sensibili.
Scelta del modello di architettura
Puoi utilizzare l'albero decisionale nel diagramma seguente per identificare l'architettura migliore per il tuo caso d'uso.
I dettagli di ciascuna architettura vengono illustrati più dettagliatamente nel presente documento, ma in linea generale, le opzioni disponibili sono le seguenti:
- Esporta da Monitoring alla soluzione legacy.
- Esporta direttamente nella soluzione precedente.
- Utilizzo di Monitoring con Prometheus e Fluentd o Fluent Bit.
- Usa Monitoring con observIQ BindPlane.
Architettura a pannello centralizzato
Un obiettivo comune per un sistema ibrido è integrare le informazioni di monitoraggio e logging provenienti da varie origini in più applicazioni e ambienti in un unico display. Questo tipo di display è noto come singolo pannello di cristallo.
Il seguente diagramma illustra questo pattern in cui i dati di monitoraggio e logging di tutte le applicazioni, sia on-premise che nel cloud, sono centralizzati in un unico repository ospitato nel cloud.
Questa architettura presenta i seguenti vantaggi:
- Hai a disposizione un'unica vista coerente per tutto il monitoraggio e il logging.
- Hai un unico posto per gestire l'archiviazione e la conservazione dei dati.
- Avrai a disposizione un controllo e una verifica dell'accesso centralizzati. Tuttavia, devi comunque garantire la sicurezza dei dati in transito nel repository centrale.
Monitoraggio centralizzato
Cloud Monitoring è una soluzione di monitoraggio e gestione gestita da Google per servizi, container, applicazioni e infrastruttura. Per un'unica console di controllo e una solida soluzione di archiviazione per metriche, log, tracce ed eventi, utilizza Google Cloud Observability. La suite fornisce inoltre una suite completa di strumenti di osservabilità, come dashboard, reporting e avvisi.
Tutti i prodotti e i servizi Google Cloud supportano l'integrazione con Monitoring. Inoltre, sono disponibili 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:
- Per soddisfare i requisiti di conformità per la conservazione dei log, configura sink di log per la tua organizzazione.
- Per un'analisi rapida degli eventi dei log, configura le esportazioni dei log in BigQuery per l'analisi di sicurezza e accesso.
- Per analizzare i log archiviati nel bucket di log, esegui query SQL tramite Analisi dei log.
- Per i progetti che contengono dati sensibili, valuta la possibilità di abilitare gli audit log di accesso ai dati, in modo da poter tenere traccia di chi ha eseguito l'accesso ai dati.
- Per rimuovere informazioni sensibili come codici fiscali, numeri di carte di credito e indirizzi email, puoi filtrare i dati di log. Puoi filtrare utilizzando una configurazione Fluentd personalizzata o una configurazione di bit Fluent personalizzata oppure importare con esclusioni dei log. Puoi anche esportare i log non filtrati separatamente per soddisfare i requisiti di conformità.
- Per ottimizzare i costi, analizza l'utilizzo di Monitoring e Logging e implementa il controllo dei costi. Monitoring e Logging sono servizi gestiti con addebiti basati sul volume per log e metriche.
Monitoraggio e logging ibridi con Monitoring e BindPlane tramite observIQ
Con BindPlane del partner di Google observIQ puoi importare in Google Cloud i dati di monitoraggio e logging da VM on-premise e da 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.
Questa architettura presenta i seguenti vantaggi:
- Oltre al monitoraggio di risorse come le VM, BindPlane offre un'integrazione profonda integrata per oltre 50 origini dati popolari.
- Non sono previsti costi aggiuntivi per le licenze per l'utilizzo di BindPlane. Le metriche BindPlane vengono importate in Monitoring come metriche personalizzate, addebitabili. Allo stesso modo, ai log di BindPlane viene addebitata la stessa tariffa degli altri log di Logging.
Per ulteriori 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 nota soluzione di monitoraggio open source completamente gestita da Google Cloud, puoi monitorare le applicazioni in esecuzione su più cluster Kubernetes con Monitoring. Questa architettura è utile quando si eseguono carichi di lavoro Kubernetes distribuiti in Google Kubernetes Engine (GKE) su Google Cloud e GKE su VMware nel data center on-premise, perché fornisce un'interfaccia unificata su entrambi. Il seguente diagramma mostra come utilizzare Prometheus e i raccoglitori Monitoring per la raccolta dei dati.
Questa architettura presenta i seguenti vantaggi:
- Metriche Kubernetes coerenti in ambienti cloud e on-premise.
- Consente di monitorare e creare avvisi a livello globale sui carichi di lavoro utilizzando Prometheus, senza dover gestire e utilizzare manualmente Prometheus su larga scala.
- Non sono previsti costi aggiuntivi per le licenze per l'utilizzo di Prometheus. Le metriche di Prometheus vengono importate in Monitoring. Le importazioni sono addebitabili e il prezzo dipende dal 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, ciascuna delle quali diventa una metrica addebitabile. Per evitare costi imprevisti, valuta la possibilità di implementare il monitoraggio del controllo dei costi.
Logging di 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 in Cloud Logging. Questa architettura è utile quando si eseguono carichi di lavoro Kubernetes distribuiti su GKE su Google Cloud e su GKE on VMware nel data center on-premise, perché fornisce un'interfaccia unificata su entrambi. Il seguente diagramma illustra il flusso dei log.
Questa architettura presenta i seguenti vantaggi:
- Puoi avere logging Kubernetes coerente in ambienti cloud e on-premise.
- Puoi personalizzare Logging per filtrare le informazioni sensibili.
- Non sono previsti costi aggiuntivi per le licenze 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 ulteriori 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.
I servizi dei partner riuniti in un pannello centralizzato
Se utilizzi già un servizio di monitoraggio o logging di terze parti come Datadog o Splunk, potresti non voler passare a Logging. In tal caso, puoi esportare i dati da Google Cloud a molti servizi di monitoraggio e logging comuni. Puoi scegliere di utilizzare un servizio integrato di monitoraggio e logging o selezionare servizi di monitoraggio e logging separati, più adatti alle tue esigenze.
Esporta da Logging ai servizi partner
In questo pattern, autorizzi il servizio di monitoraggio del partner, ad esempio 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 efficiente e resiliente 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 dei partner possano gestire i log in modo pannello centralizzato.
Il diagramma seguente mostra l'architettura combinata per il logging e il monitoraggio.
Questa architettura presenta i seguenti vantaggi:
- Puoi continuare a usare gli strumenti già noti.
- 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 partner sono in genere ospitate esternamente, il che significa che potrebbero non essere disponibili o raccogliere dati in caso di interruzione delle connessioni di rete. A volte, puoi mitigare questo rischio con il self-hosting, ma a costo di dover gestire personalmente l'infrastruttura della 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 commissioni più elevate per la licenza.
Ecco alcuni esempi di integrazioni dettagliate:
- Datadog: Monitoraggio delle metriche di Compute Engine e Raccolta di log di Logging
- Elastic: Esportazione dei log di Logging in Elastic Cloud
- Splunk: scenari per l'esportazione del logging
Analizza le metriche di Prometheus e Logging con Grafana
Grafana è un noto strumento di monitoraggio open source comunemente accoppiato a Prometheus per la raccolta delle metriche. In questa architettura, viene utilizzato Prometheus come livello di raccolta on-premise e Grafana come pannello centralizzato sia per Google Cloud che per le risorse on-premise. Il seguente diagramma mostra un'architettura di esempio che analizza le metriche di Google Cloud e on-premise.
Questa architettura presenta i seguenti vantaggi:
- È adatta 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:
- Prometheus supporta solo il monitoraggio, quindi il logging deve essere configurato separatamente, ad esempio utilizzando Fluentd o il plug-in Cloud Logging per Grafana.
- Prometheus è open source ed estensibile, ma supporta solo una gamma limitata di integrazioni software aziendali.
- Prometheus e Grafana sono strumenti di terze parti e non prodotti Google ufficiali. Google non offre assistenza per Prometheus o Grafana.
Per ulteriori informazioni, consulta Risoluzione dei problemi migliore con il plug-in Cloud Logging per Grafana.
Esportare i log utilizzando Fluentd
Un pattern precedente coperto utilizzando 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.
Questa architettura presenta i seguenti vantaggi:
- È adatta 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 dei sistemi di logging e analisi dei dati di terze parti più diffusi.
- Fluent Bit può anche leggere da molti input, inclusi i log di sistema.
- Fluent Bit offre output per molti dei più diffusi sistemi di logging e analisi dei dati 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 ufficiali di Google. Google non offre assistenza in merito.
- I log esportati non sono disponibili per l'assistenza Google Cloud per la risoluzione dei problemi. In particolare, Google non offre assistenza per i cluster GKE on VMware senza Logging abilitato.
Separa i dati dell'applicazione da quelli delle operazioni
Le architetture a pannello centralizzato 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 che impongono rigide vincoli su quali dati possono essere archiviati nel cloud pubblico.
Un pattern utile per questi ambienti ibridi consiste nel separare i dati sensibili delle applicazioni dai dati delle operazioni a basso rischio, come illustrato nel diagramma di seguito.
Separa i dati delle applicazioni e del sistema con GKE Enterprise
GKE Enterprise su VMware, 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 dati sensibili delle applicazioni interamente on-premise, esportando comunque i dati di sistema in Logging su Google Cloud. Il seguente diagramma illustra questa architettura.
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 di Google Cloud, sono centralizzati in Logging e sono inoltre accessibili all'assistenza Google Cloud quando necessario.
Per un esempio di implementazione utilizzando Elastic Stack come soluzione partner, consulta Monitoraggio di GKE Enterprise con Elastic Stack.
Passaggi successivi
- Scopri di più sulle best practice per gli ambienti ibridi e multi-cloud con la serie di pattern e best practice ibridi e multi-cloud, tra cui pattern di architettura e pattern di architettura di networking sicuri.
- Iscriviti alla Quest delle best practice di Cloud Kubernetes per esercizi pratici sull'osservabilità e altro ancora su GKE.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.