Questo documento descrive come configurare un ambiente che combina raccoglitori di cui è stato eseguito il deployment autonomamente con raccoglitori gestiti, in diversi progetti e cluster Google Cloud.
Consigliamo vivamente di utilizzare la raccolta gestita per tutti gli ambienti Kubernetes; in questo modo si elimina praticamente l'overhead associato all'esecuzione dei raccoglitori Prometheus all'interno del cluster. Puoi eseguire raccoglitori gestiti e con deployment autonomo all'interno dello stesso cluster. Consigliamo di utilizzare un approccio coerente al monitoraggio, ma potresti scegliere di combinare metodi di deployment per alcuni casi d'uso specifici, come l'hosting di un gateway push, come illustrato in questo documento.
Il seguente diagramma illustra una configurazione che utilizza due progetti Google Cloud, tre cluster e combina una raccolta gestita e con deployment autonomo. Se utilizzi solo una raccolta gestita o con deployment autonomo, lo schema è comunque applicabile. Ignora semplicemente lo stile della raccolta che non stai utilizzando:
Per impostare e utilizzare una configurazione come quella nel diagramma, tieni presente quanto segue:
Devi installare tutti gli esportatori necessari nei tuoi cluster. Google Cloud Managed Service per Prometheus non installa alcun esportatore per tuo conto.
Il progetto 1 ha un cluster che esegue una raccolta gestita che viene eseguita come agente nodo. I raccoglitori sono configurati con risorse PodMonitoring per eseguire lo scraping dei target all'interno di uno spazio dei nomi e con risorse ClusterPodMonitoring per eseguire lo scraping dei target in un cluster. I podMonitoring devono essere applicati a ogni spazio dei nomi in cui vuoi raccogliere le metriche. I ClusterPodMonitoring vengono applicati una volta per cluster.
Tutti i dati raccolti nel progetto 1 vengono salvati in Monarch nel progetto 1. Questi dati vengono archiviati per impostazione predefinita nella regione Google Cloud da cui sono stati emessi.
Il progetto 2 ha un cluster che esegue una raccolta con deployment autonomo utilizzando prometheus-operator ed è in esecuzione come servizio autonomo. Questo cluster è configurato per utilizzare Prometheus-operator PodMonitors o ServiceMonitors per eseguire lo scraping dei dati degli esportatori su pod o VM.
Il progetto 2 ospita anche un gateway push per il gateway per raccogliere metriche dai carichi di lavoro temporanei.
Tutti i dati raccolti nel progetto 2 vengono salvati in Monarch nel progetto 2. Questi dati vengono archiviati per impostazione predefinita nella regione Google Cloud da cui sono stati emessi.
Il progetto 1 include inoltre un cluster che esegue Grafana e il sincronizzatore dell'origine dati. In questo esempio, questi componenti sono ospitati in un cluster autonomo, ma possono essere ospitati in qualsiasi singolo cluster.
Il sincronizzazione dell'origine dati è configurato per utilizzare ambiting_project_A e l'account di servizio sottostante dispone delle autorizzazioni Visualizzatore Monitoring per l'ambito_project_A.
Quando un utente invia query da Grafana, Monarch espande l'ambitong_project_A nei progetti monitorati e restituisce i risultati per il progetto 1 e il progetto 2 in tutte le regioni di Google Cloud. Tutte le metriche mantengono le etichette originali
project_idelocation(regione di Google Cloud) a scopo di raggruppamento e filtro.
Se il cluster non è in esecuzione in Google Cloud, devi configurare manualmente le etichette project_id e location. Per informazioni sull'impostazione di questi valori, consulta Eseguire Managed Service per Prometheus al di fuori di Google Cloud.
Non eseguire la federazione quando utilizzi Managed Service per Prometheus. Per ridurre la cardinalità e i costi tramite l'"aggregazione" dei dati prima di inviarli a Monarch, utilizza invece l'aggregazione locale. Per ulteriori informazioni, consulta la sezione Configurare l'aggregazione locale.