In questo documento vengono descritte le architetture di monitoraggio e logging per deployment ibridi e multi-cloud e vengono fornite 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. Sebbene tu debba progettare e adattare la tua architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni.
I pattern trattati in questo documento rientrano in due categorie:
- In un'architettura single pane of glass, tutto il monitoraggio e la registrazione vengono 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 sono separati dai dati meno sensibili delle operazioni, con l'obiettivo di soddisfare i requisiti di conformità per i dati sensibili.
Scegliere il pattern dell'architettura
Puoi utilizzare l'albero decisionale nel seguente diagramma per identificare l'architettura migliore per il tuo caso d'uso.
I dettagli di ciascuna architettura vengono discussi più avanti in questo documento, ma a livello generale, le tue 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 a pannello centralizzato
Un obiettivo comune per un sistema ibrido è integrare le informazioni di monitoraggio e logging provenienti da varie fonti in più applicazioni e ambienti in un'unica visualizzazione. Questo tipo di visualizzazione è chiamato pannello centralizzato.
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 una visualizzazione singola e coerente per tutto il monitoraggio e il logging.
- Hai un unico posto in cui gestire l'archiviazione e la conservazione dei dati.
- Ottieni il controllo dell'accesso e l'audit centralizzati. Tuttavia, devi comunque garantire la sicurezza dei dati in transito al repository centrale.
Monitoraggio centralizzato
Cloud Monitoring è una soluzione di monitoraggio e gestione gestita da Google per servizi, container, applicazioni e infrastruttura. Per un unico pannello e una soluzione di archiviazione solida per metriche, log, tracce ed eventi, utilizza Google Cloud Observability. La suite fornisce anche una suite completa di strumenti di osservabilità, come dashboard, report e avvisi.
Tutti Google Cloud i prodotti e i servizi 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 pannello centralizzato:
- Per soddisfare i requisiti di conformità per la conservazione dei log, configura i 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 della sicurezza e dell'accesso.
- Per analizzare i log archiviati nel bucket di log, esegui query SQL tramite Analisi dei log.
- Per i progetti contenenti dati sensibili, valuta la possibilità di attivare i log di controllo dell'accesso ai dati, in modo da poter monitorare chi ha avuto 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 l'importazione 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 del partner di Google observIQ, puoi importare dati di monitoraggio e logging da VM on-premise e da altri provider 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 profonda e integrata per oltre 50 origini dati popolari.
- 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 addebbitabili. Allo stesso modo, i log BindPlane vengono addebitati alla stessa tariffa degli altri log 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 quando si eseguono 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 raccoglitori Monitoring 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 relativo prezzo viene calcolato in base al numero di campioni importati.
Questa architettura presenta i seguenti svantaggi:
- Prometheus supporta solo il monitoraggio, pertanto la registrazione deve essere configurata separatamente. La sezione seguente descrive 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.
Logging GKE ibrido con Fluentd o Fluent Bit e Cloud Logging
Con Fluentd o Fluent Bit, un popolare 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 esegui carichi di lavoro Kubernetes distribuiti su GKE su Google Cloud e Google Distributed Cloud nel tuo data center on-premise, perché 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 in ambienti cloud e on-premise.
- Puoi personalizzare la registrazione 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 a pagamento.
Questa architettura presenta i seguenti svantaggi:
- Fluentd e Fluent Bit supportano solo la registrazione, pertanto il monitoraggio deve essere configurato separatamente. La sezione precedente descrive 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 logging di terze parti come Datadog o Splunk, potresti non voler passare a Logging. In questo caso, puoi esportare i dati da Google Cloud a molti servizi comuni di monitoraggio e logging. Puoi scegliere di utilizzare un servizio di monitoraggio e logging integrato oppure selezionare servizi di monitoraggio e logging separati che soddisfino al meglio le tue esigenze.
Esportare 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 partner possano fungere da 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 che conosci.
- Google Cloud L'assistenza 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 a costo di dover gestire personalmente l'infrastruttura della soluzione.
- Le dashboard ospitate esternamente non sono disponibili direttamente per Google Cloud l'assistenza. Questa mancanza di disponibilità può rallentare la risoluzione dei problemi e la mitigazione.
- Le soluzioni dei partner commerciali potrebbero comportare ulteriori tariffe per licenza.
Di seguito sono riportati 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 di Logging
Analizzare le metriche di Prometheus e Logging con Grafana
Grafana è uno strumento di monitoraggio open source molto diffuso, spesso abbinato a Prometheus per la raccolta delle metriche. In questa architettura, utilizzi Prometheus come livello di raccolta on-premise e Grafana come pannello centralizzato per le risorseGoogle Cloud e 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 ad 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 Google ufficiali. Google non offre assistenza per Prometheus o Grafana.
Per saperne di più, consulta Risoluzione dei problemi più efficace con un plug-in Cloud Logging per Grafana.
Esportare i log utilizzando Fluentd
Un pattern precedente prevedeva l'utilizzo di 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 pattern.
Questa architettura presenta i seguenti vantaggi:
- È adatto ad 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 logging di terze parti popolari.
- 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 logging di terze parti popolari.
Questa architettura presenta i seguenti svantaggi:
- Fluentd e Fluent Bit supportano solo i log, pertanto il monitoraggio deve essere configurato separatamente. La sezione precedente descrive 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 per questi dispositivi.
- I log esportati non sono disponibili per l'assistenza Google Cloud per la risoluzione dei problemi. In particolare, Google non offre supporto per i cluster Google Distributed Cloud senza Logging abilitato.
Dati separati di applicazioni e operazioni
Le architetture centralizzate richiedono il monitoraggio delle applicazioni di streaming e la registrazione dei dati nel cloud. Tuttavia, potresti avere requisiti normativi o di conformità che richiedono di conservare i dati dei clienti on-premise o che 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 basso rischio, come illustrato nel seguente diagramma.
Separare i dati di sistema e delle applicazioni con un'architettura ibrida e multi-cloud
Per monitorare i cluster on-premise, puoi utilizzare strumenti open source come Prometheus e Grafana. Per raccogliere e instradare i dati di telemetria, puoi utilizzare una soluzione come OpenTelemetry Collector o observIQ BindPlane. Questi strumenti ti consentono di configurare l'importazione e la visualizzazione dei dati sensibili delle applicazioni interamente on-premise, ad esempio in una soluzione di monitoraggio e logging self-hosted. Puoi esportare dati di sistema meno sensibili in Monitoring e 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 la registrazione on-premise non hanno dipendenze dal cloud e rimangono disponibili anche se la connessione di rete viene interrotta.
- Tutti i dati di sistema GKE, sia on-premise che Google Cloud, sono centralizzati in Monitoring e Logging e sono anche accessibili all'assistenza Google Cloud , se necessario.
Passaggi successivi
- Scopri di più sulle best practice ibride e multi-cloud con la serie Hybrid and multicloud patterns and practices, inclusi i modelli di architettura e i modelli di architettura di rete sicura.
- Iscriviti alla quest Cloud Kubernetes Best Practice per esercizi pratici su osservabilità e altro ancora su GKE.
- Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.