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.

APIs Explorer für die Fehlerbehebung verwenden

APIs Explorer ist ein in die Referenzseiten für API-Methoden eingebundenes Widget. 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 APIs 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-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.
  • 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 den APIs Explorer nicht nutzen, versuchen Sie es stattdessen. Wenn Ihr API-Aufruf in APIs Explorer funktioniert, gibt es wahrscheinlich ein Autorisierungsproblem in der Umgebung, 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 APIs Explorer verwenden, geben Sie den Wert des Zeitfelds nicht an.

    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: Wiederholungen sind nach einer Verzögerung nur für Hintergrundjobs mit langer Ausführungszeit mit zeitbasiertem Kontingent nützlich, z. B. wenn Sie 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.