Fehlerbehebung bei der Looker API

Auf dieser Seite finden Sie Anleitungen zur Fehlerbehebung für die folgenden Probleme, die bei der Verwendung der Looker API auftreten können:

API-Endpunkt ist nicht erreichbar

Wenn Sie einen API-Endpunkt nicht erreichen können:

API-Anmeldedaten überprüfen

Wenn Ihr Looker API-Endpunkt nicht erreichbar ist, prüfen Sie zuerst, ob Ihre API-Anmeldedaten korrekt sind. So rufen Sie Ihre API-Anmeldedaten auf:

  1. Greifen Sie in Looker auf den Admin-Bereich zu, indem Sie im linken Navigationsbereich die Option Admin auswählen.
  2. Scrollen Sie im linken Bereich der Seite Verwaltung nach unten und klicken Sie auf Nutzer.
  3. Suchen Sie in der Nutzerliste nach Ihrem Nutzernamen und klicken Sie darauf, um Ihre Nutzerseite zu bearbeiten.
  4. Klicken Sie auf API-Schlüssel bearbeiten. Sie sehen die Client-ID und können auf das Augensymbol klicken, um das Client-Secret für jeden konfigurierten API-Schlüssel aufzurufen. Prüfen Sie, ob Ihre API-Anmeldedaten mit den Anmeldedaten übereinstimmen, die Sie in Ihrem Skript verwenden.

API-URL prüfen

Ein weiteres häufiges Problem beim Erreichen eines API-Endpunkt ist eine falsche API-Host-URL. Die meisten Looker-Instanzen verwenden die Standard-URL für die API. Bei Looker-Installationen mit einem alternativen API-Pfad oder bei Looker-Installationen, die sich hinter einem Load-Balancer (z. B. einer Clusterkonfiguration) oder einem anderen Proxy befinden, wird die Standard-URL jedoch möglicherweise nicht verwendet. In diesem Fall muss die API-Host-URL den API-Hostnamen und ‑Port angeben, die für den Nutzer sichtbar sind.

Looker-Administratoren können die Host-URL der API in den API-Administratoreinstellungen sehen (diese werden auf der Dokumentationsseite Administratoreinstellungen – API genauer beschrieben). So rufen Sie die API-Host-URL auf:

  1. Klicken Sie auf das Hauptmenü  und wählen Sie Admin aus, um den Bereich Admin zu öffnen.
  2. Klicken Sie im Bereich Verwaltung auf API.

  3. API-Host-URL ansehen

    Wenn das Feld API-Host-URL leer ist, verwendet Ihre Looker-Instanz das Standardformat:

    https://<instance_name>.cloud.looker.com:<port>

So testen Sie die API-Host-URL:

  1. Öffnen Sie einen Browser und dann die Browserkonsole.

  2. Geben Sie Ihre API-Host-URL gefolgt von /alive ein. Wenn Ihre API-Host-URL beispielsweise https://company.cloud.looker.com lautet, geben Sie Folgendes ein:

    https://company.cloud.looker.com/alive

    Wenn das Feld API-Host-URL leer ist, verwenden Sie die Standard-API-URL. Für Instanzen, die in Google Cloud oder Microsoft Azure gehostet werden, und für Instanzen, die in Amazon Web Services (AWS) gehostet werden und am oder nach dem 07.07.2020 erstellt wurden, wird für den Looker API-Standardpfad beispielsweise der Port 443 verwendet:

    https://<instance_name>.cloud.looker.com:443/alive

    Für auf AWS gehostete Instanzen, die vor dem 07.07.2020 erstellt wurden, wird für den Standard-Looker API-Pfad Port 19999 verwendet:

    https://<instance_name>.cloud.looker.com:19999/alive

Wenn die API-Host-URL korrekt ist, führt diese URL zu einer leeren Webseite und nicht zu einer Fehlerseite.

Sie können auch in der Browserkonsole nachsehen, ob Sie die API erreicht haben. Die Netzwerkantwort sollte 200 lauten.

Wenn diese Prüfungen fehlschlagen, rufen Sie die API möglicherweise falsch auf oder es gibt andere Fehler in Ihrem Code. Überprüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese korrekt sind, lesen Sie den nächsten Abschnitt zum Überprüfen des Ports.

API-Port prüfen

Wenn die vorherigen Prüfungen fehlschlagen und Sie eine von Kunden gehostete Looker-Bereitstellung haben, muss der API-Port möglicherweise in der Netzwerkinfrastruktur geöffnet werden.

Der API-Port sollte an den Looker-Server weitergeleitet werden. Bitten Sie bei von Kunden gehosteten Looker-Bereitstellungen Ihren Netzwerkadministrator, die API-Porteinstellungen zu prüfen. Der API-Port ist am häufigsten 443 oder 19999. Der API-Port sollte dieselben Konfigurationseinstellungen wie der Looker-Instanzport (standardmäßig 9999) haben. Ihr Netzwerkadministrator sollte prüfen, ob die folgenden Einstellungen für den API-Port mit denen für den Port Ihrer Looker-Instanz übereinstimmen:

  • Proxys
  • Load-Balancer
  • Firewalls

URL des API-Aufrufs prüfen

Prüfen Sie, ob Sie die richtige URL für Ihren API-Aufruf verwenden. Das Format einer API-Endpunkt-URL ist:

<API Host URL>/api/<API version>/<API call>

Wenn Sie die Standard-API-Host-URL verwenden, hat die URL eines API-Endpunkt das folgende Format:

https://<instance_name>:<port>/api/<API version>/<API call>

Das URL-Format für API-Endpunkte finden Sie im API Explorer oder in der API-Referenzdokumentation.

In der API 4.0-Referenz wird beispielsweise der folgende relative Pfad für den Endpunkt „Get All Running Queries“ angegeben:

/api/4.0/running_queries

Die vollständige API-Endpunkt-URL für den Endpunkt „Get All Running Queries“ in der docsexamples.dev.looker.com-Looker-Instanz lautet also:

https://docsexamples.dev.looker.com:443/api/4.0/running_queries

Das API-Ergebnis ist unsinniger Text

Wenn die API eine Antwort mit verstümmeltem Text zurückgibt, sehen Sie wahrscheinlich den binären Inhalt einer PDF-, PNG- oder JPG-Datei. Bei einigen HTTP-REST-Bibliotheken wird davon ausgegangen, dass API-Antworten Textdateien sind. Daher werden andere Dateitypen als Binärtext angezeigt.

In diesem Fall müssen Sie darauf achten, dass Ihre HTTP-REST-Bibliothek die API-Antwort als Binärdaten und nicht als Text verarbeitet. In einigen Fällen kann dies bedeuten, dass Sie ein Flag für den API-Aufruf festlegen müssen, um der HTTP REST-Bibliothek mitzuteilen, dass es sich um ein binäres Ergebnis handelt. Möglicherweise müssen Sie das Ergebnis auch auf besondere Weise verarbeiten, z. B. als Byte-Stream oder als Byte-Array, anstatt es einer String-Variablen zuzuweisen.

API-Aufrufe werden nicht beantwortet

Wenn Sie den API Explorer öffnen können, Ihre API-Aufrufe jedoch nicht beantwortet werden, prüfen Sie, ob die Einstellung API-Host-URL Ihrer Looker-Instanz richtig festgelegt ist. Looker-Administratoren können die Host-URL der API in den API-Administratoreinstellungen von Looker sehen (siehe Dokumentationsseite Administratoreinstellungen – API).

Fehler aufgrund ungültiger Codierung

Wenn Sie beim Versuch, einen API-Aufruf zu starten, einen Codierungsfehler erhalten, müssen Sie möglicherweise die richtige Content-Type in Ihrem Header während der Anfrage festlegen. Gemäß den HTTP-Protokollstandards muss jede POST-, PUT- oder PATCH-Anfrage einen Content-Type-Header enthalten. Da in der Looker API durchgehend JSON verwendet wird, sollte der Content-Type-Header auf application/json festgelegt werden.

Wenn Sie ein Looker-SDK verwenden, wird dieses Problem automatisch behoben.

Fehler vom Typ „Methode nicht gefunden“

Wenn Sie einen „Method Not Found“-Fehler erhalten, z. B. method not found: all_looks(), sollten Sie zuerst Ihre API-Version überprüfen. Es gibt mehrere API-Aufrufe, die in API 4.0 neu sind oder in API 4.0 entfernt wurden. Eine Liste der Updates finden Sie in der Ankündigung zur allgemeinen Verfügbarkeit der Looker API 4.0.

Fehler vom Typ „Bad Request“ (400)

Ein 400 Bad Request-Fehler weist darauf hin, dass die in einem API-Aufruf bereitgestellten Daten nicht erkannt werden. Häufig ist fehlerhaftes oder ungültiges JSON die Ursache, z. B. ein Parsing-Fehler. In den meisten Fällen wurde die Authentifizierung bei 400‑Fehlern bereits bestanden. Die Fehlermeldung enthält daher genauere Informationen zum Fehler.

Fehler „Nicht autorisiert“ (401)

Ein 401 Unauthorized-Fehler bei einem API-Aufruf bedeutet, dass der API-Aufruf nicht richtig authentifiziert wurde. Weitere Informationen zur Fehlerbehebung finden Sie unter Wie behebe ich 401-Fehler? Community-Artikel.

Fehler „Forbidden (403)“

Die Looker API gibt nicht jedes Mal 403-Fehler zurück, wenn ein Nutzer versucht, auf ein LookML-Objekt oder andere Inhalte zuzugreifen, für die er keine Berechtigung hat. Wenn anstelle eines 404-Fehlers ein 403-Fehler zurückgegeben wird, kann in einigen Fällen die Existenz eines bestimmten Explores, Dashboards oder LookML-Objekts bestätigt werden, obwohl der Inhaber dies möglicherweise nicht möchte. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück. Die zugehörige Fehlermeldung in der Looker-Benutzeroberfläche lautet: „Die angeforderte Seite konnte nicht gefunden werden. Entweder ist er nicht vorhanden oder Sie sind nicht berechtigt, ihn anzusehen.“

Je nach Umgebung, in der Ihre Looker-Instanz gehostet wird, und Konfiguration Ihrer Looker-Instanz können sich die Portnummer und die zugehörige URL, über die auf die API zugegriffen werden kann, unterscheiden. Wenn Sie eine falsche Portnummer verwenden, wird möglicherweise ein 403-Fehler angezeigt. Wenn Ihre Looker-Instanz beispielsweise mit dem Standard-API-Port 443 konfiguriert ist, wird beim Herstellen einer Verbindung zu https://mycompany.looker.com/api/4.0/login anstelle von https://mycompany.looker.com:443/api/4.0/login ein 403-Fehler zurückgegeben. Weitere Informationen zu kundengehosteten Instanzen finden Sie unter Looker-Startoptionen. Dort können Sie den API-Port definieren.

Das kann auch passieren, wenn Sie eine veraltete Version des Ruby SDK-Gems verwenden. Achte darauf, dass du diese Gems immer auf dem neuesten Stand hältst. Sie können das unter https://rubygems.org/gems/looker-sdk prüfen.

Das kann auch passieren, wenn Sie den /api/<version number>/-Teil der URL nicht angeben. Wenn ein Nutzer in diesem Fall versucht, eine Verbindung zu https://mycompany.looker.com:443/login herzustellen, wird der Fehlercode 403 zurückgegeben.

Fehler „Nicht gefunden“ (404)

Der Fehler 404 Not Found ist der Standardfehler, wenn etwas schiefgeht, in der Regel bei Berechtigungen. Die Antwortnachricht für einen 404-Fehler enthält nur wenige oder gar keine Informationen. Das ist so gewollt, da 404-Fehler für Nutzer mit falschen Anmeldedaten oder unzureichenden Berechtigungen angezeigt werden. Looker möchte keine spezifischen Informationen in 404-Antwortnachrichten bereitstellen, da diese Informationen verwendet werden könnten, um die „Angriffsfläche“ der Looker API zu ermitteln.

Wenn bei API-Anmeldeversuchen 404-Fehler zurückgegeben werden, liegt das höchstwahrscheinlich daran, dass Ihre API-Client-ID oder Ihr Client-Secret ungültig ist (siehe API-Anmeldedaten überprüfen weiter oben auf dieser Seite). Der REST-Endpunkt für die API-Anmeldung lautet:

  • https://<your-looker-hostname>:<port>/api/4.0/login

Wenn Sie eine Swagger-Codegenerierungs-API oder ein Looker-SDK verwenden, prüfen Sie, ob der Wert für base_url korrekt ist:

  • Für einen Swagger-Codegen-Client sollte base_url so aussehen:

    • https://<your-looker-hostname>:<port>/api/4.0/

  • Bei Looker SDK-Implementierungen, die looker.ini verwenden, sollte der Wert von api_version 4.0 sein und der Wert von base_url sollte mit der URL Ihrer Looker-Instanz-API im Format https://<your-looker-hostname>:<port> übereinstimmen. Hier sehen Sie eine looker.ini-Beispieldatei:

    # api_version should be 4.0
api_version=4.0
base_url=https://<your-looker-hostname>:<port>

Es kann auch nach der Anmeldung ein 404-Fehler auftreten. Wenn Sie angemeldet sind und einen 404-Fehler erhalten, haben Sie keine Berechtigungen für den API-Befehl, den Sie gerade aufgerufen haben.

Fehler „Method Not Allowed“ (405)

Ein 405 Method Not Allowed-Fehler weist darauf hin, dass der Server die Anfragemethode kennt, die Zielressource diese Methode jedoch nicht unterstützt.

Der Server muss in einer Antwort mit dem Statuscode 405 ein Allow-Headerfeld generieren. Das Feld muss eine Liste der Methoden enthalten, die von der Zielressource unterstützt werden.

Ein Beispiel dafür, wie dieses Problem in Looker auftreten kann, ist, wenn Sie versuchen, den update_dashboard()-Endpunkt zu verwenden, um die Metadaten eines LookML-Dashboards zu aktualisieren. Das Ändern des Parameters id eines LookML-Dashboards wird über die Looker API nicht unterstützt. Daher würde ein 405-Fehler auftreten.

Fehler vom Typ „Conflict (409)“

Der Antwortstatuscode 409 Conflict gibt an, dass ein Konflikt zwischen einer Anfrage und dem aktuellen Status der Zielressource besteht.

Konflikte treten am häufigsten als Reaktion auf eine PUT-Anfrage auf. Ein häufiges Beispiel für diesen Fehler, das nicht mit Looker zusammenhängt, ist das Hochladen einer Datei, die älter als die vorhandene Datei auf dem Server ist. Dies führt zu einem Versionskontrollkonflikt.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, über die API einen neuen Git-Branch auszuchecken, oder wenn Sie Endpunkte wie create_group() oder create_dashboard() verwenden. Prüfen Sie in diesen Fällen, ob das Objekt, das Sie erstellen möchten, bereits vorhanden ist.

Validierungsfehler (422)

Validierungsfehler treten auf, wenn bei den durchgeführten Datenprüfungen etwas in der Anfrage fehlgeschlagen ist. Die Anfrage enthält einen oder mehrere der folgenden Fehlertypen (die genauen Fehler werden in der Fehlerantwort angegeben):

  • Fehlende Felder: Ein erforderlicher Parameter wurde nicht angegeben. In der Fehlerantwort wird angegeben, welches Feld fehlt.
  • Ungültig: Der angegebene Wert stimmt nicht mit einem vorhandenen Wert überein oder hat nicht das richtige Format. Wenn Sie beispielsweise versuchen, einen Look zu erstellen, und die im API-Aufruf angegebene Abfrage-ID nicht mit einer vorhandenen Abfrage übereinstimmt, erhalten Sie einen Validierungsfehler.
  • Bereits vorhanden: Mit dem API-Aufruf wird versucht, ein Objekt mit einer ID oder einem Namen zu erstellen, die bzw. der bereits in Ihrer Looker-Instanz vorhanden ist. So müssen beispielsweise Namen von Datenbankverbindungen eindeutig sein. Wenn Sie versuchen, eine neue Datenbankverbindung mit dem Namen einer vorhandenen Verbindung zu erstellen, erhalten Sie einen Validierungsfehler mit dem Code already_exists.

In der Fehlermeldung finden Sie Details dazu, welche Felder möglicherweise fehlen oder erforderlich sind oder welche Felder ungültige Werte enthalten. In der Antwortnachricht werden alle Validierungsfehler gleichzeitig angegeben. Wenn Sie also fehlende und falsche Felder haben, werden in der Fehlerantwort alle Probleme mit Ihrem API-Aufruf aufgeführt.

Hier ist eine Beispielantwort:

{
  "message": "Validation Failed",
  "errors": [
    {
    "field": "dialect",
    "code": "missing_field",
    "message": "This field is required.",
    "documentation_url": "http://docs.looker.com/"
    },
    {
    "field": "db_timezone",
    "code": "invalid",
    "message": "Must specify a database timezone when user timezones are activated.",
    "documentation_url": "http://docs.looker.com/"
    }
  ],
    ...

In diesem Fall fehlte im API-Aufruf das erforderliche Feld dialect und im Feld db_timezone wurde ein ungültiger Wert angegeben.

Fehler „Too Many Requests (429)“

Der Antwortstatuscode 429 Too Many Requests gibt an, dass der Nutzer innerhalb eines bestimmten Zeitraums zu viele Anfragen gesendet hat („Ratenbegrenzung“). Weitere Informationen zu den Ratenbegrenzungsrichtlinien von Looker finden Sie im Looker-Community-Beitrag Is there a limit to the number of API requests you can send at one time?

Fehler „Internal Server Error (500)“

Der Antwortcode 500 Internal Server Error gibt an, dass auf dem Server eine unerwartete Bedingung aufgetreten ist, die ihn daran gehindert hat, die Anfrage zu erfüllen.

Diese Fehlerantwort ist eine allgemeine „Auffangantwort“. Normalerweise bedeutet das, dass der Server keinen spezifischeren 5xx-Fehlercode für die Antwort finden kann. Eine 500-Antwort von Looker ist unerwartet. Wenn dieser Fehler also immer wieder auftritt, wenn Sie mit Looker interagieren, empfehlen wir Ihnen, eine Supportanfrage zu stellen.