Google Cloud Managed Service for Prometheus unterstützt die mit Prometheus kompatible Regelauswertung und Benachrichtigung. In diesem Dokument wird beschrieben, wie Sie die verwaltete Regelauswertung einrichten.
Regelauswertung
Managed Service for Prometheus bietet eine Regelevaluator-Komponente, mit der Sie Regeln im Kontext eines globalen Prometheus-Back-Ends sicher schreiben können. Dadurch wird verhindert, dass Sie Daten von anderen Nutzern in größeren Organisationen beeinträchtigen. Die Komponente wird bei der Ausführung in Kubernetes-Clustern automatisch als Teil der verwalteten Erfassung bereitgestellt.
Sie können Regeln und Benachrichtigungen für Managed Service for Prometheus-Messwerte und Cloud Monitoring-Messwerte schreiben. Sie müssen die GlobalRules-Ressource verwenden, wenn Sie Regeln für Cloud Monitoring-Messwerte schreiben.
Regeln
Der verwaltete Regelevaluator verwendet die Rules-Ressource zum Konfigurieren von Aufzeichnungs- und Benachrichtigungsregeln. Hier ist eine beispielhafte Rules-Ressource:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Das Format des .spec.groups
-Elements ist mit dem vorgelagerten Prometheus-rule_group
-Array identisch. Benachrichtigungs- und Aufnahmeregeln, die unter Rules
definiert sind, gelten für project_id
, cluster
und namespace
der Ressource. Die Abfrage job:up:sum
in der obigen Ressource fragt beispielsweise sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"})
effektiv ab.
Dadurch wird gewährleistet, dass Benachrichtigungs- oder Aufzeichnungsregeln nicht versehentlich Messwerte von Anwendungen auswerten, die Sie vielleicht gar nicht kennen.
Führen Sie folgenden Befehl aus, um die Beispielregeln auf Ihren Cluster anzuwenden:
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.10.0/examples/rules.yaml
Nach einigen Minuten ist der Messwert job:up:sum
verfügbar.
Die Benachrichtigung AlwaysFiring
wird ebenfalls ausgelöst. Informationen zum Senden von Benachrichtigungen an einen Alertmanager finden Sie unter Alertmanager-Konfiguration.
Die Ressourcen ClusterRules und GlobalRules bieten dieselbe Schnittstelle wie die Ressource Rules
, wenden die Regeln jedoch auf größere Bereiche an.
ClusterRules wählen Daten mit den Labels project_id
und cluster
aus und GlobalRules wählen alle Daten im Bereich der abgefragten Messwerte aus, ohne die Labels einzuschränken.
Eine Referenzdokumentation zu allen benutzerdefinierten Ressourcen für Managed Service for Prometheus finden Sie in der Referenz zu prometheus-engine/doc/api reference.
Umwandlung von Prometheus-Regeln in Rules
Die Regelressource bietet eine kompatible Schnittstelle zu Prometheus-Regeln, um einen nahtlosen Migrationspfad zum Einbinden vorhandener Regeln in die verwaltete Regelauswertung zu bieten. Sie können Ihre vorhandenen Regeln in eine Regelressource aufnehmen. Im Folgenden ist beispielsweise eine Prometheus-Regel dargestellt:
groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Die entsprechende Regelressource mit der ursprünglichen Prometheus-Regel in Fettschrift sieht so aus:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
ClusterRules
Mit der ClusterRules-Ressource können Sie Aufnahme- und Benachrichtigungsregeln konfigurieren, die alle Zeitachsen auswerten können, die von allen Namespaces in einem bestimmten Cluster an Managed Service for Prometheus gesendet werden.
Die Spezifikation ist mit der Spezifikation von Rules
identisch. Die vorherige Beispiel-Prometheus-Regel wird zur folgenden ClusterRules
-Ressource:
apiVersion: monitoring.googleapis.com/v1 kind: ClusterRules metadata: name: example-clusterrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Wir empfehlen, ClusterRules-Ressourcen nur für horizontale Messwerte zu verwenden, die beispielsweise von einem Service Mesh erzeugt wurden. Verwenden Sie für Messwerte einzelner Bereitstellungen Rules-Ressourcen, um sicherzustellen, dass die Auswertung keine unbeabsichtigten Daten enthält.
Globale Regeln
Sie können die Ressource GlobalRules verwenden, um Aufnahme- und Benachrichtigungsregeln zu konfigurieren, die alle an Managed Service for Prometheus gesendeten Zeitachsen über alle Projekte innerhalb eines Messwertbereichs auswerten können.
Die Spezifikation ist mit der Spezifikation von Rules
identisch. Die vorherige Beispiel-Prometheus-Regel wird zur folgenden GlobalRules
-Ressource:
apiVersion: monitoring.googleapis.com/v1 kind: GlobalRules metadata: name: example-globalrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Da Cloud Monitoring-Messwerte nicht auf einen Namespace oder Cluster beschränkt sind, müssen Sie die GlobalRules-Ressource beim Schreiben von Regeln oder Benachrichtigungen für Cloud Monitoring-Messwerte verwenden. Die Verwendung von GlobalRules ist auch bei Benachrichtigungen in Google Kubernetes Engine-Systemmesswerten erforderlich.
Wenn Ihre Regel die Labels project_id
oder location
nicht beibehält, werden standardmäßig die Werte des Clusters verwendet.
Für Messwerte von Managed Service for Prometheus empfehlen wir, GlobalRules nur für die seltenen Anwendungsfälle zu verwenden, in denen eine Benachrichtigung möglicherweise Daten in allen Clustern gleichzeitig benötigt. Verwenden Sie für Messwerte einzelner Bereitstellungen Regeln oder ClusterRules-Ressourcen, um die Zuverlässigkeit zu erhöhen und sicherzustellen, dass die Bewertung keine unbeabsichtigten Daten enthält. Wir empfehlen dringend, die Labels cluster
und namespace
in den Ergebnissen der Regelauswertung beizubehalten, es sei denn, die Regel dient dazu, diese Labels zusammenzufassen. Andernfalls kann die Abfrageleistung sinken und es können Kardinalitätslimits auftreten. Es wird dringend davon abgeraten, beide Labels zu entfernen.
Evaluierung mehrerer Projekte und globaler Regeln
Bei der Bereitstellung in Google Kubernetes Engine verwendet der Regelevaluator das Google Cloud-Projekt, das dem Cluster zugeordnet ist, das vom Regelevaluator automatisch erkannt wird. Zur Auswertung von Regeln, die sich über Projekte erstrecken, müssen Sie den Regelevaluator konfigurieren, der die GlobalRules-Ressource ausführt, um ein Projekt mit einem Messwertbereich für mehrere Projekte zu verwenden. Dafür haben Sie die beiden folgenden Möglichkeiten:
- Platzieren Sie die Ressource GlobalRules in einem Projekt mit einem Messwertbereich für mehrere Projekte.
- Legen Sie das Feld
queryProjectID
in OperatorConfig fest, um ein Projekt mit einem Messwertbereich mit mehreren Projekten zu verwenden.
Sie müssen auch die Berechtigungen des Dienstkontos aktualisieren, das vom Regelevaluator verwendet wird, damit das Dienstkonto (in der Regel das Standarddienstkonto auf dem Knoten) aus dem den Bereich festlegenden Projekt lesen und in alle überwachten Projekte im Messwertbereich schreiben kann.
Wenn der Messwertbereich alle Ihre Projekte enthält, werden Ihre Regeln global ausgewertet. Weitere Informationen finden Sie unter Messwertbereiche.
Benachrichtigungen mit Cloud Monitoring-Messwerten
Sie können die GlobalRules-Ressource verwenden, um mithilfe von PromQL Benachrichtigungen zu Google Cloud-Systemmesswerten zu senden. Eine Anleitung zum Erstellen einer gültigen Abfrage finden Sie unter PromQL für Cloud Monitoring-Messwerte.
Regeln und Benachrichtigungen mit Terraform konfigurieren
Sie können die Erstellung und Verwaltung von Regel-, ClusterRules- und GlobalRules-Ressourcen automatisieren. Verwenden Sie dazu den kubernetes_manifest
-Terraform-Ressourcentyp oder den kubectl_manifest
-Terraform-Ressourcentyp, mit denen Sie beliebige benutzerdefinierte Ressourcen angeben können.
Allgemeine Informationen zur Verwendung von Google Cloud mit Terraform finden Sie unter Terraform mit Google Cloud.
Anmeldedaten explizit angeben
Bei der Ausführung in GKE ruft der Regelevaluator automatisch Anmeldedaten aus der Umgebung anhand des Dienstkontos des Knotens ab. In Nicht-GKE-Kubernetes-Clustern müssen Anmeldedaten explizit über die OperatorConfig-Ressource im gmp-public-Namespace bereitgestellt werden.
Legen Sie den Kontext auf Ihr Zielprojekt fest:
gcloud config set project PROJECT_ID
Erstellen Sie ein Dienstkonto:
gcloud iam service-accounts create gmp-test-sa
Gewähren Sie die erforderlichen Berechtigungen für das Dienstkonto:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Erstellen Sie einen Schlüssel für das Dienstkonto und laden Sie ihn herunter:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
Fügen Sie dem Nicht-GKE-Cluster die Schlüsseldatei als Secret hinzu:
kubectl -n gmp-public create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:
kubectl -n gmp-public edit operatorconfig config
Fügen Sie der Ressource den fett formatierten Text hinzu:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: credentials: name: gmp-test-sa key: key.json
Achten Sie darauf, diese Anmeldedaten auch dem Abschnittcollection
hinzuzufügen, damit die verwaltete Erfassung funktioniert.Speichern Sie die Datei und schließen Sie den Editor. Nachdem die Änderung angewendet wurde, werden die Pods neu erstellt und beginnen mit der Authentifizierung beim Messwert-Backend mit dem angegebenen Dienstkonto.
Auswertung von Skalierungsregeln
Der Regelevaluator wird als einzelnes Replikat-Deployment mit festen Ressourcenanforderungen und -limits ausgeführt. Möglicherweise stellen Sie fest, dass die Arbeitslast Unterbrechungen aufweist, z. B. wenn sie bei der Auswertung einer großen Anzahl von Regeln OOMKilled verursacht. Zur Umgehung dieses Problems können Sie einen
VerticalPodAutoscaler
bereitstellen, um die Bereitstellung vertikal zu skalieren. Prüfen Sie zuerst, ob vertikales Pod-Autoscaling in Ihrem Kubernetes-Cluster aktiviert ist. Wenden Sie dann eineVerticalPodAutoscaler
-Ressource wie die folgende an:apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: rule-evaluator namespace: gmp-system spec: resourcePolicy: containerPolicies: - containerName: evaluator controlledResources: - memory maxAllowed: memory: 4Gi minAllowed: memory: 16Mi mode: Auto targetRef: apiVersion: apps/v1 kind: Deployment name: rule-evaluator updatePolicy: updateMode: Auto
Sie können überprüfen, ob das Autoscaling funktioniert, indem Sie dessen Status überprüfen:
kubectl get vpa --namespace gmp-system rule-evaluator
Wenn das Autoscaling funktioniert, wird in der Spalte "BEREITGESTELLT" angezeigt, dass die Ressourcenempfehlungen für die Arbeitslast berechnet wurden:
NAME MODE CPU MEM PROVIDED AGE rule-evaluator Auto 2m 11534336 True 30m
Alertmanager-Konfiguration
Mit der OperatorConfig-Ressource können Sie den verwalteten Regelevaluator konfigurieren, um Benachrichtigungen an einen Prometheus-Alertmanager zu senden. Sie können Benachrichtigungen zusätzlich zu selbst bereitgestellten Alertmanagern an den automatisch bereitgestellten verwalteten Alertmanager senden.
Verwalteter Alertmanager
Managed Service for Prometheus stellt eine verwaltete Instanz von Alertmanager bereit. Regelevaluatoren werden automatisch dafür konfiguriert, Benachrichtigungen dorthin zu senden. Standardmäßig wird diese Konfiguration mit einem speziell benannten Kubernetes-Secret festgelegt, das eine Alertmanager-Konfigurationsdatei enthält.
So aktivieren und konfigurieren Sie die Berichterstellung für die bereitgestellte Alertmanager-Instanz:
Erstellen Sie eine lokale Konfigurationsdatei mit Ihren Alertmanager-Einstellungen (siehe Beispielkonfigurationsvorlagen):
touch alertmanager.yaml
Aktualisieren Sie die Datei mit den gewünschten Alertmanager-Einstellungen und erstellen Sie ein Secret mit dem Namen
alertmanager
im Namespacegmp-public
:kubectl create secret generic alertmanager \ -n gmp-public \ --from-file=alertmanager.yaml
Nach wenigen Augenblicken erfasst Managed Service for Prometheus das neue Konfigurations-Secret und aktiviert den verwalteten Alertmanager mit Ihren Einstellungen.
Secret-Konfigurationsnamen anpassen
Der verwaltete Alertmanager unterstützt auch benutzerdefinierte Secret-Namen zum Laden der Konfiguration. Diese Funktion ist nützlich, wenn Sie mehrere Konfigurations-Secrets haben und Ihre Alertmanager-Instanz zwischen den entsprechenden Konfigurationen wechseln soll. Beispielsweise können Sie die Benachrichtigungskanäle basierend auf rotierenden Bereitschaftsverschiebungen ändern oder zu einer experimentellen Alertmanager-Konfiguration wechseln, um eine neue Benachrichtigungsroute zu testen.
So geben Sie einen nicht standardmäßigen Secret-Namen mithilfe der OperatorConfig-Ressource an:
Erstellen Sie ein Secret aus Ihrer lokalen Alertmanager-Konfigurationsdatei:
kubectl create secret generic SECRET_NAME \ -n gmp-public \ --from-file=FILE_NAME
Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:
kubectl -n gmp-public edit operatorconfig config
Bearbeiten Sie die Ressource, um die verwaltete Alertmanager-Berichterstellung zu aktivieren. Ändern Sie dazu den Abschnitt
managedAlertmanager
wie im folgenden fett formatierten Text gezeigt:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: configSecret: name: SECRET_NAME key: FILE_NAME
Wenn Sie Änderungen an der Alertmanager-Konfiguration vornehmen müssen, können Sie die Konfiguration für diesen Alertmanager bearbeiten, indem Sie das zuvor erstellte Secret aktualisieren.
Externe URL anpassen
Sie können die externe URL für den verwalteten Alertmanager so konfigurieren, dass Benachrichtigungen einen Callback-Link zu Ihrer Benachrichtigungs-UI bereitstellen können. Dies entspricht der Verwendung des Flags
--web.external-url
von vorgelagerten Prometheus Alertmanager.apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: externalURL: EXTERNAL_URL
Selbst bereitgestellter Alertmanager
So konfigurieren Sie den Regelevaluator für einen selbst bereitgestellten Alertmanager:
Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:
kubectl -n gmp-public edit operatorconfig config
Konfigurieren Sie die Ressource, um Benachrichtigungen an Ihren Alertmanager-Dienst zu senden:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: alerting: alertmanagers: - name: SERVICE_NAME namespace: SERVICE_NAMESPACE port: PORT_NAME
Befindet sich Ihr Alertmanager in einem anderen Cluster als Ihr Regelevaluator, müssen Sie möglicherweise eine Endpoints-Ressource einrichten. Wenn Ihre OperatorConfig beispielsweise besagt, dass Alertmanager-Endpunkte im Endpoints-Objekt
ns=alertmanager/name=alertmanager
gefunden werden, können Sie dieses Objekt manuell oder programmatisch selbst erstellen und mit erreichbaren IP-Adressen aus dem anderen Cluster befüllen. Unter AlertmanagerEndpoints-Konfiguration finden Sie bei Bedarf Optionen zur Autorisierungskonfiguration.