Fehlerbehebung bei der Looker API

Auf dieser Seite finden Sie Verfahren zur Fehlerbehebung bei den folgenden Problemen mit der Looker API:

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, prü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 Verwaltung auswählen.
  2. Scrollen Sie auf der Seite Verwaltung 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. Klicken Sie auf das Augensymbol, 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 Script 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 Looker-Installationen, die sich hinter einem Load Balancer (z. B. einer Clusterkonfiguration) oder einem anderen Proxy befinden, wird die Standard-URL möglicherweise nicht verwendet. In diesem Fall müssen in der API-Host-URL der für Nutzer sichtbare API-Hostname und der Port angegeben werden.

Looker-Administratoren können die API-Host-URL in den API-Administratoreinstellungen sehen. Weitere Informationen finden Sie auf der Dokumentationsseite Administratoreinstellungen – API. So rufen Sie die API-Host-URL auf:

  1. Wählen Sie im linken Navigationsbereich die Option Verwaltung aus, um den Bereich Verwaltung aufzurufen.
  2. Klicken Sie im Bereich Verwaltung auf API.

  3. Rufen Sie die API-Host-URL auf.

    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 die 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. Beispielsweise wird für Instanzen, die auf Google Cloud, Microsoft Azure und Amazon Web Services (AWS) gehostet und am oder nach dem 07.07.2020 erstellt wurden, der Port 443 für den Standardpfad der Looker API 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 Standardpfad der Looker API der Port 19999 verwendet:

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

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

Sie können auch in der Browserkonsole die Netzwerkantwort prüfen, um zu sehen, ob Sie die API erreicht haben. Die Netzwerkantwort sollte 200 sein.

Wenn diese Prüfungen fehlschlagen, liegt das Problem möglicherweise daran, dass Sie die API falsch aufrufen oder dass andere Fehler in Ihrem Code vorhanden sind. Prüfen Sie Ihre API-Aufrufe und den Code in Ihrem Script. Wenn das der Fall ist, lesen Sie den nächsten Abschnitt zur Überprüfung des Anschlusses.

API-Port prüfen

Wenn die vorherigen Prüfungen fehlschlagen und Sie eine vom 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 in der Regel 443 oder 19999. Der API-Port sollte dieselben Konfigurationseinstellungen wie der Port der Looker-Instanz haben (standardmäßig 9999). Ihr Netzwerkadministrator sollte prüfen, ob die folgenden Einstellungen für den API-Port mit den Einstellungen 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. Die URL eines API-Endpunkt hat folgendes Format:

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

Wenn Sie die Standard-API-Host-URL verwenden, hat eine API-Endpunkt-URL 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 Referenz zur Looker API 4.0 wird beispielsweise der folgende relative Pfad für den Endpunkt „Alle laufenden Abfragen abrufen“ angegeben:

/api/4.0/running_queries

Die vollständige API-Endpunkt-URL für den Endpunkt „Alle laufenden Abfragen abrufen“ in der Looker-Instanz docsexamples.dev.looker.com lautet daher:

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

Das API-Ergebnis ist unsinnig

Wenn die API eine Antwort mit unleserlichem Text zurückgibt, sehen Sie wahrscheinlich den Binärinhalt einer PDF-, PNG- oder JPG-Datei. Einige HTTP-REST-Bibliotheken gehen davon aus, dass API-Antworten Textdateien sind. Daher werden andere Dateitypen als Binärtext angezeigt.

In diesem Fall müssen Sie dafür sorgen, dass Ihre HTTP-REST-Bibliothek die API-Antwort als Binärdaten und nicht als Text verarbeitet. In einigen Fällen kann das bedeuten, dass ein Flag für den API-Aufruf festgelegt wird, um der HTTP REST-Bibliothek mitzuteilen, dass es sich um ein binäres Ergebnis handelt. Es kann auch bedeuten, dass das Ergebnis auf eine spezielle Weise verarbeitet wird, z. B. als Bytestream oder als Bytearray, anstatt es einer Stringvariablen zuzuweisen.

API-Aufrufe geben keine Antwort zurück

Wenn Sie den API Explorer öffnen können, Ihre API-Aufrufe aber nicht reagieren, prüfen Sie, ob die Einstellung API-Host-URL Ihrer Looker-Instanz richtig festgelegt ist. Looker-Administratoren finden die API-Host-URL in den API-Administratoreinstellungen von Looker. Eine Beschreibung finden Sie auf der Dokumentationsseite Administratoreinstellungen – API.

Fehler bei ungültiger Codierung

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

Wenn Sie ein Looker SDK verwenden, wird dieses Problem automatisch für Sie behoben.

Fehler vom Typ „Methode nicht gefunden“

Wenn Sie einen Fehler vom Typ „Methode nicht gefunden“ erhalten, z. B. method not found: all_looks(), sollten Sie zuerst Ihre API-Version prüfen. Es gibt mehrere API-Aufrufe, die in API 4.0 neu sind oder in API 4.0 entfernt wurden. Eine Liste der Änderungen finden Sie in der Ankündigung Looker API 4.0 allgemein verfügbar.

Fehler vom Typ „Bad Request“ (400)

Ein 400 Bad Request-Fehler gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkannt werden können. Häufig ist die Ursache eine fehlerhafte oder ungültige JSON-Datei, möglicherweise ein Parsefehler. Bei 400-Fehlern wurde in den meisten Fällen bereits die Authentifizierung bestanden. Die Fehlerantwort 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 ordnungsgemäß authentifiziert wurde. Weitere Informationen zur Fehlerbehebung finden Sie im Hilfeartikel Wie behebe ich 401-Fehler? Community-Artikel

Forbidden-Fehler (403)

Die Looker API gibt nicht jedes Mal einen 403-Fehler zurück, wenn ein Nutzer versucht, auf ein LookML-Objekt oder andere Inhalte zuzugreifen, für die er keine Berechtigung hat. Wenn ein 403-Fehler anstelle eines 404-Fehlers zurückgegeben wird, kann das in einigen Fällen bestätigen, dass ein bestimmtes Explore, Dashboard oder LookML-Objekt vorhanden ist, auch wenn der Inhaber dies nicht preisgeben möchte. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück. In der Looker-Benutzeroberfläche wird dann die folgende Fehlermeldung angezeigt: „Die von Ihnen 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 der 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 der Fehler 403 angezeigt. Wenn Ihre Looker-Instanz beispielsweise mit dem Standard-API-Port 443 konfiguriert ist, wird bei 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. Bei von Kunden gehosteten Instanzen können Sie die Looker-Startoptionen verwenden, um den API-Port zu definieren.

Das kann auch passieren, wenn Sie eine veraltete Version der Ruby SDK-Gem verwenden. Achten Sie darauf, diese Assets auf dem neuesten Stand zu halten. Sie können das unter https://rubygems.org/gems/looker-sdk prüfen.

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

Fehler 404 (nicht gefunden)

Ein 404 Not Found-Fehler ist der Standardfehler, wenn etwas schiefgeht, in der Regel bei Berechtigungen. Die Antwortnachricht für einen 404-Fehler enthält nur wenige Informationen, wenn überhaupt. Das ist beabsichtigt, da 404-Fehler Nutzern mit falschen Anmeldedaten oder unzureichenden Berechtigungen angezeigt werden. Looker möchte keine bestimmten Informationen in 404-Antwortnachrichten angeben, da diese Informationen dazu verwendet werden könnten, die „Angriffsfläche“ der Looker API zu kartieren.

Wenn bei API-Anmeldeversuchen 404-Fehler zurückgegeben werden, ist Ihre API-Client-ID oder Ihr API-Client-Secret höchstwahrscheinlich ungültig. Weitere Informationen finden Sie oben auf dieser Seite unter API-Anmeldedaten bestätigen. Der REST-Endpunkt für die API-Anmeldung lautet:

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

Wenn Sie eine Swagger codegen API oder ein Looker SDK verwenden, muss der Wert für base_url korrekt sein:

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

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

  • Bei Looker SDK-Implementierungen, die eine 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 sein, dass nach der Anmeldung ein 404-Fehler auftritt. Wenn Sie angemeldet sind und einen 404-Fehler erhalten, haben Sie keine Berechtigungen für den gerade aufgerufenen API-Befehl.

Fehler „Method Not Allowed“ (405)

Ein 405 Method Not Allowed-Fehler gibt an, 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-Header-Feld generieren. Das Feld muss eine Liste der Methoden enthalten, die von der Zielressource unterstützt werden.

Ein Beispiel für dieses Problem in Looker wäre, wenn Sie versuchen, mit dem Endpunkt update_dashboard() die Metadaten eines LookML-Dashboards zu aktualisieren. Das Ändern des Parameters id eines LookML-Dashboards wird über die Looker API nicht unterstützt. Daher tritt der Fehler 405 auf.

Fehler vom Typ „Conflict“ (409)

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

Konflikte treten am häufigsten als Reaktion auf eine PUT-Anfrage auf. Ein häufiges Beispiel für diesen Fehler außerhalb von Looker ist der Upload einer Datei, die älter als die vorhandene Datei auf dem Server ist. Dies führt zu einem Konflikt bei der Versionskontrolle.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, einen neuen Git-Branch mit der API zu klonen, 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 einer Anfrage die durchgeführten Datenprüfungen fehlgeschlagen sind. Die Anfrage enthält mindestens einen 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 ist nicht im richtigen Format. Wenn Sie beispielsweise versuchen, einen Look zu erstellen, die im API-Aufruf angegebene Abfrage-ID aber nicht mit einer vorhandenen Abfrage übereinstimmt, erhalten Sie einen Validierungsfehler.
  • „Already exists“ (Bereits vorhanden): Beim API-Aufruf wird versucht, ein Objekt mit einer ID oder einem Namen zu erstellen, das bzw. der bereits in Ihrer Looker-Instanz vorhanden ist. So müssen beispielsweise Datenbankverbindungsnamen 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 Fehlerantwort finden Sie Details dazu, welche Felder möglicherweise fehlten oder erforderlich waren oder welche Felder ungültige Werte enthalten. Die Antwort enthält alle Validierungsfehler gleichzeitig. Wenn also Felder fehlen oder falsch sind, werden in der Fehlerantwort alle Probleme mit Ihrem API-Aufruf aufgeführt.

Hier ist ein Beispiel:

{
  "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 es wurde im Feld 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 („Geschwindigkeitsbegrenzung“). Weitere Informationen zu den Richtlinien für die Begrenzung der Rate von Looker finden Sie im Looker-Communitybeitrag Ist die Anzahl der API-Anfragen, die gleichzeitig gesendet werden können, begrenzt?

Fehler vom Typ „Interner Serverfehler“ (500)

Der Antwortcode 500 Internal Server Error gibt an, dass der Server auf eine unerwartete Bedingung gestoßen ist, die die Ausführung der Anfrage verhindert hat.

Diese Fehlerantwort ist eine allgemeine „Allgemein-Antwort“. Normalerweise bedeutet das, dass der Server keinen spezifischeren 5xx-Fehlercode finden kann, der als Antwort zurückgegeben werden kann. Eine 500-Antwort von Looker ist unerwartet. Wenn dieser Fehler bei der Interaktion mit Looker immer wieder auftritt, empfehlen wir Ihnen, eine Supportanfrage zu stellen.