Fehlerbehebung für die Looker API

Diese Seite enthält Verfahren zur Fehlerbehebung für die folgenden Probleme, die bei der Looker API auftreten können:

API-Endpunkt nicht erreichbar

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

API-Anmeldedaten überprüfen

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

  1. Rufen Sie in Looker den Bereich Verwaltung auf, indem Sie im linken Navigationsbereich die Option Admin auswählen.
  2. Scrollen Sie auf der Seite Admin im linken Bereich 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 den Clientschlüssel für jeden konfigurierten API-Schlüssel aufzurufen. Prüfen Sie, ob Ihre API-Anmeldedaten mit denen in Ihrem Skript übereinstimmen.

API-URL prüfen

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

Looker-Administratoren können die API-Host-URL in den API-Administratoreinstellungen sehen. Dies wird auf der Dokumentationsseite Admin-Einstellungen – API ausführlicher beschrieben. So rufen Sie die API-Host-URL auf:

  1. Rufen Sie das Admin-Steuerfeld auf, indem Sie im linken Navigationsbereich die Option Verwaltung auswählen.
  2. Klicken Sie im Bereich Admin auf API.

  3. Sehen Sie sich die API-Host-URL an.

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

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

So testen Sie die API-Host-URL:

  1. Öffnen Sie einen Browser und die Browserkonsole. In diesem Artikel von ConcreteCMS.org erfahren Sie, wie Sie eine Konsole für Ihren Browser öffnen.

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

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

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

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

    Für in AWS gehostete Instanzen, die vor dem 7. Juli 2020 erstellt wurden, verwendet der Standardpfad der Looker API Port 19999:

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

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

Anhand der Netzwerkantwort in der Browserkonsole können Sie auch prüfen, ob Sie die API erreicht haben. Die Netzwerkantwort sollte 200 lauten:

Wenn diese Prüfungen fehlschlagen, kann das daran liegen, dass Sie die API nicht korrekt aufrufen oder dass Ihr Code andere Fehler enthält. Prüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese korrekt sind, lesen Sie im nächsten Abschnitt, wie Sie Ihre Rufnummernmitnahme bestätigen.

API-Port prüfen

Wenn die oben genannten Prüfungen fehlschlagen und eine vom Kunden gehostete Looker-Bereitstellung vorhanden ist, muss der API-Port möglicherweise in der Netzwerkinfrastruktur geöffnet werden.

Der API-Port muss an den Looker-Server weitergeleitet werden. Bei vom Kunden gehosteten Looker-Bereitstellungen sollten Sie Ihren Netzwerkadministrator bitten, die Einstellungen für den API-Port zu prüfen. Der API-Port ist meistens 443 oder 19999. Der API-Port sollte dieselben Konfigurationseinstellungen wie der Looker-Instanzport haben (standardmäßig 9999). Ihr Netzwerkadministrator sollte prüfen, ob die folgenden Einstellungen für den API-Port und für den Looker-Instanzport identisch sind:

  • Proxys
  • Load-Balancer
  • Firewalls

URL des API-Aufrufs überprü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 das Format einer API-Endpunkt-URL folgendes Format:

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

Sie können das URL-Format für API-Endpunkte im API Explorer, im Entwicklerportal von Looker oder in der API-Referenzdokumentation abrufen.

Die API 4.0-Referenz enthält beispielsweise den folgenden relativen Pfad für den Endpunkt "Alle ausgeführten Abfragen abrufen":

Die vollständige API-Endpunkt-URL für die Looker-Instanz docsexamples.dev.looker.com sieht so aus:

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

API-Ergebnis ist unsinnig

Wenn die API eine Antwort mit verstümmeltem Text zurückgibt, ist es wahrscheinlich, dass Sie den binären Inhalt einer PDF-, PNG- oder JPG-Datei sehen. Bei einigen HTTP-REST-Bibliotheken wird davon ausgegangen, dass es sich bei API-Antworten um Textdateien handelt, während andere Dateitypen als binärer Text erscheinen.

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 das bedeuten, dass dem API-Aufruf ein Flag gesetzt wird, um die HTTP-REST-Bibliothek darüber zu informieren, dass es sich um ein binäres Ergebnis handelt. Es kann auch sein, dass das Ergebnis auf besondere Weise verarbeitet wird, z. B. als Stream von Byte oder als Byte-Array, anstatt das Ergebnis einer Stringvariable zuzuweisen.

API-Aufrufe reagieren nicht

Wenn Sie API Explorer öffnen können, aber Ihre API-Aufrufe nicht reagieren, prüfen Sie, ob die Einstellung API-Host-URL für die Looker-Instanz richtig eingestellt ist. Looker-Administratoren können die URL des API-Hosts in den API-Administratoreinstellungen von Looker sehen. Diese wird auf der Dokumentationsseite Admin-Einstellungen – API beschrieben.

Ungültige Codierungsfehler

Wenn Sie bei einem API-Aufruf einen Codierungsfehler erhalten, müssen Sie bei der Anfrage möglicherweise die richtige Content-Type im Header angeben. Gemäß den HTTP-Protokollstandards müssen alle POST-, PUT- oder PATCH-Anfragen den Header Content-Type enthalten. Da die Looker API durchgehend JSON verwendet, sollte der Content-Type-Header auf application/json festgelegt werden.

Dieses Problem wird automatisch von einem Looker SDK behoben.

Fehler „Methode nicht gefunden“

Wenn Sie einen Fehler vom Typ „Methode nicht gefunden“ erhalten, z. B. method not found: all_looks(), prüfen Sie zuerst Ihre API-Version. 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 Mitteilung Looker API 4.0 General Availability.

Fehler 400 (Ungültige Anfrage)

Der Fehler 400 Bad Request gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkennbar sind. Der Grund ist häufig fehlerhaft oder ungültig, möglicherweise ein Parsing-Fehler. In den meisten Fällen sind 400-Fehler bereits vor der Authentifizierung aufgetreten. Die Fehlermeldung enthält daher genauere Informationen zum Fehler.

Verbotene (403)-Fehler

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. Die Rückgabe eines 403-Fehlers statt eines 404-Fehlers könnte in einigen Fällen die Existenz eines bestimmten Explore-, Dashboard- oder LookML-Objekts bestätigen, wenn der Inhaber dies lieber weiß. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück und der zugehörige Fehler in der Looker-UI lautet: "Die angeforderte Seite wurde nicht gefunden. Entweder existiert sie nicht oder Sie sind nicht berechtigt, sie anzusehen.

Abhängig von der Umgebung, in der Ihre Looker-Instanz gehostet wird, und der Konfiguration Ihrer Looker-Instanz können sich die Portnummer und die zugehörige URL unterscheiden, auf die auf die API zugegriffen werden kann. Wenn Sie eine falsche Portnummer verwenden, wird möglicherweise ein 403-Fehler angezeigt. Wenn beispielsweise die Looker-Instanz mit dem Standard-API-Port 443 konfiguriert ist und beim Herstellen einer Verbindung zu https://mycompany.looker.com/api/4.0/login statt https://mycompany.looker.com:443/api/4.0/login ein 403-Fehler zurückgegeben wird. Für von Kunden gehostete Instanzen finden Sie unter Looker-Startoptionen weitere Informationen zum Definieren des API-Ports.

Das kann auch passieren, wenn Sie eine veraltete Version des Ruby SDK verwenden. Halten Sie diese Edelsteine immer auf dem neuesten Stand. Du kannst hier nachsehen: https://rubygems.org/gems/looker-sdk.

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

Fehler 404 (nicht gefunden)

Der Fehler 404 Not Found ist der Standardfehler, wenn etwas schiefgeht, normalerweise mit Berechtigungen wie Berechtigungen. Die Antwort auf einen 404-Fehler enthält mindestens Informationen. Das ist beabsichtigt, weil Nutzern mit falschen Anmeldedaten oder unzureichenden Berechtigungen 404-Fehler angezeigt werden. Looker möchte keine spezifischen Informationen in 404-Antwortnachrichten zur Verfügung stellen, da diese verwendet werden könnten, um die Angriffsfläche der Looker API abzubilden.

Wenn bei API-Anmeldeversuchen 404-Fehler zurückgegeben werden, ist dies wahrscheinlich darauf zurückzuführen, dass Ihre API3-Client-ID oder Ihr Clientschlüssel nicht gültig ist. Weitere Informationen finden Sie oben auf dieser Seite unter API-Anmeldedaten bestätigen. Der API-Anmelde-REST-Endpunkt ist einer der folgenden, abhängig von der verwendeten API-Version:

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

Wenn Sie eine Swagger Codegen 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 je nach verwendeter API-Version einer der folgenden Werte sein:
    • https://<your-looker-hostname>:<port>/api/4.0/
    • https://<your-looker-hostname>:<port>/api/3.1/

  • Für Looker SDK-Implementierungen, die looker.ini verwenden, sollte der Wert von api_version entweder 4.0 oder 3.1 sein und der Wert von base_url muss mit der URL Ihrer Looker-Instanz-API im Format https://<your-looker-hostname>:<port> übereinstimmen. Hier ein Beispiel für eine looker.ini-Datei:

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

Außerdem kann nach der Anmeldung ein 404-Fehler angezeigt werden. Wenn Sie angemeldet sind und ein 404-Fehler angezeigt wird, sind Sie nicht berechtigt, den API-Befehl aufzurufen.

Fehler des Typs „Methode nicht zulässig“ (405)

Der Fehler 405 Method Not Allowed gibt an, dass der Server die Anfragemethode kennt, die Zielressource diese Methode jedoch nicht unterstützt.

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

Das kann zum Beispiel der Fall sein, wenn Sie versuchen würden, den Endpunkt update_dashboard() 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, sodass ein 405-Fehler auftritt.

Konflikt (409)

Der Antwortstatuscode 409 Conflict gibt einen Anfragekonflikt mit dem aktuellen Status der Zielressource an.

Konflikte treten am häufigsten als Antwort auf eine PUT-Anfrage auf. Ein häufiges Nicht-Looker-Fehler dieser Fehlermeldung tritt auf, wenn eine Datei hochgeladen wird, die älter als die vorhandene Datei auf dem Server ist. Dies führt zu einem Konflikt bei der Versionsverwaltung.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, einen neuen Git-Zweig mit der API oder mit Endpunkten wie create_group() oder create_dashboard() zu testen. Prüfen Sie in diesen Fällen, ob das Objekt, das Sie erstellen möchten, bereits vorhanden ist.

Validierungsfehler (422)

Validierungsfehler treten auf, wenn etwas in der Anfrage die Datenprüfungen nicht bestanden hat. Die Anfrage enthält mindestens einen der folgenden Fehlertypen (die Fehlerantwort gibt die genauen Fehler an):

  • Fehlende Felder: Ein erforderlicher Parameter wurde nicht angegeben. Die Fehlermeldung gibt an, welches Feld fehlt.
  • Ungültig: Der angegebene Wert stimmt nicht mit einem vorhandenen Wert überein oder er hat nicht das richtige Format. Wenn Sie beispielsweise versuchen, einen Look zu erstellen, und die Abfrage-ID im API-Aufruf nicht mit einer vorhandenen Abfrage übereinstimmt, erhalten Sie einen Validierungsfehler.
  • Bereits vorhanden: Der API-Aufruf versucht, ein Objekt mit einer ID oder einem Namen zu erstellen, die bereits in Ihrer Looker-Instanz vorhanden sind. Beispielsweise müssen Datenbankverbindungsnamen eindeutig sein. Wenn Sie versuchen, eine neue Datenbankverbindung zu erstellen, die den Namen einer vorhandenen Verbindung verwendet, erhalten Sie einen Validierungsfehler mit dem Code already_exists.

In der Fehlermeldung erfahren Sie, welche Felder fehlen oder erforderlich sind bzw. welche Felder ungültige Werte enthalten. Die Antwortnachricht enthält alle Validierungsfehler gleichzeitig. Wenn also Felder fehlen und die Felder falsch sind, werden in der Fehlerantwort alle Probleme mit Ihrem API-Aufruf aufgelistet.

Hier 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 beim API-Aufruf das erforderliche dialect-Feld und außerdem wurde im db_timezone ein ungültiger Wert angegeben.

Fehler „Zu viele Anfragen“ (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 Artikel Gibt es eine Beschränkung für die Anzahl der API-Anfragen, die Sie gleichzeitig senden können?

Interner Serverfehler (500)

Der Antwortcode 500 Internal Server Error gibt an, dass auf dem Server ein unerwarteter Fehler aufgetreten ist, der die Ausführung der Anfrage verhindert hat.

Diese Fehlerantwort ist eine allgemeine Catchall-Antwort. Dies deutet in der Regel darauf hin, dass der Server keinen spezifischeren 5xx-Fehlercode findet, der als Antwort zurückgegeben werden kann. Jede 500-Antwort von Looker ist unerwartet. Wenn Ihnen dieser Fehler bei der Interaktion mit Looker immer wieder angezeigt wird, empfehlen wir Ihnen, sich an den Looker-Support zu wenden.