Standardfehlerantworten
Wenn eine Real Time Reporting API-Anfrage erfolgreich ist, gibt die API den Statuscode 200
zurück. Wenn bei einer Anfrage ein Fehler auftritt, gibt die API je nach Fehlertyp einen HTTP-Statuscode, -status und -grund in der Antwort zurück.
Außerdem enthält der Antworttext eine detaillierte Beschreibung der Fehlerursache. 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 enthalten Informationen darüber, welcher Wert ungültig war. |
Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Für den in der Fehlerantwort angegebenen Parameter muss ein gültiger Wert angegeben werden. |
400 | badRequest |
Gibt an, dass die Abfrage ungültig war. Beispiel: Die übergeordnete ID fehlte oder die Kombination der angeforderten Dimensionen oder Messwerte war ungültig. | 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 ist oder abgelaufen ist. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie benötigen ein neues Authentifizierungstoken. |
403 | insufficientPermissions |
Gibt an, dass der Nutzer keine ausreichenden Berechtigungen für die in der Abfrage angegebene Entität hat. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie benötigen ausreichende Berechtigungen, um den Vorgang für die angegebene Entität ausführen zu können. |
403 | dailyLimitExceeded |
Gibt an, dass der Nutzer das Tageskontingent entweder pro Projekt oder pro Ansicht (Profil) überschritten hat. | Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Ihr Tageskontingent ist aufgebraucht. Siehe API-Limits und Kontingente. |
403 | userRateLimitExceeded |
Gibt an, dass das Limit für Abfragen pro 100 Sekunden pro Nutzer überschritten wurde. Der in der Google API Console festgelegte Standardwert ist 100 Abfragen pro 100 Sekunden und Nutzer. Sie können dieses Limit in der Google API Console auf maximal 1.000 erhöhen. | Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit verlangsamen, mit der Sie die Anfragen senden. |
403 | rateLimitExceeded |
Gibt an, dass die Ratenbegrenzungen für Abfragen pro 100 Sekunden überschritten wurden. | Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit verlangsamen, mit der Sie die Anfragen senden. |
403 | quotaExceeded |
Gibt an, dass die zehn gleichzeitigen Anfragen pro Datenansicht (Profil) in der Core Reporting API erreicht wurden. | Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Warten Sie, bis mindestens eine Anfrage in Bearbeitung ist, damit diese Datenansicht (Profil) abgeschlossen werden kann. |
500 | internalServerError |
Ein unerwarteter interner Serverfehler ist aufgetreten. | Wiederholen Sie diese Abfrage nicht mehr als einmal. |
503 | backendError |
Der Server hat einen Fehler zurückgegeben. | Wiederholen Sie diese Abfrage nicht mehr als einmal. |
500 oder 503 Antworten verarbeiten
Ein 500
- oder 503
-Fehler kann bei starker Auslastung oder bei komplexeren Anfragen auftreten. Bei größeren Anfragen sollten Sie Daten für einen kürzeren Zeitraum anfordern. Sie sollten sich auch überlegen, exponentiellen Backoff zu implementieren.
Die Häufigkeit dieser Fehler hängt von der Ansicht (Profil) und der Menge der damit verbundenen Berichtsdaten ab. Eine Abfrage, die den Fehler 500
oder 503
für eine Datenansicht (Profil) verursacht, führt nicht unbedingt zu einem Fehler für dieselbe Abfrage mit einer anderen Datenansicht (Profil).
Exponentiellen Backoff implementieren
Der exponentielle Backoff ist der Prozess, bei dem ein Client eine fehlgeschlagene Anfrage regelmäßig über einen zunehmenden Zeitraum wiederholt. Dies ist eine standardmäßige Strategie zur Fehlerbehandlung von Netzwerkanwendungen. Die Real Time Reporting API wurde in der Erwartung entwickelt, dass Clients, die fehlgeschlagene Anfragen wiederholen möchten, dies mithilfe eines exponentiellen Backoffs tun. Die Verwendung eines exponentiellen Backoffs sorgt nicht nur für die Anforderung „exponentiell erforderlich“, sondern erhöht auch die Effizienz der Bandbreitennutzung, verringert die Anzahl der Anfragen, die für den Erhalt einer erfolgreichen Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in gleichzeitigen Umgebungen.
So implementieren Sie einen einfachen exponentiellen Backoff:
- Anfrage an die API senden
- Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
- 1 Sekunde +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
- 2 Sekunden +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
- 4 Sekunden +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
- 8 s +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
- 16 Sekunden +
random_number_milliseconds
Sekunden warten - Anfrage wiederholen
- Wenn Sie weiterhin eine Fehlermeldung erhalten, beenden Sie den Fehler 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 ist immer (2 ^ n) + random_number_milliseconds
, wobei n eine monoton ansteigende Ganzzahl ist, die anfangs als 0 definiert ist. n wird für jede Iteration (jede Anfrage) um 1 erhöht.
Der Algorithmus ist so eingerichtet, dass er endet, wenn n = 5. Diese Obergrenze dient lediglich dazu, die unendliche Wiederholung von Clients zu verhindern. Dies 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 zur Wiederherstellung nach 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."