Fehlerantworten

Standardfehlerantworten

Wenn eine User Deletion API-Anfrage erfolgreich ist, gibt die API den Statuscode 200 zurück. Wenn bei einer Anfrage ein Fehler auftritt, gibt die API einen HTTP-Statuscode, den Status und den Grund in der Antwort je nach Fehlertyp zurück. Außerdem enthält der Antworttext eine detaillierte Beschreibung der Fehlerursache. Hier 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 Parameter angeben, der in der Fehlerantwort angegeben ist.
400 badRequest Gibt an, dass die Abfrage ungültig war. Das könnte z.B. der Fall sein, wenn die ID des übergeordneten Elements fehlt oder die angeforderte Kombination von 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 überschritten hat (entweder pro Projekt oder pro Ansicht (Profil)). Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Sie haben Ihr Tageskontingent aufgebraucht. Siehe API-Limits und Kontingente.
403 userRateLimitExceeded Zeigt an, dass das Limit 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 bis zu 1.000 erhöhen. Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit verringern, mit der Anfragen gesendet werden.
403 rateLimitExceeded Zeigt an, dass die Ratenbegrenzungen für Abfragen pro 100 Sekunden des Projekts überschritten wurden. Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit verringern, mit der Anfragen gesendet werden.
403 quotaExceeded Gibt an, dass die 10 gleichzeitigen Anfragen pro Datenansicht (Profil) in der Core Reporting API erreicht wurden. Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen warten, bis mindestens eine in Bearbeitung befindliche Anfrage abgeschlossen ist, damit diese Ansicht bzw. dieses 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

Bei hoher Last oder bei größeren, komplexeren Anfragen kann der Fehler 500 oder 503 auftreten. Bei größeren Anfragen sollten Sie Daten für einen kürzeren Zeitraum anfordern. Erwägen Sie auch die Implementierung eines exponentiellen Backoffs. Die Häufigkeit dieser Fehler kann von der Datenansicht (Profil) und der Menge der mit dieser Datenansicht verknüpften Berichtsdaten abhängen. 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 (Profil).

Exponentiellen Backoff implementieren

Ein exponentieller Backoff ist der Prozess, bei dem ein Client eine fehlgeschlagene Anfrage regelmäßig über einen zunehmenden Zeitraum wiederholt. Dies ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Die User Deletion API wurde so konzipiert, dass Clients, die fehlgeschlagene Anfragen wiederholen, dies mithilfe von exponentiellem Backoff tun. Der exponentielle Backoff ist nicht nur „erforderlich“, sondern erhöht auch die Effizienz der Bandbreitennutzung, reduziert die Anzahl der Anfragen, die für eine erfolgreiche Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in gleichzeitigen Umgebungen.

Der Ablauf zur Implementierung eines einfachen exponentiellen Backoffs ist wie folgt.

  1. Anfrage an die API senden
  2. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  3. 1 s + random_number_milliseconds Sekunden warten
  4. Anfrage wiederholen
  5. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  6. 2 s + random_number_milliseconds Sekunden warten
  7. Anfrage wiederholen
  8. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  9. 4 s + random_number_milliseconds Sekunden warten
  10. Anfrage wiederholen
  11. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  12. 8 s + random_number_milliseconds Sekunden warten
  13. Anfrage wiederholen
  14. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  15. 16 s + random_number_milliseconds Sekunden warten
  16. Anfrage wiederholen
  17. 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 bei 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 kontinuierlich 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 gilt nur, um zu verhindern, dass Clients unendlich viele Versuche ausführen. Dies führt zu einer Gesamtverzögerung von etwa 32 Sekunden, bevor eine Anfrage als „nicht behebbarer Fehler“ erachtet wird.

Der folgende Python-Code ist eine Implementierung des obigen Ablaufs zur Behebung 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."