Évaluation des règles et des alertes avec une collection autodéployé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 qui utilise une collection auto-déployé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:
Pour configurer et utiliser un déploiement comme celui du diagramme, notez les points suivants :
Les règles sont installées dans chaque serveur de collection du service géré pour Prometheus, comme c'est le cas lorsque vous utilisez Prometheus standard. L'évaluation des règles s'exécute sur les données stockées localement sur chaque serveur. Les serveurs sont configurés pour conserver les données suffisamment longtemps pour couvrir la période d'analyse de toutes les règles, qui ne dépasse généralement pas une heure. 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 serveurs Prometheus sont configurés en modifiant le champ alertmanager_config du fichier de configuration pour envoyer des 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.
Un cluster unique exécuté dans Google Cloud est désigné comme cluster d'évaluation de la règle globale pour un champ d'application des métriques. L'évaluateur de règle autonome est déployé dans ce cluster et les règles sont installées à l'aide du format de fichier de règles Prometheus standard.
L'évaluateur de règle autonome 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. Le compte de service sous-jacent doit disposer des autorisations du lecteur Monitoring pour scoping_project_A.
L'utilisation d'un évaluateur de règle global auto-déployé 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 vos règles conservent le libellé project_id (à l'aide d'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 vos règles ne conservent 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 où l'évaluateur de règle global est en cours d'exécution.
Dans ce scénario, vous n'avez pas besoin de modifier davantage le compte de service sous-jacent.
Si vos règles conservent le libellé location (à l'aide d'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 vos règles ne conservent pas le libellé location, les données sont réécrites à l'emplacement du cluster dans lequel l'évaluateur de règle global est exécuté.
Dans la mesure du possible, nous vous recommandons vivement de conserver les libellés cluster et namespace dans les résultats de l'évaluation des règles. 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 self-deployed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[self-deployed collection](/stackdriver/docs/managed-prometheus/setup-unmanaged).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- Rules are installed within each Managed Service for Prometheus collection\n server, just as they are when using standard Prometheus. Rule evaluation\n executes against the data stored locally on each server. Servers are\n configured to retain data long enough to cover the lookback period of all\n rules, which is typically no more than 1 hour. Rule results are written\n to Monarch after evaluation.\n\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Prometheus servers are configured by [editing the\n `alertmanager_config` field of the configuration file](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged) to send\n fired alerting rules to their local AlertManager instance. Silences,\n acknowledgements, and incident management workflows are typically\n handled in a third-party tool such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged).\n- One single cluster running inside Google Cloud is designated as the\n global rule evaluation cluster for a metrics scope. The [standalone\n rule evaluator](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged) is deployed in that cluster and rules are\n installed using the standard Prometheus rule-file format.\n\n The standalone rule evaluator is configured to use scoping_project_A,\n which contains Projects 1 and 2. Rules executed against scoping_project_A\n automatically fan out to Projects 1 and 2. The underlying service account\n must be given the [Monitoring Viewer](/monitoring/access-control#mon_roles_desc) permissions\n for scoping_project_A.\n\n The rule evaluator is configured to send alerts to the local Prometheus\n Alertmanager by using the [`alertmanager_config` field of the configuration\n file](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged).\n\nUsing a self-deployed global rule evaluator may have unexpected\neffects, depending on whether you preserve or aggregate the `project_id`,\n`location`, `cluster`, and `namespace` labels in your rules:\n\n- If your rules preserve 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 rules do not preserve the `project_id` label (by not using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the `project_id` value of the cluster where the\n 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 rules preserve the `location` label (by using a `by(location)`\n clause), then rule results are written back to Monarch\n using each original Google Cloud region from which the underlying\n time series originated.\n\n If your rules do not preserve the `location` label, then data is written\n back to the location of the cluster where the global rule evaluator\n is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels\nin rule evaluation results whenever possible. Otherwise, query performance\nmight decline and you might encounter cardinality limits. Removing both\nlabels is strongly discouraged."]]
