Importazione e query con raccolte gestite e con deployment autonomo
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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 con deployment autonomo nello stesso cluster.
Ti consigliamo di utilizzare un approccio coerente al monitoraggio, ma puoi scegliere di combinare i metodi di implementazione 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 progettiGoogle Cloud , tre cluster e combina collezioni gestite e di autodeployment. Se utilizzi solo raccolte gestite o di cui hai eseguito il deployment autonomo, il diagramma è comunque applicabile; ignora lo stile di raccolta che non utilizzi:
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 esportatori 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 le risorse PodMonitoring per eseguire lo scraping dei target all'interno di uno spazio dei nomi e con le 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 le 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 Google Cloud regione
da cui sono stati emessi.
Il progetto 2 ha un cluster che esegue la raccolta con deployment automatico utilizzando prometheus-operator e funziona 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 workload temporanei.
Tutti i dati raccolti nel Progetto 2 vengono salvati in Monarch nella sezione Progetto 2. Questi dati vengono archiviati per impostazione predefinita nella Google Cloud regione
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, questi componenti sono ospitati in un cluster autonomo, ma possono essere ospitati in qualsiasi 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 esegue 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 le etichette project_id e location (regioneGoogle Cloud ) originali ai fini di raggruppamento e applicazione di filtri.
Non eseguire la federazione quando utilizzi Managed Service per Prometheus.
Per ridurre la cardinalità e i costi "aggregando" i dati prima di inviarli a Monarch, utilizza l'aggregazione locale. Per ulteriori informazioni, consulta Configurare l'aggregazione locale.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["# Ingestion and querying with managed and self-deployed collection\n\nThis document describes how you might set up an environment that mixes\nself-deployed collectors with managed collectors, across different\nGoogle Cloud projects and clusters.\n\nWe strongly recommend using managed collection for all Kubernetes\nenvironments; doing so practically eliminates the overhead of running\nPrometheus collectors within your cluster.\nYou can run managed and self-deployed collectors within the same cluster.\nWe recommend using a consistent approach to monitoring, but you might choose\nto mix deployment methods for some specific use cases, such as hosting a\npush gateway, as illustrated in this document.\n\nThe following diagram illustrates a configuration that uses two\nGoogle Cloud projects, three clusters, and mixes managed and self-deployed\ncollection. If you use only managed or self-deployed collection, then the\ndiagram is still applicable; just ignore the collection style you aren't using:\n\nTo set up and use a configuration like the one in the diagram, note the\nfollowing:\n\n- You must install any necessary [exporters](https://prometheus.io/docs/instrumenting/exporters/)\n in your clusters.\n Google Cloud Managed Service for Prometheus does not install any exporters on your behalf.\n\n- Project 1 has a cluster running managed collection, which runs as a node\n agent. Collectors are configured with\n [PodMonitoring](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#podmonitoring) resources to scrape\n targets within a namespace and with\n [ClusterPodMonitoring](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterpodmonitoring) resources\n to scrape targets across a cluster. PodMonitorings must be applied in\n every namespace in which you want to collect metrics.\n ClusterPodMonitorings are applied once per cluster.\n\n All data collected in Project 1 is saved in Monarch under\n Project 1. This data is stored by default in the Google Cloud region\n from which it emitted.\n- Project 2 has a cluster running self-deployed collection using\n prometheus-operator and running as a standalone service. This cluster\n is configured to use prometheus-operator PodMonitors or ServiceMonitors\n to scrape exporters on pods or VMs.\n\n Project 2 also hosts a push gateway sidecar to gather metrics from\n ephemeral workloads.\n\n All data collected in Project 2 is saved in Monarch under\n Project 2. This data is stored by default in the Google Cloud region\n from which it emitted.\n- Project 1 also has a cluster running [Grafana](/stackdriver/docs/managed-prometheus/query#ui-grafana) and the\n [data source syncer](/stackdriver/docs/managed-prometheus/query#grafana-oauth). In this example, these\n components are hosted in a standalone cluster, but they can be hosted in\n any single cluster.\n\n The data source syncer is configured to use scoping_project_A,\n and its underlying service account has [Monitoring Viewer](/monitoring/access-control#mon_roles_desc)\n permissions for scoping_project_A.\n\n When a user issues queries from Grafana,\n Monarch expands scoping_project_A into its constituent\n monitored projects and returns results for both Project 1 and Project 2\n across all Google Cloud regions. All metrics retain their original\n `project_id` and `location` (Google Cloud region) labels for\n grouping and filtering purposes.\n\nIf your cluster is not running inside Google Cloud, you must manually\nconfigure the `project_id` and `location` labels. For information about setting\nthese values, see [Run Managed Service for Prometheus outside of\nGoogle Cloud](/stackdriver/docs/managed-prometheus/setup-unmanaged#gmp-outside-gcp).\n\n**Do not federate when using Managed Service for Prometheus.**\nTo reduce cardinality and cost by \"rolling up\" data before sending it to\nMonarch, use local aggregation instead. For more information,\nsee [Configure local aggregation](/stackdriver/docs/managed-prometheus/cost-controls#local-aggregation)."]]
