Questo documento descrive come configurare un ambiente che combina di raccoglitori auto-distribuiti con raccoglitori gestiti, in diversi di progetti e cluster Google Cloud.
Consigliamo vivamente di utilizzare la raccolta gestita per tutte le risorse Kubernetes ambienti cloud-native; In questo modo si elimina praticamente il problema della gestione Collettori Prometheus all'interno del tuo 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 i metodi di implementazione 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 impostare e utilizzare una configurazione come quella nel diagramma, tieni presente seguenti:
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 nodo un agente. 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 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 di Google Cloud da cui è stata emessa.
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 in modo da usare PodMonitors o ServiceMonitors dell'operatore prometheus per eseguire lo scraping dei dati degli esportatori su pod o VM.
Il progetto 2 ospita anche un file collaterale gateway push per raccogliere metriche carichi di lavoro temporanei.
Tutti i dati raccolti nel progetto 2 vengono salvati in Monarch in Progetto 2. Questi dati vengono archiviati per impostazione predefinita nella regione di Google Cloud da cui è stata emessa.
Il progetto 1 include anche un cluster che esegue Grafana sincronizzatore dell'origine dati. In questo esempio, sono ospitati in un cluster autonomo, ma possono essere in un singolo cluster.
Lo strumento di sincronizzazione dell'origine dati è configurato per utilizzare ambiting_project_A, e l'account di servizio sottostante ha un visualizzatore Monitoring le autorizzazioni per progetto_ambito_A.
Quando un utente invia query a Grafana, Monarch espande il progettong_ambito_A nel suo costituente progetti monitorati e restituisce i risultati sia per il Progetto 1 che per il Progetto 2 in tutte le regioni di 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
questi valori, vedi Eseguire Managed Service for Prometheus al di fuori
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.