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 die folgenden 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
• Nutzung von Messwerten in Benachrichtigungsrichtlinien und benutzerdefinierten Dashboards
• Fehlerrate beim Schreiben von Messwerten

Auf der Seite Messwertverwaltung können Sie auch nicht benötigte Messwerte ausschließen, um unnötige Kosten bei der Datenaufnahme zu vermeiden.

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 der Workload Identity-Föderation für GKE, wenn dieses Feature für Ihren Cluster aktiviert ist. Weitere Informationen finden Sie unter Dienstkonto für Workload Identity Federation for GKE konfigurieren.

Gehen Sie zuerst so vor:

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

• Wenn Sie die Workload Identity-Föderation für GKE verwenden, prüfen Sie, ob Ihr Dienstkonto die richtigen Berechtigungen hat. Gehen Sie dazu so vor:

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

     Rufen Sie IAM auf.

     Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & Admin lautet.

  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 der Workload Identity-Föderation für 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 Unterstützung benötigen, wenden Sie sich an den Google Cloud -Support. Weitere Informationen zu Kontingenten finden Sie in der Dokumentation zu Cloud-Kontingenten.

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 einemGoogle 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, 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 Google Cloud Console, wenn Sie den Rohwert von kumulativen Prometheus-Messwerten abfragen, einschließlich Zählern, Histogrammen und Zusammenfassungen. Dieses Verhalten ist so vorgesehen.

Monarch erfordert Startzeitstempel, Prometheus jedoch nicht. Managed Service for Prometheus generiert Startzeitstempel, indem der erste erfasste Punkt in einer Zeitreihe übersprungen und in einen Startzeitstempel umgewandelt wird. Bei nachfolgenden Punkten wird der Wert des ursprünglich übersprungenen Punkts von ihrem Wert abgezogen, damit die Raten korrekt sind. Das führt zu einem dauerhaften Defizit beim Rohwert dieser Punkte.

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

Das ist akzeptabel, da für die Produktion keine Abfrage für Rohwerte für kumulative Messwerte erforderlich ist. Für alle nützlichen Abfragen ist eine rate()-Funktion oder Ähnliches erforderlich. In diesem Fall ist der Unterschied über einen beliebigen Zeitraum hinweg in beiden Benutzeroberflächen identisch. Kumulative Messwerte nehmen immer zu. Daher können Sie keinen Alarm für eine Rohabfrage festlegen, da eine Zeitreihe einen Schwellenwert nur einmal erreicht. Alle nützlichen Benachrichtigungen und Diagramme verdeutlichen die Änderung oder die Änderungsrate des Werts.

Der Collector speichert nur etwa 10 Minuten lang Daten lokal. Abweichungen bei kumulativen Rohwerten können auch auftreten, wenn ein Reset vor dem 10-Minuten-Horizont erfolgt. Um diese Möglichkeit auszuschließen, sollten Sie beim Vergleich der Collector-Benutzeroberfläche mit der Google Cloud -Konsole nur einen Rückblickzeitraum von 10 Minuten für die Abfrage festlegen.

Abweichungen können auch dadurch verursacht werden, dass Ihre Anwendung mehrere Worker-Threads mit jeweils einem /metrics-Endpunkt hat. 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 untypisierte Messwerte, indem er sie mit „unknown“ kennzeichnet und zweimal erfasst, einmal als Gauge und einmal als Zähler. Die Abfrage-Engine entscheidet dann, ob der zugrunde liegende Messwert vom Typ „Zähler“ oder „Messgerät“ abgefragt wird, je nachdem, welche Abfragefunktionen Sie verwenden.

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 speziell typisierte Objekte sind, funktionieren Histogrammfunktionen nicht, wenn die drei erforderlichen Histogrammmesswerte als einzelne Zählermesswerte erfasst werden. Da Messwerte unbekannten Typs zweimal erfasst werden, verdoppelt sich die Anzahl der erfassten Stichproben, wenn Sie keinen TYPE festlegen.

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

• Ein Managed Service for Prometheus-Collector wurde versehentlich als Föderationsserver konfiguriert. 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 einem beliebigen Punkt in der Erfassungspipeline verwenden. Bei diesem Protokoll werden TYPE-Informationen bewusst weggelassen.
• Sie verwenden eine Umschreibungsregel, die den Messwertnamen ändert. Dadurch wird die Zuordnung des umbenannten Messwerts zu den TYP-Informationen des ursprünglichen Messwertnamens aufgehoben.
• Der Exporter gibt für jeden Messwert keinen TYPE aus.
• Ein vorübergehendes Problem, bei dem TYPE beim ersten Start des Collectors nicht berücksichtigt 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 Erfassungspfad.
• Prüfen Sie, ob das Feld # TYPE für jeden Messwert vorhanden ist. Rufen Sie dazu den Endpunkt /metrics auf.
• Löschen Sie alle Neubezeichnungsregeln, mit denen der Name eines Messwerts geändert wird.
• 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.

Sie können auch eine Regel zum Ausschließen von Messwerten in der Messwertverwaltung erstellen, um zu verhindern, dass Messwerte mit dem Suffix „unbekannt“ aufgenommen werden. Verwenden Sie dazu den regulären Ausdruck prometheus.googleapis.com/.+/unknown.*. Wenn Sie das zugrunde liegende Problem nicht beheben, bevor Sie diese Regel installieren, werden möglicherweise keine gewünschten Messwertdaten erfasst.

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.

Inkonsistente Ergebnisse von Abfrage- oder Benachrichtigungsregeln, die sich automatisch korrigieren

Möglicherweise stellen Sie ein Muster fest, bei dem für Abfragen über aktuelle Zeiträume, z. B. Abfragen, die von Aufzeichnungs- oder Benachrichtigungsregeln ausgeführt werden, unerklärliche Datenspitzen zurückgegeben werden. Wenn Sie den Anstieg untersuchen, indem Sie die Abfrage in Grafana oder Metrics Explorer ausführen, stellen Sie möglicherweise fest, dass der Anstieg verschwunden ist und die Daten wieder normal aussehen.

Dieses Verhalten kann häufiger auftreten, wenn eine der folgenden Bedingungen zutrifft:

• Sie führen viele sehr ähnliche Abfragen parallel aus, möglicherweise mithilfe von Regeln. Diese Anfragen können sich nur durch ein einzelnes Attribut unterscheiden. Sie haben beispielsweise 50 Aufzeichnungsregeln, die sich nur durch die VALUE für den Filter {foo="VALUE"} oder durch unterschiedliche [duration]-Werte für die rate-Funktion unterscheiden.
• Sie führen Abfragen mit „time=now“ ohne Puffer aus.
• Sie führen Sofortabfragen wie Benachrichtigungs- oder Aufzeichnungsregeln aus. Wenn Sie eine Aufzeichnungsregel verwenden, kann es sein, dass der gespeicherte Output den Spike enthält, er aber nicht gefunden wird, wenn Sie eine Abfrage für die Rohdaten ausführen.
• Sie fragen zwei Messwerte ab, um ein Verhältnis zu erstellen. Die Spitzen sind deutlicher, wenn die Anzahl der Zeitreihen in der Zähler- oder Nennerabfrage gering ist.
• Ihre Messwertdaten befinden sich in größeren Google Cloud Regionen wie us-central1 oder us-east4.

Für vorübergehende Spitzen bei solchen Anfragen gibt es mehrere mögliche Ursachen:

• (Häufigste Ursache) Ihre ähnlichen, parallelen Abfragen fordern alle Daten aus derselben Gruppe von Monarch-Knoten an, wodurch insgesamt viel Arbeitsspeicher auf jedem Knoten belegt wird. Wenn Monarch in einer Cloud-Region über ausreichend verfügbare Ressourcen verfügt, funktionieren Ihre Anfragen. Wenn in einer Cloud-Region Ressourcenengpässe bei Monarch auftreten, werden Anfragen auf jedem Knoten gedrosselt. Dabei werden Nutzer, die auf den einzelnen Knoten den meisten Arbeitsspeicher belegen, bevorzugt gedrosselt. Sobald Monarch wieder über genügend Ressourcen verfügt, funktionieren Ihre Anfragen wieder. Diese Anfragen können SLIs sein, die automatisch von Tools wie Sloth generiert werden.
• Sie haben Daten, die erst spät eintreffen, und Ihre Abfragen sind nicht tolerant gegenüber diesem Problem. Es dauert etwa 3 bis 7 Sekunden, bis neu geschriebene Daten abgefragt werden können. Dabei werden die Netzwerklatenz und Verzögerungen aufgrund von Ressourcenengpässen in Ihrer Umgebung nicht berücksichtigt. Wenn in Ihrer Abfrage keine Verzögerung oder kein Offset berücksichtigt wird, um verspätete Daten zu berücksichtigen, fragen Sie möglicherweise unwissentlich einen Zeitraum ab, für den nur teilweise Daten verfügbar sind. Sobald die Daten eingegangen sind, sehen die Abfrageergebnisse normal aus.
• Bei Monarch kann es zu geringfügigen Inkonsistenzen beim Speichern Ihrer Daten in verschiedenen Replikaten kommen. Die Abfrage-Engine versucht, das Replikat mit der besten Qualität auszuwählen. Wenn jedoch für verschiedene Abfragen unterschiedliche Replikate mit leicht unterschiedlichen Datensätzen ausgewählt werden, können sich die Ergebnisse zwischen den Abfragen geringfügig unterscheiden. Das ist ein erwartetes Verhalten des Systems. Ihre Benachrichtigungen sollten diese geringfügigen Abweichungen tolerieren.
• Eine ganze Monarch-Region ist möglicherweise vorübergehend nicht verfügbar. Wenn eine Region nicht erreichbar ist, behandelt die Abfrage-Engine die Region so, als hätte sie nie existiert. Sobald die Region wieder verfügbar ist, werden in den Abfrageergebnissen weiterhin Daten aus dieser Region zurückgegeben.

Um diesen möglichen Ursachen Rechnung zu tragen, sollten Sie darauf achten, dass Ihre Abfragen, Regeln und Benachrichtigungen den folgenden Best Practices entsprechen:

• Fassen Sie ähnliche Regeln und Benachrichtigungen in einer einzigen Regel zusammen, die nach Labels aggregiert wird, anstatt separate Regeln für jede Permutation von Labelwerten zu verwenden. Wenn es sich um Benachrichtigungsregeln handelt, können Sie labelbasierte Benachrichtigungen verwenden, um Benachrichtigungen aus der aggregierten Regel weiterzuleiten, anstatt einzelne Weiterleitungsregeln für jede Benachrichtigung zu konfigurieren.

  Wenn Sie beispielsweise ein Label foo mit den Werten bar, baz und qux haben, sollten Sie nicht für jeden Labelwert eine separate Regel erstellen (eine mit der Abfrage sum(metric{foo="bar"}), eine mit der Abfrage sum(metric{foo="baz"}) und eine mit der Abfrage sum(metric{foo="qux"})). Stattdessen sollten Sie eine einzelne Regel verwenden, die für dieses Label aggregiert wird und optional nach den Labelwerten gefiltert wird, die Sie benötigen (z. B. sum by (foo) metric{foo=~"bar|baz|qux"}).

  Wenn Ihr Messwert zwei Labels mit jeweils 50 Werten hat und Sie für jede Kombination von Labelwerten eine separate Regel haben und Ihre Regelabfragen ein Verhältnis sind, werden in jedem Zeitraum 50 × 50 × 2 = 5.000 parallele Monarch-Abfragen gestartet, die jeweils auf denselben Satz von Monarch-Knoten zugreifen. Insgesamt verbrauchen diese 5.000 parallelen Abfragen viel Arbeitsspeicher auf jedem Monarch-Knoten. Dadurch steigt das Risiko, dass Sie gedrosselt werden, wenn in einer Monarch-Region Ressourcen knapp werden.

  Wenn Sie stattdessen Aggregationen verwenden, um diese Regeln in einer einzigen Regel zusammenzufassen, die ein Verhältnis ist, werden in jedem Zeitraum nur zwei parallele Monarch-Abfragen gestartet. Diese beiden parallelen Abfragen verbrauchen insgesamt viel weniger Arbeitsspeicher als die 5.000 parallelen Abfragen und das Risiko,dass Ihre Anfragen gedrosselt werden, ist viel geringer.

• Wenn Ihre Regel mehr als einen Tag zurückblickt, sollten Sie sie seltener als jede Minute ausführen. Bei Abfragen, die auf Daten zugreifen, die älter als 25 Stunden sind, wird das Monarch-Repository für On-Disk-Daten verwendet. Diese Repository-Abfragen sind langsamer und verbrauchen mehr Arbeitsspeicher als Abfragen für neuere Daten. Dadurch werden alle Probleme mit dem Arbeitsspeicherverbrauch durch parallele Aufzeichnungsregeln noch verstärkt.

  Führen Sie diese Art von Abfragen einmal pro Stunde statt einmal pro Minute aus. Wenn Sie jede Minute eine Abfrage für einen ganzen Tag ausführen, ändert sich das Ergebnis in jedem Zeitraum nur um 1/1440 = 0,07 %. Das ist eine vernachlässigbare Änderung. Wenn Sie stündlich eine Abfrage für einen ganzen Tag ausführen, ändert sich das Ergebnis in jedem Zeitraum um 60/1440 = 4 %. Das ist eine relevantere Signalgröße. Wenn Sie benachrichtigt werden möchten, wenn sich die Daten in letzter Zeit geändert haben, können Sie eine andere Regel mit einem kürzeren Rückblickzeitraum (z. B. 5 Minuten) einmal pro Minute ausführen.

• Verwenden Sie das Feld for: in Ihren Regeln, um vorübergehende abweichende Ergebnisse zu tolerieren. Mit dem Feld for: wird verhindert, dass Ihre Benachrichtigung ausgelöst wird, es sei denn, die Benachrichtigungsbedingung wurde für mindestens die konfigurierte Dauer erfüllt. Legen Sie dieses Feld auf die doppelte Länge Ihres Regelauswertungsintervalls oder länger fest.

  Die Verwendung des Felds for: ist hilfreich, da vorübergehende Probleme oft von selbst behoben werden und daher nicht in aufeinanderfolgenden Benachrichtigungszyklen auftreten. Wenn Sie einen Anstieg sehen, der über mehrere Zeitstempel und mehrere Benachrichtigungszyklen hinweg anhält, können Sie sich sicher sein, dass es sich um einen echten Anstieg und nicht um ein vorübergehendes Problem handelt.

• Verwenden Sie den offset-Modifikator in PromQL, um die Auswertung der Abfrage zu verzögern, damit sie nicht für den letzten Zeitraum mit Daten erfolgt. Sehen Sie sich Ihr Stichprobenintervall und Ihr Regelauswertungsintervall an und ermitteln Sie das längere der beiden. Idealerweise ist Ihr Abfrage-Offset mindestens doppelt so lang wie das längere Intervall. Wenn Sie beispielsweise alle 15 Sekunden Daten senden und alle 30 Sekunden Regeln ausführen, sollten Sie Ihre Abfragen um mindestens 1 Minute versetzen. Durch einen Offset von 1 Minute wird in Ihren Regeln ein End-Zeitstempel verwendet, der mindestens 60 Sekunden alt ist. So wird ein Puffer für verspätete Daten geschaffen, die vor dem Ausführen der Regel eintreffen.

  Dies ist sowohl eine Best Practice für Cloud Monitoring (alle verwalteten PromQL-Benachrichtigungen haben mindestens einen Offset von 1 Minute) als auch eine Best Practice für Prometheus.

• Gruppieren Sie die Ergebnisse nach dem Label location, um potenzielle Probleme mit nicht verfügbaren Regionen zu isolieren. Das Label mit der Google Cloud Region kann in einigen Systemmesswerten zone oder region heißen.

  Wenn Sie nicht nach Region gruppieren und eine Region nicht mehr verfügbar ist, sieht es so aus, als würden Ihre Ergebnisse plötzlich sinken. Möglicherweise sinken auch die bisherigen Ergebnisse. Wenn Sie nach Region gruppieren und eine Region nicht mehr verfügbar ist, erhalten Sie keine Ergebnisse aus dieser Region. Die Ergebnisse aus anderen Regionen sind davon nicht betroffen.

• Wenn Ihr Verhältnis ein Erfolgsverhältnis ist (z. B. 2xx-Antworten im Verhältnis zu Gesamtzahl der Antworten), sollten Sie es stattdessen in ein Fehlerverhältnis umwandeln (z. B. 4xx- und 5xx-Antworten im Verhältnis zur Gesamtzahl der Antworten). Fehlerraten sind toleranter gegenüber inkonsistenten Daten, da ein vorübergehender Rückgang der Daten das Abfrageergebnis unter Ihren Schwellenwert senkt und daher keine Benachrichtigung ausgelöst wird.

• Teilen Sie eine Verhältnisabfrage oder Aufzeichnungsregel nach Möglichkeit in separate Zähler- und Nennerabfragen auf. Dies ist eine Prometheus-Best Practice. Die Verwendung von Verhältnissen ist zwar zulässig, da die Abfrage im Zähler jedoch unabhängig von der Abfrage im Nenner ausgeführt wird, kann die Verwendung von Verhältnissen die Auswirkungen vorübergehender Probleme verstärken:

  • Wenn die Zählerabfrage, aber nicht die Nennerabfrage durch Monarch gedrosselt wird, erhalten Sie möglicherweise unerwartet niedrige Ergebnisse. Wenn Monarch die Nennerabfrage, aber nicht die Zählerabfrage drosselt, können unerwartet hohe Ergebnisse auftreten.
  • Wenn Sie Daten für aktuelle Zeiträume abfragen und verspätet eintreffende Daten haben, kann es sein, dass eine Abfrage im Verhältnis vor dem Eintreffen der Daten und die andere Abfrage im Verhältnis nach dem Eintreffen der Daten ausgeführt wird.
  • Wenn eine Seite Ihres Verhältnisses aus relativ wenigen Zeitreihen besteht, werden Fehler verstärkt. Wenn Zähler und Nenner jeweils 100 Zeitreihen enthalten und Monarch in der Zählerabfrage nicht eine Zeitreihe zurückgibt, werden Sie den Unterschied von 1% wahrscheinlich bemerken. Wenn Zähler und Nenner jeweils 1.000.000 Zeitreihen haben und Monarch in der Zählerabfrage nicht 1 Zeitreihe zurückgibt, werden Sie den Unterschied von 0,0001% wahrscheinlich nicht bemerken.

• Wenn Ihre Daten spärlich sind, verwenden Sie in Ihrer Anfrage eine längere Ratenlaufzeit. Wenn Ihre Daten alle 10 Minuten eintreffen und in Ihrer Abfrage rate(metric[1m]) verwendet wird, werden nur Daten aus der letzten Minute berücksichtigt. Daher erhalten Sie manchmal leere Ergebnisse. Als Faustregel gilt: Legen Sie [duration] auf mindestens das Vierfache Ihres Abrufintervalls fest.

  Bei Messwertabfragen werden standardmäßig Daten der letzten 5 Minuten berücksichtigt. Wenn Sie den Zeitraum verlängern möchten, verwenden Sie eine beliebige gültige x_over_time-Funktion wie last_over_time.

Diese Empfehlungen sind hauptsächlich relevant, wenn Sie bei der Abfrage aktueller Daten inkonsistente Abfrageergebnisse erhalten. Wenn dieses Problem beim Abfragen von Daten auftritt, die älter als 25 Stunden sind, liegt möglicherweise ein technisches Problem mit Monarch vor. Wenden Sie sich in diesem Fall an Cloud Customer Care, damit wir das Problem untersuchen können.

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 Zielstatusinformationen.

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 einen Collector auf demselben Knoten wie einen Ihrer Endpunkte nicht erreichen.
• Bei einer oder mehreren Ihrer PodMonitoring- oder ClusterPodMonitoring-Konfigurationen wurden keine gültigen Ziele gefunden.

Ä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 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 Extraktionsendpunkt

Wenn einer der folgenden Fehler angezeigt wird und für Ihr Extraktionsziel 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 Unterstützung benötigen, wenden Sie sich an den Google Cloud -Support. Weitere Informationen zu Kontingenten finden Sie in der Dokumentation zu Cloud-Kontingenten.

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 Kubernetes-Cluster 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. Rufen Sie in der Google Cloud Console die Seite IAM auf:

   Rufen Sie IAM auf.

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & Admin lautet.

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.

Zulassungs-Webhook kann HTTP-Clientkonfiguration nicht parsen oder sie ist ungültig

In Versionen von Managed Service for Prometheus vor 0.12 wird möglicherweise ein Fehler wie der folgende angezeigt, der sich auf das Einfügen von Secrets in den nicht standardmäßigen Namespace bezieht:

• „admission webhook ‚validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com‘ hat die Anfrage abgelehnt: Ungültige Definition für Endpunkt mit Index 0: Prometheus-HTTP-Clientkonfiguration kann nicht geparst werden oder ist ungültig: Namespace ‚my-custom-namespace‘ muss verwendet werden, ‚default‘ wurde angegeben“

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>

Bei bestimmten Bibliotheken, z. B. Bibliotheken von VictoriaMetrics, die älter als Version 1.28.0 sind, werden die Typinformationen absichtlich gelöscht. 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.

Hinweis: Die Anzahl der Labels (auch als Labelnamen, Labelschlüssel oder Dimensionen bezeichnet) unterscheidet sich von der Kardinalität. Kardinalität bezieht sich auf die Anzahl der Kombinationen eindeutiger Labelwerte in allen Labels.

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.

   • Sie können das APIs Explorer-Widget auf der Seite metricDescriptors.list verwenden, um die Methode aufzurufen. Weitere Informationen finden Sie unter APIs Explorer. Beispiele finden Sie unter Messwert und Ressourcentypen auflisten.

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 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 einzelnenGoogle Cloud -Projekt erreicht:

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

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

Prometheus hat ein dimensionales Datenmodell, in dem Informationen wie der Cluster- oder Namespace-Name als Labelwert codiert werden sollten. Wenn Dimensionsinformationen stattdessen in den Messwertnamen eingebettet sind, steigt die Anzahl der Messwertdeskriptoren unbegrenzt. Da in diesem Szenario Labels nicht richtig verwendet werden, ist es außerdem viel schwieriger, Daten über Cluster, Namespaces oder Dienste hinweg abzufragen und zusammenzufassen.

Weder Cloud Monitoring noch Managed Service for Prometheus unterstützen nicht dimensionale Messwerte, z. B. solche, die für StatsD oder Graphite formatiert sind. Die meisten Prometheus-Exporter sind standardmäßig richtig konfiguriert. Bestimmte Exporter wie der StatsD-Exporter, der Vault-Exporter oder der Envoy-Proxy, der mit Istio geliefert wird, müssen jedoch explizit so konfiguriert werden, dass Labels verwendet werden, 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. Prüfen Sie,ob die Summe der aktiven und inaktiven Messwerte über 25.000 liegt. In den meisten Fällen sollten Sie eine große Anzahl inaktiver Messwerte sehen.
4. Wählen Sie im Bereich „Schnellfilter“ die Option „Inaktiv“ aus, blättern Sie durch die Liste und suchen Sie nach Mustern.
5. Wählen Sie im Bereich „Schnellfilter“ die Option „Aktiv“ aus, sortieren Sie die Liste absteigend nach Abrechenbares Stichprobenvolumen, blättern Sie durch die Liste und suchen Sie nach Mustern.
6. Sortieren Sie nach Samples billable volume (Abrechenbares Volumen für Stichproben) aufsteigend, blättern Sie durch die Liste und suchen Sie nach Mustern.

Alternativ können Sie dieses 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 erkannt haben, die auf fehlerhafte Messwerte hinweisen, können Sie das Problem beheben, indem Sie den Exporter an der Quelle korrigieren und dann die entsprechenden Messwertdeskriptoren löschen.

Damit dieses Problem nicht noch einmal auftritt, müssen Sie zuerst den entsprechenden Exporter so konfigurieren, dass keine fehlerhaften Messwerte mehr ausgegeben werden. Wir empfehlen, die Dokumentation Ihres Exporttools zu lesen. Sie können überprüfen, ob Sie das Problem behoben haben, indem Sie den /metrics-Endpunkt manuell aufrufen und die exportierten Messwertnamen prüfen.

Anschließend können Sie Ihr Kontingent freigeben, indem Sie die fehlerhaften Messwerte mit der projects.metricDescriptors.delete-Methode löschen. Um die Liste der fehlerhaften Messwerte einfacher zu durchlaufen, stellen wir ein Golang-Skript zur Verfügung, das Sie verwenden können. Dieses Skript akzeptiert einen regulären Ausdruck, mit dem Sie Ihre fehlerhaften Messwerte identifizieren können, und löscht alle Messwertdeskriptoren, die dem Muster entsprechen. Da das Löschen von Messwerten nicht rückgängig gemacht werden kann, empfehlen wir dringend, das Script zuerst im Probelaufmodus auszuführen.

Einige Messwerte fehlen für kurz laufende Ziele

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

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

1. Suchen Sie die YAML-Datei für das Deployment des Cronjobs 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, damit die Messwertdaten konsistent erfasst werden können.

   Versuchen Sie Folgendes, um dieses Problem zu beheben:

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

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

   • Erwägen Sie, einen logbasierten Verteilungsmesswert zu erstellen, anstatt Messwertdaten zu erfassen. Diese Vorgehensweise wird empfohlen, wenn Daten nur selten veröffentlicht werden. Weitere Informationen finden Sie unter Übersicht über logbasierte Messwerte.

3. Wenn die Laufzeit länger als fünf Minuten ist oder nicht konsistent ist, lesen Sie den Abschnitt Nicht fehlerfreie 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 vom 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äß.

Fehler aufgrund fehlenden Speichers (Out Of Memory, OOM) im Collector

Wenn Sie die verwaltete Erfassung verwenden und auf Ihren Collectors Speicherplatzmangel auftritt, sollten Sie vertikales Pod-Autoscaling aktivieren.

Fehler aufgrund von unzureichendem Arbeitsspeicher (Out Of Memory, OOM) bei Operatoren

Wenn Sie die verwaltete Erfassung verwenden und auf Ihrem Operator Fehler aufgrund von ungenügendem Arbeitsspeicher (Out Of Memory, OOM) auftreten, sollten Sie das Feature für den Zielstatus deaktivieren. Die Funktion „Zielstatus“ kann in größeren Clustern zu Leistungsproblemen bei Operatoren führen.

Zu viele Zeitreihen oder vermehrte 503-Antworten und Fehler vom Typ „context deadline exceeded“, insbesondere bei Spitzenlast

Dieses Problem kann auch auftreten, wenn die folgende Fehlermeldung angezeigt wird:

• „Die überwachte Ressource (abcdefg) hat zu viele Zeitachsen (Prometheus-Messwerte)“

„Context deadline exceeded“ ist ein allgemeiner 503-Fehler, der von Monarch für jedes Problem auf der Aufnahmeseite zurückgegeben wird, für das es keine spezifische Ursache gibt. Bei normaler Nutzung des Systems ist eine sehr geringe Anzahl von Fehlern vom Typ „context deadline exceeded“ zu erwarten.

Möglicherweise stellen Sie jedoch ein Muster fest, bei dem die Fehler „context deadline exceeded“ zunehmen und die Datenaufnahme erheblich beeinträchtigen. Eine mögliche Ursache ist, dass Sie Zielvorhabenlabels falsch festlegen. Das ist wahrscheinlicher, wenn Folgendes zutrifft:

• Ihre Fehler vom Typ „Context deadline exceeded“ folgen einem zyklischen Muster. Sie treten häufiger auf, wenn die Last für Sie oder für die Google Cloud -Region, die durch Ihr location-Label angegeben wird, hoch ist.
• Wenn Sie mehr Messwerte in den Dienst aufnehmen, werden mehr Fehler angezeigt.
• Sie verwenden den statsd_exporter für Prometheus, Envoy für Istio, den SNMP-Exporter, das Prometheus Pushgateway, kube-state-metrics oder einen ähnlichen Exporter, der Messwerte im Namen anderer Ressourcen, die in Ihrer Umgebung ausgeführt werden, weiterleitet und meldet. Das Problem tritt nur bei Messwerten auf, die von diesem Exporttyp ausgegeben werden.
• Sie stellen fest, dass die betroffenen Messwerte in der Regel den String localhost im Wert für das Label instance enthalten oder dass es nur sehr wenige Werte für das Label instance gibt.
• Wenn Sie Zugriff auf die Abfrage-UI des Prometheus-Collectors im Cluster haben, können Sie sehen, dass die Messwerte erfolgreich erfasst werden.

Wenn diese Punkte zutreffen, hat Ihr Exporteur die Ressourcenlabels wahrscheinlich so konfiguriert, dass sie mit den Anforderungen von Monarch in Konflikt stehen.

In Monarch werden zusammengehörige Daten in einem Ziel gespeichert. Ein Ziel für Managed Service for Prometheus wird durch den Ressourcentyp prometheus_target und die Labels project_id, location, cluster, namespace, job und instance definiert. Weitere Informationen zu diesen Labels und zum Standardverhalten finden Sie unter Reservierte Labels in der verwalteten Erfassung oder Reservierte Labels in der selbst bereitgestellten Erfassung.

Von diesen Labels ist instance das Zielfeld der niedrigsten Ebene und daher am wichtigsten. Für das effiziente Speichern und Abfragen von Messwerten in Monarch sind relativ kleine, vielfältige Ziele erforderlich, die idealerweise etwa die Größe einer typischen VM oder eines Containers haben. Wenn Sie Managed Service for Prometheus in typischen Szenarien ausführen, werden durch das im Collector integrierte Open-Source-Standardverhalten in der Regel gute Werte für die Labels job und instance ausgewählt. Aus diesem Grund wird dieses Thema an anderer Stelle in der Dokumentation nicht behandelt.

Die Standardlogik kann jedoch fehlschlagen, wenn Sie einen Exporter ausführen, der Messwerte im Namen anderer Ressourcen in Ihrem Cluster meldet, z. B. statsd_exporter. Anstatt den Wert von instance auf die IP:Port-Adresse der Ressource festzulegen, die den Messwert ausgibt, wird der Wert von instance auf die IP:Port-Adresse des statsd_exporter selbst festgelegt. Das Problem kann durch das Label job noch verstärkt werden, da es sich nicht auf das Messwertpaket oder den Dienst bezieht, sondern auch an Vielfalt mangelt, da es auf statsd-exporter festgelegt ist.

In diesem Fall werden alle Messwerte, die von diesem Exporter in einem bestimmten Cluster und Namespace stammen, in dasselbe Monarch-Ziel geschrieben. Wenn dieses Ziel größer wird, schlagen Schreibvorgänge fehl und es treten vermehrt 503-Fehler vom Typ „Context deadline exceeded“ auf.

Sie können sich vergewissern, dass dies bei Ihnen der Fall ist, indem Sie Cloud Customer Care kontaktieren und sie bitten, die „Monarch Quarantiner-Hospitalisierungsprotokolle“ zu prüfen. Geben Sie alle bekannten Werte für die sechs reservierten Labels in Ihrem Ticket an. Geben Sie das Google Cloud Projekt an, aus dem die Daten gesendet werden, nicht das Google Cloud Projekt Ihres Messwertbereichs.

Um dieses Problem zu beheben, müssen Sie in Ihrer Erfassungspipeline vielfältigere Ziellabels verwenden. Hier sind einige mögliche Strategien, die nach Effektivität sortiert sind:

• Anstatt einen zentralen Exporter auszuführen, der Messwerte im Namen aller VMs oder Knoten meldet, führen Sie für jede VM einen separaten Exporter als Knoten-Agent aus oder stellen Sie den Exporter als Kubernetes-Daemonset bereit. Damit das Label instance nicht auf localhost gesetzt wird, führen Sie den Exporter nicht auf demselben Knoten wie den Collector aus.
  • Wenn Sie nach dem Sharding des Exportprogramms immer noch mehr Zielvielfalt benötigen, führen Sie mehrere Exportprogramme auf jeder VM aus und weisen Sie jedem Exportprogramm logisch verschiedene Messwertgruppen zu. Anstatt den Job mit dem statischen Namen statsd-exporter zu ermitteln, verwenden Sie für jede logische Gruppe von Messwerten einen anderen Jobnamen. Instanzen mit unterschiedlichen Werten für job werden in Monarch verschiedenen Zielvorhaben zugewiesen.
  • Wenn Sie kube-state-metrics verwenden, können Sie die integrierte horizontale Shardierung nutzen, um mehr Zielvielfalt zu schaffen. Andere Exporteure bieten möglicherweise ähnliche Funktionen.
• Wenn Sie OpenTelemetry oder eine selbst bereitgestellte Sammlung verwenden, ändern Sie den Wert von instance mit einer Neubezeichnungsregel von der IP-Adresse:Port oder dem Namen des Exporters in die IP-Adresse:Port oder den eindeutigen Namen der Ressource, die die Messwerte generiert. Höchstwahrscheinlich erfassen Sie die IP-Adresse:Port oder den Namen der ursprünglichen Ressource bereits als Messwertlabel. Außerdem müssen Sie das Feld honor_labels in Ihrer Prometheus- oder OpenTelemetry-Konfiguration auf true setzen.
• Wenn Sie OpenTelemetry oder die selbst bereitgestellte Erfassung verwenden, verwenden Sie eine Relabeling-Regel mit einer hashmod-Funktion, um mehrere Scrape-Jobs für denselben Exporter auszuführen und dafür zu sorgen, dass für jede Scrape-Konfiguration ein anderes Instanzlabel ausgewählt wird.

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 Cloudist 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.

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.

Von Monarch blockierte und abgebrochene Anfragen

Wenn der folgende Fehler angezeigt wird, haben Sie das interne Limit für die Anzahl der gleichzeitigen Abfragen erreicht, die für ein beliebiges Projekt ausgeführt werden können:

• „internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500.“

Zum Schutz vor Missbrauch wird im System ein hartes Limit für die Anzahl der Abfragen festgelegt, die gleichzeitig in Monarch für ein Projekt ausgeführt werden können. Bei der typischen Prometheus-Nutzung sollten Abfragen schnell ausgeführt werden und dieses Limit sollte nie erreicht werden.

Dieses Limit kann erreicht werden, wenn Sie viele gleichzeitige Abfragen ausführen, die länger als erwartet dauern. Abfragen, die Daten für mehr als 25 Stunden anfordern, werden in der Regel langsamer ausgeführt als Abfragen, die Daten für weniger als 25 Stunden anfordern. Je länger der Abfragezeitraum ist, desto langsamer ist die Ausführung der Abfrage.

Normalerweise wird dieses Problem durch die Ausführung vieler Regeln mit langem Rückblickzeitraum auf ineffiziente Weise ausgelöst. Angenommen, Sie haben viele Regeln, die einmal pro Minute ausgeführt werden und eine 4‑Wochen-Rate anfordern. Wenn die Ausführung jeder dieser Regeln lange dauert, kann es schließlich zu einem Rückstau von Abfragen kommen, die für Ihr Projekt ausgeführt werden müssen. In diesem Fall drosselt Monarch die Abfragen.

Um dieses Problem zu beheben, müssen Sie das Auswertungsintervall Ihrer Regeln mit langem Lookback-Zeitraum so verlängern, dass sie nicht jede Minute ausgeführt werden. Es ist nicht erforderlich, alle 1 Minute eine Abfrage für eine 4-Wochen-Rate auszuführen. In 4 Wochen gibt es 40.320 Minuten. Jede Minute liefert also kaum ein zusätzliches Signal (Ihre Daten ändern sich höchstens um 1/40.320). Ein 1-stündiges Auswertungsintervall sollte für eine Abfrage, in der eine 4-Wochen-Rate angefordert wird, ausreichen.

Wenn Sie den Engpass beheben, der durch ineffiziente, lange ausgeführte Abfragen verursacht wird, die zu häufig ausgeführt werden, sollte sich das Problem von selbst beheben.

Inkompatible Werttypen

Wenn bei der Aufnahme oder Abfrage der folgende Fehler 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 steht im Konflikt mit dem vorhandenen Werttyp (INT64).“

Dieser Fehler kann bei der Aufnahme auftreten, da in Monarch keine DOUBLE-Daten in INT64-Messwerte und keine INT64-Daten in DOUBLE-Messwerte geschrieben werden können. Dieser Fehler kann auch auftreten, wenn Sie einen Messwertbereich mit mehreren Projekten abfragen, da Monarch keine Messwerte vom Typ DOUBLE in einem Projekt mit Messwerten vom Typ INT64 in einem anderen Projekt zusammenführen kann.

Dieser Fehler tritt nur auf, wenn OpenTelemetry-Collectors Daten melden. Er ist wahrscheinlicher, wenn Sie sowohl OpenTelemetry (mit dem googlemanagedprometheus-Exporter) als auch Prometheus verwenden, um Daten für denselben Messwert zu melden, wie es häufig beim Messwert target_info der Fall ist.

Die Ursache ist wahrscheinlich eine der folgenden:

• Sie erfassen OTLP-Messwerte und der Werttyp der OTLP-Messwertbibliothek wurde 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 von 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 Collectors schreiben jetzt zwei Werttypen in denselben Messwert im selben Projekt und nur der Collector, der den Messwertdeskriptor zuerst erstellt hat, ist erfolgreich.
• 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 Messwertbereich abfragen, wird eine ungültige Vereinigung zwischen inkompatiblen Messwerttypen verursacht.

Dieses Problem lässt sich beheben, indem Sie alle Messwerttypen zu DOUBLE erzwingen. Gehen Sie dazu so vor:

1. Konfigurieren Sie Ihre OpenTelemetry Collectors neu, um alle Messwerte als DOUBLE zu erzwingen, indem Sie das feature-gate exporter.googlemanagedprometheus.intToDouble-Flag aktivieren.
2. Alle INT64-Messwertdeskriptoren löschen und als DOUBLE neu erstellen lassen. Sie können dies mit dem delete_metric_descriptors.go-Skript automatisieren.

Durch diese Schritte werden alle Daten gelöscht, die als INT64-Messwert gespeichert sind. Es gibt keine Alternative zum Löschen der INT64-Messwerte, die dieses Problem vollständig behebt.