Fehlerbehebung bei der Monitoring API

In diesem Leitfaden werden einige 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 zum Debugging verwenden

APIs Explorer ist ein Widget, das in die Referenzseiten für API-Methoden integriert ist. Sie können die Methode aufrufen, indem Sie Felder ausfüllen. Sie müssen dafür keinen Code schreiben.

Wenn bei einem Methodenaufruf Probleme auftreten, können Sie das Problem mithilfe des APIs Explorer-Widgets (API testen) auf der Referenzseite für diese Methode 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 mit "Die angeforderte URL wurde auf diesem Server nicht gefunden": Ein Teil der URL ist falsch. Vergleichen Sie die URL mit der URL für die Methode, die auf der Referenzseite der Methode angezeigt wird. Dieser Fehler kann bedeuten, dass ein Rechtschreibfehler wie „Projekt“ statt „Projekte“ oder ein Großschreibungsfehler wie „TimeSeries“ anstelle von „timeSeries“ vorliegt.
401 UNAUTHENTICATED durch „Nutzer ist nicht berechtigt, auf das Projekt oder den Messwert zuzugreifen“: Dieser Fehlercode weist in der Regel auf ein Autorisierungsproblem hin, kann aber bedeuten, dass die Projekt-ID oder der Name des Messwerttyps fehlerhaft ist. Überprüfen Sie die Rechtschreibung, einschließlich der Groß-/Kleinschreibung.

Wenn Sie APIs Explorer nicht verwenden, probieren Sie es aus. Wenn der API-Aufruf im APIs Explorer funktioniert, liegt wahrscheinlich ein Autorisierungsproblem in der Umgebung vor, in der Sie den API-Aufruf ausführen. Rufen Sie die API-Manager-Seite 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 Schreibweise und Formatierung des Monitoringfilters. Weitere Informationen finden Sie unter Filter überwachen.
400 INVALID_ARGUMENT mit „Request was missing field period.endTime““: Diese Meldung wird angezeigt, wenn die Endzeit fehlt oder vorhanden ist, aber nicht richtig formatiert ist. Wenn Sie APIs Explorer verwenden, dürfen Sie den Wert des Zeitfelds nicht zitieren.

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, beachten Sie Folgendes:

Wenn beim Aufruf ein Filter verwendet wird, stimmt er möglicherweise mit keinem Filter überein. Bei der Filterübereinstimmung wird zwischen Groß- und Kleinschreibung unterschieden. Wenn Sie Filterprobleme beheben möchten, geben Sie zuerst 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, muss das Projekt angegeben sein, das den Messwert definiert.

Wenn Sie die Methode timeSeries.list verwenden, kann es mehrere Gründe dafür geben, dass Datenpunkte fehlen:

Die Daten sind möglicherweise älter. 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:
- Überprüfen Sie, ob die Endzeit korrekt ist.
- Prüfen Sie, ob die Startzeit korrekt und vor der Endzeit liegt. Wenn die Startzeit fehlt oder fehlerhaft ist, legt die API die Startzeit auf die Endzeit fest. Bei GAUGE-Messwerten stimmt dieses Zeitintervall nur mit Punkten überein, deren Start- und Endzeit genau dem Ende des Intervalls entsprechen. Für CUMULATIVE- oder DELTA-Messwerte, die über Zeitintervalle hinweg gemessen werden, werden keine Punkte zugeordnet. 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 ein kurzlebiger oder vorübergehender Zustand ist.
429 RESOURCE_EXHAUSTED: Wiederholungsversuche sind nach einer Verzögerung für lang andauernde Hintergrundjobs mit zeitbasierten Kontingenten wie n Aufrufen pro t Sekunden nützlich. Wiederholungsversuche sind nicht nützlich, wenn das Problem ein kurzlebiger oder vorübergehender Zustand ist oder wenn Sie ein volumenbasiertes Kontingent ausgeschöpft haben. Erwägen Sie, den Fehler bei vorübergehenden Bedingungen zu tolerieren. Bei Problemen mit dem Kontingent können Sie Ihre Kontingentnutzung reduzieren oder eine Erhöhung des Kontingents 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. Im folgenden Beispiel wird eine zunehmende Backoff-Verzögerung zu einer Mindestverzögerung von 1.000 ms hinzugefügt. 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⁰ = 1	1001
1	2¹ = 2	1002
2	2² = 4	1004
3	2³ = 8	1008
4	2⁴ = 16	1016
...	...	...
n	2ⁿ	1000 + 2ⁿ

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.