Verwaltete Regelauswertung und Benachrichtigungen

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.13.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.

GlobalRules

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.

  1. Legen Sie den Kontext auf Ihr Zielprojekt fest:

    gcloud config set project PROJECT_ID

  2. Erstellen Sie ein Dienstkonto:

    gcloud iam service-accounts create gmp-test-sa

  3. 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

  4. 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

  5. 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

  6. Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:

    kubectl -n gmp-public edit operatorconfig config

    1. 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 Abschnitt collection hinzuzufügen, damit die verwaltete Erfassung funktioniert.

    2. 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.

    Regelauswertung für die Skalierung

    Der Regelevaluator wird als einzelnes Replikat-Deployment mit festen Ressourcenanforderungen und -limits ausgeführt. Möglicherweise stellen Sie Unterbrechungen der Arbeitslast fest, z. B. OOMKilled bei der Auswertung einer großen Anzahl von Regeln. Sie können dieses Problem jedoch mit einer VerticalPodAutoscaler beheben, um die Bereitstellung vertikal zu skalieren. Prüfen Sie zuerst, ob vertikales Pod-Autoscaling in Ihrem Kubernetes-Cluster aktiviert ist. Wenden Sie dann eine VerticalPodAutoscaler-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 prüfen, ob der Autoscaler funktioniert, indem Sie den Status des Autoscalers prüfen:

    kubectl get vpa --namespace gmp-system rule-evaluator

    Wenn der Autoscaler funktioniert, wird in der Spalte „Bereitgestellt“ angegeben, dass die Ressourcenempfehlungen für die Arbeitslast berechnet wurden:

    NAME             MODE   CPU   MEM        PROVIDED   AGE
rule-evaluator   Auto   2m    11534336   True       30m

    Konfigurationen komprimieren

    Wenn Sie viele Rules-Ressourcen haben, kann der ConfigMap-Speicherplatz knapp werden. Aktivieren Sie dazu die gzip-Komprimierung in Ihrer OperatorConfig-Ressource:

      apiVersion: monitoring.googleapis.com/v1
  kind: OperatorConfig
  metadata:
    namespace: gmp-public
    name: config
  features:
    config:
      compression: gzip

    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:

    1. Erstellen Sie eine lokale Konfigurationsdatei mit Ihren Alertmanager-Einstellungen (siehe Beispielkonfigurationsvorlagen):

      touch alertmanager.yaml

    2. Aktualisieren Sie die Datei mit den gewünschten Alertmanager-Einstellungen und erstellen Sie ein Secret mit dem Namen alertmanager im Namespace gmp-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:

    1. Erstellen Sie ein Secret aus Ihrer lokalen Alertmanager-Konfigurationsdatei:

      kubectl create secret generic SECRET_NAME \
  -n gmp-public \
  --from-file=FILE_NAME

    2. Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:

      kubectl -n gmp-public edit operatorconfig config

    3. 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 enthalten. Dies entspricht der Verwendung des Flags --web.external-url des Upstream-Prometheus Alertmanagers.

    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:

    1. Öffnen Sie die OperatorConfig-Ressource zum Bearbeiten:

      kubectl -n gmp-public edit operatorconfig config

    2. 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.