Questo documento descrive come configurare un ambiente che combina i collector di cui è stato eseguito il deployment autonomo con i collector gestiti in diversi progetti e cluster Google Cloud.
Ti consigliamo vivamente di utilizzare la raccolta gestita per tutti gli ambienti Kubernetes. In questo modo, elimini praticamente il sovraccarico di esecuzione dei collezionisti Prometheus all'interno del cluster. Puoi eseguire raccoglitori gestiti e di cui è stato eseguito il deployment autonomo all'interno dello stesso cluster. Consigliamo di utilizzare un approccio coerente al monitoraggio, ma potresti scegliere in modo da combinare metodi di deployment per alcuni casi d'uso specifici, ad esempio l'hosting come illustrato in questo documento.
Il seguente diagramma illustra una configurazione che utilizza due progetti Google Cloud, tre cluster e un mix di soluzioni gestite e di cui è stato eseguito il deployment autonomo . Se utilizzi solo una raccolta gestita o di cui è stato eseguito il deployment autonomo, è ancora applicabile; ignora lo stile di raccolta che non stai utilizzando:
Per configurare e utilizzare una configurazione come quella nel diagramma, tieni presente quanto segue:
Devi installare eventuali 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 la raccolta gestita, che viene eseguita come agente del nodo. I raccoglitori sono configurati con Risorse PodMonitoring di cui eseguire lo scraping target all'interno di uno spazio dei nomi e Risorse ClusterPodMonitoring per eseguire lo scraping dei target in un cluster. I PodMonitoring devono essere applicati in ogni spazio dei nomi in cui vuoi raccogliere metriche. I controlli ClusterPodMonitoring vengono applicati una volta per cluster.
Tutti i dati raccolti nel Progetto 1 vengono salvati in Monarch nella sezione 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 di cui è stato eseguito il deployment autonomo utilizzando operatore Prometheus e in esecuzione come servizio autonomo. Questo cluster è configurato per utilizzare PodMonitor o ServiceMonitor di prometheus-operator per eseguire lo scraping degli esportatori su pod o VM.
Il progetto 2 ospita anche un sidecar del gateway push per raccogliere le metriche dai carichi di lavoro effimeri.
Tutti i dati raccolti nel Progetto 2 vengono salvati in Monarch nella sezione Progetto 2. Questi dati vengono archiviati per impostazione predefinita nella regione Google Cloud da cui sono stati emessi.
Il progetto 1 ha anche un cluster su cui sono in esecuzione Grafana e il sincronizzatore delle origini dati. In questo esempio, sono ospitati in un cluster autonomo, ma possono essere in un singolo cluster.
Il sincronizzatore delle origini dati è configurato per utilizzare scoping_project_A e il relativo account di servizio sottostante dispone delle autorizzazioni Visualizzatore monitoraggio per scoping_project_A.
Quando un utente invia query da Grafana, Monarch espande scoping_project_A nei progetti monitorati costituenti e restituisce risultati sia per il progetto 1 sia per il progetto 2 in tutte le regioni Google Cloud. Tutte le metriche mantengono lo stato originale Etichette
project_idelocation(regione Google Cloud) per a scopo di raggruppamento e filtro.
Se il cluster non è in esecuzione all'interno di Google Cloud, devi manualmente
configurare 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 federare quando utilizzi Managed Service per Prometheus. Per ridurre la cardinalità e i costi mediante "aggregazione" prima di inviarli al Monarch, utilizza l'aggregazione locale. Per ulteriori informazioni, consulta Configurare l'aggregazione locale.