Évaluation des règles et des alertes avec une collection gérée
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document décrit une configuration pour l'évaluation des règles et des alertes dans un déploiement de service géré pour Prometheus utilisant une collection gérée.
Le schéma suivant illustre un déploiement qui utilise plusieurs clusters dans deux Google Cloud projets et utilise à la fois l'évaluation des règles et des alertes, ainsi que la ressource GlobalRules facultative:
Pour configurer et utiliser un déploiement comme celui du diagramme, notez les points suivants:
L'évaluateur de règles géré est automatiquement déployé dans tout cluster sur lequel la collection gérée est exécutée. Ces évaluateurs sont configurés comme suit:
Utilisez les ressources Règles pour exécuter des règles sur les données d'un espace de noms. Les ressources de règles doivent être appliquées à chaque espace de noms dans lequel vous souhaitez exécuter la règle.
Utilisez les ressources ClusterRules pour exécuter des règles sur les données d'un cluster. Les ressources ClusterRules doivent être appliquées une fois par cluster.
Toutes les évaluations de règles s'exécutent sur le datastore global Monarch.
Les ressources de règles filtrent automatiquement les règles en fonction du projet, de l'emplacement, du cluster et de l'espace de noms dans lesquels elles sont installées.
Les ressources ClusterRules filtrent automatiquement les règles en fonction du projet, de l'emplacement et du cluster dans lesquels elles sont installées.
Tous les résultats de la règle sont écrits dans Monarch après l'évaluation.
Une instance Prometheus AlertManager est déployée manuellement dans chaque cluster. Les évaluateurs de règles gérées sont configurés en modifiant la ressource OperatorConfig pour envoyer les règles d'alerte déclenchées à leur instance AlertManager locale. Les workflows de silence, d'accusé de réception et de gestion des incidents sont généralement gérés dans un outil tiers tel que PagerDuty.
Vous pouvez centraliser la gestion des alertes sur plusieurs clusters en un seul gestionnaire d'alertes à l'aide d'une ressource Endpoints Kubernetes.
Le schéma précédent montre également la ressource facultative GlobalRules.
Utilisez les règles globales avec parcimonie pour des tâches telles que le calcul des SLO mondiaux sur des projets ou pour l'évaluation de règles sur des clusters au sein d'un même Google Cloud projet.
Nous vous recommandons fortement d'utiliser des règles et des règles de cluster dans la mesure du possible. Ces ressources offrent une fiabilité supérieure et conviennent mieux aux mécanismes de déploiement et aux modèles de locataire Kubernetes courants.
Si vous utilisez la ressource GlobalRules, notez les points suivants du diagramme précédent:
Un cluster unique exécuté dans Google Cloud est désigné comme cluster d'évaluation des règles à l'échelle mondiale pour un champ d'application des métriques. Cet évaluateur de règle gérée est configuré pour utiliser scoping_project_A, qui contient les projets 1 et 2. Les règles exécutées sur scoping_project_A font automatiquement l'objet d'une distribution ramifiée vers les projets 1 et 2.
Comme dans tous les autres clusters, cet évaluateur de règles est configuré avec des ressources Rules et ClusterRules qui évaluent les règles appliquées à un espace de noms ou à un cluster. Ces règles sont automatiquement filtrées en tant que projet local (projet 1, dans ce cas). Comme scoping_project_A contient le projet 1, les règles et les règles configurées ClusterRules ne s'exécutent que sur les données du projet local, comme prévu.
Ce cluster dispose également de ressources GlobalRules qui exécutent des règles dans "scoping_project_A". Les règles globales ne sont pas automatiquement filtrées et, par conséquent, les règles globales s'exécutent exactement telles qu'elles sont écrites dans tous les projets, emplacements, clusters et espaces de noms de scoping_project_A.
Les règles d'alerte déclenchées sont envoyées à l'Alert-Manager auto-hébergé comme prévu.
L'utilisation de règles globales peut avoir des effets inattendus, selon que vous conservez ou agrégez les libellés project_id, location, cluster et namespace dans vos règles:
Si votre règle GlobalRules conserve le libellé project_id (en utilisant une clause by(project_id)), les résultats de la règle sont réécrits dans Monarch à l'aide de la valeur project_id d'origine de la série temporelle sous-jacente.
Dans ce scénario, vous devez vous assurer que le compte de service sous-jacent dispose des autorisations Rédacteur de métriques Monitoring pour chaque projet surveillé dans scoping_project_A. Si vous ajoutez un nouveau projet surveillé à scoping_project_A, vous devez également ajouter manuellement une nouvelle autorisation au compte de service.
Si la règle GlobalRules ne conserve pas le libellé project_id (en n'utilisant pas de clause by(project_id)), les résultats de la règle sont réécrits dans Monarch à l'aide de la valeur project_id du cluster sur lequel l'évaluateur de règle global est exécuté.
Dans ce scénario, vous n'avez pas besoin de modifier davantage le compte de service sous-jacent.
Si votre règle GlobalRules conserve le libellé location (en utilisant une clause by(location)), les résultats de la règle sont réécrits dans Monarch à l'aide de chaque région Google Cloud d'origine à partir de laquelle la série temporelle sous-jacente est créée.
Si GlobalRules ne conserve pas le libellé location, les données sont réécrites à l'emplacement du cluster où l'évaluateur de règle globale est exécuté.
Nous vous recommandons vivement de conserver les libellés cluster et namespace dans les résultats de l'évaluation des règles, sauf si l'objectif de la règle est de les agréger. Sinon, les performances de requête risquent de diminuer, et vous risquez de rencontrer des limites de cardinalité. Il est fortement déconseillé de supprimer les deux libellés.
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 2025/09/04 (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 2025/09/04 (UTC)."],[],[],null,["# Evaluation of rules and alerts with managed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[managed collection](/stackdriver/docs/managed-prometheus/setup-managed).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation, as well\nas the optional GlobalRules resource:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- The [managed rule evaluator](/stackdriver/docs/managed-prometheus/rules-managed) is automatically\n deployed in any cluster where managed collection is running. These\n evaluators are configured as follows:\n\n - Use [Rules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#rules) resources to run rules on data\n within a namespace. Rules resources must be applied in every namespace\n in which you want to execute the rule.\n\n - Use [ClusterRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterrules) resources to run\n rules on data across a cluster. ClusterRules resources should be applied\n once per cluster.\n\n- All rule evaluation executes against the global datastore,\n Monarch.\n\n - Rules resources automatically filter rules to the project, location, cluster, and namespace in which they are installed.\n - ClusterRules resources automatically filter rules to the project, location, and cluster in which they are installed.\n - All rule results are written to Monarch after evaluation.\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Managed rule evaluators are configured by [editing the\n OperatorConfig resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed) to send fired alerting\n rules to their local AlertManager instance. Silences, acknowledgements, and\n incident management workflows are typically handled in a third-party tool\n such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes\n [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed).\n\nThe preceding diagram also shows the optional\n[GlobalRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#globalrules) resource.\nUse GlobalRules very sparingly, for tasks like\ncalculating global SLOs across projects or for evaluating rules across\nclusters within a single Google Cloud project.\n**We strongly recommend using Rules and ClusterRules whenever possible**;\nthese resources provide superior reliability and are better fits for\ncommon Kubernetes deployment mechanisms and tenancy models.\n\nIf you use the GlobalRules resource, note the following from the\npreceding diagram:\n\n- One single cluster running inside Google Cloud is designated as the\n global rule-evaluation cluster for a metrics scope. This managed rule\n evaluator is configured to use scoping_project_A, which contains\n Projects 1 and 2. Rules executed against scoping_project_A automatically\n fan out to Projects 1 and 2.\n\n The underlying service account must be given the [Monitoring\n Viewer](/monitoring/access-control#mon_roles_desc) permissions for scoping_project_A.\n For additional information on how to set these fields, see\n [Multi-project and global rule evaluation](/stackdriver/docs/managed-prometheus/rules-managed#multi-project_and_global_rule_evaluation).\n- As in all other clusters, this rule evaluator is set up with Rules\n and ClusterRules resources that evaluate rules scoped to a namespace\n or cluster. These rules are automatically filtered to the *local*\n project---Project 1, in this case. Because scoping_project_A\n contains Project 1, Rules and ClusterRules-configured rules execute\n only against data from the local project as expected.\n\n- This cluster also has GlobalRules resources that execute rules against\n scoping_project_A. GlobalRules are not automatically filtered, and\n therefore GlobalRules execute exactly as written across all projects,\n locations, clusters, and namespaces in scoping_project_A.\n\n- Fired alerting rules will be sent to the self-hosted AlertManager as\n expected.\n\nUsing GlobalRules may have unexpected effects, depending on whether you\npreserve or aggregate the `project_id`, `location`, `cluster`, and\n`namespace` labels in your rules:\n\n- If your GlobalRules rule preserves the `project_id` label (by using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the original `project_id` value of the underlying\n time series.\n\n In this scenario, you need to ensure the underlying service account\n has the [Monitoring Metric Writer](/monitoring/access-control#mon_roles_desc) permissions for each\n monitored project in scoping_project_A. If you add a new\n monitored project to scoping_project_A, then you must also manually\n add a new permission to the service account.\n- If your GlobalRules rule does not preserve the `project_id` label (by\n not using a `by(project_id)` clause), then rule results are written back\n to Monarch using the `project_id` value of the cluster\n where the global rule evaluator is running.\n\n In this scenario, you do not need to further modify the underlying\n service account.\n- If your GlobalRules preserves the `location` label (by using a\n `by(location)` clause), then rule results are written back to\n Monarch using each original Google Cloud region from which\n the underlying time series originated.\n\n If your GlobalRules does not preserve the `location` label, then data\n is written back to the location of the cluster where the global rule\n evaluator is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels in\nrule evaluation results unless the purpose of the rule is to aggregate away\nthose labels. Otherwise, query performance might decline and you might\nencounter cardinality limits. Removing both labels is strongly discouraged."]]
