Questo documento illustra le architetture di monitoraggio e logging per i deployment ibridi e multicloud e fornisce le best practice per implementarle utilizzando Google Cloud. Con questo documento puoi identificare i pattern e i prodotti più adatti ai tuoi ambienti.
Ogni azienda ha un portafoglio unico di carichi di lavoro delle applicazioni che impongono requisiti e vincoli all'architettura di una configurazione ibrida o multi-cloud. Anche se devi progettare e personalizzare l'architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni.
Gli schemi trattati in questo documento rientrano in due categorie:
- In un'architettura single pane of glass, tutto il monitoraggio e la registrazione sono centralizzati, con l'obiettivo di fornire un unico punto di accesso e controllo.
- In un'architettura separata per applicazioni e operazioni, i dati sensibili delle applicazioni vengono separati dai dati operativi meno sensibili, con lo scopo di soddisfare i requisiti di conformità per i dati sensibili.
Scelta del pattern di architettura
Puoi utilizzare l'albero decisionale nel seguente diagramma per identificare l'architettura migliore per il tuo caso d'uso.
I dettagli di ogni architettura sono descritti più dettagliatamente in questo documento, ma a livello generale le tue scelte sono le seguenti:
- Esporta da Monitoring alla soluzione precedente.
- Esporta direttamente nella soluzione precedente.
- Utilizza il monitoraggio con Prometheus e Fluentd o Fluent Bit.
- Utilizza il monitoraggio con observIQ BindPlane.
Architettura a pannello unico
Un obiettivo comune di un sistema ibrido è integrare le informazioni di monitoraggio e registrazione provenienti da varie origini in più applicazioni ed ambienti in un'unica visualizzazione. Questo tipo di visualizzazione è chiamato pannello centralizzato.
Il seguente diagramma illustra questo modello in cui i dati di monitoraggio e registrazione 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 una singola visualizzazione coerente per tutto il monitoraggio e il logging.
- Hai un unico posto in cui gestire lo spazio di archiviazione e la conservazione dei dati.
- Puoi usufruire di controllo dell'accesso e auditing centralizzati. Tuttavia, devi comunque garantire la sicurezza dei dati in transito verso il repository centrale.
Monitoraggio da un'pannello centralizzato
Cloud Monitoring è una soluzione di monitoraggio e gestione gestita da Google per servizi, container, applicazioni e infrastruttura. Per una singola dashboard e una soluzione di archiviazione solida per metriche, log, tracce ed eventi, utilizza Google Cloud Observability. 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, sono disponibili diversi strumenti integrati che puoi utilizzare per estendere il monitoraggio alle risorse on-premise e ibride.
Le seguenti best practice si applicano a tutte le architetture che utilizzano il monitoraggio come un pannello centralizzato:
- Per soddisfare i requisiti di conformità per la conservazione dei log, configura i canali di log per la tua organizzazione.
- Per un'analisi rapida degli eventi dei log, configura le esportazioni dei log in BigQuery per analisi di sicurezza e accesso.
- Per analizzare i log archiviati nel bucket di log, esegui query SQL tramite Analisi dei log.
- Per i progetti contenenti dati sensibili, ti consigliamo di attivare gli audit log di accesso ai dati per monitorare 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 dei log. Puoi filtrare utilizzando una configurazione Fluent Bit personalizzata o importando con esclusioni dei log. Puoi anche esportare i log non filtrati separatamente per soddisfare i requisiti di conformità.
Monitoraggio e logging ibridi con Monitoring e BindPlane di observIQ
Con BindPlane di observIQ, partner di Google, puoi importare i dati di monitoraggio e logging sia dalle VM on-premise sia da altri fornitori di servizi cloud, come Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud e IBM Cloud in Google Cloud. Il seguente diagramma mostra come Monitoring e BindPlane possono fornire un unico pannello per un cloud ibrido.
Questa architettura presenta i seguenti vantaggi:
- Oltre a monitorare risorse come le VM, BindPlane offre un'integrazione approfondita integrata per oltre 50 origini dati comuni.
- Non sono previsti costi di licenza aggiuntivi per l'utilizzo di BindPlane. Le metriche di BindPlane vengono importate in Monitoring come metriche personalizzate, che sono addebitabili. Analogamente, i log di BindPlane vengono addebitati allo stesso prezzo 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 popolare 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 per l'esecuzione di carichi di lavoro Kubernetes distribuiti su Google Kubernetes Engine (GKE) suGoogle Cloud e Google Distributed Cloud nel tuo data center on-premise, perché fornisce un'interfaccia unificata per entrambi. Il seguente diagramma mostra come utilizzare Prometheus e i collector di monitoraggio per la raccolta dei dati.
Questa architettura presenta i seguenti vantaggi:
- Metriche Kubernetes coerenti in ambienti cloud e on-premise.
- Ti consente di monitorare e creare avvisi sui tuoi 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 viene calcolato in base al numero di campioni importati.
Questa architettura presenta i seguenti svantaggi:
- Prometheus supporta solo il monitoraggio, pertanto il logging deve essere configurato distintamente. La sezione seguente illustra un'opzione comune per la registrazione 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, valuta la possibilità di implementare i controlli dei costi di monitoraggio.
Log GKE ibrido con Fluentd o Fluent Bit e Cloud Logging
Con Fluentd o Fluent Bit, un agente di logging open source molto diffuso, e Cloud Logging, puoi importare i log dalle applicazioni in esecuzione su più cluster GKE in Cloud Logging. Questa architettura è utile per l'esecuzione di carichi di lavoro Kubernetes distribuiti su GKE su Google Cloud e su Google Distributed Cloud nel tuo data center on-premise, in quanto fornisce un'interfaccia unificata per entrambi. Il seguente diagramma illustra il flusso dei log.
Questa architettura presenta i seguenti vantaggi:
- Puoi avere un logging Kubernetes coerente negli ambienti cloud e on-premise.
- Puoi personalizzare la registrazione per filtrare le informazioni sensibili.
- Non sono previsti costi aggiuntivi per l'utilizzo di Fluentd o Fluent Bit. I log che vengono importati in Logging utilizzando Fluentd o Fluent Bit sono pagabili.
Questa architettura presenta i seguenti svantaggi:
- Fluentd e Fluent Bit supportano solo il logging, pertanto 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 di Fluent Bit per i log di Google Kubernetes Engine.
Servizi partner come pannelli centralizzati
Se utilizzi già un servizio di monitoraggio o registrazione di terze parti come Datadog o Splunk, potresti non voler passare a Logging. In questo caso, puoi esportare i dati da Google Cloud in molti servizi comuni di monitoraggio e logging. Puoi scegliere di utilizzare un servizio di monitoraggio e logging integrato o selezionare servizi di monitoraggio e logging separati che si adattano meglio alle tue esigenze.
Esportazione 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 il logging, in modo che Datadog possa funzionare come un pannello centralizzato per il monitoraggio.
Per i dati di log, Logging fornisce esportazioni (sink di log) in Pub/Sub. Queste esportazioni forniscono un metodo efficace e resiliente per i servizi di logging dei partner, come Elastic e Splunk, per importare in tempo reale grandi volumi di log da Logging, in modo che questi servizi partner possano offrire un pannello centralizzato per i log.
L'architettura combinata per il logging e il monitoraggio è mostrata nel seguente diagramma.
Questa architettura presenta i seguenti vantaggi:
- Puoi continuare a utilizzare gli strumenti esistenti di cui hai dimestichezza.
- L'assistenzaGoogle Cloud continua ad avere accesso ai log di registrazione 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 se le connessioni di rete vengono interrotte. A volte puoi mitigare questo rischio con l'hosting autonomo, ma con il costo aggiuntivo di dover gestire autonomamente l'infrastruttura per la soluzione.
- Le dashboard ospitate esternamente non sono disponibili direttamente per l'assistenza diGoogle Cloud . Questa mancanza di disponibilità può rallentare la risoluzione dei problemi e la mitigazione.
- Le soluzioni dei partner commerciali potrebbero comportare un aumento delle tariffe di licenza.
Ecco alcuni esempi dettagliati di integrazioni:
- Datadog: monitoraggio delle metriche di Compute Engine e raccolta dei log di Logging
- Elastic: Esportazione dei log di Logging in Elastic Cloud
- Splunk: Scenari per l'esportazione dei log
Analizza le metriche di Prometheus e del logging con Grafana
Grafana è uno strumento di monitoraggio open source molto utilizzato, spesso associato a Prometheus per la raccolta delle metriche. In questa architettura, utilizzi Prometheus come livello di raccolta on-premise e Grafana come un'pannello centralizzato sia perGoogle Cloud sia 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:
- È 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:
- Prometheus supporta solo il monitoraggio, pertanto 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 di software aziendale.
- Prometheus e Grafana sono strumenti di terze parti e non prodotti ufficiali di Google. Google non offre assistenza per Prometheus o Grafana.
Per ulteriori informazioni, consulta Migliorare la risoluzione dei problemi con un 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 analisi dei dati o di registrazione che supportano Fluentd o Fluent Bit, tra cui BigQuery, Elastic e Splunk. Il seguente diagramma illustra questo pattern.
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 sistemi di analisi dei dati e di registrazione di terze parti molto diffusi.
- Fluent Bit può anche leggere da molti input, inclusi i log di sistema.
- Fluent Bit offre output per molti sistemi di analisi dei dati e di registrazione di terze parti molto diffusi.
Questa architettura presenta i seguenti svantaggi:
- Fluentd e Fluent Bit supportano solo i log, pertanto il monitoraggio deve essere configurato distintamente. 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 Google. Google non offre assistenza per questi prodotti.
- I log esportati non sono disponibili per l'assistenza di Google Cloud per la risoluzione dei problemi. In particolare, Google non offre assistenza per i cluster Google Distributed Cloud senza il logging abilitato.
Dati separati per applicazioni e operazioni
Le architetture di monitoraggio centralizzato richiedono il monitoraggio delle applicazioni in streaming e la registrazione dei dati nel cloud. Tuttavia, potresti avere requisiti normativi o di conformità che richiedono di mantenere i dati dei clienti on-premise o impongono vincoli rigorosi sui dati che possono essere archiviati nel cloud pubblico.
Un pattern utile per questi ambienti ibridi è separare i dati delle applicazioni sensibili dai dati delle operazioni a rischio più basso, come illustrato nel seguente diagramma.
Separare i dati di sistema e dell'applicazione con GKE Enterprise
GKE Enterprise on VMware, che fa parte della suite GKE Enterprise, include Grafana per il monitoraggio dei cluster on-premise. Inoltre, puoi scegliere di installare una soluzione di partner come Elastic Stack o Splunk per la registrazione. Con queste soluzioni, puoi importare e visualizzare i dati delle applicazioni sensibili interamente on-premise, continuando a esportare i dati di sistema in Logging suGoogle 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 dal cloud e rimangono disponibili anche se la connessione di rete viene interrotta.
- Tutti i dati di sistema di GKE, sia on-premise che su Google Cloud, sono centralizzati in Logging e sono anche accessibili all'assistenza di Google Cloud in base alle esigenze.
Per un esempio di implementazione che utilizza Elastic Stack come soluzione partner, consulta Monitoraggio di GKE Enterprise con Elastic Stack.
Passaggi successivi
- Scopri di più sulle best practice ibride e multi-cloud con la serie Modelli e best practice ibride e multi-cloud, inclusi modelli di architettura e modelli di architettura di rete sicura.
- Registrati alla quest sulle best practice di Kubernetes su Cloud per esercizi pratici sull'osservabilità e altro su GKE.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.