Fehlerbehebung für die 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 Admin auf, indem Sie im linken Navigationsbereich die Option Admin 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 und auf das Augensymbol, um den Clientschlüssel für jeden von Ihnen konfigurierten API-Schlüssel zu sehen. Prüfen Sie, ob Ihre API-Anmeldedaten mit den Anmeldedaten übereinstimmen, die Sie in Ihrem Script verwenden.

API-URL überprü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 hinter einem Load-Balancer (z. B. einer Clusterkonfiguration) oder einem anderen Proxy wird die Standard-URL jedoch 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. Diese werden auf der Dokumentationsseite Administratoreinstellungen – API genauer beschrieben. 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 anschließend die Browserkonsole.

  2. Geben Sie die API-Host-URL gefolgt von /alive ein. Lautet die API-Host-URL beispielsweise https://company.cloud.looker.com, 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

    Bei auf AWS gehosteten Instanzen, die vor dem 07.07.2020 erstellt wurden, verwendet der Looker-Standard-API-Pfad Port 19999:

    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 überprüfen, ob Sie die API erreicht haben, indem Sie sich die Netzwerkantwort in der Browserkonsole ansehen. Die Netzwerkantwort sollte 200 sein.

Wenn diese Prüfungen fehlschlagen, liegt das Problem möglicherweise daran, dass Sie die API falsch aufrufen oder 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 weiterleiten. Bitten Sie bei von Kunden gehosteten Looker-Bereitstellungen Ihren Netzwerkadministrator, die API-Porteinstellungen zu überprüfen. Der API-Port ist in der Regel 443 oder 19999. Der API-Port muss die gleichen Konfigurationseinstellungen haben wie der Port der Looker-Instanz (standardmäßig 9999). Ihr Netzwerkadministrator sollte überprü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. Die URL eines API-Endpunkts 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-Referenz.

Die API 4.0-Referenz gibt beispielsweise den folgenden relativen Pfad für den Endpunkt zum Abrufen aller ausgeführten Abfragen an:

/api/4.0/running_queries

Daher sieht die vollständige API-Endpunkt-URL für den Endpunkt zum Abrufen aller ausgeführten Abfragen auf der Looker-Instanz docsexamples.dev.looker.com so aus:

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

API-Ergebnis ist unsinniger Text

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. Andere Dateitypen werden daher 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 reagieren nicht

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 können die API-Host-URL in den API-Administratoreinstellungen von Looker sehen. Diese wird auf der Dokumentationsseite Administratoreinstellungen – API beschrieben.

Fehler bei ungültiger Codierung

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

Wenn Sie ein Looker SDK verwenden, wird dies automatisch für Sie erledigt.

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 Aktualisierungen finden Sie in der Ankündigung unter Allgemeine Verfügbarkeit der Looker API 4.0.

Fehler wegen ungültiger Anfragen (400)

Der Fehler 400 Bad Request gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkennbar sind. Die Ursache ist oft ein fehlerhaftes oder ungültiges JSON, möglicherweise ein Parsing-Fehler. In den meisten Fällen wurde die Authentifizierung nach 400-Fehlern bereits erfolgreich durchgeführt. Die Fehlermeldung enthält daher genauere Informationen zum Fehler.

Nicht autorisierte 401-Fehler

Der Fehler 401 Unauthorized bei einem API-Aufruf bedeutet, dass der API-Aufruf nicht ordnungsgemäß authentifiziert ist. 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 den Fehler 403 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 der Umgebung, in der Ihre Looker-Instanz gehostet wird, und der Konfiguration Ihrer Looker-Instanz können die Portnummer und die zugehörige URL, auf die auf die API zugegriffen werden kann, unterschiedlich sein. 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 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 des Ruby SDK-Gem verwenden. Achten Sie darauf, diese Assets auf dem neuesten Stand zu halten. Sie können unter https://rubygems.org/gems/looker-sdk nachsehen.

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

Fehler 404 (Nicht gefunden)

Ein 404 Not Found-Fehler ist der Standardfehler, wenn ein Fehler auftritt – in der Regel im Zusammenhang mit Berechtigungen. Die Antwortmeldung 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 base_url-Wert 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 looker.ini verwenden, sollte der Wert von api_version 4.0 und der Wert von base_url 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 405: "Method Not Allowed" (Methode nicht zulässig)

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 ein Allow-Headerfeld in einer 405-Statuscode-Antwort generieren. Das Feld muss eine Liste der Methoden enthalten, die von der Zielressource unterstützt werden.

In Looker kann das beispielsweise der Fall sein, wenn Sie versuchen, die Metadaten eines LookML-Dashboards mit dem Endpunkt update_dashboard() 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 tritt auf, wenn eine Datei hochgeladen wird, die älter als die vorhandene Datei auf dem Server ist, was zu einem Konflikt bei der Versionsverwaltung führt.

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 Datenprüfungen fehlgeschlagen sind. Die Anfrage weist einen oder mehrere der folgenden Fehlertypen auf (die Fehlerantwort gibt die genauen Fehler an):

  • 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, und die Abfrage-ID, die Sie im API-Aufruf angeben, 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. Beispielsweise müssen Namen von Datenbankverbindungen eindeutig sein. Wenn Sie versuchen, eine neue Datenbankverbindung mit dem Namen einer bestehenden 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 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 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 500 Internal Server Error-Antwortcode gibt an, dass auf dem Server eine unerwartete Bedingung aufgetreten ist, die die Ausführung der Anfrage verhindert hat.

Diese Fehlerantwort ist eine allgemeine „Allgemein-Antwort“. Normalerweise bedeutet dies, dass der Server keinen spezifischeren 5xx-Fehlercode für die Antwort finden 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.