Bewertung von Regeln und Benachrichtigungen mit verwalteter Erfassung
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In diesem Dokument wird eine Konfiguration für die Regel- und Benachrichtigungsbewertung in einer Managed Service for Prometheus-Bereitstellung beschrieben, die die verwaltete Erfassung verwendet.
Das folgende Diagramm veranschaulicht eine Bereitstellung, die mehrere Cluster in zwei Google Cloud -Projekten verwendet und sowohl die Regel- als auch die Benachrichtigungsbewertung sowie die optionale GlobalRules-Ressource verwendet:
Beachten Sie Folgendes, um eine Bereitstellung wie im Diagramm einzurichten und zu verwenden:
Die verwaltete Regelbewertung wird automatisch in jedem Cluster bereitgestellt, in dem die verwaltete Erfassung ausgeführt wird. Diese Bewertungen werden so konfiguriert:
Verwenden Sie Rules-Ressourcen, um Regeln für Daten in einem Namespace auszuführen. Rules-Ressourcen müssen in jedem Namespace angewendet werden, in dem Sie die Regel ausführen möchten.
Verwenden Sie ClusterRules-Ressourcen, um Regeln für Daten in einem Cluster auszuführen. ClusterRules-Ressourcen sollten einmal pro Cluster angewendet werden.
Die gesamte Regelbewertung wird für den globalen Datenspeicher Monarch ausgeführt.
Rules-Ressourcen filtern automatisch Regeln für das Projekt, den Standort, den Cluster und den Namespace, in dem sie installiert sind.
ClusterRules-Ressourcen filtern automatisch Regeln für das Projekt, den Standort und den Cluster, in dem sie installiert sind.
Alle Regelergebnisse werden nach der Bewertung in Monarchisch geschrieben.
Eine Prometheus AlertManager-Instanz wird in jedem einzelnen Cluster manuell bereitgestellt. Verwaltete Regelbewertungen werden durch Bearbeiten der OperatorConfig-Ressource konfiguriert, um ausgelöste Benachrichtigungsregeln an ihre lokale AlertManager-Instanz zu senden. Stummschaltungen, Bestätigungen und Workflows für das Vorfallmanagement werden normalerweise in einem Drittanbietertool wie PagerDuty verarbeitet.
Sie können die Benachrichtigungsverwaltung über mehrere Kubernetes-Endpunkte hinweg in einem einzigen AlertManager verwalten, indem Sie eine Endpunktressource von Kubernetes verwenden.
Das obige Diagramm zeigt auch die optionale GlobalRules-Ressource.
Verwenden Sie GlobalRules sparsam, z. B. für Aufgaben wie die Berechnung globaler SLOs für Projekte oder die clusterübergreifende Bewertung von Regeln in einem einzelnen Google Cloud Projekt.
Wir empfehlen dringend, nach Möglichkeit Rules und ClusterRules zu verwenden. Diese Ressourcen bieten eine herausragende Zuverlässigkeit und eignen sich besser für gängige Kubernetes-Bereitstellungsmechanismen und -Mandantenmodelle.
Wenn Sie die GlobalRules-Ressource verwenden, beachten Sie Folgendes im vorherigen Diagramm:
Ein einzelner Cluster, der in Google Cloud ausgeführt wird, wird als globaler Cluster zur Regelbewertung für einen Messwertbereich festgelegt. Die verwaltete Regelbewertung ist für die Verwendung von Bereichsprojekt_A konfiguriert, das die Projekte 1 und 2 enthält. Regeln, die für Bereichsprojekt_A ausgeführt werden, werden automatisch auf die Projekte 1 und 2 verteilt.
Wie in allen anderen Clustern wird die Regelbewertung mit Rules- und ClusterRules-Ressourcen eingerichtet, die Regeln bewerten, die einem Namespace oder Cluster zugeordnet sind. Diese Regeln werden automatisch in das lokale Projekt – in diesem Fall Projekt 1 – gefiltert. Da Bereichsprojekt_A Projekt 1 enthält, werden die konfigurierten Rules- und ClusterRules-Regeln wie erwartet nur für Daten aus dem lokalen Projekt ausgeführt.
Dieser Cluster enthält auch GlobalRules-Ressourcen, die Regeln für Bereichsprojekt_A ausführen. GlobalRules werden nicht automatisch gefiltert und werden daher genau wie geschrieben in allen Projekten, Standorten, Clustern und Namespaces in Bereichsprojekt_A ausgeführt.
Ausgelöste Benachrichtigungsregeln werden wie erwartet an den selbst gehosteten AlertManager gesendet.
Die Verwendung von GlobalRules kann unerwartete Auswirkungen haben, je nachdem, ob Sie die Labels project_id, location, cluster oder namespace in Ihren Regeln beibehalten oder zusammenfassen:
Wenn Ihre GlobalRules-Regel das Label project_id mithilfe einer by(project_id)-Klausel beibehält, werden die Regelergebnisse mit dem ursprünglichen project_id-Wert der zugrunde liegenden Zeitachse wieder in Monarch geschrieben.
In diesem Szenario müssen Sie dafür sorgen, dass das zugrunde liegende Dienstkonto die Berechtigungen Monitoring-Messwert-Autor für jedes überwachte Projekt in Bereichsprojekt_A hat. Wenn Sie ein neues überwachtes Projekt zu Bereichsprojekt_A hinzufügen, müssen Sie dem Dienstkonto manuell eine neue Berechtigung hinzufügen.
Wenn Ihre GlobalRules-Regel das Label project_id nicht behält (da keine by(project_id)-Klausel verwendet wird), werden die Regelergebnisse mit dem project_id-Wert des Clusters, in dem die globale Regelbewertung ausgeführt wird, wieder in Monarch geschrieben.
In diesem Szenario müssen Sie das zugrunde liegende Dienstkonto nicht weiter ändern.
Wenn Ihre GlobalRules-Regel das Label location mithilfe einer by(location)-Klausel beibehält, werden die Regelergebnisse mit jeder ursprünglichen Google Cloud -Region, aus der die zugrunde liegende Zeitachse stammt, wieder in Monarch geschrieben.
Wenn Ihre GlobalRules-Regel das Label location nicht beibehält, werden die Daten an den Standort des Clusters geschrieben, in dem die globale Regelbewertung ausgeführt wird.
Wir empfehlen dringend, die Labels cluster und namespace in den Ergebnissen der Regelbewertung beizubehalten, sofern der Zweck der Regel nicht darin besteht, diese Labels durch Zusammenfassung zu entfernen. Andernfalls kann die Abfrageleistung sinken und es können Kardinalitätslimits auftreten. Es wird dringend davon abgeraten, beide Labels zu entfernen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
