Standardfehlerantworten
Wenn eine Multi-Channel-Trichter Reporting API-Anfrage erfolgreich ist, gibt die API den Statuscode 200
zurück. Wenn bei einer Anfrage ein Fehler auftritt, gibt die API in der Antwort einen HTTP-Statuscode, Status und Grund basierend auf dem Fehlertyp zurück.
Darüber hinaus enthält der Antworttext eine detaillierte Beschreibung der Fehlerursache. Hier ist ein Beispiel für eine Fehlerantwort:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalidParameter",
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
"locationType": "parameter",
"location": "max-results"
}
],
"code": 400,
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
}
}
Fehlertabelle
Code | Grund | Beschreibung | Empfohlene Maßnahme |
---|---|---|---|
400 | invalidParameter |
Gibt an, dass ein Anfrageparameter einen ungültigen Wert hat. Die Felder locationType und location in der Fehlerantwort geben an, welcher Wert ungültig war. |
Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie müssen einen gültigen Wert für den in der Fehlerantwort angegebenen Parameter angeben. |
400 | badRequest |
Gibt an, dass die Abfrage ungültig war. Dies kann beispielsweise der Fall sein, wenn die ID des übergeordneten Elements fehlt oder die angeforderte Kombination aus Dimensionen oder Messwerten ungültig war. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie müssen Änderungen an der API-Abfrage vornehmen, damit sie funktioniert. |
401 | invalidCredentials |
Gibt an, dass das Authentifizierungstoken ungültig oder abgelaufen ist. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie müssen ein neues Authentifizierungstoken anfordern. |
403 | insufficientPermissions |
Gibt an, dass der Nutzer nicht über ausreichende Berechtigungen für die in der Abfrage angegebene Entität verfügt. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie benötigen ausreichende Berechtigungen, um den Vorgang für die angegebene Entität auszuführen. |
403 | dailyLimitExceeded |
Gibt an, dass der Nutzer das Tageskontingent (pro Projekt oder pro Datenansicht (Profil)) überschritten hat. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie haben Ihr Tageskontingent aufgebraucht. Siehe API-Limits und Kontingente. |
403 | userRateLimitExceeded |
Gibt an, dass das Limit für Abfragen pro 100 Sekunden und Nutzer überschritten wurde. Der Standardwert in der Google API Console ist 100 Abfragen pro 100 Sekunden und Nutzer. Sie können dieses Limit in der Google API Console auf maximal 1.000 erhöhen. | Wiederholen Sie den Vorgang mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit, mit der Sie die Anfragen senden, verringern. |
403 | rateLimitExceeded |
Gibt an, dass die Ratenlimits für die Abfragen pro 100 Sekunden des Projekts überschritten wurden. | Wiederholen Sie den Vorgang mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit, mit der Sie die Anfragen senden, verringern. |
403 | quotaExceeded |
Gibt an, dass die 10 gleichzeitigen Anfragen pro Datenansicht (Profil) in der Core Reporting API erreicht wurden. | Wiederholen Sie den Vorgang mit dem exponentiellen Backoff. Sie müssen warten, bis mindestens eine laufende Anfrage ausgeführt wird, damit diese Ansicht bzw. dieses Profil abgeschlossen wird. |
500 | internalServerError |
Ein unerwarteter interner Serverfehler ist aufgetreten. | Wiederholen Sie diese Abfrage nur einmal. |
503 | backendError |
Der Server hat einen Fehler zurückgegeben. | Wiederholen Sie diese Abfrage nur einmal. |
500- oder 503-Antworten verarbeiten
Ein 500
- oder 503
-Fehler kann bei hoher Auslastung oder bei größeren, komplexeren Anfragen auftreten. Bei größeren Anfragen sollten Sie Daten für einen kürzeren Zeitraum anfordern. Ziehen Sie auch die Implementierung des exponentiellen Backoffs in Betracht.
Die Häufigkeit dieser Fehler hängt von der Datenansicht (Profil) und der Menge der Berichtsdaten ab, die mit dieser Datenansicht verknüpft sind. Eine Abfrage, die für eine Datenansicht (Profil) den Fehler 500
oder 503
verursacht, führt nicht unbedingt zu einem Fehler für dieselbe Abfrage mit einer anderen Datenansicht (einem anderen Profil).
Exponentiellen Backoff implementieren
Ein exponentieller Backoff ist der Prozess, bei dem ein Client eine fehlgeschlagene Anfrage regelmäßig wiederholt, während er immer länger wird. Es ist eine standardmäßige Fehlerbehandlungsstrategie für Netzwerkanwendungen. Bei der Entwicklung der Multi-Channel Trichter Reporting API wird erwartet, dass Kunden, die fehlgeschlagene Anfragen wiederholen, dies mithilfe des exponentiellen Backoffs tun. Der exponentielle Backoff ist nicht nur „erforderlich“, sondern erhöht auch die Effizienz der Bandbreitennutzung, die Anzahl der für eine erfolgreiche Antwort erforderlichen Anfragen und maximiert den Durchsatz von Anfragen in Umgebungen, die gleichzeitig ausgeführt werden.
Der Ablauf zur Implementierung eines einfachen exponentiellen Backoffs sieht so aus:
- Anfrage an die API stellen
- Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode
- 1 Sek. +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode
- 2 Sek. +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode
- 4 Sek. +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode
- 8 Sek. +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode
- 16 Sek. +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Wenn Sie weiterhin einen Fehler erhalten, beenden Sie den Vorgang und protokollieren Sie ihn.
Im obigen Ablauf ist random_number_milliseconds
eine zufällige Anzahl von Millisekunden, die kleiner oder gleich 1.000 ist. Dies ist erforderlich, um bestimmte Sperrfehler in einigen gleichzeitigen Implementierungen zu vermeiden.
random_number_milliseconds
muss nach jeder Wartezeit neu definiert werden.
Hinweis: Die Wartezeit beträgt immer (2 ^ n) + random_number_milliseconds
, wobei n eine monoton ansteigende Ganzzahl ist, die anfänglich als 0 definiert ist. n wird bei jeder Iteration (jede Anfrage) um 1 erhöht.
Der Algorithmus ist so eingerichtet, dass er endet, wenn n = 5. Diese Obergrenze verhindert nur, dass Clients unbegrenzte Wiederholungen ausführen. Sie führt zu einer Gesamtverzögerung von etwa 32 Sekunden, bevor eine Anfrage als "nicht behebbarer Fehler" gilt.
Der folgende Python-Code ist eine Implementierung des obigen Ablaufs zum Beheben von Fehlern, die in einer Methode namens makeRequest
auftreten.
import random import time from apiclient.errors import HttpError def makeRequestWithExponentialBackoff(analytics): """Wrapper to request Google Analytics data with exponential backoff. The makeRequest method accepts the analytics service object, makes API requests and returns the response. If any error occurs, the makeRequest method is retried using exponential backoff. Args: analytics: The analytics service object Returns: The API response from the makeRequest method. """ for n in range(0, 5): try: return makeRequest(analytics) except HttpError, error: if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded', 'internalServerError', 'backendError']: time.sleep((2 ** n) + random.random()) else: break print "There has been an error, the request never succeeded."