Ingestão e consulta com coletas gerenciadas e autoimplantadas
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve como configurar um ambiente que combina
coletores autoimplantados com coletores gerenciados em diferentes
projetos e clusters doGoogle Cloud .
É altamente recomendável usar a coleta gerenciada em todos os ambientes do Kubernetes. Assim, você praticamente elimina a sobrecarga de executar
coletores Prometheus no cluster.
Vale lembrar que é possível executar coletores gerenciados e autoimplantados no mesmo cluster.
É aconselhável seguir uma abordagem consistente de monitoramento, mas você pode optar por combinar os métodos de implantação em alguns casos de uso específicos (por exemplo, para hospedar um gateway push, conforme ilustrado neste documento).
O diagrama a seguir ilustra uma configuração que usa dois
projetosGoogle Cloud , três clusters e combina coleta gerenciada e
autoimplantada. O diagrama também é válido para quem usa somente a coleta gerenciada ou autoimplantada, basta ignorar os estilos de coleta que não são usados:
Para definir e usar uma configuração como a do diagrama:
É necessário instalar todos os exportadores necessários
nos clusters.
já que o Google Cloud Managed Service para Prometheus faz isso em seu nome.
O Projeto 1 tem um cluster que faz a coleta gerenciada, executado como um agente
de nó. Os coletores são configurados com recursos
PodMonitoring para fazer a raspagem de dados dos destinos
em um namespace; e com recursos
ClusterPodMonitoring
para fazer a raspagem de dados dos destinos em um cluster. Os PodMonitorings precisam ser aplicados em todos os namespaces em que você quer coletar métricas.
Já ps ClusterPodMonitorings são aplicados uma vez por cluster.
Todos os dados coletados no Projeto 1 são salvos no Monarch em
"Projeto 1". Esses dados são armazenados por padrão na região do Google Cloud
de onde foram emitidos.
O Projeto 2 tem um cluster que faz a coleta autoimplantada com prometheus-operator, executado como um serviço independente. Esse cluster é configurado para usar PodMonitors ou ServiceMonitors de prometheus-operator para fazer a raspagem de dados de exportadores de pods ou VMs.
O Projeto 2 também hospeda um arquivo secundário de gateway push para coletar métricas de
cargas de trabalho temporárias.
Todos os dados coletados no Projeto 2 são salvos no Monarch em
"Projeto 2". Esses dados são armazenados por padrão na região do Google Cloud
de onde foram emitidos.
O projeto 1 também tem um cluster que executa o Grafana e o sincronizador de fonte de dados. No exemplo, esses
componentes ficam hospedados em um cluster independente, mas podem ser hospedados em
qualquer cluster único.
O sincronizador de fonte de dados está configurado para que use scoping_project_A, e a conta de serviço subjacente tem permissões de Leitor do Monitoring para scoping_project_A.
Quando um usuário emite consultas do Grafana,
o Monarch expande scoping_project_A para os projetos monitorados
constituintes e retorna resultados para o Projeto 1 e o Projeto 2
em todas as Google Cloud regiões. Todas as métricas mantêm os identificadores originais
project_id e location (regiãoGoogle Cloud ) para
agrupamento e filtragem.
Não faça a federação ao usar o Managed Service para Prometheus.
Para reduzir a cardinalidade e o custo na "visualização completa" de dados antes de enviá-los ao Monarch, use a agregação local. Para saber mais,
consulte Configurar a agregação local.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
