Prometheus verwenden

Prometheus ist ein Monitoringtool, das oft mit Kubernetes verwendet wird. Wenn Sie Kubernetes Engine Operations konfigurieren und dabei die Prometheus-Unterstützung einbinden, können die Messwerte, die von Diensten mit dem Prometheus-Darstellungsformat generiert werden, aus dem Cluster exportiert und als externe Messwerte in Cloud Monitoring angezeigt werden.

Auf dieser Seite wird gezeigt, wie Prometheus mit Kubernetes Engine Operations konfiguriert und verwendet wird. Der Quellcode für die Einbindung ist öffentlich verfügbar.

Hinweis

Sie können keine Cluster mit Legacy-Logging und -Monitoring mit Prometheus konfigurieren. Weitere Informationen zu Legacy-Logging und -Monitoring finden Sie unter Anleitungen zu Legacy-Logging und -Monitoring.

Diese Seite enthält keine Anleitung zum Installieren eines Prometheus-Servers oder zum Erstellen eines GKE-Clusters mit Kubernetes Engine Operations.

Prüfen Sie vor der Installation des Stackdriver-Collectors die folgenden Anforderungen:

Collector installieren

Gehen Sie so vor, um den Stackdriver-Collector bereitzustellen:

  1. Ermitteln Sie das Objekt, das aktualisiert werden soll, nach seinem Namen und dem Controller-Typ. Nur die Controller-Typen deployment und statefulset werden unterstützt.

  2. Legen Sie die folgenden Umgebungsvariablen fest:

    • KUBE_NAMESPACE: Namespace zur Ausführung des Skripts.
    • KUBE_CLUSTER: Parameter des Clusternamens für die Sidecar-Datei
    • GCP_REGION: Google Cloud-Regionsparameter für die Sidecar-Datei.
    • GCP_PROJECT: Google Cloud-Projektparameter für die Sidecar-Datei.
    • DATA_DIR: Datenverzeichnis für die Sidecar-Datei. Dies ist das Verzeichnis, in dem sich das freigegebene Volume befindet, auf das Ihr Prometheus-Server schreibt. In den nachfolgenden Anweisungen wird diese Variable auf den Wert /data gesetzt.
    • DATA_VOLUME: Name des freigegebenen Volume in Variable DATA_DIR, die Prometheus-Daten enthält. In den nachfolgenden Anweisungen wird diese Variable auf data-volume gesetzt.
    • SIDECAR_IMAGE_TAG: Docker-Image-Version für die Prometheus-Sidecar-Datei. Die neueste Version befindet sich in Container Registry.
  3. Führen Sie das folgende Skript aus und geben Sie die beiden Parameter an, die im ersten Schritt dieses Verfahrens identifiziert wurden:

    #!/bin/sh
    
    set -e
    set -u
    
    usage() {
      echo -e "Usage: $0 <deployment|statefulset> <name>\n"
    }
    
    if [  $# -le 1 ]; then
      usage
      exit 1
    fi
    
    # Override to use a different Docker image name for the sidecar.
    export SIDECAR_IMAGE_NAME=${SIDECAR_IMAGE_NAME:-'gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar'}
    
    kubectl -n "${KUBE_NAMESPACE}" patch "$1" "$2" --type strategic --patch "
    spec:
      template:
        spec:
          containers:
          - name: sidecar
            image: ${SIDECAR_IMAGE_NAME}:${SIDECAR_IMAGE_TAG}
            imagePullPolicy: Always
            args:
            - \"--stackdriver.project-id=${GCP_PROJECT}\"
            - \"--prometheus.wal-directory=${DATA_DIR}/wal\"
            - \"--stackdriver.kubernetes.location=${GCP_REGION}\"
            - \"--stackdriver.kubernetes.cluster-name=${KUBE_CLUSTER}\"
            #- \"--stackdriver.generic.location=${GCP_REGION}\"
            #- \"--stackdriver.generic.namespace=${KUBE_CLUSTER}\"
            ports:
            - name: sidecar
              containerPort: 9091
            volumeMounts:
            - name: ${DATA_VOLUME}
              mountPath: ${DATA_DIR}
    "
    

Nach erfolgreicher Ausführung des Skripts wird der Stackdriver-Collector als Sidecar-Datei zu den Pods für das im ersten Schritt des Verfahrens angegebene Objekt hinzugefügt. Die beiden auskommentierten Zeilen im Skript sind für die Erfassung von Messwertdaten aus GKE-Clustern nicht relevant. Diese beiden Zeilen sind jedoch relevant, wenn Sie eine generische MonitoredResource einfügen möchten.

Es sind zusätzliche Schritte erforderlich, um die Konfigurationsänderungen endgültig festzulegen. Diese Schritte werden in den folgenden Abschnitten beschrieben.

Die Installation prüfen

Zur Validierung der Installation des Stackdriver-Collectors führen Sie den folgenden Befehl aus:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name> -o=go-template='{{$output := "stackdriver-prometheus-sidecar does not exists."}}{{range .spec.template.spec.containers}}{{if eq .name "stackdriver-prometheus-sidecar"}}{{$output = (print "stackdriver-prometheus-sidecar exists. Image: " .image)}}{{end}}{{end}}{{printf $output}}{{"\n"}}'
  • Wenn die Prometheus-Sidecar-Datei erfolgreich installiert wurde, enthält die Ausgabe des Skripts das Image, das aus Container Registry verwendet wurde. Im folgenden Beispiel lautet die Image-Version 0.4.3. In Ihrer Installation kann die Version anders aussehen:

    stackdriver-prometheus-sidecar exists. Image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:0.4.3
    
  • Andernfalls zeigt die Ausgabe des Skripts Folgendes:

    stackdriver-prometheus-sidecar does not exist.
    

Führen Sie folgende Schritte aus, um festzustellen, ob Ihre Arbeitslast aktuell und verfügbar ist:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name>

Konfigurationsänderung dauerhaft vornehmen

Nachdem Sie überprüft haben, ob der Collector erfolgreich installiert wurde, aktualisieren Sie Ihre Clusterkonfiguration, um die Änderungen dauerhaft zu machen:

  1. Konfigurieren Sie den Prometheus-Server so, dass er auf ein freigegebenes Volume schreibt. In den folgenden Beispielschritten wird davon ausgegangen, dass DATA_DIR auf /data und DATA_VOLUME auf data-volume gesetzt wurde:

    1. Achten Sie darauf, dass sich im Prometheus-Pod ein freigegebenes Volume befindet:

      volumes:
        - name: data-volume
          emptyDir: {}
      
    2. Prometheus veranlassen, das Volume unter /data bereitzustellen:

      volumeMounts:
      - name: data-volume
        mountPath: /data
      
    3. Weisen Sie den Prometheus-Server an, in das freigegebene Volume in /data zu schreiben, indem Sie dem Container Folgendes hinzufügen args:

      --storage.tsdb.path=/data
      
  2. Verwenden Sie die Tools, die Sie zur Verwaltung der Konfiguration Ihrer Arbeitslasten verwenden, wenden Sie die Konfiguration erneut auf den Cluster an und fügen Sie den Stackdriver-Collector-Container in der neuen Konfiguration als Sidecar-Datei hinzu:

    - name: sidecar
      image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:[SIDECAR_IMAGE_TAG]
      args:
      - "--stackdriver.project-id=[GCP_PROJECT]"
      - "--prometheus.wal-directory=/data/wal"
      - "--prometheus.api-address=[API_ADDRESS]"
      - "--stackdriver.kubernetes.location=[GCP_REGION]"
      - "--stackdriver.kubernetes.cluster-name=[KUBE_CLUSTER]"
      ports:
      - name: sidecar
        containerPort: 9091
      volumeMounts:
      - name: data-volume
        mountPath: /data
    

    Im vorherigen Ausdruck bezieht sich [API_ADDRESS] auf die Prometheus-API-Adresse, typischerweise http://127.0.0.1:9090.

Weitere Konfigurationsdetails für den Collector finden Sie in der Dokumentation zur Sidecar-Datei von Stackdriver Prometheus.

Messwerte ansehen

Prometheus ist so konfiguriert, dass Messwerte als externe Messwerte in die Operations-Suite von Google Cloud exportiert werden.

So rufen Sie diese Messwerte auf:

  1. Wählen Sie in der Cloud Console Monitoring aus:

    Zu Monitoring

  2. Klicken Sie im Navigationsbereich auf  Metrics Explorer.

  3. Im Menü Ressourcentyp und Messwert finden:

    • Wählen Sie Kubernetes Container (k8s_container) für den Ressourcentyp aus.
    • Wählen Sie für das Feld Messwert eines mit dem Präfix external/prometheus/ aus. Sie können beispielsweise external/prometheus/go_memstats_alloc_bytes auswählen.

    Im folgenden Beispiel wurde ein Filter hinzugefügt, um die Messwerte für einen bestimmten Cluster anzuzeigen. Die Filterung nach Clusternamen ist hilfreich, wenn Sie mehrere Cluster in einem Arbeitsbereich haben:

    Beispiel für einen Prometheus-Messwert für einen Kubernetes-Container.

Kosten für von Prometheus abgeleitete Messwerte verwalten

Normalerweise ist Prometheus so konfiguriert, dass alle von Ihrer Anwendung exportierten Messwerte erfasst werden. Standardmäßig sendet der Stackdriver-Collector diese Messwerte an Cloud Monitoring. Diese Sammlung enthält Messwerte, die von Bibliotheken exportiert wurden, von denen Ihre Anwendung abhängig ist. Die Prometheus-Clientbibliothek exportiert beispielsweise viele Messwerte zur Anwendungsumgebung.

Sie können Filter im Stackdriver-Collector konfigurieren, um auszuwählen, welche Messwerte in Cloud Monitoring aufgenommen werden. Um beispielsweise nur die von kubernetes-pods und kubernetes-service-endpoints generierten Messwerte zu importieren, fügen Sie beim Starten der Sidecar-Datei von Stackdriver Prometheus die folgende --include-Anweisung hinzu:

 --include={job=~"kubernetes-pods|kubernetes-service-endpoints"}

Weitere Informationen finden Sie unter Dokumentation zur Sidecar-Datei von Stackdriver Prometheus.

Sie können auch schätzen, wie viel diese Messwerte zu Ihrer Rechnung beitragen.

Prometheus-Integrationsprobleme

In Cloud Monitoring werden keine Daten angezeigt.

Wenn in Cloud Monitoring nach den Installationsschritten keine Daten angezeigt werden, suchen Sie in den Collector-Logs nach Fehlermeldungen.

Wenn die Logs keine offensichtlichen Fehlermeldungen enthalten, aktivieren Sie das Debug-Logging, indem Sie das Flag --log.level=debug an den Collector übergeben. Sie müssen den Collector neu starten, damit die Loggingänderung wirksam wird. Suchen Sie nach dem Neustart des Collectors in den Collector-Logs nach Fehlermeldungen.

Um zu prüfen, ob Daten an Cloud Monitoring gesendet werden, können Sie die Anfragen mithilfe des Befehlszeilenparameters --stackdriver.store-in-files-directory an Dateien senden und dann die Dateien in diesem Verzeichnis überprüfen.

Berechtigung verweigert

Wenn von der Monitoring API Fehler aufgrund von abgelehnten Berechtigungen angezeigt werden, lesen Sie die unter Vorbereitung beschriebenen Anforderungen. Achten Sie darauf, dass Ihre Dienstkonten die erforderlichen Berechtigungen haben. Wenn Sie die Arbeitslastidentität verwenden, achten Sie darauf, dass Sie eine Beziehung zwischen den KSAs und GSAs herstellen.

Ich verwende Aufnahmeregeln und die Messwerte werden nicht in Cloud Monitoring angezeigt.

Wenn Sie Aufnahmerollen verwenden, nehmen Sie wenn möglich den unbearbeiteten Messwert in Cloud Monitoring auf und verwenden Sie die Cloud Monitoring-Features, um die Daten beim Erstellen eines Diagramms oder Dashboards zusammenzufassen.

Wenn die Aufnahme des unbearbeiteten Messwerts keine Option ist, fügen Sie in der Konfiguration des Collectors einen static_metadata-Eintrag hinzu. Bei dieser Option müssen die Labels job und instance beibehalten werden. Die aktuelle Konfiguration ist beispielsweise wie folgt gültig:

  • Ihre Prometheus-Serverkonfiguration:

    groups:
    - name: my-groups
      rules:
      - record: backlog_avg_10m
        expr: avg_over_time(backlog_k8s[10m])
      - record: backlog_k8s
        expr: sum(total_lag) by (app, job, instance)
    
  • Ihre Prometheus-Collector-Konfiguration:

    static_metadata:
      - metric: backlog_avg_10m
        type: gauge
    

Aufnahmeregeln, die die Labels job oder instance ändern oder entfernen, werden nicht unterstützt.

In meinen Messwerten fehlen die Prometheus-Labels job und instance.

Der Stackdriver-Collector für Prometheus erstellt eine Cloud Monitoring-MonitoredResource für Ihre Kubernetes-Objekte aus bekannten Prometheus-Labels. Wenn Sie die Labeldeskriptoren ändern, kann der Collector die Messwerte nicht in Monitoring schreiben.

In den Logs werden Fehler vom Typ "doppelte Zeitachse" oder "falsche Schreibvorgänge" angezeigt.

Diese Fehler werden dadurch verursacht, dass Messwertdaten zweimal in dieselbe Zeitachse geschrieben werden. Sie treten auf, wenn Ihre Prometheus-Endpunkte denselben Messwert von einer einzelnen überwachten Cloud Monitoring-Ressource zweimal verwenden.

Ein Kubernetes-Container könnte beispielsweise Prometheus-Messwerte an mehrere Ports senden. Da die überwachte Monitoring-Ressource k8s_container keine Ressourcen basierend auf dem Port unterscheidet, erkennt Monitoring, dass Sie zwei Punkte für dieselbe Zeitachse schreiben. Fügen Sie in Prometheus ein Messwertlabel hinzu, das die Zeitachse unterscheidet, um dies zu vermeiden. Beispiel: Sie können das Label __meta_kubernetes_pod_annotation_prometheus_io_port verwenden, da es bei Container-Neustarts konstant bleibt.

In den Logs werden Fehler des Typs "Messwertart muss X sein, ist aber Y" angezeigt.

Diese Fehler werden durch Ändern des Prometheus-Messwerttyps für einen vorhandenen Messwertdeskriptor verursacht. Cloud Monitoring-Messwerte sind strikt typisiert und unterstützen keine Änderung des Messwerttyps zwischen Gauge, Zähler und anderen.

Sie müssen die entsprechenden Messwertdeskriptoren löschen und einen neuen Deskriptor erstellen, um den Typ eines Messwerts zu ändern. Durch das Löschen eines Messwertdeskriptors wird der Zugriff auf vorhandene Zeitachsendaten gesperrt.

Ich bin mir sicher, dass ich vorher schon Prometheus-Messwerttypen gesehen habe, finde sie aber nicht!

Prometheus ist so vorkonfiguriert, dass Messwerte als externe Messwerte an Cloud Monitoring exportiert werden. Wenn Daten exportiert werden, erstellt Monitoring den entsprechenden Messwertdeskriptor für den externen Messwert. Wenn mindestens 24 Monate lang keine Daten dieses Messwerttyps geschrieben wurden, wird der Messwertdeskriptor gelöscht.

Es gibt keine Garantie dafür, dass nicht verwendete Messwertdeskriptoren nach 24 Monaten gelöscht werden. Monitoring behält sich jedoch das Recht vor, alle Prometheus-Messwertdeskriptoren zu löschen, die in den letzten 24 Monaten nicht verwendet wurden.

Einstellungsrichtlinie

Die Einbindung von Prometheus in Cloud Monitoring unterliegt der Richtlinie zur Einstellung von Agents.