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.
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:
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 die Workload Identity Federation for GKE 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 Federation for GKE 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 die Workload Identity Federation for GKE konfigurieren
Sie können diesen Abschnitt überspringen, wenn in Ihrem Kubernetes-Cluster die Workload Identity Federation for GKE nicht aktiviert ist.
Managed Service for Prometheus erfasst Messwertdaten mithilfe der Cloud Monitoring API. Wenn in Ihrem Cluster die Workload Identity Federation for GKE verwendet wird, müssen Sie Ihrem 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
Fehlerbehebung der Konfiguration von Workload Identity Federation for GKE
Wenn Sie Probleme mit der Workload Identity Federation for GKE haben, lesen Sie die Dokumentation zum Prüfen der Workload Identity Federation for GKE-Einrichtung und zur Fehlerbehebung bei der Workload Identity Federation for GKE.
Da Tippfehler und partielle Kopierfunktionen die häufigsten Fehlerquellen bei der Konfiguration von Workload Identity Federation for GKE sind, empfehlen wir dringend die bearbeitbaren Variablen und anklickbaren Symbole, die in die Codebeispiele in dieser Anleitung eingebettet sind.
Workload Identity Federation for GKE 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 Federation for GKE 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.
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.13.0/manifests/rule-evaluator.yaml
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 der Workload Identity Federation for GKE ab.
In Nicht-GKE-Kubernetes-Clustern müssen Anmeldedaten explizit mit Flags oder der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS
für den Regelevaluator 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
Mit diesem Schritt wird das Dienstkonto erstellt, das Sie möglicherweise bereits in der Anleitung für Workload Identity Federation for GKE erstellt haben.
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 NAMESPACE_NAME create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Öffnen Sie die Deployment-Ressource für den Regelevaluator, um sie zu bearbeiten:
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
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 ...
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.
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 dieselbeexternal_labels
-basierte Konfiguration wie die Managed Service for Prometheus-Serverbinärdatei. Wir empfehlen dringend, Regeln zu schreiben, damit die Labelsproject_id
,location
,cluster
undnamespace
für ihre Aggregationsebene entsprechend beibehalten werden, da ansonsten die Abfrageleistung sinken kann und Kardinalitätslimits auftreten können.Die Labels
project_id
oderlocation
sind obligatorisch. Wenn diese Labels fehlen, werden die Werte in den Ergebnissen der Regelauswertung auf der Grundlage der Konfiguration des Regelevaluators festgelegt. Fehlendecluster
- undnamespace
-Labels erhalten keine Werte.Selbstbeobachtung
Der Regelauswerter gibt Prometheus-Messwerte mit dem Flag
--web.listen-address
über einen konfigurierbaren Port aus.Wenn der Pod
rule-evaluator-64475b696c-95z29
diese Messwerte beispielsweise über den Port9092
freigibt, können sie manuell mitkubectl
aufgerufen werden:# Port forward the metrics endpoint. kubectl port-forward rule-evaluator-64475b696c-95z29 9092 # Then query in a separate terminal. curl localhost:9092/metrics
Sie können Ihren Prometheus-Stack so konfigurieren, dass diese erfasst werden, damit Sie die Leistung des Regelbewerters im Blick behalten können.
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.