Fehlermeldungen

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:

  1. Anfrage an die API senden
  2. Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
  3. 1 Sekunde + random_number_milliseconds Sekunden warten
  4. Anfrage wiederholen
  5. Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
  6. 2 Sekunden + random_number_milliseconds Sekunden warten
  7. Anfrage wiederholen
  8. Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
  9. 4 Sekunden + random_number_milliseconds Sekunden warten
  10. Anfrage wiederholen
  11. Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
  12. 8 s + random_number_milliseconds Sekunden warten
  13. Anfrage wiederholen
  14. Eine Fehlermeldung mit einem wiederholbaren Fehlercode empfangen
  15. 16 Sekunden + random_number_milliseconds Sekunden warten
  16. Anfrage wiederholen
  17. 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."