Questo documento illustra le architetture di monitoraggio e logging per ambienti ibridi e deployment multi-cloud e fornisce le best practice per implementarli mediante utilizzando Google Cloud. Con questo documento, puoi identificare pattern e prodotti sono 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. Sebbene sia necessario 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 a singolo punto di osservazione, tutte le attività di monitoraggio e logging 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 per il tuo caso d'uso.
I dettagli di ciascuna architettura vengono discussi più in dettaglio in questo documento, ma nel dettaglio di alto livello, le opzioni 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 monitoraggio e logging informazioni da varie origini in diversi ambienti e applicazioni in un'unica visualizzazione. Questo tipo di display è noto come singolo punto di osservazione.
Il seguente diagramma illustra questo pattern in cui il monitoraggio e il logging i dati 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 gestita da Google per il monitoraggio e la gestione di servizi, container applicazioni e infrastruttura. Per una singola e una solida soluzione di archiviazione metriche, log, tracce ed eventi utilizzano Google Cloud Observability. La offre inoltre una suite completa di strumenti di osservabilità, come dashboard, generazione di 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 sink di log per la tua organizzazione.
- Per un'analisi rapida degli eventi dei log, configura esportazioni dei log in BigQuery per l'analisi dei dati e della sicurezza.
- 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 di Fluent Bit personalizzata oppure importazione con esclusioni dei log. Puoi anche esportare i log non filtrati separatamente per soddisfare i requisiti di conformità.
- Per ottimizzare i tuoi costi, analizzare l'utilizzo di Monitoring e Logging. 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 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 aggiuntivi per le licenze per l'utilizzo di BindPlane. Le metriche BindPlane vengono importate in Monitoring come metriche, che sono addebitabile. Allo stesso modo, i log di BindPlane vengono addebitati alla stessa tariffa degli altri Logging dei log.
Per ulteriori dettagli sull'implementazione di questo pattern, vedi 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 monitoraggio. Questa architettura è utile quando si esegue Kubernetes di lavoro distribuiti in Google Kubernetes Engine (GKE) Google Cloud e Google Distributed Cloud nel tuo data center on-premise perché fornisce un'interfaccia unificata su 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. Prometeo vengono importate in Monitoring. Le importazioni sono addebitabile 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 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 logging Kubernetes coerente nel cloud e on-premise ambienti cloud-native.
- Puoi personalizzare Logging per filtrare i dati sensibili informazioni.
- Non sono previsti costi aggiuntivi per le licenze 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, quindi il monitoraggio configurati separatamente. La sezione precedente illustra un'opzione comune per il monitoraggio con Prometheus.
Per ulteriori dettagli sull'implementazione di questo pattern, vedi 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 logging di terze parti come Datadog o Splunk, potresti non voler passare a Logging. Se per consentirti di esportare i dati da Google Cloud a 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.
Esporta 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 il logging dei partner servizi come Elastico e Splunk importare grandi volumi di log da Logging in tempo reale, questi servizi partner sono in grado di gestire i log in modo centralizzato.
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 Logging dei log 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 il self-hosting, ma il costo necessario per gestire autonomamente l'infrastruttura della 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 commissioni più elevate per la licenza.
Ecco alcuni esempi di integrazioni dettagliate:
- Datadog: Monitoraggio delle metriche di Compute Engine e Raccolta dei log di logging
- Elastico: 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 un'architettura di esempio che analizza le metriche di Google Cloud 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 configurati separatamente, ad esempio utilizzando Flessibili o il plug-in Cloud Logging per Grafana.
- Prometheus è open source ed estensibile, ma supporta solo gamma limitata di integrazioni software aziendali.
- 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, vedi Risoluzione dei problemi migliorata 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 la stessa architettura di base può essere utilizzata anche per altre attività 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 molti 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 opzioni comuni per 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 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 di conformità requisiti che richiedono di conservare i dati dei clienti on-premise vincoli rigidi ai dati che possono essere archiviati nel cloud pubblico.
Un pattern utile per questi ambienti ibridi è quello di 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 su VMware, 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. Utilizzo queste soluzioni, puoi importare e visualizzare completamente i dati sensibili delle applicazioni on-premise, continuando a esportare i dati di sistema in Logging in 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 rimangono disponibili anche se la connessione di rete si interrompe.
- Tutti i dati di sistema GKE, sia on-premise Google Cloud, è centralizzato in Logging ed è anche accessibili all'assistenza Google Cloud in base alle esigenze.
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 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. Dai un'occhiata al nostro Centro architetture cloud.