Configurations inhabituelles

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ément project_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.