Fehlerbehebung bei der Monitoring API

In dieser Anleitung werden einige der Probleme erläutert, die bei der Verwendung der Monitoring API v3 auftreten können.

Die Monitoring API ist eine der Cloud APIs. Diese APIs haben eine gemeinsame Reihe von Fehlercodes. Eine Liste der Fehlercodes, die von den Cloud APIs definiert werden, und allgemeine Vorschläge zur Fehlerbehandlung finden Sie unter Fehlerbehandlung.

API Explorer für die Fehlerbehebung verwenden

API 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 API Explorer.

Allgemeine API-Fehler

Nachfolgend finden Sie einige der Monitoring API-Fehler und -Meldungen, die bei API-Aufrufen angezeigt werden:

  • 404 NOT_FOUND

    • "Die angeforderte URL wurde auf diesem Server nicht gefunden": Ein Teil der URL ist falsch. Vergleichen Sie die URL mit der URL der Methode, die auf der Referenzseite der Methode dargestellt ist. Prüfen Sie, ob Rechtschreibfehler ("project" statt "projects") und Großschreibung ("TimeSeries" statt "timeSeries") vorliegen.

    • "projects/PROJECT_ID ist kein Arbeitsbereich": Das bedeutet, dass das von Ihnen verwendete Google Cloud-Projekt nicht Teil eines Cloud Monitoring-Arbeitsbereichs ist. Mit Arbeitsbereichen werden Monitoring-Informationen aus Google Cloud-Projekten organisiert. Bei den meisten Monitoring API-Methoden ist das Projekt Teil eines Arbeitsbereichs. Weitere Informationen finden Sie unter Arbeitsbereiche.

  • 401 UNAUTHENTICATED mit "User ist nicht zum Zugriff auf das Projekt (oder den Messwert) berechtigt". Dies kann ein Autorisierungsproblem sein, aber es kann auch bedeuten, dass Sie einfach eine Projekt-ID oder einen Messwerttyp falsch geschrieben haben. Überprüfen Sie die Rechtschreibung und die Großschreibung.

    Wenn Sie API Explorer nicht verwenden, probieren Sie es aus. Wenn der API-Aufruf in API Explorer funktioniert, liegt wahrscheinlich ein Autorisierungsproblem in der Umgebung vor, die Sie für Ihren API-Aufruf verwenden. Überprüfen Sie auf der Seite "API-Manager", ob die Monitoring API v3 für Ihr Projekt aktiviert ist.

  • 400 INVALID_ARGUMENT mit "Field filter has a invalid value" (Feldfilter hat einen ungültigen Wert): Prüfen Sie die Rechtschreibung und Formatierung Ihres Monitoringfilters. Weitere Informationen finden Sie unter Filter überwachen.

  • 400 INVALID_ARGUMENT mit "Request was missing field interval.endTime"": Diese Meldung wird angezeigt, wenn die Endzeit fehlt oder nicht vorhanden, sondern falsch formatiert ist. Wenn Sie API Explorer verwenden, setzen Sie den Wert des Zeitfelds nicht in Anführungszeiche.

    Hier einige Beispiele für korrekte Zeitangaben:

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

Fehlende Ergebnisse

Wenn Ihr API-Aufruf den Statuscode 200 und eine leere Antwort zurückgibt, gibt es mehrere Möglichkeiten:

  • Wenn in Ihrem 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, haben Sie möglicherweise nicht das Projekt angegeben, in dem der benutzerdefinierte Messwert definiert ist.

Wenn Sie Zeitachsendaten mit timeSeries.list abrufen und einige der Datenpunkte fehlen, überprüfen Sie die folgenden zusätzlichen Ursachen:

  • Wenn die Daten mehr als ein paar Wochen alt sind, sind sie möglicherweise abgelaufen. Weitere Informationen finden Sie unter Datenaufbewahrung.

  • Wenn die Daten nur geschrieben wurden, befinden sie sich möglicherweise noch nicht in Monitoring. Weitere Informationen finden Sie unter Latenz von Messwertdaten.

  • Überprüfen Sie, ob Sie das Zeitintervall korrekt angegeben haben:

    • Überprüfen Sie, ob die Endzeit korrekt ist.
    • Überprüfen Sie, ob die Startzeit korrekt und vor der Endzeit liegt. Wenn die Startzeit fehlt oder falsch formatiert ist, wird standardmäßig der Endzeitwert verwendet und das Zeitintervall stimmt nur mit den Punkten überein, deren Start- und Endzeit genau der Endzeit des Intervalls entspricht. (Dies gilt für GAUGE-Messwerte, die einen Zeitpunkt messen, aber nicht für CUMULATIVE- oder DELTA-Messwerte, die über Zeitintervalle messen. Weitere Informationen finden Sie unter Zeitintervalle.

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. Wenn Sie jedoch ein volumenbasiertes Kontingent ausgeschöpft haben, sind Wiederholungsversuche nicht hilfreich. Ihr Kontingent muss erhöht werden.

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. Das folgende Beispiel zeigt ein einfaches Backoff-Verzögerung mit einer minimalen Verzögerung von 1.000 ms. 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.