Ingestion et interrogation avec une collection gérée et auto-déployée
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document explique comment configurer un environnement combinant des collecteurs autodéployés avec des collecteurs gérés, sur différents projets Google Cloud et clusters.
Nous vous recommandons vivement d'utiliser la collecte gérée pour tous les environnements Kubernetes. Cela permet d'éliminer pratiquement les frais généraux liés à l'exécution des collecteurs Prometheus dans votre cluster.
Vous pouvez exécuter des collecteurs gérés et auto-déployés dans le même cluster.
Nous vous recommandons d'adopter une approche cohérente pour la surveillance, mais vous pouvez choisir de combiner des méthodes de déploiement pour certains cas d'utilisation spécifiques, tels que l'hébergement d'une passerelle d'envoi, comme illustré dans ce document.
Le schéma suivant illustre une configuration qui utilise deux projets Google Cloud, trois clusters et un mélange de collection gérée et auto-déployée. Si vous n'utilisez que des collections gérées ou auto-déployées, le schéma reste applicable : Il vous suffit d'ignorer le style de collection que vous n'utilisez pas :
Pour réaliser et utiliser une configuration comme celle du diagramme, notez les points suivants :
Vous devez installer les exportateurs nécessaires dans vos clusters.
Le service géré Google Cloud pour Prometheus n'installe aucun exportateur en votre nom.
Le projet 1 possède un cluster exécutant la collection gérée, qui s'exécute en tant qu'agent de nœud. Les collecteurs sont configurés avec des ressources PodMonitoring pour scraper des cibles dans un espace de noms et avec des ressources ClusterPodMonitoring pour scraper des cibles dans un cluster. Les éléments PodMonitorings doivent être appliqués dans chaque espace de noms dans lequel vous souhaitez collecter des métriques.
Les ClusterPodMonitorings sont appliqués une fois par cluster.
Toutes les données collectées dans le projet 1 sont enregistrées dans Monarch sous le projet 1. Ces données sont stockées par défaut dans la région Google Cloud à partir de laquelle elles ont été émises.
Le projet 2 comporte un cluster exécutant une collection auto-déployée à l'aide de l'opérateur Prometheus et s'exécutant en tant que service autonome. Ce cluster est configuré pour utiliser des PodMonitors ou des ServiceMonitors de Prometheus-opérateur pour scraper des exportateurs sur des pods ou des VM.
Le projet 2 héberge également une passerelle side-car push pour collecter des métriques de charges de travail éphémères.
Toutes les données collectées dans le projet 2 sont enregistrées dans Monarch sous le projet 2. Ces données sont stockées par défaut dans la région Google Cloud à partir de laquelle elles ont été émises.
Le projet 1 contient également un cluster exécutant Grafana et le synchronisateur de sources de données. Dans cet exemple, ces composants sont hébergés dans un cluster autonome, mais ils peuvent être hébergés dans n'importe quel cluster.
Le synchronisateur de sources de données est configuré pour utiliser scoping_project_A, et son compte de service sous-jacent dispose des autorisations du rôle Lecteur Monitoring pour scoping_project_A.
Lorsqu'un utilisateur émet des requêtes depuis Grafana, Monarch développe le projet scoping_project_A dans ses projets surveillés constitutifs et renvoie les résultats du projet 1 et du projet 2 dans toutes les régions Google Cloud. Toutes les métriques conservent leurs libellés project_id et location d'origine (région Google Cloud) à des fins de regroupement et de filtrage.
Si votre cluster ne s'exécute pas dans Google Cloud, vous devez configurer manuellement les libellés project_id et location. Pour en savoir plus sur la définition de ces valeurs, consultez la page Exécuter le service géré pour Prometheus en dehors de Google Cloud.
Ne fédérez pas lorsque vous utilisez le service géré pour Prometheus.
Pour réduire la cardinalité et les coûts en "consolidant" des données avant de les envoyer à Monarch, utilisez plutôt l'agrégation locale. Pour en savoir plus, consultez la section Configurer l'agrégation locale.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/12/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/12/05 (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)."]]
