Fehlerbehebung für Managed Service for Prometheus

In diesem Dokument werden einige Probleme beschrieben, die bei der Verwendung von Google Cloud Managed Service for Prometheus auftreten können. Außerdem enthält es Informationen zur Diagnose und Lösung von Problemen.

Sie haben Managed Service for Prometheus konfiguriert, aber es werden keine Messwertdaten in Grafana oder auf der Prometheus-Benutzeroberfläche angezeigt. Auf übergeordneter Ebene kann die Ursache eine der folgenden sein:

  • Ein Problem auf der Abfrageseite, sodass keine Daten gelesen werden können. Abfrageseitige Probleme werden häufig durch falsche Berechtigungen für das Dienstkonto, das die Daten liest, oder durch eine fehlerhafte Konfiguration von Grafana verursacht.

  • Ein Problem auf der Datenaufnahmeseite, sodass keine Daten gesendet werden. Probleme auf Datenaufnahmeseite können durch Konfigurationsprobleme mit Dienstkonten, Collectors oder der Regelauswertung verursacht werden.

Um festzustellen, ob das Problem auf der Aufnahme- oder der Abfrageseite liegt, versuchen Sie, Daten mit dem Tab PromQL von Metrics Explorer in der Google Cloud Console abzufragen. Auf dieser Seite werden bestimmt keine Probleme mit Leseberechtigungen oder Grafana-Einstellungen auftreten.

So rufen Sie diese Seite auf:

  1. Wählen Sie in der Projektauswahl in der Google Cloud Console das Projekt aus, bei dem Sie keine Daten sehen.

  2. Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf.

    Zum Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  3. Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche  MQL oder  PromQL.

  4. Prüfen Sie, ob PromQL in der Ein-/Aus-Schaltfläche PromQL ausgewählt ist. Die Sprachschaltfläche befindet sich in derselben Symbolleiste, mit der Sie Ihre Abfrage formatieren können.

  5. Geben Sie im Editor folgende Abfrage ein und klicken Sie dann auf Abfrage ausführen: 

    up

Wenn Sie den Messwert up abfragen und Ergebnisse sehen, liegt das Problem auf der Abfrageseite. Informationen zum Beheben dieser Probleme finden Sie unter Abfrageseitige Probleme.

Wenn Sie den Messwert up abfragen und keine Ergebnisse sehen, liegt das Problem auf der Datenaufnahmeseite. Informationen zur Behebung dieser Probleme finden Sie unter Probleme auf Datenaufnahmeseite.

Eine Firewall kann auch Aufnahme- und Abfrageprobleme verursachen. Weitere Informationen finden Sie unter Firewalls.

Auf der Cloud Monitoring-Seite Messwertverwaltung können Sie den Betrag steuern, den Sie für abrechenbare Messwerte ausgeben, ohne die Beobachtbarkeit zu beeinträchtigen. Die Seite Messwertverwaltung enthält folgende Informationen:

  • Aufnahmevolumen für byte- und probenbasierte Abrechnung für Messwertdomains und einzelne Messwerte
  • Daten zu Labels und zur Kardinalität von Messwerten
  • Anzahl der Lesevorgänge für jeden Messwert.
  • Verwenden Messwerten in Benachrichtigungsrichtlinien und benutzerdefinierten Dashboards
  • Rate von Messwert-Schreibfehlern

Mit der Messwertverwaltung können Sie auch unnötige Messwerte ausschließen, sodass keine Kosten für die Datenaufnahme anfallen.

So rufen Sie die Seite Messwertverwaltung auf:

  1. Rufen Sie in der Google Cloud Console die Seite  Messwertverwaltung auf:

    Zur Messwertverwaltung

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. Wählen Sie in der Symbolleiste das Zeitfenster aus. Standardmäßig werden auf der Seite Messwertverwaltung Informationen zu den Messwerten angezeigt, die am Vortag erfasst wurden.

Weitere Informationen zur Seite Messwertverwaltung finden Sie unter Messwertnutzung ansehen und verwalten.

Abfrageseitige Probleme

Die meisten Probleme auf Abfrageseite haben eine der folgenden Ursachen:

Gehen Sie zuerst so vor:

  • Prüfen Sie Ihre Konfiguration sorgfältig anhand der Einrichtungsanleitung für Abfragen.

  • Wenn Sie die Identitätsföderation von Arbeitslasten für GKE verwenden, prüfen Sie, ob Ihr Dienstkonto die richtigen Berechtigungen hat. Gehen Sie dazu so vor:

    1. Öffnen Sie in der Google Cloud Console die Seite IAM:

      Rufen Sie IAM auf.

      Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM und Verwaltung ist.

    2. Suchen Sie den Namen des Dienstkontos in der Liste der Hauptkonten. Prüfen Sie, ob der Name des Dienstkontos korrekt geschrieben ist. Klicken Sie dann auf Bearbeiten.

    3. Wählen Sie das Feld Rolle aus, klicken Sie auf Aktuell verwendet und suchen Sie nach der Rolle „Monitoring-Betrachter“. Wenn das Dienstkonto diese Rolle nicht hat, fügen Sie sie jetzt hinzu.

Wenn das Problem weiterhin besteht, prüfen Sie die folgenden Möglichkeiten:

Falsch konfigurierte oder falsch typisierte Secrets

Wenn Sie eines der folgenden Secrets sehen, fehlt möglicherweise ein Secret oder es liegt eine falsche Typisierung vor:

  • Einer der folgenden „verbotenen“ Fehler in Grafana oder der Prometheus-Benutzeroberfläche:

    • „Warnung: Unerwarteter Antwortstatus beim Abrufen der Serverzeit: Unzulässig“
    • „Warnung: Fehler beim Abrufen der Messwertliste: Unerwarteter Antwortstatus beim Abrufen von Messwertnamen: Unzulässig“

  • Eine Nachricht wie diese wird in Ihren Logs angezeigt:
    „Datei mit Anmeldedaten kann nicht gelesen werden: /gmp/key.json öffnen: keine Datei oder Verzeichnis vorhanden“

Wenn Sie den Datenquellensynchronisierungsdienst verwenden, um Grafana zu authentifizieren und zu konfigurieren, versuchen Sie Folgendes, um diese Fehler zu beheben:

  1. Prüfen Sie, ob Sie den richtigen Grafana API-Endpunkt, die Grafana-Datenquellen-UID und das Grafana API-Token ausgewählt haben. Sie können die Variablen im CronJob mit dem Befehl kubectl describe cronjob datasource-syncer prüfen.

  2. Achten Sie darauf, dass Sie die Projekt-ID des Datenquellen-Synchronizer auf denselben Messwertbereich oder auf dasselbe Projekt festgelegt haben, für das Ihr Dienstkonto Anmeldedaten hat.

  3. Prüfen Sie, ob Ihr Grafana-Dienstkonto die Rolle „Administrator“ hat und Ihr API-Token nicht abgelaufen ist.

  4. Prüfen Sie, ob Ihr Dienstkonto die Rolle "Monitoring-Betrachter" für die ausgewählte Projekt-ID hat.

  5. Führen Sie kubectl logs job.batch/datasource-syncer-init aus, um zu prüfen, ob die Logs für den Datenquellen-Synchronisierungsjob fehlerfrei sind. Dieser Befehl muss unmittelbar nach dem Anwenden der Datei datasource-syncer.yaml ausgeführt werden.

  6. Prüfen Sie bei Verwendung von Workload Identity Federation for GKE, ob Sie den Kontoschlüssel oder die Anmeldedaten falsch eingegeben haben und ob Sie ihn an den richtigen Namespace gebunden haben.

Wenn Sie den Legacy-Front-End-UI-Proxy verwenden, versuchen Sie, diese Fehler zu beheben:

  1. Achten Sie darauf, dass die Projekt-ID der Frontend-UI auf denselben Messwertbereich oder dasselbe Projekt gesetzt ist, für das Ihr Dienstkonto Anmeldedaten hat.

  2. Prüfen Sie die Projekt-ID, die Sie bei --query.project-id-Flags angegeben haben.

  3. Prüfen Sie, ob Ihr Dienstkonto die Rolle "Monitoring-Betrachter" für die ausgewählte Projekt-ID hat.

  4. Vergewissern Sie sich, dass Sie bei der Bereitstellung der Frontend-Benutzeroberfläche die korrekte Projekt-ID eingestellt haben und nicht den String PROJECT_ID verwendet haben.

  5. Prüfen Sie bei Verwendung von Workload Identity, ob Sie den Kontoschlüssel oder die Anmeldedaten falsch eingegeben haben und ob Sie ihn an den richtigen Namespace gebunden haben.

  6. Wenn Sie Ihr eigenes Secret bereitstellen, muss das Secret vorhanden sein:

    kubectl get secret gmp-test-sa -o json | jq '.data | keys'

  7. Prüfen Sie, ob das Secret korrekt bereitgestellt wurde:

    kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

  8. Prüfen Sie, ob das Secret korrekt an den Container übergeben wurde: 

    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

Falsche HTTP-Methode für Grafana

Wenn der folgende API-Fehler von Grafana angezeigt wird, ist Grafana so konfiguriert, dass eine POST-Anfrage anstelle einer GET-Anfrage gesendet wird:

  • "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Zur Behebung dieses Problems konfigurieren Sie Grafana so, dass eine GET-Anfrage verwendet wird. Folgen Sie dazu der Anleitung unter Datenquelle konfigurieren.

Zeitüberschreitungen bei großen oder lang andauernden Abfragen

Wenn der folgende Fehler in Grafana angezeigt wird, ist das Standardzeitlimit für Abfragen zu niedrig:

  • "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

Beim verwalteten Dienst von Prometheus tritt keine Zeitüberschreitung auf, wenn eine Abfrage 120 Sekunden überschreitet, während bei Grafana standardmäßig nach 30 Sekunden eine Zeitüberschreitung auftritt. Erhöhen Sie das Problem, indem Sie die Zeitlimits in Grafana auf 120 Sekunden erhöhen. Folgen Sie dazu der Anleitung unter Datenquelle konfigurieren.

Fehler bei der Labelvalidierung

Wenn einer der folgenden Fehler in Grafana angezeigt wird, verwenden Sie möglicherweise einen nicht unterstützten Endpunkt:

  • „Validierung: Andere Labels als Name werden noch nicht unterstützt“
  • „Vorlagen [Job]: Fehler beim Aktualisieren von Optionen: Andere Labels als Name werden noch nicht unterstützt.“

Managed Service for Prometheus unterstützt den Endpunkt /api/v1/$label/values nur für das Label __name__. Diese Einschränkung führt dazu, dass Abfragen, die die Variable label_values($label) in Grafana verwenden, fehlschlagen.

Verwenden Sie stattdessen das Formular label_values($metric, $label). Diese Abfrage wird empfohlen, da sie die zurückgegebenen Labelwerte nach Messwert beschränkt, der den Abruf von Werten verhindert, die nicht mit dem Inhalt des Dashboards zusammenhängen. Diese Abfrage ruft einen unterstützten Endpunkt für Prometheus auf.

Weitere Informationen zu unterstützten Endpunkten finden Sie unter API-Kompatibilität.

Das Kontingent wurde überschritten.

Wenn der folgende Fehler angezeigt wird, haben Sie Ihr Lesekontingent für die Cloud Monitoring API überschritten:

  • „429: RESOURCE_EXHAUSTED: Das Kontingent wurde für den Kontingentmesswert „Zeitachsenabfragen“ überschritten und „Zeitachsenabfragen pro Minute“ für den Dienst „monitoring.googleapis.com' for consumer 'project_number...“ wurde begrenzt.

Senden Sie zur Behebung dieses Problems eine Anfrage zur Erhöhung Ihres Lesekontingents für die Monitoring API. Wenn Sie Hilfe benötigen, wenden Sie sich an den Google Cloud-Support. Weitere Informationen zu Kontingenten finden Sie unter Mit Kontingenten arbeiten.

Messwerte aus mehreren Projekten

Wenn Sie Messwerte aus mehreren Google Cloud-Projekten aufrufen möchten, müssen Sie nicht mehrere Datenquellen-Synchronizer konfigurieren oder in Grafana mehrere Datenquellen erstellen.

Erstellen Sie stattdessen einen Cloud Monitoring-Messwertbereich in einem Google Cloud-Projekt (Projektbereich), in dem die Projekte enthalten sind, die Sie überwachen möchten. Wenn Sie die Grafana-Datenquelle mit einem Projektbereich konfigurieren, erhalten Sie Zugriff auf die Daten aus allen Projekten im Messwertbereich. Weitere Informationen finden Sie unter Abfrage- und Messwertbereiche.

Kein überwachter Ressourcentyp angegeben

Wenn der folgende Fehler angezeigt wird, müssen Sie einen überwachten Ressourcentyp angeben, wenn Sie PromQL zum Abfragen eines Google Cloud-Systemmesswerts verwenden:

  • „Messwert ist so konfiguriert, dass er mit mehr als einem überwachten Ressourcentyp verwendet werden kann; der Serienselektor muss einen Label-Matcher für den Namen der überwachten Ressource angeben“

Sie können einen überwachten Ressourcentyp angeben, indem Sie mit dem Label monitored_resource filtern. Weitere Informationen zum Identifizieren und Auswählen eines gültigen überwachten Ressourcentyps finden Sie unter Typ der überwachten Ressource angeben.

Rohwerte für Zähler, Histogramme und Zusammenfassungen stimmen nicht mit der Collector-UI und der Google Cloud Console überein

Möglicherweise bemerken Sie einen Unterschied zwischen den Werten in der Prometheus-Benutzeroberfläche des lokalen Collectors und der Google Cloud Console, wenn Sie den Rohwert kumulativer Prometheus-Messwerte abfragen, einschließlich Zähler, Histogramme und Zusammenfassungen. Dieses Verhalten ist so vorgesehen.

Monarch erfordert Startzeitstempel, Prometheus hat jedoch keine Startzeitstempel. Managed Service for Prometheus generiert Startzeitstempel, indem der erste aufgenommene Punkt in einer Zeitreihe übersprungen und in einen Startzeitstempel umgewandelt wird. Von den Werten nachfolgender Punkte wird der Wert des übersprungenen Punktes abgezogen, damit die Preise korrekt sind. Dies führt zu einem anhaltenden Defizit beim Rohwert dieser Punkte.

Die Differenz zwischen der Zahl in der Collector-UI und der Zahl in der Google Cloud Console entspricht dem ersten Wert, der in der Collector-UI aufgezeichnet wurde. Dies ist zu erwarten, da das System diesen Anfangswert überspringt und von den nachfolgenden Punkten abzieht.

Das ist akzeptabel, da in der Produktion keine Abfrage für Rohwerte für kumulative Messwerte ausgeführt werden muss. Alle nützlichen Abfragen erfordern eine rate()-Funktion oder ähnliches. In diesem Fall ist der Unterschied über einen beliebigen Zeitraum zwischen den beiden UIs identisch. Kumulative Messwerte steigen immer an. Daher können Sie keine Benachrichtigung für eine Rohabfrage einrichten, da eine Zeitreihe einen Grenzwert nur einmal erreicht. Alle nützlichen Benachrichtigungen und Diagramme verdeutlichen die Änderung oder die Änderungsrate des Werts.

Der Collector speichert nur etwa 10 Minuten an Daten lokal. Abweichungen bei den Rohkumulativwerten können auch durch ein Zurücksetzen vor Ablauf der 10 Minuten auftreten. Um diese Möglichkeit auszuschließen, legen Sie beim Vergleichen der Benutzeroberfläche des Collectors mit der Google Cloud Console einen Rückblickzeitraum von nur 10 Minuten fest.

Abweichungen können auch durch mehrere Worker-Threads in Ihrer Anwendung verursacht werden, die jeweils einen /metrics-Endpunkt haben. Wenn Ihre Anwendung mehrere Threads startet, müssen Sie die Prometheus-Clientbibliothek in den Multiprozessmodus versetzen. Weitere Informationen finden Sie in der Dokumentation zur Verwendung des Multiprozessmodus in der Python-Clientbibliothek von Prometheus.

Fehlende Zählerdaten oder fehlerhafte Histogramme

Das häufigste Signal für dieses Problem ist, dass beim Abfragen eines einfachen Zählermesswerts (z. B. eine PromQL-Abfrage von metric_name_foo) entweder keine Daten oder Datenlücken angezeigt werden. Sie können das bestätigen, wenn Daten nach dem Hinzufügen einer rate-Funktion zu Ihrer Abfrage (z. B. rate(metric_name_foo[5m])) angezeigt werden.

Möglicherweise stellen Sie fest, dass Ihre aufgenommenen Stichproben stark gestiegen sind, ohne dass das Scraping-Volumen erheblich geändert wurde oder dass neue Messwerte mit den Suffixen "unknown" oder "unknown:counter" in Cloud Monitoring erstellt werden.

Möglicherweise stellen Sie auch fest, dass Histogrammvorgänge wie die quantile()-Funktion nicht wie erwartet funktionieren.

Diese Probleme treten auf, wenn ein Messwert ohne Prometheus-Messwerttyp erfasst wird. Da Monarch stark typisiert ist, berücksichtigt Managed Service for Prometheus nicht typisierte Messwerte, indem ihnen das Suffix „unbekannt“ hinzugefügt und sie zweimal aufgenommen werden: einmal als Messwert und einmal als Zähler. Die Abfrage-Engine wählt dann anhand der verwendeten Abfragefunktionen aus, ob der zugrunde liegende Messwert für Messwerte oder Zähler abgefragt werden soll.

Diese Heuristik funktioniert in der Regel recht gut, kann jedoch bei der Abfrage eines Rohmesswerts „unknown:counter“ zu Problemen wie seltsamen Ergebnissen führen. Da Histogramme in Monarch spezielle Typen von Objekten sind, funktionieren Histogrammfunktionen nicht, wenn die drei erforderlichen Histogrammmesswerte als einzelne Zählermesswerte aufgenommen werden. Da Messwerte unbekannten Typs zweimal aufgenommen werden, verdoppelt sich die Anzahl der aufgenommenen Stichproben, wenn Sie keinen TYPE festlegen.

Häufige Gründe dafür, dass TYPE möglicherweise nicht festgelegt ist:

  • Versehentliches Konfigurieren eines Managed Service for Prometheus-Collectors als Föderationsserver Föderation wird nicht bei Verwendung von Managed Service for Prometheus unterstützt. Da eine Föderation absichtlich TYPE-Informationen löscht, führt die Implementierung der Föderation zu Messwerten unbekannten Typs.
  • Prometheus Remote Write an beliebiger Stelle in der Datenaufnahmepipeline verwenden Bei diesem Protokoll werden auch TYPE-Informationen absichtlich gelöscht.
  • Mit einer Umschreiberegel, die den Messwertnamen ändert. Dadurch wird die Verknüpfung des umbenannten Messwerts mit den TYPE-Informationen aufgehoben, die mit dem ursprünglichen Messwertnamen verknüpft waren.
  • Der Exporter gibt für jeden Messwert keinen TYPE aus.
  • Ein vorübergehendes Problem, bei dem TYPE beim ersten Start des Collectors gelöscht wird.

So beheben Sie das Problem:

  • Beenden Sie die Verwendung der Föderation mit Managed Service for Prometheus. Wenn Sie die Kardinalität und die Kosten durch die Zusammenfassung von Daten reduzieren möchten, bevor Sie sie an Monarch senden, finden Sie weitere Informationen unter Lokale Aggregation konfigurieren.
  • Verwenden Sie Prometheus Remote Write nicht mehr in Ihrem Sammlungspfad.
  • Rufen Sie den Endpunkt /metrics auf, um zu prüfen, ob das Feld # TYPE für jeden Messwert vorhanden ist.
  • Löschen Sie alle Regeln zum Umbenennen, die den Namen eines Messwerts ändern.
  • Löschen Sie alle in Konflikt stehenden Messwerte mit dem Suffix "unknown" oder "unknown:counter", indem Sie DeleteMetricDescriptor aufrufen.
  • Oder Sie können Zähler immer mit rate oder einer anderen Zählerverarbeitungsfunktion abfragen.

Grafana-Daten werden nach dem Neustart des Pods nicht beibehalten

Wenn Ihre Daten nach einem Neustart des Pods aus Grafana verschwinden, aber in Cloud Monitoring sichtbar sind, verwenden Sie Grafana, um die lokale Prometheus-Instanz anstelle von Managed Service for Prometheus abzufragen.

Informationen zum Konfigurieren von Grafana für die Verwendung des verwalteten Dienstes als Datenquelle finden Sie unter Grafana.

Grafana-Dashboards importieren

Informationen zur Verwendung und Fehlerbehebung des Dashboard-Importers finden Sie unter Grafana-Dashboards in Cloud Monitoring importieren.

Informationen zu Problemen bei der Konvertierung des Dashboard-Inhalts finden Sie in der Datei README des Importers.

Probleme bei der Datenaufnahme

Probleme bei der Datenaufnahme können sich entweder auf die Sammlungs- oder Regelauswertung beziehen. Sehen Sie sich als Erstes die Fehlerlogs für die verwaltete Sammlung an. Sie können die folgenden Befehle ausführen:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

In GKE Autopilot-Clustern können Sie die folgenden Befehle ausführen:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Mit dem Zielstatusfeature können Sie Fehler in Ihrem Extraktionsziel beheben. Weitere Informationen finden Sie unter Informationen zum Zielstatus.

Endpunktstatus fehlt oder ist zu alt

Wenn Sie das Zielstatusfeature aktiviert haben, aber bei einer oder mehreren Ihrer PodMonitoring- oder ClusterPodMonitoring-Ressourcen das Feld oder der Wert Status.Endpoint Statuses fehlt, haben Sie möglicherweise eines der folgenden Probleme:

  • Managed Service for Prometheus konnte keinen Collector auf demselben Knoten wie einer Ihrer Endpunkte erreichen.
  • Mindestens eine Ihrer PodMonitoring- oder ClusterPodMonitoring-Konfigurationen hat keine gültigen Ziele.

Ähnliche Probleme können auch dazu führen, dass das Feld Status.Endpoint Statuses.Last Update Time einen Wert enthält, der älter ist als einige Minuten plus das Extraktionsintervall.

Prüfen Sie zur Behebung dieses Problems zuerst, ob die mit Ihrem Scraping-Eendpunkt verknüpften Kubernetes-Pods ausgeführt werden. Wenn Ihre Kubernetes-Pods ausgeführt werden, die Labelselektoren übereinstimmen und Sie manuell auf die Scraping-Endpunkte zugreifen können (in der Regel durch Aufrufen des Endpunkts /metrics), überprüfen Sie, ob die Managed Service for Prometheus-Collectors ausgeführt werden.

Der Anteil der Collectors ist kleiner als 1

Wenn Sie die Zielstatusfunktion aktiviert haben, erhalten Sie Statusinformationen zu Ihren Ressourcen. Der Wert Status.Endpoint Statuses.Collectors Fraction Ihrer PodMonitoring- oder ClusterPodMonitoring-Ressourcen gibt den Anteil der erreichbaren Collectors an, ausgedrückt mit einem Wert zwischen 0 und 1. Beispiel: Der Wert 0.5 gibt an, dass 50 % Ihrer Collectors erreichbar sind. Der Wert 1 gibt an, dass 100 % Ihrer Collectors erreichbar sind.

Wenn das Feld Collectors Fraction einen anderen Wert als 1 hat, sind ein oder mehrere Collectors nicht erreichbar und Messwerte in einem dieser Knoten werden möglicherweise nicht extrahiert. Sorgen Sie dafür, dass alle Collectors ausgeführt werden und über das Clusternetzwerk erreichbar sind. Mit dem folgenden Befehl können Sie den Status von Collector-Pods aufrufen:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

In GKE Autopilot-Clustern sieht dieser Befehl geringfügig anders aus:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Mit dem folgenden Befehl können Sie einzelne Collector-Pods (z. B. einen Collector-Pod mit dem Namen collector-12345) untersuchen:

kubectl -n gmp-system describe pods/collector-12345

Führen Sie in GKE Autopilot-Clustern den folgenden Befehl aus:

kubectl -n gke-gmp-system describe pods/collector-12345

Wenn Collectors fehlerhaft sind, finden Sie weitere Informationen unter Fehlerbehebung bei GKE-Arbeitslasten.

Wenn die Collectors fehlerfrei sind, prüfen Sie die Operatorlogs. Um die Operatorlogs zu prüfen, führen Sie zuerst den folgenden Befehl aus, um den Namen des Operator-Pods zu ermitteln:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Führen Sie in GKE Autopilot-Clustern den folgenden Befehl aus:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Prüfen Sie dann die Operatorlogs (z. B. einen Operator-Pod mit dem Namen gmp-operator-12345) mit dem folgenden Befehl:

kubectl -n gmp-system logs pods/gmp-operator-12345

Führen Sie in GKE Autopilot-Clustern den folgenden Befehl aus:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Fehlerhafte Ziele

Wenn Sie das Zielstatusfeature aktiviert haben, aber eine oder mehrere Ihrer PodMonitoring- oder ClusterPodMonitoring-Ressourcen im Feld Status.Endpoint Statuses.Unhealthy Targets einen anderen Wert als 0 haben, kann der Collector eines oder mehrere Ihrer Ziele nicht extrahieren.

Sehen Sie sich das Feld Sample Groups an, das Ziele nach Fehlermeldung gruppiert, und suchen Sie das Feld Last Error. Das Feld Last Error stammt von Prometheus und gibt an, warum das Ziel nicht extrahiert werden konnte. Prüfen Sie zur Behebung dieses Problems anhand der Beispielziele als Referenz, ob die Scraping-Endpunkte ausgeführt werden.

Nicht autorisierter Scrape-Endpunkt

Wenn einer der folgenden Fehler angezeigt wird und für Ihr Scraping-Ziel eine Autorisierung erforderlich ist, ist Ihr Collector entweder nicht für die Verwendung des richtigen Autorisierungstyps eingerichtet oder verwendet die falsche Autorisierungsnutzlast:

  • server returned HTTP status 401 Unauthorized
  • x509: certificate signed by unknown authority

Informationen zur Behebung dieses Problems finden Sie unter Autorisierten Scraping-Endpunkt konfigurieren.

Das Kontingent wurde überschritten.

Wenn der folgende Fehler angezeigt wird, haben Sie Ihr Aufnahmekontingent für die Cloud Monitoring API überschritten:

  • „429: Kontingent für Kontingentmesswert „Zeitachsenaufnahmeanfragen“ wurde überschritten und „Zeitachsenaufnahmeanfragen pro Minute“ des Dienstes „monitoring.googleapis.com' for consumer 'project_number:PROJECT_NUMBER“ für den Nutzer „project_number:PROJECT_NUMBER'., rateLimitExceeded“ wurde begrenzt

Dieser Fehler tritt häufig auf, wenn Sie den verwalteten Dienst zum ersten Mal aufrufen. Das Standardkontingent ist bei 100.000 Samples pro Sekunde aufgebraucht.

Senden Sie zur Behebung dieses Problems eine Anfrage zur Erhöhung Ihres Aufnahmekontingents für die Monitoring API. Wenn Sie Hilfe benötigen, wenden Sie sich an den Google Cloud-Support. Weitere Informationen zu Kontingenten finden Sie unter Mit Kontingenten arbeiten.

Fehlende Berechtigung für das Standarddienstkonto des Knotens

Wenn einer der folgenden Fehler angezeigt wird, fehlen dem Standarddienstkonto auf dem Knoten möglicherweise Berechtigungen:

  • „Abfrage ausführen: Fehler bei der Abfrage von Prometheus: client_error: Clientfehler: 403“
  • „Bereitschaftsprüfung fehlgeschlagen: HTTP-Prüfung fehlgeschlagen mit Statuscode: 503“
  • „Fehler beim Abfragen der Prometheus-Instanz“

Die verwaltete Sammlung und der Evaluator für verwaltete Regeln in Managed Service for Prometheus verwenden beide das Standarddienstkonto auf dem Knoten. Dieses Konto wird mit allen erforderlichen Berechtigungen erstellt, Kunden entfernen jedoch manchmal manuell die Monitoring-Berechtigungen. Das Entfernen führt dazu, dass die Auswertung der Sammlung und Regeln fehlschlägt.

Führen Sie einen der folgenden Schritte aus, um die Berechtigungen des Dienstkontos zu prüfen:

  • Ermitteln Sie den zugrunde liegenden Compute Engine-Knotennamen und führen Sie dann den folgenden Befehl aus:

    gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts

    Suchen Sie nach dem String https://www.googleapis.com/auth/monitoring. Fügen Sie gegebenenfalls Monitoring hinzu, wie unter Falsch konfiguriertes Dienstkonto beschrieben.

  • Rufen Sie die zugrunde liegende VM im Cluster auf und prüfen Sie die Konfiguration des Dienstkontos des Knotens:

    1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

      Zur Seite Kubernetes-Cluster

      Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Kubernetes Engine lautet.

    2. Wählen Sie Knoten aus und klicken Sie dann in der Tabelle Knoten auf den Namen des Knotens.

    3. Klicken Sie auf Details.

    4. Klicken Sie auf den Link VM-Instanz.

    5. Suchen Sie den Bereich API und Identitätsverwaltung und klicken Sie auf Details ansehen.

    6. Suchen Sie nach der Stackdriver Monitoring API mit uneingeschränktem Zugriff.

Es ist auch möglich, dass der Datenquellen-Syncer oder die Prometheus-Benutzeroberfläche so konfiguriert wurde, dass sie das falsche Projekt betrachtet. Informationen zum Prüfen, ob Sie den beabsichtigten Messwertbereich abfragen, finden Sie unter Abgefragtes Projekt ändern.

Falsch konfiguriertes Dienstkonto

Wenn eine der folgenden Fehlermeldungen angezeigt wird, hat das vom Collector verwendete Dienstkonto nicht die richtigen Berechtigungen:

  • „code = PermissionDenied desc = Berechtigung monitoring.timeSeries.create abgelehnt (oder die Ressource ist nicht vorhanden)“
  • „google: Es konnten keine Standardanmeldedaten gefunden werden. Weitere Informationen finden Sie unter https://developers.google.com/accounts/docs/application-default-credentials.“

So prüfen Sie, ob Ihr Dienstkonto die richtigen Berechtigungen hat:

  1. Öffnen Sie in der Google Cloud Console die Seite IAM:

    Rufen Sie IAM auf.

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM und Verwaltung ist.

  2. Suchen Sie den Namen des Dienstkontos in der Liste der Hauptkonten. Prüfen Sie, ob der Name des Dienstkontos korrekt geschrieben ist. Klicken Sie dann auf Bearbeiten.

  3. Wählen Sie das Feld Rolle aus, klicken Sie auf Aktuell verwendet und suchen Sie nach der Rolle "Monitoring Metric Writer" oder "Monitoring Editor". Wenn das Dienstkonto keine dieser Rollen hat, weisen Sie dem Dienstkonto die Rolle Monitoring Metric Writer (roles/monitoring.metricWriter) zu.

Wenn Sie GKE Kubernetes nicht ausführen, müssen Sie Anmeldedaten sowohl an die Collector- als auch die Regelauswertung explizit übergeben. Sie müssen die Anmeldedaten unter rules und collection wiederholen. Weitere Informationen finden Sie unter Anmeldedaten explizit angeben (für Sammlungen) oder Anmeldedaten explizit angeben (für Regeln).

Dienstkonten sind häufig auf ein einzelnes Google Cloud-Projekt beschränkt. Wenn Sie ein Dienstkonto zum Schreiben von Messwertdaten für mehrere Projekte verwenden, z. B. wenn ein Evaluator für verwaltete Regeln einen Messwertbereich mit mehreren Projekten abfragt, kann dieser Berechtigungsfehler auftreten. Wenn Sie das Standarddienstkonto verwenden, sollten Sie ein dediziertes Dienstkonto konfigurieren, damit Sie die Berechtigung monitoring.timeSeries.create für mehrere Projekte sicher hinzufügen können. Wenn Sie diese Berechtigung nicht erteilen können, können Sie die Messwert-Umschreibung verwenden, um den Namen des project_id-Labels zu ändern. Die Projekt-ID wird dann standardmäßig in das Google Cloud-Projekt geändert, in dem Ihr Prometheus-Server oder die Regelauswertung ausgeführt wird.

Ungültige Scraping-Konfigurationen

Wenn der folgende Fehler angezeigt wird, ist Ihr PodMonitoring oder ClusterPodMonitoring nicht ordnungsgemäß formatiert:

  • „Interner Fehler: Fehler beim Aufrufen des Webhooks „validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com“: Post „https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s“: EOF““

Achten Sie zur Behebung dieses Problems darauf, dass Ihre benutzerdefinierte Ressource gemäß der Spezifikation ordnungsgemäß geformt ist.

Admission-Webhook konnte nicht geparst werden oder ungültige HTTP-Clientkonfiguration

In Versionen von Managed Service for Prometheus vor 0.12 wird möglicherweise ein Fehler ähnlich dem folgenden angezeigt, der sich auf die Geheimdaten-Injection in einem nicht standardmäßigen Namespace bezieht:

  • „Der Zulassungs-Webhook „validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com“ hat die Anfrage abgelehnt: ungültige Definition für Endpunkt mit Index 0: konnte nicht geparst werden oder ungültige Prometheus-HTTP-Clientkonfiguration: muss Namespace „my-custom-namespace“ verwenden, wurde aber „default“ zurückgegeben“

Führen Sie zur Problembehebung ein Upgrade auf Version 0.12 oder höher durch.

Probleme mit Extraktionsintervallen und Zeitüberschreitungen

Bei Verwendung von Managed Service for Prometheus darf das Zeitlimit für die Extraktion nicht größer sein als das Extraktionsintervall. Führen Sie den folgenden Befehl aus, um Ihre Logs auf dieses Problem zu prüfen:

kubectl -n gmp-system logs ds/collector prometheus

Führen Sie in GKE Autopilot-Clustern den folgenden Befehl aus:

kubectl -n gke-gmp-system logs ds/collector prometheus

Suchen Sie nach dieser Nachricht:

  • „Zeitlimit für Extraktion ist größer als Extraktionsintervall für Extraktionskonfiguration mit Jobname „PodMonitoring/gmp-system/example-app/go-metrics““

Stellen Sie zur Problembehebung den Wert des Extraktionsintervalls gleich oder größer dem Wert des Extraktionszeitlimits ein.

TYPE auf Messwert fehlt

Wenn der folgende Fehler angezeigt wird, fehlen im Messwert Informationen zum Typ:

  • „keine Metadaten für Messwertname „{metric_name}“ gefunden“

Wenn Sie feststellen möchten, ob das Problem auf fehlende Informationen zum Typ zurückzuführen ist, prüfen Sie die /metrics-Ausgabe der Exportanwendung. Wenn keine Zeile wie die folgende vorhanden ist, fehlen die Typinformationen:

# TYPE {metric_name} <type>

Bestimmte Bibliotheken, z. B. Bibliotheken von VictoriaMetrics älter als Version 1.28.0, löschen die Typinformationen absichtlich. Diese Bibliotheken werden von Managed Service for Prometheus nicht unterstützt.

Zeitachsenkollisionen

Wenn einer der folgenden Fehler angezeigt wird, versucht möglicherweise mehr als ein Collector, in dieselbe Zeitreihe zu schreiben:

  • „Eine oder mehrere TimeSeries konnten nicht geschrieben werden: Ein oder mehrere Punkte wurden häufiger als der für den Messwert konfigurierte maximale Stichprobenzeitraum geschrieben.“
  • „Eine oder mehrere TimeSeries konnten nicht geschrieben werden: Punkte müssen in der richtigen Reihenfolge geschrieben werden. Mindestens einer der angegebenen Punkte hat eine ältere Endzeit als der letzte Punkt.“

Dies sind die häufigsten Ursachen und Lösungen:

  • Hochverfügbarkeitspaare verwenden. Managed Service for Prometheus unterstützt keine herkömmliche Hochverfügbarkeitssammlung. Durch diese Konfiguration können mehrere Collectors erstellt werden, die versuchen, Daten in dieselbe Zeitreihe zu schreiben, was diesen Fehler verursacht.

    Deaktivieren Sie zur Behebung des Problems die doppelten Collectors. Dazu reduzieren Sie die Replikatanzahl auf 1 oder verwenden die unterstützte Hochverfügbarkeitsmethode.

  • Regeln für die Labelerstellung verwenden, insbesondere solche, die für Jobs oder Instanzen ausgeführt werden. Managed Service for Prometheus identifiziert eine eindeutige Zeitreihe teilweise durch die Kombination aus {project_id, location, cluster, namespace, job, instance}-Labels. Wenn Sie eine Labelregel verwenden, um diese Labels zu löschen, insbesondere die Labels job und instance, kommt es nicht selten zu einer Kollision. Das Überschreiben dieser Labels wird nicht empfohlen.

    Löschen Sie die Regel, die das Problem verursacht, um das Problem zu beheben. Dies kann häufig durch die Regel metricRelabeling erfolgen, die die Aktion labeldrop verwendet. Sie können die problematische Regel identifizieren, indem Sie alle Regeln für die Labelerstellung auskommentieren und diese dann wieder reaktivieren, bis der Fehler wieder auftritt.

Eine weniger häufige Ursache für Zeitachsenkollisionen ist die Verwendung eines Extraktionsintervalls, das kürzer als 5 Sekunden ist. Das von Managed Service for Prometheus unterstützte minimale Extraktionsintervall beträgt 5 Sekunden.

Limit für die Anzahl der Labels überschreiten

Wenn der folgende Fehler angezeigt wird, sind für einen Ihrer Messwerte möglicherweise zu viele Labels definiert:

  • „Eine oder mehrere TimeSeries konnten nicht geschrieben werden: Die neuen Labels würden dazu führen, dass der Messwert prometheus.googleapis.com/METRIC_NAME mehr als PER_PROJECT_LIMIT Labels hat.“

Dieser Fehler tritt normalerweise auf, wenn Sie die Definition des Messwerts schnell ändern, sodass ein Messwertname effektiv mehrere unabhängige Gruppen von Labelschlüsseln für die gesamte Lebensdauer Ihres Messwerts enthält. In Cloud Monitoring gibt es für jeden Messwert ein Limit für die Anzahl der Labels. Weitere Informationen finden Sie in den Limits für benutzerdefinierte Messwerte.

Es gibt drei Schritte, um dieses Problem zu lösen:

  1. Ermitteln Sie, warum ein bestimmter Messwert zu viele oder sich häufig ändernde Labels hat.

  2. Beheben Sie die Ursache des Problems. Hierfür können Sie die Regeln für die Labelerstellung für PodMonitoring anpassen, den Exporter ändern oder die Instrumentierung korrigieren.

  3. Löschen Sie den Messwertdeskriptor für diesen Messwert (was zu Datenverlust führt), damit er mit einem kleineren, stabileren Satz von Labels neu erstellt werden kann. Dazu können Sie die Methode metricDescriptors.delete verwenden.

Die häufigsten Ursachen für das Problem sind:

  • Messwerte von Exportern oder Anwendungen erfassen, die dynamische Labels an Messwerten anhängen. Beispiel: Selbst bereitgestelltes cAdvisor mit zusätzlichen Containerlabels und Umgebungsvariablen oder dem DataDog-Agent, der dynamische Annotationen einfügt.

    Zur Behebung dieses Problems können Sie einen metricRelabeling-Abschnitt auf dem PodMonitoring verwenden, um Labels entweder beizubehalten oder zu löschen. Einige Anwendungen und Exporter lassen auch die Konfiguration zu, die exportierte Messwerte ändert. cAdvisor bietet beispielsweise eine Reihe erweiterter Laufzeiteinstellungen, mit denen Labels dynamisch hinzugefügt werden können. Bei Verwendung der verwalteten Sammlung empfehlen wir die Verwendung der integrierten Sammlung automatischer Kubelet.

  • Die Verwendung von Regeln für die Labelerstellung, insbesondere solche, die Labelnamen dynamisch anhängen, kann zu einer unerwarteten Anzahl von Labels führen.

    Löschen Sie den Regeleintrag, der das Problem verursacht, um das Problem zu beheben.

Ratenbegrenzung für das Erstellen und Aktualisieren von Messwerten und Labels

Wenn der folgende Fehler angezeigt wird, haben Sie die Ratenbegrenzung pro Minute beim Erstellen neuer Messwerte und Hinzufügen neuer Messwertlabels zu vorhandenen Messwerten erreicht:

  • „Anfrage gedrosselt. Sie haben das Limit pro Projekt für Änderungen der Messwert- oder Labeldefinition pro Minute erreicht."

Diese Ratenbegrenzung wird normalerweise nur erreicht, wenn Sie zum ersten Mal eine Einbindung in Managed Service for Prometheus vornehmen, z. B. beim Migrieren einer vorhandenen, ausgereiften Prometheus-Bereitstellung, um die selbst bereitgestellte Sammlung zu verwenden. Dies ist keine Ratenbeschränkung für die Datenaufnahme. Dieses Ratenlimit gilt nur, wenn noch-nie-dagewesene Messwerte erstellt oder neue Messwerte zu vorhandenen Messwerten hinzugefügt werden.

Dieses Kontingent ist fest, aber alle Probleme sollten automatisch behoben werden, wenn neue Messwerte und Messwertlabels bis zum Limit pro Minute erstellt werden.

Limits für die Anzahl der Messwertdeskriptoren

Wenn der folgende Fehler angezeigt wird, haben Sie das Kontingentlimit für die Anzahl der Messwertbeschreibungen in einem einzelnen Google Cloud-Projekt erreicht:

  • „Ihr Kontingent für Messwertbeschreiber ist aufgebraucht.“

Standardmäßig ist dieses Limit auf 25.000 festgelegt. Dieses Kontingent kann auf Anfrage aufgehoben werden, wenn Ihre Messwerte korrekt formatiert sind. Es ist jedoch viel wahrscheinlicher, dass Sie dieses Limit erreichen, weil Sie fehlerhafte Messwertnamen in das System aufnehmen.

Prometheus hat ein dimensionales Datenmodell, bei dem Informationen wie der Cluster- oder Namespacename als Labelwert codiert werden sollten. Wenn die Dimensionsinformationen stattdessen in den Messwertnamen selbst eingebettet sind, steigt die Anzahl der Messwertbeschreiber unendlich an. Außerdem ist es in diesem Szenario aufgrund der nicht ordnungsgemäßen Verwendung von Labels viel schwieriger, Daten in Clustern, Namespaces oder Diensten abzufragen und zusammenzuführen.

Weder Cloud Monitoring noch Managed Service for Prometheus unterstützen nichtdimensionale Messwerte, z. B. solche, die für StatsD oder Graphite formatiert sind. Die meisten Prometheus-Exporter sind bereits korrekt konfiguriert. Bestimmte Exporter wie der StatsD-Exporter, der Vault-Exporter oder der mit Istio gelieferte Envoy-Proxy müssen jedoch explizit so konfiguriert werden, dass sie Labels verwenden, anstatt Informationen in den Messwertnamen einzubetten. Beispiele für fehlerhafte Messwertnamen:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

So bestätigen Sie das Problem:

  1. Wählen Sie in der Google Cloud Console das Google Cloud-Projekt aus, das mit dem Fehler verknüpft ist.

  2. Rufen Sie in der Google Cloud Console die Seite  Messwertverwaltung auf:

    Zur Messwertverwaltung

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  3. Die Summe der aktiven und inaktiven Messwerte muss über 25.000 liegen. In den meisten Fällen sollten Sie eine große Anzahl inaktiver Messwerte sehen.
  4. Sortieren Sie nach Abrechenbares Volumen von Samples in aufsteigender Reihenfolge, blättern Sie durch die Liste und suchen Sie nach Mustern.

Alternativ können Sie das Problem mit dem Metrics Explorer prüfen:

  1. Wählen Sie in der Google Cloud Console das Google Cloud-Projekt aus, das mit dem Fehler verknüpft ist.

  2. Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf.

    Zum Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  3. Klicken Sie im Query Builder auf "einen Messwert auswählen" und entfernen Sie dann das Häkchen aus dem Kästchen "Aktiv".
  4. Geben Sie „prometheus“ in die Suchleiste ein.
  5. Suchen Sie nach Mustern in den Namen der Messwerte.

Sobald Sie die Muster erkannt haben, die auf fehlerhafte Messwerte hinweisen, können Sie das Problem beheben, indem Sie den Exporter an der Quelle korrigieren und dann die betreffenden Messwertdeskriptoren löschen.

Damit dieses Problem nicht noch einmal auftritt, müssen Sie zuerst den entsprechenden Exporteur so konfigurieren, dass keine fehlerhaften Messwerte mehr gesendet werden. Weitere Informationen finden Sie in der Dokumentation Ihres Exporteurs. Sie können prüfen, ob das Problem behoben wurde, indem Sie den /metrics-Endpunkt manuell aufrufen und die exportierten Messwertnamen prüfen.

Sie können dann Ihr Kontingent freigeben, indem Sie die fehlerhaften Messwerte mit der projects.metricDescriptors.delete-Methode löschen. Damit Sie die Liste der fehlerhaften Messwerte leichter durchgehen können, stellen wir Ihnen ein Golang-Script zur Verfügung. Dieses Script akzeptiert einen regulären Ausdruck, mit dem fehlerhafte Messwerte identifiziert werden können. Alle Messwertdeskriptoren, die dem Muster entsprechen, werden gelöscht. Da das Löschen von Messwerten nicht rückgängig gemacht werden kann, empfehlen wir dringend, das Script zuerst im Probelaufmodus auszuführen.

Keine Fehler und keine Messwerte

Wenn Sie die verwaltete Sammlung verwenden, werden keine Fehler angezeigt, aber keine Daten werden in Cloud Monitoring angezeigt. Die wahrscheinlichste Ursache ist, dass Ihre Messwertexporter oder Extraktionskonfigurationen nicht richtig konfiguriert sind. Managed Service for Prometheus sendet keine Zeitachsendaten, es sei denn, Sie wenden zuerst eine gültige Extraktionskonfiguration an.

Um festzustellen, ob dies die Ursache ist, versuchen Sie, eine Beispielanwendung und eine Beispiel-PodMonitoring-Ressource bereitzustellen. Wenn Sie jetzt den Messwert up sehen, was einige Minuten dauern kann, liegt das Problem an der Extraktionskonfiguration oder am Exporter.

Es kommen viele Ursachen in Frage. Prüfen Sie Folgendes:

  • PodMonitoring verweist auf einen gültigen Port.

  • Die Deployment-Spezifikation des Exporters hat ordnungsgemäß benannte Ports.

  • Die Selektoren (häufig app) stimmen mit den Deployment- und PodMonitoring-Ressourcen überein.

  • Sie können Daten am erwarteten Endpunkt und Port sehen, indem Sie sie manuell aufrufen.

  • Sie haben die PodMonitoring-Ressource im selben Namespace wie die Anwendung installiert, die Sie extrahieren möchten. Installieren Sie keine benutzerdefinierten Ressourcen oder Anwendungen im Namespace gmp-system oder gke-gmp-system.

  • Die Messwert- und Labelnamen entsprechen dem validierenden regulären Ausdruck von Prometheus. Managed Service for Prometheus unterstützt keine Labelnamen, die mit dem Zeichen _ beginnen.

  • Sie verwenden keinen Satz von Filtern, der alle Daten herausfiltert. Achten Sie darauf, dass es keine in Konflikt stehenden Filter gibt, wenn Sie einen collection-Filter in der Ressource OperatorConfig verwenden.

  • Bei Ausführung außerhalb von Google Cloud ist project oder project-id auf ein gültiges Google Cloud-Projekt und location auf eine gültige Google Cloud-Region festgelegt. Sie können global nicht als Wert für location verwenden.

  • Ihr Messwert gehört zu einem der vier Prometheus-Messwerttypen. Einige Bibliotheken wie Kube State Metrics stellen OpenMetrics-Messwerttypen wie Info, Statuset und GaugeHistogram bereit. Diese Messwerttypen werden von Managed Service für Prometheus jedoch nicht unterstützt und werden ohne Rückmeldung verworfen.

Für kurzlebige Ziele fehlen einige Messwerte

Google Cloud Managed Service for Prometheus ist bereitgestellt und es gibt keine Konfigurationsfehler. Einige Messwerte fehlen jedoch.

Ermitteln Sie die Bereitstellung, die die teilweise fehlenden Messwerte generiert. Wenn es sich bei der Bereitstellung um einen CronJob der Google Kubernetes Engine handelt, ermitteln Sie, wie lange der Job normalerweise ausgeführt wird:

  1. Suchen Sie die YAML-Datei für die Bereitstellung des Cron-Jobs und den Status, der am Ende der Datei aufgeführt ist. Der Status in diesem Beispiel zeigt, dass der Job eine Minute lang ausgeführt wurde:

      status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"

  2. Wenn die Laufzeit weniger als fünf Minuten beträgt, wird der Job nicht lange genug ausgeführt, um die Messdaten regelmäßig zu erfassen.

    Versuchen Sie Folgendes, um dieses Problem zu beheben:

    • Konfigurieren Sie den Job so, dass er erst beendet wird, wenn mindestens fünf Minuten seit dem Start vergangen sind.

    • Konfigurieren Sie den Job so, dass vor dem Beenden erkannt wird, ob Messwerte extrahiert wurden. Für diese Funktion ist Bibliotheksunterstützung erforderlich.

    • Erwägen Sie, einen logbasierten Verteilungsmesswert zu erstellen, anstatt Messwertdaten zu erfassen. Dieser Ansatz wird empfohlen, wenn Daten mit geringer Häufigkeit veröffentlicht werden. Weitere Informationen finden Sie unter Übersicht über logbasierte Messwerte.

  3. Wenn die Ausführungsdauer länger als fünf Minuten ist oder nicht konsistent ist, lesen Sie den Abschnitt Ungesunde Ziele in diesem Dokument.

Probleme mit der Erfassung über Exporter

Prüfen Sie Folgendes, wenn Ihre Messwerte aus einem Exporter nicht aufgenommen werden:

  • Prüfen Sie mit dem Befehl kubectl port-forward, ob der Exporter funktioniert und exportiert.

    Wenn Sie beispielsweise prüfen möchten, ob Pods mit dem Selektor app.kubernetes.io/name=redis im Namespace test Messwerte am Endpunkt /metrics an Port 9121 ausgeben, können Sie so eine Portweiterleitung durchführen:

    kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121

    Greifen Sie über den Browser oder curl in einer anderen Terminalsitzung auf den Endpunkt localhost:9121/metrics zu, um zu prüfen, ob die Messwerte vom Exporter für die Extraktion bereitgestellt werden.

  • Prüfen Sie, ob Sie die Messwerte in der Google Cloud Console, aber nicht in Grafana abfragen können. Wenn dies der Fall ist, liegt das Problem bei Grafana, nicht bei der Erfassung der Messwerte.

  • Prüfen Sie, ob der verwaltete Collector den Exporter extrahieren kann. Prüfen Sie dazu die Prometheus-Weboberfläche, die der Collector zur Verfügung stellt.

    1. Ermitteln Sie den verwalteten Collector, der auf demselben Knoten ausgeführt wird, auf dem der Exporter ausgeführt wird. Wenn der Exporter beispielsweise auf Pods im Namespace test ausgeführt wird und die Pods mit app.kubernetes.io/name=redis gekennzeichnet sind, ermitteln Sie mit dem folgenden Befehl den verwalteten Collector, der auf demselben Knoten ausgeführt wird:

      kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'

    2. Richten Sie die Portweiterleitung von Port 19090 des verwalteten Collectors ein:

      kubectl port-forward POD_NAME -n gmp-system 19090

    3. Rufen Sie die URL localhost:19090/targets auf, um auf die Weboberfläche zuzugreifen. Wenn der Exporter als eines der Ziele aufgeführt ist, extrahiert der verwaltete Collector den Exporter ordnungsgemäß.

OOM-Fehler (Out Of Memory) des Collectors

Wenn Sie eine verwaltete Sammlung verwenden und auf Ihren Collectorn OOM-Fehler (Out Of Memory) auftreten, sollten Sie vertikales Pod-Autoscaling aktivieren.

Der Operator hat Fehler aufgrund von fehlendem Arbeitsspeicher

Wenn Sie die verwaltete Datenerhebung verwenden und bei Ihrem Operator Fehler aufgrund von ungenügendem Arbeitsspeicher auftreten, können Sie die Funktion für den Zielstatus deaktivieren. Die Funktion „Status von Leistungszielen“ kann in größeren Clustern zu Leistungsproblemen bei den Operatoren führen.

Firewalls

Eine Firewall kann sowohl Aufnahme- als auch Abfrageprobleme verursachen. Die Firewall muss so konfiguriert sein, dass sowohl POST- als auch GET-Anfragen an den Monitoring API-Dienst monitoring.googleapis.com zugelassen werden, um Aufnahmen und Abfragen zuzulassen.

Fehler bei gleichzeitigen Änderungen

Die Fehlermeldung „Zu viele gleichzeitige Änderungen an der Projektkonfiguration“ ist in der Regel vorübergehend und wird nach einigen Minuten behoben. Dies ist gewöhnlich darauf zurückzuführen, dass eine Regel für das Relabeling entfernt wird, die sich auf viele verschiedene Messwerte auswirkt. Durch das Entfernen wird eine Warteschlange von Aktualisierungen der Messwertdeskriptoren in Ihrem Projekt erstellt. Der Fehler verschwindet, sobald die Warteschlange verarbeitet wird.

Weitere Informationen finden Sie unter Limits für das Erstellen und Aktualisieren von Messwerten und Labels.

Inkompatible Werttypen

Wenn der folgende Fehler bei der Datenaufnahme oder Abfrage angezeigt wird, liegt eine Inkompatibilität des Werttyps in Ihren Messwerten vor:

  • „Der Werttyp für den Messwert prometheus.googleapis.com/metric_name/gauge muss INT64 sein, ist aber DOUBLE“
  • „Der Werttyp für den Messwert prometheus.googleapis.com/metric_name/gauge muss DOUBLE sein, ist aber INT64.“
  • „Eine oder mehrere TimeSeries konnten nicht geschrieben werden: Der Werttyp für den Messwert prometheus.googleapis.com/target_info/gauge kollidiert mit dem vorhandenen Werttyp (INT64)“

Dieser Fehler kann bei der Datenaufnahme auftreten, da Monarch das Schreiben von Daten vom Typ DOUBLE in Messwerte vom Typ INT64 und umgekehrt nicht unterstützt. Dieser Fehler kann auch bei Abfragen mit einem Messwertbereich mit mehreren Projekten auftreten, da Monarch Messwerte vom Typ DOUBLE in einem Projekt nicht mit Messwerten vom Typ INT64 in einem anderen Projekt zusammenführen kann.

Dieser Fehler tritt nur auf, wenn OpenTelemetry-Empfänger Daten melden. Die Wahrscheinlichkeit ist höher, wenn sowohl OpenTelemetry (mit dem googlemanagedprometheus-Exporteur) als auch Prometheus Daten für denselben Messwert melden, was häufig beim Messwert target_info der Fall ist.

Mögliche Ursachen:

  • Sie erfassen OTLP-Messwerte und die OTLP-Messwertbibliothek hat den Werttyp von DOUBLE in INT64 geändert, wie es bei den Java-Messwerten von OpenTelemetry der Fall war. Die neue Version der Messwertbibliothek ist jetzt nicht mehr mit dem Messwerttyp kompatibel, der mit der alten Version der Messwertbibliothek erstellt wurde.
  • Sie erfassen den Messwert target_info sowohl mit Prometheus als auch mit OpenTelemetry. Prometheus erfasst diesen Messwert als DOUBLE, OpenTelemetry als INT64. Ihre Messwerterfassungen schreiben jetzt zwei Werttypen in denselben Messwert im selben Projekt. Nur der Messwerterfassung, mit der der Messwertdeskriptor zuerst erstellt wurde, gelingt dies.
  • Sie erfassen target_info in einem Projekt mit OpenTelemetry als INT64 und target_info in einem anderen Projekt mit Prometheus als DOUBLE. Wenn Sie beide Messwerte demselben Messwertbereich hinzufügen und dann diesen Messwert über den Messwertbereich abfragen, führt dies zu einer ungültigen Vereinigung inkompatibler Messwerttypen.

Dieses Problem lässt sich beheben, indem Sie alle Messwerttypen auf „DOUBLE“ festlegen. Gehen Sie dazu so vor:

  1. Konfigurieren Sie Ihre OpenTelemetry-Collectors neu, damit alle Messwerte als DOUBLE erzwungen werden. Aktivieren Sie dazu das Flag „feature-gate“ exporter.googlemanagedprometheus.intToDouble.
  2. Löschen Sie alle INT64-Messwertdeskriptoren und lassen Sie sie als DOUBLE neu erstellen. Mit dem delete_metric_descriptors.go-Script können Sie diesen Vorgang automatisieren.

Durch die folgenden Schritte werden alle Daten gelöscht, die als INT64-Messwert gespeichert sind. Das Löschen der INT64-Messwerte ist die einzige Möglichkeit, dieses Problem vollständig zu beheben.