Selbst bereitgestellte Regelauswertung und Benachrichtigung

Google Cloud Managed Service for Prometheus unterstützt die mit Prometheus kompatible Regelauswertung und Benachrichtigung. In diesem Dokument wird beschrieben, wie Sie die selbst bereitgestellte Regelauswertung einrichten, einschließlich der eigenständigen Regelevaluator-Komponente.

Folgen Sie dieser Anleitung nur, wenn Sie Regeln und Benachrichtigungen für den globalen Datenspeicher ausführen möchten.

Regelauswertung für selbst bereitgestellte Sammlung

Nachdem Sie Managed Service for Prometheus bereitgestellt haben, können Sie die Regeln in jeder bereitgestellten Instanz weiterhin lokal auswerten. Verwenden Sie dazu das Feld rule_files Ihrer Prometheus-Konfigurationsdatei. Das maximale Abfragefenster für die Regeln ist jedoch durch die Dauer der Aufbewahrung lokaler Daten auf dem Server beschränkt.

Die meisten Regeln werden auf die Daten der letzten Minuten ausgeführt. Daher ist die Ausführung von Regeln auf jedem lokalen Server oft eine sinnvolle Strategie. In diesem Fall ist keine weitere Einrichtung erforderlich.

Manchmal ist es jedoch hilfreich, Regeln im Vergleich zum globalen Messwert-Backend auswerten zu können, beispielsweise wenn sich nicht alle Daten für eine Regel auf derselben Prometheus-Instanz befinden. In diesen Fällen bietet Managed Service for Prometheus auch eine Regelevaluator-Komponente.

Hinweis: Sie können Cloud Monitoring-Benachrichtigungsrichtlinien anhand von PromQL-Abfragen und Prometheus-Benachrichtigungsregeln erstellen. Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien mit PromQL.

Hinweise

In diesem Abschnitt wird die Konfiguration beschrieben, die für die in diesem Dokument beschriebenen Aufgaben erforderlich ist.

Konfigurierung Ihrer Umgebung

Führen Sie die folgende Konfiguration aus, um zu vermeiden, dass Sie Ihre Projekt-ID oder den Clusternamen wiederholt eingeben müssen:

• Konfigurieren Sie die Befehlszeilentools so:

  • Konfigurieren Sie die gcloud CLI so, dass sie auf die ID Ihres Google Cloud-Projekts verweist:

    gcloud config set project PROJECT_ID
    

  • Konfigurieren Sie die kubectl-Befehlszeile für die Verwendung Ihres Clusters:

    kubectl config set-cluster CLUSTER_NAME
    

  Weitere Informationen zu diesen Tools finden Sie hier:

  • Übersicht über gcloud-Befehlszeilen
  • kubectl-Befehle

Namespace einrichten

Erstellen Sie den Kubernetes-Namespace NAMESPACE_NAME für Ressourcen, die Sie als Teil der Beispielanwendung erstellen:

kubectl create ns NAMESPACE_NAME

Anmeldedaten für das Dienstkonto prüfen

Sie können diesen Abschnitt überspringen, wenn in Ihrem Kubernetes-Cluster Workload Identity aktiviert ist.

Bei Ausführung in GKE ruft Managed Service for Prometheus automatisch Anmeldedaten aus der Umgebung anhand des Compute Engine-Standarddienstkontos ab. Das Standarddienstkonto hat standardmäßig die erforderlichen Berechtigungen monitoring.metricWriter und monitoring.viewer. Wenn Sie Workload Identity nicht verwenden und zuvor eine dieser Rollen aus dem Standardknotendienstkonto entfernt haben, müssen Sie diese fehlenden Berechtigungen wieder hinzufügen, bevor Sie fortfahren.

Wenn Sie nicht GKE ausführen, finden Sie weitere Informationen unter Anmeldedaten explizit angeben.

Dienstkonto für Workload Identity konfigurieren

Sie können diesen Abschnitt überspringen, wenn in Ihrem Kubernetes-Cluster Workload Identity nicht aktiviert ist.

Managed Service for Prometheus erfasst Messwertdaten mithilfe der Cloud Monitoring API. Wenn Ihr Cluster Workload Identity verwendet, müssen Sie dem Kubernetes-Dienstkonto die Berechtigung für die Monitoring API erteilen. In diesem Abschnitt wird Folgendes beschrieben:

• Dediziertes Google Cloud-Dienstkonto gmp-test-sa erstellen
• Google Cloud-Dienstkonto an das Standard-Kubernetes-Dienstkonto im Test-Namespace NAMESPACE_NAME binden
• Dem Google Cloud-Dienstkonto die erforderliche Berechtigung gewähren

Dienstkonto erstellen und binden

Dieser Schritt wird an mehreren Stellen in der Dokumentation zu Managed Service for Prometheus aufgeführt. Wenn Sie diesen Schritt bereits als Teil einer vorherigen Aufgabe ausgeführt haben, müssen Sie ihn nicht wiederholen. Fahren Sie mit Dienstkonto autorisieren fort.

Mit der folgenden Befehlssequenz wird das Dienstkonto gmp-test-sa erstellt und an das Standard-Kubernetes-Dienstkonto im Namespace NAMESPACE_NAME gebunden:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Wenn Sie einen anderen GKE-Namespace oder ein anderes GKE-Dienstkonto verwenden, passen Sie die Befehle entsprechend an.

Dienstkonto autorisieren

Gruppen zusammengehöriger Berechtigungen werden in Rollen zusammengefasst und Sie weisen die Rollen einem Hauptkonto zu, in diesem Beispiel dem Google Cloud-Dienstkonto. Weitere Informationen zu Monitoring-Rollen finden Sie unter Zugriffssteuerung.

Mit dem folgenden Befehl werden dem Google Cloud-Dienstkonto gmp-test-sa die Monitoring API-Rollen zugewiesen, die zum Lesen und Schreiben von Messwertdaten erforderlich sind.

Wenn Sie dem Google Cloud-Dienstkonto im Rahmen der vorherigen Aufgabe bereits eine bestimmte Rolle zugewiesen haben, müssen Sie dies nicht noch einmal tun.

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

Workload Identity-Konfiguration debuggen

Wenn Sie Probleme mit der Workload Identity haben, lesen Sie die Dokumentation zum Prüfen der Workload Identity-Einrichtung und zur Fehlerbehebung bei Workload Identity.

Da Tippfehler und partielle Kopierfunktionen die häufigsten Fehlerquellen bei der Konfiguration von Workload Identity sind, empfehlen wir dringend die bearbeitbaren Variablen und anklickbaren Symbole, die in die Codebeispiele in dieser Anleitung eingebettet sind.

Workload Identity in Produktionsumgebungen

Das in diesem Dokument beschriebene Beispiel bindet das Google Cloud-Dienstkonto an das Standard-Kubernetes-Dienstkonto und gewährt dem Google Cloud-Dienstkonto alle erforderlichen Berechtigungen zur Verwendung der Monitoring API.

In einer Produktionsumgebung können Sie einen feiner abgestimmten Ansatz mit einem Dienstkonto für jede Komponente nutzen, das jeweils nur minimale Berechtigungen hat. Weitere Informationen zum Konfigurieren von Dienstkonten für die Verwaltung von Workload Identity finden Sie unter Workload Identity verwenden.

Evaluator für eigenständige Regeln bereitstellen

Der Regelevaluator von Managed Service for Prometheus wertet Benachrichtigungs- und Aufzeichnungsregeln von Prometheus für die HTTP API von Managed Service for Prometheus aus und schreibt die Ergebnisse in Monarch. Sie akzeptiert dasselbe Konfigurationsdatei- und Regeldateiformat wie Prometheus. Die Flags sind meist identisch.

1. Erstellen Sie ein Beispielbereitstellung des Regelevaluators, die zur Auswertung einer Benachrichtigung und einer Aufzeichnungsregel vorkonfiguriert ist:

   kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.10.0/manifests/rule-evaluator.yaml
   

2. Prüfen Sie, ob die Pods für den Regelevaluator erfolgreich bereitgestellt wurden:

   kubectl -n NAMESPACE_NAME get pod
   

   Wenn die Bereitstellung erfolgreich war, sieht die Ausgabe in etwa so aus:

   NAME                              READY   STATUS    RESTARTS   AGE
   ...
   rule-evaluator-64475b696c-95z29   2/2     Running   0          1m
   

Nachdem Sie überprüft haben, ob der Regelevaluator erfolgreich bereitgestellt wurde, können Sie die installierten Manifeste so anpassen, dass sie Folgendes tun:

• Ihre Dateien mit benutzerdefinierten Regeln hinzufügen
• Den Regelevaluator konfigurieren, um Benachrichtigungen mithilfe des Felds alertmanager_config der Konfigurationsdatei an einen selbst bereitgestellten Prometheus-Alertmanager zu senden

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.

Anmeldedaten explizit angeben

Bei der Ausführung in GKE ruft der Regelevaluator automatisch Anmeldedaten aus der Umgebung anhand des Dienstkontos des Knotens oder der Einrichtung von Workload Identity ab. In Nicht-GKE-Kubernetes-Clustern müssen Anmeldedaten explizit mit Flags oder der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS für den Regelevaluator 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
   

   Mit diesem Schritt wird das Dienstkonto erstellt, das Sie möglicherweise bereits in der Workload Identity-Anleitung erstellt haben.

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 NAMESPACE_NAME create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. Öffnen Sie die Deployment-Ressource für den Regelevaluator, um sie zu bearbeiten:

   kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
   

   1. Fügen Sie der Ressource den fett formatierten Text hinzu:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        namespace: NAMESPACE_NAME
        name: rule-evaluator
      spec:
        template
          containers:
          - name: evaluator
            args:
            - --query.credentials-file=/gmp/key.json
            - --export.credentials-file=/gmp/key.json
      ...
            volumeMounts:
            - name: gmp-sa
              mountPath: /gmp
              readOnly: true
      ...
          volumes:
          - name: gmp-sa
            secret:
              secretName: gmp-test-sa
      ...
      

   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.

   Anstelle der Verwendung der in diesem Beispiel festgelegten Flags können Sie den Schlüsseldateipfad mithilfe der Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS festlegen.

   Evaluierung mehrerer Projekte und globaler Regeln

   Wir empfehlen, dass Sie in jedem Google Cloud-Projekt und in jeder Region eine Instanz des Regelevaluators ausführen, anstatt eine Instanz auszuführen, die die Auswertung für viele Projekte und Regionen vornimmt. Wir unterstützen jedoch eine Evaluierung der Regeln mehrerer Projekte für Szenarien, die dies erfordern.

   Bei der Bereitstellung in Google Kubernetes Engine verwendet der Regelevaluator das Google Cloud-Projekt, das dem Cluster zugeordnet ist und das automatisch erkannt wird. Wenn Sie Regeln auswerten möchten, die mehrere Projekte betreffen, können Sie das abgefragte Projekt überschreiben. Verwenden Sie dazu das Flag --query.project-id und geben Sie ein Projekt mit einem Messwertbereich für mehrere Projekte an. Wenn der Messwertbereich alle Ihre Projekte enthält, werden Ihre Regeln global ausgewertet. Weitere Informationen finden Sie unter Messwertbereiche.

   Sie müssen auch die Berechtigungen des Dienstkontos aktualisieren, das vom Regelevaluator verwendet wird, damit das Dienstkonto aus dem den Bereich festlegenden Projekt lesen und in alle überwachten Projekte im Messwertbereich schreiben kann.

   Labels beim Schreiben von Regeln beibehalten

   Bei Daten, die der Evaluator in Managed Service for Prometheus schreibt, unterstützt der Evaluator dieselben --export.*-Flags und dieselbe external_labels-basierte Konfiguration wie die Managed Service for Prometheus-Serverbinärdatei. Wir empfehlen dringend, Regeln zu schreiben, damit die Labels project_id, location, cluster und namespace für ihre Aggregationsebene entsprechend beibehalten werden, da ansonsten die Abfrageleistung sinken kann und Kardinalitätslimits auftreten können.

   Die Labels project_id oder location sind obligatorisch. Wenn diese Labels fehlen, werden die Werte in den Ergebnissen der Regelauswertung auf der Grundlage der Konfiguration des Regelevaluators festgelegt. Fehlende cluster- und namespace-Labels erhalten keine Werte.

   Bereitstellungen mit Hochverfügbarkeit

   Der Regelevaluator kann in einer hochverfügbaren Konfiguration ausgeführt werden. Dazu muss derselbe Ansatz wie für den Prometheus-Server dokumentiert werden.

   Benachrichtigungen mit Cloud Monitoring-Messwerten

   Sie können den Regelauswertung so konfigurieren, dass mit PromQL Benachrichtigungen für Google Cloud-Systemmesswerte ausgelöst werden. Eine Anleitung zum Erstellen einer gültigen Abfrage finden Sie unter PromQL für Cloud Monitoring-Messwerte.