Bewertung von Regeln und Benachrichtigungen mit selbst bereitgestellter 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 selbst bereitgestellte 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 verwendet:
Beachten Sie Folgendes, um eine Bereitstellung wie im Diagramm einzurichten und zu verwenden:
Regeln werden in jedem Managed Service for Prometheus-Erfassungsserver installiert, wie bei der Verwendung von Standard-Prometheus. Die Regelbewertung wird für die Daten ausgeführt, die lokal auf jedem Server gespeichert sind. Die Server sind so konfiguriert, dass Daten so lange aufbewahrt werden, dass der Lookback-Zeitraum aller Regeln abgedeckt wird, der normalerweise nicht mehr als eine Stunde beträgt. Regelergebnisse werden nach der Bewertung in Monarch geschrieben.
Eine Prometheus AlertManager-Instanz wird in jedem einzelnen Cluster manuell bereitgestellt. Um Prometheus-Server zu konfigurieren, bearbeiten Sie das Feld alertmanager_config der Konfigurationsdatei, 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.
Ein einzelner Cluster, der in Google Cloud ausgeführt wird, wird als globaler Cluster zur Regelbewertung für einen Messwertbereich festgelegt. Die eigenständige Regelbewertung wird in diesem Cluster bereitgestellt und Regeln werden im Prometheus-Standardformat für Regeldateien installiert.
Die eigenständige 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. Dem zugrunde liegenden Dienstkonto müssen die Berechtigungen des Monitoring-Betrachters für Bereichsprojekt_A gewährt werden.
Die Verwendung einer selbst bereitgestellten globalen Regelbewertung kann unerwartete Auswirkungen haben, je nachdem, ob Sie die Labels project_id, location, cluster und namespace in Ihren Regeln beibehalten oder zusammenfassen:
Wenn Ihre Regeln das Label project_id mithilfe einer by(project_id)-Klausel beibehalten, 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 Regeln das Label project_id nicht beibehalten (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 Regeln das Label location mithilfe einer by(location)-Klausel beibehalten, werden die Regelergebnisse mit jeder ursprünglichen Google Cloud -Region, aus der die zugrunde liegende Zeitachse stammt, wieder in Monarch geschrieben.
Wenn Ihre Regeln das Label location nicht beibehalten, werden die Daten an den Standort des Clusters geschrieben, in dem die globale Regelbewertung ausgeführt wird.
Es wird dringend empfohlen, wenn möglich die Labels cluster und namespace in den Ergebnissen der Regelbewertung beizubehalten. 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 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."]]
