Fehlerbehebung bei der Monitoring API

In dieser Anleitung werden einige der Probleme erläutert, die bei der Verwendung der Monitoring API 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 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 den APIs Explorer. (API testen) auf der Referenzseite für diese Methode, um zur Fehlerbehebung. 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 mit "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. Dieser Fehler kann auf einen Rechtschreibfehler wie „project“ statt „projects“ oder einen Groß-/Kleinschreibungsfehler wie „TimeSeries“ statt „timeSeries“ zurückzuführen sein.

• 401 UNAUTHENTICATED mit „Der Nutzer ist nicht zum Zugriff auf das Projekt (oder den Messwert) berechtigt“: Dieser Fehlercode weist in der Regel auf ein Autorisierungsproblem hin, kann aber auch bedeuten, dass ein Fehler in der Projekt-ID oder im Namen des Messwerttyps vorliegt. Prüfen Sie die Rechtschreibung und Großschreibung.

  Wenn Sie den APIs Explorer noch nicht verwenden, sollten Sie das nachholen. 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.

• 400 INVALID_ARGUMENT mit „Feldfilter hatte einen ungültigen Wert“: Prüfen Sie die die Rechtschreibung und Formatierung des 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, setzen Sie den Wert des Zeitfelds nicht in Anführungszeiche.

  Hier sind einige Beispiele für gültige Zeitangaben:

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

Fehlende Ergebnisse

Wenn ein API-Aufruf den Statuscode 200 und eine leere Antwort zurückgibt, gehen Sie so vor:

• 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. Filter aufheben geben Sie zunächst nur eine Filterkomponente an, metric.type und prüfen Sie, ob Sie Ergebnisse erhalten. Fügen Sie die anderen Filterkomponenten nacheinander hinzu, um Ihre Anfrage zu erstellen.

• Prüfen Sie bei der Arbeit mit einem benutzerdefinierten Messwert, ob das Projekt angegeben ist, in dem der Messwert definiert ist.

Es kann mehrere Gründe dafür geben, dass bei der Verwendung der Methode timeSeries.list Datenpunkte fehlen:

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

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

• Das Intervall ist ungültig:

  • Prüfen Sie, ob die Uhrzeit für das Ende korrekt ist.
  • Prüfen Sie, ob die Startzeit korrekt und vor der Endzeit liegt. Wenn die Startzeit fehlt oder falsch formatiert ist, setzt die API die Startzeit auf die Endzeit. Für GAUGE-Messwerte nur dieses Zeitintervall stimmt mit Punkten überein, deren Start- und Endzeit genau den Zeiten des Intervalls entsprechen Endzeit. Bei CUMULATIVE- oder DELTA-Messwerten, die über Zeitintervalle hinweg gemessen werden, werden keine Punkte abgeglichen. 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. n Aufrufe pro t Sekunden. Wiederholungsversuche sind nicht hilfreich, wenn das Problem nur kurz vorübergehenden Zustand oder wenn ein volumenbasiertes Kontingent ausgeschöpft ist. Bei vorübergehenden Bedingungen sollten Sie den Fehler tolerieren. Bei kontingentbezogenen Problemen können Sie die 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. Das folgende Beispiel zeigt ein 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 2^retry_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	2^0 = 1	1001
1	2^1 = 2	1002
2	2^2 = 4	1004
3	2^3 = 8	1008
4	2^4 = 16	1016
…	…	…
N	2^n	1000 + 2^n

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.