Fehlerantworten

Auf dieser Seite sind die Fehler aufgeführt, die Sie von der User Deletion API erhalten können. Außerdem wird erläutert, wie Sie 500er-Fehler behandeln und ein exponentielles Backoff implementieren.

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 in der Antwort einen HTTP-Statuscode, den Status und den Grund zurück, der auf die Art des Fehlers hinweist. 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. In den Feldern locationType und location der Fehlerantwort ist angegeben, 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. 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 Datenansicht (Profil)). 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 exponentiellem Backoff. Sie müssen die Rate, mit der Sie die Anfragen senden, verlangsamen.
403 rateLimitExceeded Gibt an, dass die Ratenlimits für Abfragen pro 100 Sekunden des Projekts überschritten wurden. Versuchen Sie es noch einmal mit dem exponentiellen Backoff. Sie müssen die Geschwindigkeit reduzieren, mit der Anfragen gesendet werden.
403 quotaExceeded Gibt an, dass die 10 gleichzeitigen Anfragen pro Datenansicht (Profil) in der Core Reporting API erreicht wurden. Wiederholen Sie den Vorgang mit exponentiellem Backoff. Sie müssen warten, bis mindestens eine laufende Anfrage für diese Ansicht (Profil) abgeschlossen ist.
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.

Umgang mit 500- oder 503-Antworten

Ein 500- oder 503-Fehler kann bei hoher Auslastung oder bei größeren, komplexeren Anfragen auftreten. Bei größeren Anfragen sollten Sie gegebenenfalls Daten für einen kürzeren Zeitraum anfordern. Sie können auch einen exponentiellen Backoff implementieren. Die Häufigkeit dieser Fehler kann von der Datenansicht (dem Profil) und der Menge der zugehörigen Berichtsdaten abhängen. Eine Abfrage, die für eine Datenansicht (ein Profil) einen 500- oder 503-Fehler verursacht, führt nicht unbedingt zu einem Fehler für dieselbe Abfrage mit einer anderen Datenansicht (einem anderen Profil).

Exponentiellen Backoff implementieren

Bei einem exponentiellen Backoff wiederholt ein Client eine fehlgeschlagene Anfrage in immer längeren Abständen. Es ist eine Standardstrategie zur Fehlerbehebung für Netzwerkanwendungen. Die User Deletion API wurde so konzipiert, dass Clients, die fehlgeschlagene Anfragen wiederholen möchten, dies mithilfe eines exponentiellen Backoffs tun. Neben der Tatsache, dass es „erforderlich“ ist, erhöht die Verwendung des exponentiellen Backoffs 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 Umgebungen mit Gleichzeitigkeit.

So implementieren Sie einen exponentiellen Backoff:

  1. Stellen Sie eine Anfrage an die API.
  2. Sie erhalten eine Fehlermeldung mit einem wiederholbaren Fehlercode.
  3. Warten Sie 1 Sekunde + random_number_milliseconds Sekunden.
  4. Wiederholen Sie die Anfrage.
  5. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  6. Warten Sie 2 Sekunden + random_number_milliseconds Sekunden.
  7. Anfrage wiederholen.
  8. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  9. Warten Sie 4 Sekunden + random_number_milliseconds Sekunden.
  10. Wiederholen Sie die Anfrage.
  11. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  12. Warte 8 Sekunden und random_number_milliseconds Sekunden.
  13. Wiederholen Sie die Anfrage.
  14. Sie erhalten eine Fehlerantwort mit einem wiederholbaren Fehlercode.
  15. Warten Sie 16 Sekunden + random_number_milliseconds Sekunden.
  16. Wiederholen Sie die Anfrage.
  17. Wenn Sie weiterhin einen Fehler erhalten, beenden Sie den Vorgang und protokollieren Sie ihn.

Im obigen Ablauf steht random_number_milliseconds für eine zufällige Anzahl von Millisekunden, deren Wert 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.

Der Algorithmus ist so eingerichtet, dass er endet, wenn n = 5. Diese Obergrenze verhindert, dass die Clients unendlich fortfahren, und führt zu einer Verzögerung von insgesamt 32 Sekunden, bevor eine Anfrage als „nicht zu behebender Fehler“ gilt.

Der folgende Python-Code ist eine Implementierung des vorherigen Ablaufs zur Behebung von Fehlern, die in der Methode 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."