Transferencia y consultas con recopilación administrada y autoimplementada
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se describe cómo puedes configurar un entorno que combine recopiladores
autoimplementados con recopiladores administrados en diferentes
clústeres y proyectos deGoogle Cloud .
Te recomendamos que uses la recopilación administrada para todos los entornos de Kubernetes.
Así, prácticamente se elimina la sobrecarga que implica ejecutar
recopiladores de Prometheus dentro del clúster.
Puedes ejecutar recopiladores administrados y autoimplementados dentro del mismo clúster.
Te recomendamos que uses un enfoque coherente en la supervisión, pero puedes optar por combinar métodos
de implementación para algunos casos de uso específicos, como alojar
una puerta de enlace de envío, como se muestra en este documento.
En el siguiente diagrama, se ilustra una configuración en la que se usan dos
proyectos deGoogle Cloud , tres clústeres y una combinación de recopilación administrada y
autoimplementada. Si usas solo la recopilación administrada o la autoimplementada, el
diagrama seguirá siendo aplicable. Tan solo ignora el estilo de recopilación que no vayas a usar:
Para configurar y usar una configuración como la del diagrama, ten en cuenta
lo siguiente:
Debes instalar cualquier exportador
necesario en los clústeres.
Google Cloud Managed Service para Prometheus no instala ningún exportador por ti.
El proyecto 1 tiene un clúster que ejecuta una recopilación administrada, que se ejecuta como un agente
de nodo. Los recopiladores se configuran con
recursos de PodMonitoring para recopilar destinos dentro de un espacio de nombres y con recursos de ClusterPodMonitoring para recopilar destinos en un clúster. Los PodsMonitoring deben aplicarse
en cada espacio de nombres en el que quieras recopilar métricas.
Los ClusterPodMonitoring se aplican una vez por clúster.
Todos los datos recopilados en el proyecto 1 se guardan en Monarch en el
proyecto 1. Estos datos se almacenan de forma predeterminada en la
región de Google Cloud desde la que se emiten.
El proyecto 2 tiene un clúster que ejecuta la recopilación autoimplementada
con prometheus-operator y se ejecuta como un servicio independiente. Este clúster
está configurado para usar ServiceMonitors o PodMonitors de prometheus-operator con el objetivo de recopilar los exportadores en Pods o VMs.
El proyecto 2 también aloja un sidecar de puerta de enlace de envío para recopilar métricas
de cargas de trabajo efímeras.
Todos los datos recopilados en el proyecto 2 se guardan dentro de Monarch en el
proyecto 2. Estos datos se almacenan de forma predeterminada en la
región de Google Cloud desde la que se emiten.
El proyecto 1 también tiene un clúster que ejecuta Grafana y el
sincronizador de fuentes de datos. En este ejemplo, estos
componentes se alojan en un clúster independiente, pero se pueden alojar en
cualquier clúster único.
El sincronizador de fuentes de datos está configurado para usar scoping_project_A,
y su cuenta de servicio subyacente tiene los permisos de visualizador de Monitoring
para scoping_project_A.
Cuando un usuario emite consultas desde Grafana,
Monarch expande scoping_project_A a sus proyectos
supervisados constituyentes y muestra resultados para los proyectos 1 y 2
en todas las regiones de Google Cloud . Todas las métricas conservan sus etiquetas originales
project_id y location (región deGoogle Cloud ) para
agrupación y filtrado.
Si el clúster no se ejecuta dentro de Google Cloud, debes configurar de forma manual
las etiquetas de project_id y location. Para obtener información sobre cómo configurar
estos valores, consulta Ejecuta Managed Service para Prometheus fuera de
Google Cloud.
No realices la federación cuando uses Managed Service para Prometheus.
Para reducir la cardinalidad y los costos “agregando” datos antes de enviarlos a
Monarch, usa la agregación local en su lugar. Para obtener más información,
consulta Configura la agregación local.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
