Exécuter en dehors de Google Cloud
Si votre cluster ne s'exécute pas dans Google Cloud, vous devez configurer manuellement les valeurs des libellés project_id
et location
. Nous vous recommandons de suivre les conseils suivants :
Définissez
project_id
en fonction de la compatibilité de ce cluster avec votre modèle de surveillance mutualisé. Votre compte de service doit être configuré avec les autorisations appropriées pour l'élémentproject_id
choisi.Définissez
location
en fonction de la région Google Cloud la plus proche de votre déploiement.
Vous ne pouvez pas réécrire ces libellés à l'aide d'une règle de réécriture de libellé.
Votre organisation compte plus de 1 000 projets
Le nombre maximal de projets compatibles dans un champ d'application de métriques est de 375, mais le nombre maximal de projets non compatibles dans un champ d'application de métriques est de 1 000.
Si vous avez plus de 1 000 projets, la solution recommandée consiste à configurer vos collecteurs pour qu'ils utilisent un project_id
central au lieu de l'ID du projet dans lequel ils s'exécutent. Les métriques de tous vos projets sont ensuite stockées dans Monarch sous cet ID de projet central. Vous pouvez simplement placer le projet central dans un champ d'application des métriques.
Si vous utilisez cette approche, tenez compte des inconvénients potentiels suivants:
- Vous perdez un peu de précision pour l'architecture mutualisée, car les autorisations ne peuvent être définies qu'au niveau du projet. Vous pouvez regrouper logiquement des projets dans quelques catégories et utiliser un projet central différent pour chacun d'eux.
- La valeur
project_id
des métriques système de Google Cloud ne peut pas être remplacée. Cette solution de contournement ne vous permet pas d'afficher des métriques Google Kubernetes Engine gratuites dans le projet central, car ces métriques restent dans chaque projet d'origine. - L'utilisation d'un projet central peut compliquer votre utilisation des règles et des règles de cluster, car ces règles sont appliquées au projet dans lequel elles sont installées et qu'il est peu probable que vous disposiez du même ensemble de noms de cluster et d'espace de noms dans chaque projet. Vous devrez peut-être utiliser les règles globales à la place.
Localiser les données manuellement dans une seule région Google Cloud
Par défaut, le service géré pour Prometheus stocke les données dans la région Google Cloud d'où elles proviennent et les requêtes sont naturellement globales, ce qui signifie que vous n'avez pas besoin de colocaliser les données géographiquement pour effectuer des requêtes sur des données dans plusieurs régions Google Cloud.
Dans la plupart des cas, ce comportement par défaut est suffisant. Toutefois, dans certains cas, vous pouvez souhaiter stocker toutes les données de métriques dans une seule région Google Cloud, par exemple si vous vous trouvez dans un environnement hautement réglementé.
Pour stocker toutes les données de métriques dans une seule région, configurez vos collecteurs pour qu'ils utilisent un seul location
au lieu de l'emplacement détecté automatiquement du cluster dans lequel ils s'exécutent.
Le stockage de données dans une seule région Google Cloud peut compliquer votre utilisation des règles et des règles de cluster, car elles s'appliquent à l'emplacement où elles sont installées. Il est peu probable que vous disposiez du même ensemble de noms de cluster et d'espaces de noms dans chaque région Google Cloud. Vous devrez peut-être utiliser les règles globales à la place.