Questo documento illustra le architetture di monitoraggio e logging per i 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 delle applicazioni che Requisiti e vincoli dell'architettura di un ambiente ibrido o multi-cloud configurazione. 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, dei dati delle applicazioni vengono separati da quelli delle operazioni meno sensibili, l'obiettivo di soddisfare i requisiti di conformità per i dati sensibili.
Scelta del modello 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 legacy.
- Esporta direttamente nella soluzione precedente.
- Utilizza il monitoraggio con Prometheus e Fluentd o Fluent Bit.
- Utilizza il monitoraggio con observIQ BindPlane.
Architettura a pannello centralizzato
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 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, garantire la sicurezza dei dati in transito verso il repository centrale.
Monitoraggio centralizzato
Cloud Monitoring è una soluzione di monitoraggio e gestione gestita da Google per servizi, container, applicazioni e infrastruttura. Per una singola e una solida soluzione di archiviazione metriche, log, tracce ed eventi utilizzano Google Cloud Observability. La suite fornisce inoltre una suite completa di strumenti di osservabilità, come dashboard, report e avvisi.
Tutti i prodotti e servizi Google Cloud supportano l'integrazione con Monitoraggio. Inoltre, esistono diversi strumenti integrati puoi utilizzare per estendere Monitoring agli ambienti ibridi e on-premise Google Cloud.
Le seguenti best practice si applicano a tutte le architetture che utilizzano Monitoraggio centralizzato:
- Per soddisfare i requisiti di conformità per la conservazione dei log, configura i sink di log per dell'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 mediante Analisi dei log.
- Per i progetti contenenti dati sensibili, valuta la possibilità di abilitare Audit log degli accessi ai dati per tenere traccia di chi ha avuto accesso ai dati.
- Per rimuovere informazioni sensibili come codici fiscali, informazioni 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 tramite observIQ
Con BindPlane del partner di Google observIQ, puoi importare i dati di monitoraggio e logging sia da VM on-premise che da altre con provider cloud quali Amazon Web Services (AWS), Microsoft Azure e Alibaba Cloud e IBM Cloud in Google Cloud. Il seguente diagramma mostra come Monitoring e BindPlane possono fornire un singolo riquadro per un cloud ibrido.
Questa architettura presenta i seguenti vantaggi:
- Oltre a monitorare risorse come le VM, BindPlane dispone di strumenti per una profonda integrazione più di 50 origini dati molto utilizzate.
- Non sono previsti costi di licenza aggiuntivi per l'utilizzo di BindPlane. Le metriche BindPlane vengono importate in Monitoring come metriche, che sono addebitabile. 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) su Google Cloud e Google Distributed Cloud nel data center on-premise, poiché fornisce un'interfaccia unificata per entrambi. Il seguente diagramma mostra come utilizzare Prometheus e i raccoglitori Monitoring per i 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. 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 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, implementazione Monitoraggio del controllo dei costi.
Logging di GKE ibrido con Fluentd o Fluent Bit e Cloud Logging
Con Flessibili o bit fluido, 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 in GKE su Google Cloud Google Distributed Cloud nel tuo data center on-premise, perché fornisce un'interfaccia unificata. Il seguente diagramma illustra il flusso logaritmi.
Questa architettura presenta i seguenti vantaggi:
- Puoi avere un logging Kubernetes coerente negli ambienti cloud e on-premise.
- Puoi personalizzare Logging per filtrare i dati sensibili informazioni.
- Non sono previsti costi aggiuntivi per l'utilizzo di Fluentd o Fluent Bit. Diari importati in Logging utilizzando Fluentd o Fluent I bit sono addebitabile.
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.
I servizi dei partner riuniti in un pannello centralizzato
Se utilizzi già un servizio di monitoraggio o registrazione di terze parti come Datadog o Splunk, potresti non voler passare a Logging. Se per consentirti di esportare i dati da Google Cloud in molti sistemi di monitoraggio servizi di logging. Puoi scegliere di utilizzare un monitoraggio e un logging integrati o selezionare servizi di monitoraggio e logging separati, più adatti alle tue e alle esigenze aziendali.
Esportazione da Logging ai servizi partner
Con questo pattern, autorizzi il servizio di monitoraggio del partner, Datadog per la connessione all'API Cloud Monitoring. Questa autorizzazione consente al servizio di importare tutte le metriche disponibili per Logging, quindi Datadog può 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 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 unico punto di accesso per i log.
Di seguito è riportata l'architettura combinata per il logging e il monitoraggio. in questo diagramma.
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 dei partner sono generalmente ospitate esternamente, il che significa che potrebbero non essere disponibili o raccogliere dati se le connessioni di rete sono disastrose. 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 assistenza Google Cloud. La mancanza di disponibilità può rallentare la risoluzione dei problemi e la mitigazione dei rischi.
- Le soluzioni dei partner commerciali potrebbero comportare un aumento delle tariffe di licenza.
Ecco alcuni esempi di integrazioni dettagliate:
- 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 di Logging
Analizza le metriche di Prometheus e Logging con Grafana
Grafana è un noto strumento di monitoraggio open source, Prometheus per la raccolta delle metriche. In questa architettura, viene usato Prometheus on-premise e usare Grafana come pannello centralizzato per Google Cloud e 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 sono strumenti prodotti di big data e machine learning. 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:
- È adatta per ambienti ibridi con VM e container.
- Fluentd può leggere da molte origini dati, inclusi i log di sistema.
- Offerte Fluentd plug-in di output per molti dei più diffusi sistemi di logging e analisi dei dati di terze parti.
- Fluent Bit può anche leggere da molti input, inclusi i log di sistema.
- Offerte Fluent Bit 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 per questi prodotti.
- I log esportati non sono disponibili per l'assistenza Google Cloud per risoluzione dei problemi. Nello specifico, Google non offre per Google Distributed Cloud di cluster senza Logging abilitato.
Separa i dati dell'applicazione da quelli delle operazioni
Le architetture a pannello centralizzato richiedono il monitoraggio delle applicazioni in modalità flusso e il logging 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 sensibili dei dati dell'applicazione da quelli delle operazioni a basso rischio, come illustrato nel seguente diagramma.
Separa i dati delle applicazioni e del sistema 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 attivare per installare una soluzione partner come Elastic Stack o Splunk per il logging. Con queste soluzioni, puoi importare e visualizzare i dati delle applicazioni sensibili interamente on-premise, continuando a esportare 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 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 inoltre accessibili all'Assistenza Google Cloud, se necessario.
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 per gli ambienti ibridi e multi-cloud con il Pattern e pratiche ibridi e multi-cloud tra cui pattern di architettura e modelli di architettura di rete sicura.
- Iscriviti al Quest delle best practice per 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. Consulta il nostro Cloud Architecture Center.