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 Sprache 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 finden Sie Informationen, mit denen Sie den Betrag steuern können, den Sie für kostenpflichtige 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
  • Verwenden Messwerten in Benachrichtigungsrichtlinien und benutzerdefinierten Dashboards
  • Rate von Messwert-Schreibfehlern

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:

  • Falsche Berechtigungen oder Anmeldedaten für Dienstkonten.
  • Fehlkonfiguration von Workload Identity, wenn dieses Feature für Ihren Cluster aktiviert ist. Weitere Informationen finden Sie unter Dienstkonto für Workload Identity konfigurieren.

Gehen Sie zuerst so vor:

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

  • Wenn Sie Workload Identity 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 finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & 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, 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.

Kontingent ü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.

Zählersummen, die nicht mit der Collector-UI und der Google Cloud Console übereinstimmen

Möglicherweise bemerken Sie einen Unterschied zwischen den Werten in der Prometheus-Benutzeroberfläche des lokalen Collectors und der Google Cloud Console, wenn Sie einen Rohzähler oder die Summe eines Zählers abfragen. Dieses Verhalten ist so vorgesehen.

Monarch benötigt Startzeitstempel, aber Prometheus hat keine Startzeitstempel. Managed Service for Prometheus generiert Startzeitzeitstempel, indem der erste aufgenommene Punkt in einer beliebigen Zeitachse übersprungen und in einen Startzeitstempel konvertiert wird. Dies führt zu einem dauerhaften Defekt in der Summe eines Zählers.

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.

Das ist akzeptabel, da keine Produktion für die Abfrage von Rohzählerwerten erforderlich ist. Alle nützlichen Abfragen für Zähler erfordern eine rate()-Funktion oder Ähnliches. In diesem Fall ist der Unterschied über jeden Zeithorizont zwischen den beiden UIs identisch. Zähler werden nur erhöht. Daher können Sie keine Benachrichtigung für eine Rohabfrage festlegen, da eine Zeitachse nur einen Grenzwert erreicht. Alle nützlichen Benachrichtigungen und Diagramme verdeutlichen die Änderung oder die Änderungsrate des Werts.

Der Collector speichert lokal nur etwa zehn Minuten Daten. Abweichungen bei den Rohzählersummen können auch aufgrund eines Zurücksetzens des Zählers vor dem 10-Minuten-Zeitraum auftreten. Wenn Sie diese Möglichkeit ausschließen möchten, legen Sie einen Abfrage-Lookback-Zeitraum von 10 Minuten fest, wenn Sie die Collector-UI mit der Google Cloud Console vergleichen.

Abweichungen können auch dadurch verursacht werden, dass mehrere Worker-Threads mit jeweils einem /metrics-Endpunkt in Ihrer Anwendung vorhanden sind. Wenn Ihre Anwendung mehrere Threads auslöst, müssen Sie die Prometheus-Clientbibliothek in den Multiprozess-Modus versetzen. Weitere Informationen finden Sie in der Dokumentation zum Verwenden des Multiprozess-Modus 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.

Außerdem stellen Sie möglicherweise fest, dass Histogrammvorgänge wie die Funktion quantile() nicht wie erwartet funktionieren.

Diese Probleme treten auf, wenn ein Messwert ohne Prometheus-Messwert TYPE erfasst wird. Da Monarch stark typisiert ist, berücksichtigt Managed Service for Prometheus Messwerte ohne Typ und fügt ihnen das Suffix "unknown" hinzu und nehmen sie zweimal, einmal als Gauge und einmal als Zähler auf. Die Abfrage-Engine wählt dann anhand der verwendeten Abfragefunktionen aus, ob die zugrunde liegende Messgerätanzeige oder der Zählermesswert 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 speziell typisierte Objekte in Monarch sind, funktioniert die Aufnahme der drei erforderlichen Histogrammmesswerte, da einzelne Zählermesswerte dazu führen, dass Histogrammfunktionen nicht funktionieren. Da Messwerte unbekannten Typs zweimal aufgenommen werden, wird die Menge der aufgenommenen Beispiele nicht verdoppelt, wenn kein TYPE festgelegt ist.

Häufige Gründe dafür, dass TYPE 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-Schreibvorgänge jederzeit in der Aufnahmepipeline verwenden. Bei diesem Protokoll werden außerdem TYPE-Informationen absichtlich gelöscht.
  • Eine Regel für das Relabeling verwenden, die den Messwertnamen ändert. Dadurch wird die Benennung des umbenannten Messwerts von den TYPE-Informationen getrennt, die dem ursprünglichen Messwertnamen zugeordnet sind.
  • Der Exporter gibt für jeden Messwert einen TYPE aus.
  • Ein vorübergehendes Problem, bei dem TYPE beim ersten Start des Collectors verworfen 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.
  • Beenden Sie die Verwendung von Prometheus Remote Write in Ihrem Sammlungspfad.
  • Prüfen Sie, ob das Feld # TYPE für jeden Messwert vorhanden ist. Rufen Sie dazu den Endpunkt /metrics auf.
  • Löschen Sie alle Regeln für die Labelerstellung, 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.
  • Eine oder mehrere Ihrer PodMonitoring- oder ClusterPodMonitoring-Konfigurationen haben zu keinem gültigen Ziel geführt.

Ä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 Funktion für den Zielstatus aktiviert haben, erhalten Sie Statusinformationen zu Ihren Ressourcen. Der Wert Status.Endpoint Statuses.Collectors Fraction Ihrer PodMonitoring- oder ClusterPodMonitoring-Ressourcen stellt den Anteil der Collectors dar, die von 0 bis 1 ausgedrückt werden und erreichbar sind. 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.

Kontingent ü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 ist.

    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 finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & 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.

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. die 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 Ratenbegrenzung für die Aufnahme von Datenpunkten. 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 Messwertdeskriptoren in einem einzelnen Google Cloud-Projekt erreicht:

  • „Ihr Messwertdeskriptorkontingent ist aufgebraucht.“

Dieses Limit ist standardmäßig auf 25.000 festgelegt. Obwohl dieses Kontingent auf Anfrage erhöht werden kann, wenn Ihre Messwerte wohlgeformt sind, ist es wahrscheinlicher, dass Sie dieses Limit erreichen, da Sie fehlerhafte Messwertnamen in das System aufnehmen.

Prometheus hat ein dimensionales Datenmodell, bei dem Informationen wie Cluster- oder Namespace-Name als Labelwert codiert werden sollen. Wenn dimensionale Informationen stattdessen in den Messwertnamen selbst eingebettet sind, erhöht sich die Anzahl der Messwertdeskriptoren unbegrenzt. Da Labels in diesem Szenario nicht ordnungsgemäß verwendet werden, wird es schwieriger, Daten über Cluster, Namespaces oder Dienste hinweg abzufragen und zusammenzufassen.

Weder Cloud Monitoring noch Managed Service for Prometheus unterstützen nichtdimensionale Messwerte, beispielsweise für StatsD oder Graphite formatiert. Während die meisten Prometheus-Exporter standardmäßig vorkonfiguriert sind, müssen bestimmte Exporter wie der StatsD-Exporter, der Vault-Exporter oder der mit Istio enthaltene Envoy-Proxy explizit für die Verwendung von Labels konfiguriert werden. anstelle von Informationen in den Messwertnamen. 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. Prüfen Sie,ob die Summe der Messwerte „Aktiv“ und „Inaktiv“ über 25.000 liegt. In den meisten Fällen sollten Sie eine große Anzahl inaktiver Messwerte sehen.
  4. Sortieren Sie die Logs nach Samples abrechenbares Volume aufsteigend, blättern Sie durch die Liste und suchen Sie nach Mustern.

Alternativ können Sie das Problem mit dem Metrics Explorer bestätigen:

  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 ermittelt haben, die auf fehlerhafte Messwerte hinweisen, können Sie das Problem beheben. Beheben Sie dazu den Exporter an der Quelle und löschen Sie dann die problematischen Messwertdeskriptoren.

Damit dieses Problem nicht noch einmal auftritt, konfigurieren Sie zuerst den relevanten Exporter so, dass keine fehlerhaften Messwerte mehr ausgegeben werden. Wir empfehlen Ihnen, sich die Dokumentation Ihres Exporters anzusehen. Sie können prüfen, ob Sie das Problem behoben haben. Rufen Sie dazu den Endpunkt /metrics manuell auf und prüfen Sie die exportierten Messwertnamen.

Sie können Ihr Kontingent dann freigeben, indem Sie die fehlerhaften Messwerte mit der Methode projects.metricDescriptors.delete löschen. Damit Sie die Liste fehlerhafter Messwerte einfacher iterieren können, stellen wir Ihnen ein Golang-Skript zur Verfügung, das Sie verwenden können. Dieses Skript akzeptiert einen regulären Ausdruck, der fehlerhafte Messwerte identifizieren kann, und löscht alle Messwertdeskriptoren, die mit dem Muster übereinstimmen. Da das Löschen von Messwerten nicht rückgängig gemacht werden kann, empfehlen wir dringend, das Skript 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 ist einer 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.

Einige Messwerte für Ziele mit kurzer Laufzeit fehlen

Google Cloud Managed Service for Prometheus wird bereitgestellt und es gibt keine Konfigurationsfehler. Es fehlen jedoch einige Messwerte.

Bestimmen Sie die Bereitstellung, die die teilweise fehlenden Messwerte generiert. Wenn das Deployment ein CronJob von Google Kubernetes Engine ist, legen Sie fest, wie lange der Job in der Regel ausgeführt wird:

  1. Suchen Sie die YAML-Datei für die Cronjob-Bereitstellung und suchen Sie den Status, der am Ende der Datei aufgelistet 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 Messwertdaten konsistent zu extrahieren.

    Versuchen Sie Folgendes, um dieses Problem zu beheben:

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

    • Konfigurieren Sie den Job so, dass vor dem Beenden erkannt wird, ob Messwerte extrahiert wurden. Für diese Funktion muss Bibliotheken unterstützt werden.

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

  3. Wenn die Laufzeit länger als fünf Minuten ist oder inkonsistent ist, lesen Sie den Abschnitt Fehlerhafte 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 abfragen können, aber nicht in Grafana. 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 über 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 Web-UI zuzugreifen. Wenn der Exporter als eines der Ziele aufgeführt ist, extrahiert der verwaltete Collector den Exporter ordnungsgemäß.

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.