Fehlerbehebung bei der Monitoring API

In diesem Leitfaden finden Sie Methoden zur Fehlerbehebung und Lösungen für Fehler, die bei der Verwendung der Monitoring API auftreten können. So können Sie API-Fehler diagnostizieren, Ablehnungen bei der Messwerterfassung beheben und fehlende Suchergebnisse ermitteln.

Die Monitoring API ist Teil der Cloud APIs. Eine Liste der gemeinsamen Fehlercodes und allgemeine Empfehlungen zur Fehlerbehandlung finden Sie unter Fehlerbehandlung.

APIs Explorer für die Fehlerbehebung verwenden

APIs Explorer ist ein Widget, das in die Referenzseiten für API-Methoden integriert ist. Sie können die Methode durch Ausfüllen von Feldern aufrufen und müssen keinen Code schreiben.

Wenn Sie Probleme mit einem Methodenaufruf haben, verwenden Sie das API Explorer-Widget (API testen) auf der Referenzseite für diese Methode, um das Problem zu beheben. Weitere Informationen finden Sie unter APIs Explorer.

Allgemeine API- und Authentifizierungsfehler

In diesem Abschnitt werden Fehlercodes aufgeführt, die von verschiedenen Monitoring API-Methoden zurückgegeben werden können.

401 UNAUTHENTICATED

Der Fehlercode 401 UNAUTHENTICATED weist auf fehlende, abgelaufene oder ungültige OAuth2- oder IAM-Anmeldedaten hin.

Die beiden häufigsten Fehlermeldungen für diesen Fehlercode sind Request is missing required authentication credential und User is not authorized to access the project (or metric).

  • Ursache:Fehlender Authorization: Bearer <token>-Header, abgelaufenes OAuth2- oder OIDC-Token oder ungültige Dienstkontoanmeldedaten.
  • Lösung:Aktualisieren Sie die Authentifizierungstokens mit den Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) oder gcloud auth print-access-token. Prüfen Sie außerdem, ob der Dienstkontoschlüssel gültig ist.
Wenn Sie den APIs Explorer nicht verwenden, probieren Sie es aus. Wenn der API-Aufruf in APIs Explorer funktioniert, liegt wahrscheinlich ein Autorisierungsproblem in der Umgebung vor, in der Sie den API-Aufruf ausführen. Rufen Sie die Seite „API-Manager“ auf, um zu prüfen, ob die Monitoring API für Ihr Projekt aktiviert ist.

403 PERMISSION_DENIED für Projektzugriff und Abrechnung

Der Fehlercode 403 PERMISSION_DENIED weist darauf hin, dass Sie nicht die erforderlichen Berechtigungen zum Ausführen der angeforderten Aktion haben.

Dieser Fehlercode kann mit verschiedenen Fehlermeldungen kombiniert werden. Zwei häufige Fehlermeldungen sind Billing check failed for project [PROJECT_ID] und Billing account disabled:

  • Ursache:Cloud Billing ist für dasGoogle Cloud Projekt deaktiviert oder gesperrt. Für die Aufnahme benutzerdefinierter Messwerte ist ein aktives Rechnungskonto erforderlich.
  • Lösung:Verknüpfen Sie ein aktives Cloud-Rechnungskonto mit dem Projekt in der Google Cloud -Konsole.

Wenn Sie diesen Fehlercode beim Schreiben von Messwertdaten erhalten, lesen Sie auch 403 PERMISSION_DENIED beim Schreiben von Messwertdaten.

404 NOT_FOUND

Der Fehlercode 404 NOT_FOUND gibt an, dass die Zielprojekt-ID nicht vorhanden ist oder dass die Region oder der Standort nicht erkannt wird.

Im Folgenden finden Sie häufige Fehlermeldungen für diesen Fehlercode:

  • Project [PROJECT_ID] not found

    • Ursache:Das im Anfrage-URI angegebene Projekt ist nicht vorhanden oder wurde gelöscht.
    • Lösung:Prüfen Sie die Schreibweise der Projekt-ID und ob das Projekt in der Google Cloud -Konsole aktiv ist.

  • Unavailable region or location oder Unrecognized region or location

    • Ursache:Das Label für den Standort oder die Region der überwachten Ressource ist ungültig oder wird nicht erkannt.
    • Lösung:Verwenden Sie gültige Google Cloud Regions- und Zonennamen, z. B. us-central1 oder us-central1-a.

  • The requested URL was not found on this server

    • Ursache:Der Ressourcenpfad in der URL ist falsch.
    • Lösung:Vergleichen Sie die URL mit der URL der Methode, die auf der Referenzseite der Methode dargestellt ist. Dieser Fehler kann darauf hindeuten, dass ein Rechtschreibfehler vorliegt, z. B. „project“ statt „projects“, oder ein Fehler bei der Großschreibung, z. B. „TimeSeries“ statt „timeSeries“.

500 INTERNAL, 503 UNAVAILABLE, 504 DEADLINE_EXCEEDED

Für diese Fehlercodes gibt es zwei häufige Fehlermeldungen: Internal error encountered. Please retry after a few seconds und The service is currently unavailable.

  • Ursache:Vorübergehende Fehler in der Backend-Infrastruktur, Netzwerkprobleme oder interne Neuausrichtung von Datenbankpartitionen.
  • Lösung:Implementieren Sie einen abgeschnittenen exponentiellen Backoff mit Jitter für Wiederholungsversuche, beginnend bei 1 Sekunde und bis zu 32 Sekunden. Legen Sie für RPC-Clients Zeitlimits von mindestens 15 Sekunden fest. Weitere Informationen finden Sie unter API-Fehler wiederholen.

Fehlende Ergebnisse

Wenn ein API-Aufruf den Statuscode 200 und eine leere Antwort zurückgibt, sollten Sie Folgendes beachten:

  • Wenn im Aufruf ein Filter verwendet wird, stimmt der Filter möglicherweise nicht überein. Bei der Filterübereinstimmung wird zwischen Groß- und Kleinschreibung unterschieden. Um Filterprobleme zu beheben, geben Sie zuerst nur eine Filterkomponente wie metric.type an und prüfen Sie, ob Sie Ergebnisse erhalten. Fügen Sie die anderen Filterkomponenten nacheinander hinzu, um Ihre Anfrage zu erstellen.
  • Wenn Sie mit einem benutzerdefinierten Messwert arbeiten, prüfen Sie, ob das Projekt, in dem der Messwert definiert ist, angegeben ist.

Das Fehlen von Datenpunkten bei Verwendung der Methode timeSeries.list kann mehrere Gründe haben:

  • Die Daten sind möglicherweise veraltet. Weitere Informationen finden Sie unter Datenaufbewahrung.

  • Die Daten wurden möglicherweise noch nicht an Monitoring weitergegeben. Weitere Informationen finden Sie unter Latenz von Messwertdaten.

  • Das Intervall ist ungültig:

    • Prüfen Sie, ob die Endzeit korrekt ist.
    • Prüfen Sie, ob die Startzeit korrekt ist und vor der Endzeit liegt. Wenn die Startzeit fehlt oder falsch formatiert ist, wird sie von der API auf die Endzeit festgelegt. Bei GAUGE-Messwerten stimmt dieses Zeitintervall nur mit den Punkten überein, deren Start- und Endzeit genau der Endzeit des Intervalls entspricht. Für CUMULATIVE- oder DELTA-Messwerte, die über Zeitintervalle hinweg gemessen werden, werden keine Punkte abgeglichen. Weitere Informationen finden Sie unter Zeitintervalle.

Fehler beim Abfragen von Messwertdaten

In diesem Abschnitt finden Sie Informationen zu den Fehlern, die beim Lesen von Messwertdaten mit einer Methode wie timeSeries.list auftreten können.

400 INVALID_ARGUMENT beim Abfragen von Messwertdaten

Der Fehlercode 400 INVALID_ARGUMENT weist auf einen clientseitigen Validierungsfehler hin. Die mit dem Fehlercode verknüpfte Fehlermeldung enthält detailliertere Informationen und ist spezifisch für die API-Methode.

Wenn Sie beispielsweise Messwertdaten abfragen, erhalten Sie möglicherweise die folgenden Meldungen:

  • Field filter had an invalid value oder Field filter had an invalid value of "[FILTER]": [EXPLANATION]

    • Ursache:Weist auf ein Problem mit dem Monitoring-Filter hin.
    • Lösung:Prüfen Sie die Rechtschreibung und Formatierung des Filters. Weitere Informationen finden Sie unter Filter überwachen.

  • Request was missing field interval.endTime oder Field interval.endTime had an invalid value

    • Ursache:Die Endzeit fehlt in der Anfrage oder der Wert ist fehlerhaft.

    • Lösung:Wenn Sie APIs Explorer verwenden, setzen Sie den Wert des Zeitfelds nicht in Anführungszeichen. Die folgenden Formate sind gültig:

      2026-05-11T01:23:45Z
2026-05-11T01:23:45.678Z
2026-05-11T01:23:45.678+05:00
2026-05-11T01:23:45.678-04:30
```

Fehler beim Schreiben von Messwertdaten

In diesem Abschnitt finden Sie Informationen zu den Fehlern, die auftreten können, wenn Sie die Methode timeSeries.create zum Schreiben von Messwertdaten verwenden. Dazu gehören:

  • Eine Zusammenfassung der Fehlercodes.
  • Eine Liste der Fehlermeldungen, die mit jedem Fehlercode verknüpft sind. Diese Einträge enthalten sowohl eine Ursache als auch Informationen zur Lösung. Die allgemeinen API-Fehler gelten auch für die Methode create.

Wenn Sie keine Audit-Logs zum Datenzugriff für Monitoring aktivieren, können Fehler bei der Methode timeSeries.create unbemerkt bleiben. Sie haben jedoch folgende Möglichkeiten:

  • Mit dem Metrics Explorer können Sie Informationen zu Fehlerraten abrufen. Verwenden Sie die folgenden Einstellungen:

    • Messwert: monitoring.googleapis.com/api/request_count
    • Filter:method = "google.monitoring.v3.MetricService.CreateTimeSeries"
    • Aggregation:Gruppieren nach response_code

  • Mit dem Log-Explorer können Sie Ihre Logs zur Administratoraktivität abfragen. Diese werden vom System erstellt, wenn versucht wird, automatisch einen Messwertdeskriptor zu erstellen, und diese Aktion fehlschlägt. Führen Sie zum Aufrufen dieser Logeinträge die folgende Abfrage aus. Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Google Cloud Projekts:

    logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="monitoring.googleapis.com"
protoPayload.methodName="google.monitoring.v3.MetricService.CreateMetricDescriptor"
severity>=ERROR

  • Verwenden Sie den Log-Explorer, um Ihre clientseitigen Logs abzufragen.

Wenn Sie Audit-Logs zum Datenzugriff für Cloud Monitoring aktivieren, schreibt das System für jeden Datenzugriff einen Logeintrag. Diese Logeinträge enthalten insbesondere Details zur Anzahl der Punkte, die nicht geschrieben werden konnten, und zur Ursache des Fehlers:

  • Informationen zum Aktivieren von Audit-Logs zum Datenzugriff finden Sie unter Audit-Logs zum Datenzugriff konfigurieren.

  • Wenn Sie diese Logeinträge aufrufen möchten, verwenden Sie den Log-Explorer und führen Sie die folgende Abfrage aus, nachdem Sie PROJECT_ID durch die ID IhresGoogle Cloud -Projekts ersetzt haben:

    logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="monitoring.googleapis.com"
protoPayload.methodName="google.monitoring.v3.MetricService.CreateTimeSeries"
severity>=ERROR

Zusammenfassung der timeSeries.create-Fehlercodes

HTTP-Code gRPC-Statuscode Hauptursachen
400 INVALID_ARGUMENT Fehler bei der Nutzlastvalidierung: Batchgröße, Labelgröße oder ‑schlüssel, Reihenfolge der Zeitstempel, Schema- oder Typkonflikt, Struktur des Verteilungshistogramms.
400 FAILED_PRECONDITION Abtastrate überschritten, nicht unterstützter Metriktyp oder verspätete Ankunft außerhalb des Aufbewahrungszeitraums.
401 UNAUTHENTICATED Fehlende, abgelaufene oder ungültige OAuth2- oder IAM-Anmeldedaten.
403 PERMISSION_DENIED Fehlende roles/monitoring.metricWriter-IAM-Rolle, deaktiviertes Cloud Billing oder unbefugter Versuch, in reservierte Systemmesswertdomains zu schreiben.
404 NOT_FOUND Die Zielprojekt-ID ist nicht vorhanden oder die Region/der Standort wird nicht erkannt.
429 RESOURCE_EXHAUSTED Das Limit für die Kardinalität aktiver Zeitreihen für eine überwachte Ressource wurde überschritten, die Grenzwerte für Projektmesswertdeskriptoren wurden erreicht oder die Grenzwerte für die API-Anforderungsrate wurden überschritten.
500 INTERNAL Fehler im internen Speicher oder Schemadienst.
503 UNAVAILABLE Vorübergehende Nichtverfügbarkeit des Backend-Dienstes.
504 DEADLINE_EXCEEDED Die Zeitüberschreitung ist aufgetreten, bevor Datenpunkte in Speicherknoten geschrieben wurden.

400 INVALID_ARGUMENT beim Schreiben von Messwertdaten

400 INVALID_ARGUMENT gibt clientseitige Validierungsfehler in der Anfragestruktur, den Messwertmetadaten, den Labeldefinitionen, der Zeitstempelanpassung oder den Punktwerten an.

Verstöße gegen Struktur und Batching melden

In den folgenden Listen finden Sie Fehlermeldungen im Zusammenhang mit Struktur- und Batching-Verstößen:

  • Request was missing field timeSeries

    • Ursache:Das time_series-Array in der Anfrage war leer.
    • Resolution: Fügen Sie jeder Anfrage mindestens ein TimeSeries Objekt hinzu.

  • The maximum number of TimeSeries objects per Create request is 200

    • Ursache:Die Anfrage enthält mehr als 200 TimeSeries-Objekte.
    • Lösung:Führen Sie Batch-Schreibvorgänge mit maximal 200 Zeitreihen pro Anfrage durch.

  • Field points had an invalid value: Only one point can be written per TimeSeries per request

    • Ursache:Ein einzelnes TimeSeries-Objekt enthält mehr als einen Eintrag im Feld points.
    • Lösung:Geben Sie pro Anfrage genau ein Point pro TimeSeries-Objekt an. Wenn Sie mehrere Datenpunkte für denselben Messwert über die Zeit hinweg schreiben möchten, senden Sie sie in separaten Anfragen.

  • Duplicate TimeSeries encountered. Only one point can be written per TimeSeries per request

    • Ursache:Zwei oder mehr TimeSeries-Objekte in derselben Anfrage haben identische Messwerttypen, Messwertlabels und Labels für überwachte Ressourcen.
    • Lösung:Entfernen Sie Duplikate aus Zeitreihen in clientseitigen Batches, sodass jede eindeutige Zeitreihe höchstens einmal pro Anfrage vorkommt.

  • user defined metrics are not supported on the metric domain "[DOMAIN]"

    • Ursache:Benutzerdefinierte Messwerte werden in der angegebenen Domain nicht unterstützt.
    • Lösung:Keine.

Labels und Namensbeschränkungen

In den folgenden Listen sind Fehlermeldungen im Zusammenhang mit Labels und Namensbeschränkungen aufgeführt:

  • Field metric.labels had an invalid value of "[KEY]": Label value exceeds the maximum string size of 1024 characters

    • Ursache:Ein Messwert- oder Ressourcenlabelwert überschreitet 1.024 Zeichen.
    • Lösung:Konfigurieren Sie Ihren Collector oder Ihre Anwendung so, dass Labelwerte auf maximal 1.024 Zeichen gekürzt werden. Vermeiden Sie es, Text mit hohem Volumen in Messwertlabels zu speichern. Schreiben Sie diese Details stattdessen in Cloud Logging.

  • Field metric.labels had an invalid value of "[KEY]": Label key contains invalid characters

    • Ursache:Ein Labelschlüssel enthält Zeichen, die nicht dem zulässigen Muster entsprechen. Schlüssel dürfen alphanumerische Zeichen und Unterstriche enthalten, müssen maximal 100 Zeichen lang sein und mit einem Buchstaben beginnen.
    • Lösung:Benennen Sie die Labelschlüssel so um, dass nur gültige Zeichen verwendet werden.

  • The metric type must be a URL-formatted string with a domain and non-empty path

    • Ursache: Das metric.type ist fehlerhaft oder es fehlt ein Domainpräfix.
    • Auflösung:Formatieren Sie benutzerdefinierte Messwerttypen als custom.googleapis.com/<category>/<name> oder workload.googleapis.com/<name>.

  • Field metric.labels had an invalid value: The metric [METRIC_NAME] has more than [LIMIT] labels

    • Ursache:Die Anzahl der Labels für einen benutzerdefinierten Messwertdeskriptor überschreitet 30 oder, für Prometheus-Messwerte, 200.
    • Lösung:Entfernen Sie unnötige Labels, um das Deskriptorlimit nicht zu überschreiten.

  • unrecognized metric label "[LABEL_KEY]"

    • Ursache:Der Messwertdeskriptor ist bereits vorhanden, aber im Antrag wird ein Labelschlüssel angegeben, der im Deskriptor nicht definiert ist.
    • Lösung:Achten Sie darauf, dass die Labelschlüssel mit dem vorhandenen MetricDescriptor übereinstimmen. Erstellen Sie andernfalls einen neuen Messwertdeskriptor, wenn eine Schemaänderung erforderlich ist.

Abweichungen bei Projekt- und Ressourcen-IDs

In den folgenden Listen sind Fehlermeldungen im Zusammenhang mit Abweichungen bei Projekt- und Ressourcen-IDs aufgeführt:

  • Field resource.labels.project_id had an invalid value of "[VAL]": if present, must be the project number or ID in the request name ([PROJECT]) oder Field resource.labels.project_id had an invalid value of "[VAL]": if present, must be the resource container ID in the request name [PROJECT]

    • Ursache:Das in resource.labels angegebene Label project_id oder resource_container stimmt nicht mit der Projekt-ID oder -nummer im Anfragenamen überein.
    • Lösung:Legen Sie das project_id-Label der Ressource so fest, dass es mit dem Anfrageprojekt übereinstimmt, oder lassen Sie das project_id-Label in resource.labels weg, damit es standardmäßig auf das Anfrageprojekt festgelegt wird.

  • unrecognized resource type "[RESOURCE_TYPE]" oder missing resource type

    • Ursache:Der resource.type wird von Cloud Monitoring nicht erkannt oder für einen nicht benutzerdefinierten Messwert ausgelassen.
    • Lösung:Verwenden Sie einen gültigen Typ der überwachten Ressource, z. B. gce_instance, k8s_container, generic_task oder global.

Zeitstempel und Intervalle

Im Folgenden finden Sie eine Liste mit Fehlermeldungen zu Zeitstempeln und Intervallen:

  • Points must be written in order. One or more of the points specified had an older end time than the most recent point

    • Ursache:Der end_time des Datenpunkts ist älter als oder gleich dem Zeitstempel des letzten Datenpunkts, der zuvor für diese Zeitreihe aufgenommen wurde.
    • Lösung:Punkte müssen in chronologischer Reihenfolge erfasst werden.

  • Field points[0].interval.start_time had an invalid value of "[START]": The start time must be equal to the end time ([END]) for the gauge metric '[METRIC]'

    • Ursache:Es wurde ein GAUGE-Messwertpunkt eingereicht, bei dem start_time nicht gleich end_time ist.
    • Auflösung:Legen Sie für GAUGE-Messwerte start_time auf end_time fest oder lassen Sie start_time weg.

  • Field points[0].interval.start_time had an invalid value of "[START]": The start time must be before the end time ([END]) for the non-gauge metric '[METRIC]'

    • Ursache:Ein Messpunkt für CUMULATIVE oder DELTA hat einen start_time-Wert, der größer oder gleich dem end_time-Wert ist.
    • Lösung:Achten Sie darauf, dass der Wert für start_time kleiner als der Wert für end_time ist und ein Zeitintervall ungleich null darstellt.

  • Field points[0].interval.end_time had an invalid value of "[TIME]": Data points cannot be written more than 5m into the future.

    • Ursache:Der Zeitstempel des Punktes liegt mehr als 5 Minuten vor der aktuellen Serverzeit.
    • Lösung:Synchronisieren Sie die Systemuhr mit Google Public NTP (time.google.com).

  • Field points[0].interval.end_time had an invalid value of "[TIME]": Data points cannot be written more than approximately 24 hours in the past

    • Ursache:Der Zeitstempel des Punkts ist älter als der In-Memory-Aufbewahrungszeitraum von 24 Stunden.
    • Lösung:Schreiben Sie Echtzeitdaten innerhalb von 24 Stunden nach der Generierung.

Werttypen und Verteilungen

In den folgenden Listen sind Fehlermeldungen im Zusammenhang mit Werttypen und Verteilungen aufgeführt:

  • value type for metric must be [EXPECTED], but is [ACTUAL] oder metric kind for metric must be [EXPECTED], but is [ACTUAL]

    • Ursache:Der eingehende Werttyp (INT64, DOUBLE, STRING, BOOL, DISTRIBUTION) oder die Art der Messwertart (GAUGE, DELTA, CUMULATIVE) steht im Konflikt mit dem vorhandenen MetricDescriptor.
    • Lösung:Achten Sie darauf, dass die Datentypen mit dem vorhandenen Deskriptor übereinstimmen. Werttypen und Messwertarten können nach der Erstellung nicht mehr geändert werden.

  • Field points[0].value had an invalid value: The metric value exceeds the maximum string size of 1024 characters

    • Ursache:Ein Messwertpunkt vom Typ STRING überschreitet 1.024 Zeichen.
    • Lösung:Kürzen Sie String-Messwertwerte auf maximal 1.024 Zeichen oder senden Sie Logs stattdessen an Cloud Logging.

  • Field points[0].value had an invalid value: Bucket options must be specified for Distribution metric

    • Ursache:Für einen DISTRIBUTION-Punkt ist bucket_options nicht angegeben.
    • Lösung:Definieren Sie linear_buckets, exponential_buckets oder explicit_buckets für Verteilungsmesswerte.

  • Field points[0].value.distributionValue had an invalid value: Distribution value has |bucket_counts| fields that sum to X which does not equal the |count| field value of Y

    • Ursache:Die Summe der Anzahl in bucket_counts entspricht nicht dem Feld count.
    • Lösung:Die Summe aller Bucket-Anzahlen muss mit der Stichprobe count übereinstimmen.

  • Field points[0].value had an invalid value: Distribution metric has too many buckets

    • Ursache:Die Anzahl der Histogramm-Buckets überschreitet 200.
    • Auflösung:Passen Sie die Bucket-Parameter an, damit die Gesamtzahl der Buckets maximal 200 beträgt.

400 FAILED_PRECONDITION

In den folgenden Listen finden Sie Fehlermeldungen, die mit diesem Fehlercode zusammenhängen:

  • One or more points were written more frequently than the maximum sampling period configured for the metric

    • Ursache:Punkte für dieselbe Zeitachse wurden schneller als die maximal zulässige Rate von einem Punkt alle 5 Sekunden gesendet.
    • Lösung:Beschränken Sie die Aufnahme von Daten so, dass zwischen aufeinanderfolgenden Punkten für eine bestimmte Zeitreihe mindestens 5 Sekunden liegen.

  • ingestion of prometheus delta metrics is not supported in this API

    • Ursache:Mit der Anfrage wurde versucht, Prometheus-DELTA-Messwerte über timeSeries.create zu schreiben.
    • Lösung:Verwenden Sie Prometheus-Messwerte vom Typ GAUGE oder CUMULATIVE oder nehmen Sie Daten über die OTLP-Endpunkte von Google Cloud Managed Service for Prometheus auf.

  • One or more points arrived late outside of its aggregation window

    • Ursache:Punkte sind nach dem Aggregationszeitraum für Messwerte mit Sammlungsebenen eingegangen.
    • Lösung:Leeren Sie den Puffer und streamen Sie Punkte mit niedrigeren Pufferlatenzen.

403 PERMISSION_DENIED beim Schreiben von Messwertdaten

Beim Schreiben von Messwertdaten kann aus Gründen, die mit Projektzugriff und Abrechnung zusammenhängen, und aus den folgenden Gründen eine 403 PERMISSION_DENIED-Antwort zurückgegeben werden:

  • Permission monitoring.timeSeries.create denied on resource (or it may not exist)

    • Ursache:Dem Aufrufer fehlt die Berechtigung monitoring.timeSeries.create für das Zielprojekt.
    • Lösung:Weisen Sie dem Dienstkonto oder Hauptkonto die Rolle Monitoring Metric Writer (roles/monitoring.metricWriter) zu.

  • Billing check failed for project [PROJECT_ID] oder Billing account disabled

    • Ursache:Cloud Billing ist für dasGoogle Cloud Projekt deaktiviert oder gesperrt. Für die Aufnahme benutzerdefinierter Messwerte ist ein aktives Rechnungskonto erforderlich.
    • Lösung:Verknüpfen Sie ein aktives Cloud-Rechnungskonto mit dem Projekt in der Google Cloud -Konsole.

  • User does not have permission to write to metric [METRIC]

    • Ursache:Der Aufrufer hat versucht, benutzerdefinierte Messwerte direkt in systemreservierte Domains wie compute.googleapis.com oder storage.googleapis.com zu schreiben.
    • Lösung:Verwenden Sie benutzerdefinierte Messwertdomains wie custom.googleapis.com/ oder workload.googleapis.com/.

429 RESOURCE_EXHAUSTED

In den folgenden Listen finden Sie Fehlermeldungen, die mit diesem Fehlercode zusammenhängen:

  • Monitored resource ([RESOURCE_ID]) has too many time series (custom metrics)

    • Ursache:Das Limit für aktive Zeitachsen wurde überschritten (hohe Kardinalität). Die Anzahl der aktiven Zeitreihen für eine einzelne überwachte Ressource hat das Limit von 200.000 aktiven Zeitreihen in einem 24-Stunden-Zeitraum überschritten. Für Prometheus-Messwerte gilt ein Limit von 1.000.000 aktiven Zeitreihen. Das passiert in der Regel, wenn temporäre IDs wie Container-IDs, Pod-UUIDs, Anfrage-IDs, Nutzer-IDs oder Zeitstempel in Messwertlabels für Ressourcen mit hoher Fluktuation enthalten sind.
    • Lösung:
      • Entfernen Sie kurzlebige oder Labels mit hoher Kardinalität aus Ihren Messwerten.
      • Wenn Sie Messwerte für einzelne kurzlebige Aufgaben erfassen müssen, verwenden Sie den überwachten Ressourcentyp generic_task anstelle von ressourcenspezifischen Typen wie dataflow_job. Ordnen Sie die temporäre Kennung dem Label task_id der Ressource generic_task zu.

  • Your Metric Ingestion quota has been exhausted

    • Ursache:Das Projekt hat das Ratenkontingent für die API-Aufnahme überschritten.
    • Lösung:Führen Sie Batch-Schreibvorgänge für Zeitreihen mit bis zu 200 Serien pro Anfrage durch oder fordern Sie auf der Seite „Kontingente“ in der Google Cloud Console eine Kontingenterhöhung an.

  • Your Metric Descriptors quota has been exhausted

    • Ursache:Das Projekt hat das maximale Limit von 10.000 benutzerdefinierten Messwertdeskriptoren pro Projekt erreicht. Für Prometheus-Messwerte gilt ein Limit von 25.000 Messwerten pro Projekt.
    • Lösung:Löschen Sie nicht verwendete Messwertdeskriptoren mit projects.metricDescriptors.delete oder reduzieren Sie die dynamische Benennung von Messwerten.

  • Rate of metric descriptor creation exceeded

    • Ursache:Im Projekt wurde versucht,neue Messwertdeskriptoren schneller als 6.000 pro Minute und Projekt zu erstellen.
    • Lösung:Vermeiden Sie das dynamische Erstellen neuer Messwerttypen während der Datenerfassung. Erstellen Sie Deskriptoren nach Möglichkeit im Voraus.

API-Fehler wiederholen

Zwei der Cloud APIs-Fehlercodes geben Gründe an, in denen die Anfrage eventuell wiederholt werden kann:

  • 503 UNAVAILABLE: Wiederholungsversuche sind nützlich, wenn das Problem eine kurzfristige oder vorübergehende Bedingung ist.
  • 429 RESOURCE_EXHAUSTED: Wiederholungsversuche sind nach einer Verzögerung hilfreich, nur für lang andauernde Hintergrundjobs mit zeitbasiertem Kontingent, z. B. wenn auf n Aufrufe pro t Sekunden. Wiederholungsversuche sind nicht hilfreich, wenn das Problem kurzlebig oder vorübergehend ist oder wenn Sie ein volumebasiertes Kontingent ausgeschöpft haben. Bei vorübergehenden Bedingungen sollten Sie den Fehler tolerieren. Bei kontingentbezogenen Problemen sollten Sie Ihre Kontingentnutzung reduzieren oder eine Kontingenterhöhung beantragen.

Wenn Sie Code schreiben, der Anfragen möglicherweise wiederholt, prüfen Sie zuerst, ob die Anfrage wieder korrekt ist.

Ist die Anfrage sicher für einen erneuten Versuch?

Wenn Ihre Anfrage idempotent ist, kann der Vorgang wiederholt werden. Eine idempotente Aktion ist eine, bei der jede Statusänderung nicht vom aktuellen Status abhängt. Beispiel:

  • Das Lesen von x ist idempotent; Der Wert bleibt unverändert.
  • Die Festlegung von x auf 10 ist idempotent. Sonst wird unter Umständen der Zustand geändert, wenn der Wert noch nicht 10 ist, der aktuelle Wert jedoch nicht berücksichtigt wird. Dabei spielt es keine Rolle, wie oft Sie den Wert festlegen möchten.
  • Die Erhöhung von x ist nicht idempotent; hängt der neue Wert vom aktuellen Wert ab.

Mit exponentiellem Backoff wiederholen.

Wenn Sie Code für das erneute Senden von Anfragen implementieren, sollten Sie neue Anfragen nicht unbegrenzt auf unbestimmte Zeit veröffentlichen. Wenn ein System überlastet ist, trägt dieses Ansatz zu dem Problem bei.

Verwenden Sie stattdessen einen abgeschnittenen exponentiellen Backoff. Wenn Anfragen aufgrund vorübergehender Überlastungen und nicht von echter Nichtverfügbarkeit fehlschlagen, reduziert sich diese Lösung. Ein abgeschnittenes exponentielles Backoff folgt diesem allgemeinen Muster:

  • Legen Sie fest, wie lange Sie warten möchten, und versuchen Sie es dann noch einmal. Wenn dieses Limit überschritten wird, beachten Sie, dass der Dienst nicht verfügbar ist, und behandeln diese Bedingung für Ihre Anwendung entsprechend. Dadurch wird der Backoff abgekürzt. An einem bestimmten Punkt hören Sie auf, weitere Wiederholungsversuche zu unternehmen.

  • Wiederholen Sie die Anfrage mit zunehmend längeren Pausen, um die Häufigkeit von Wiederholungsversuchen zurückzusetzen. Wiederholen Sie den Vorgang, bis die Anfrage erfolgreich ist oder das festgelegte Limit erreicht ist.

    Das Intervall wird in der Regel um einige Funktionen der Wiederholungsanzahl erhöht und ist somit ein exponentieller Backoff.

Es gibt viele Möglichkeiten, einen exponentiellen Backoff zu implementieren. Nachfolgend ein Beispiel, das eine zunehmende Backoff-Verzögerung zu einer minimalen Verzögerung von 1000 ms hinzufügt. Die anfängliche Backoff-Verzögerung beträgt 2 ms und wird bei jedem Versuch auf 2retry_count ms erhöht.

Die folgende Tabelle zeigt die Wiederholungsintervalle unter Verwendung der Anfangswerte:

  • Mindestverzögerung = 1 s = 1.000 ms
  • Anfänglicher Backoff = 2 ms
Anzahl der erneuten Versuche Zusätzliche Verzögerung (ms) Erneut versuchen nach (ms)
0 20 = 1 1001
1 21 = 2 1002
2 22 = 4 1004
3 23 = 8 1008
4 24 = 16 1016
… … …
N 2n 1000 + 2n

Sie können den Wiederholungszyklus verkürzen, indem Sie entweder nach n Versuchen oder nach dem Erreichen eines angemessenen Werts für Ihre Anwendung warten.

Weitere Informationen finden Sie im Wikipedia-Artikel Exponentieller Backoff.