Fehlerbehebung für die Looker API

Auf dieser Seite finden Sie Verfahren zur Fehlerbehebung für die folgenden Probleme, die möglicherweise mit der Looker-API auftreten:

API-Endpunkt ist 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 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 auf das Augensymbol, um den Clientschlüssel für jeden von Ihnen konfigurierten API-Schlüssel zu sehen. Überprüfen Sie, ob Ihre API-Anmeldedaten mit den im Skript verwendeten Anmeldedaten übereinstimmen.

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 muss die API-Host-URL den für den Nutzer sichtbaren Hostnamen und Port angeben.

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. Rufen Sie den Admin-Bereich 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 Ihre Looker-Instanz das Standardformat, also:

    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. Bei Instanzen, die in Google Cloud, Microsoft Azure und auf Amazon Web Services (AWS) gehostet werden und die am oder nach dem 07.07.2020 erstellt wurden, wird für den standardmäßigen Looker API-Pfad beispielsweise Port 443 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, kann das Problem daran liegen, dass Sie die API falsch aufrufen oder andere Fehler in Ihrem Code vorliegen. Überprüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese Angaben korrekt sind, lesen Sie den nächsten Abschnitt zum Bestätigen der Rufnummernmitnahme.

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 sollte die gleichen Konfigurationseinstellungen haben wie der Port der Looker-Instanz (standardmäßig 9999). 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

API-Aufruf-URL prüfen

Prüfen Sie, ob Sie die richtige URL für Ihren API-Aufruf verwenden. API-Endpunkt-URLs haben folgendes Format:

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

Wenn Sie die standardmäßige API-Host-URL verwenden, lautet das Format einer API-Endpunkt-URL:

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, wird wahrscheinlich der binäre Inhalt einer PDF-, PNG- oder JPG-Datei angezeigt. Einige HTTP-REST-Bibliotheken gehen davon aus, dass es sich bei API-Antworten um Textdateien handelt. 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äre Daten und nicht als Text verarbeitet. In einigen Fällen kann dies bedeuten, dass für den API-Aufruf ein Flag gesetzt wird, um der HTTP REST-Bibliothek mitzuteilen, dass es sich um ein binäres Ergebnis handelt. Es kann aber auch bedeuten, dass das Ergebnis auf eine bestimmte Weise verarbeitet wird, z. B. als Bytestream oder als Array von Byte, anstatt es einer Stringvariablen zuzuweisen.

API-Aufrufe reagieren nicht

Wenn Sie den API Explorer öffnen können, aber die API-Aufrufe nicht reagieren, prüfen Sie, ob die Einstellung für die 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.

Ungültige Codierungsfehler

Wenn Sie beim Versuch, einen API-Aufruf auszuführen, einen Codierungsfehler erhalten, müssen Sie bei der Anfrage möglicherweise die richtige Content-Type im Header angeben. Die HTTP-Protokollstandards erfordern, dass jede POST-, PUT- oder PATCH-Anfrage 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 des Typs "Methode nicht gefunden"

Wenn ein Fehler wie method not found: all_looks() angezeigt wird, 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 Anfrage (400)

Der Fehler 400 Bad Request gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkennbar sind. Die Ursache ist häufig ein fehlerhaftes oder ungültiges JSON, möglicherweise ein Parsing-Fehler. Die meisten Fehler des Typs 400 haben die Authentifizierung bereits bestanden. 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 unter Wie behebe ich 401-Fehler? Community-Artikel

Fehler „Verbotene“ (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. Durch die Rückgabe eines 403-Fehlers anstelle eines 404-Fehlers kann in einigen Fällen die Existenz eines bestimmten Explore-, Dashboard- oder LookML-Objekts verifiziert werden, wenn der Eigentümer es vorzieht, dass dies nicht bekannt ist. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück und der entsprechende Fehler in der Looker-Benutzeroberfläche lautet: „Die von Ihnen angeforderte Seite konnte nicht gefunden werden. Entweder existiert er nicht 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 beim Herstellen einer Verbindung zu https://mycompany.looker.com/api/4.0/login statt mit https://mycompany.looker.com:443/api/4.0/login der Fehler 403 zurückgegeben. Bei von Kunden gehosteten Instanzen können Sie unter Looker-Startoptionen den API-Port definieren.

Das kann auch passieren, wenn Sie eine veraltete Version des Ruby SDK-Gem verwenden. Achte darauf, dass diese Edelsteine immer auf dem neuesten Stand sind. Sie können unter https://rubygems.org/gems/looker-sdk nachsehen.

Das kann auch passieren, wenn du den /api/<version number>/-Teil der URL nicht einfügst. 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 etwas schiefgeht, normalerweise im Zusammenhang mit Berechtigungen. Die Antwortnachricht für einen 404-Fehler enthält minimale Informationen, sofern vorhanden. Das ist beabsichtigt, da Personen mit falschen Anmeldedaten oder unzureichenden Berechtigungen 404-Fehler angezeigt werden. Looker möchte keine spezifischen Informationen in 404-Antwortnachrichten angeben, da diese Informationen verwendet werden könnten, um die „Angriffsfläche“ der Looker-API abzubilden.

Wenn API-Anmeldeversuche 404-Fehler zurückgeben, liegt das wahrscheinlich daran, dass Ihre API-Client-ID oder der Clientschlüssel ungültig ist. Weitere Informationen erhalten Sie weiter oben auf dieser Seite unter API-Anmeldedaten überprüfen. Der REST-Endpunkt der API-Anmeldung ist:

  • 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 eine looker.ini-Beispieldatei:

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

Sie können einen 404-Fehler auch nach der Anmeldung erhalten. Wenn Sie angemeldet sind und der Fehler 404 angezeigt wird, haben Sie keine Berechtigungen für den gerade aufgerufenen API-Befehl.

Fehler 405: Methode nicht zulässig

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

Der Server muss ein Allow-Headerfeld in einer 405-Statuscode-Antwort generieren. Das Feld muss eine Liste von 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 id-Parameters eines LookML-Dashboards wird über die Looker API nicht unterstützt, sodass ein 405-Fehler auftreten würde.

Konfliktfehler (409)

Der Antwortstatuscode 409 Conflict zeigt 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-Zweig mithilfe der API 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 ein Teil der Anfrage die durchgeführten Datenprüfungen nicht bestanden hat. 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 Fehlermeldung wird angegeben, welches Feld fehlt.
  • Ungültig: Der angegebene Wert stimmt mit keinem vorhandenen Wert überein oder der Wert hat ein falsches 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 Fehlermeldung finden Sie Informationen dazu, welche Felder möglicherweise fehlen oder erforderlich sind oder welche Felder ungültige Werte enthalten. Die Antwortnachricht enthält alle Validierungsfehler zur selben Zeit. Wenn also Felder fehlen und auch falsche Felder vorhanden sind, werden in der Fehlerantwort alle Probleme mit dem API-Aufruf aufgelistet.

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 beim API-Aufruf das Pflichtfeld dialect und der Wert für db_timezone wurde ungültig.

Fehler 429 (zu viele Anfragen)

Der Antwortstatuscode 429 Too Many Requests gibt an, dass der Nutzer zu viele Anfragen innerhalb eines bestimmten Zeitraums gesendet hat („Ratenbegrenzung“). Weitere Informationen zu den Richtlinien zur Ratenbegrenzung von Looker finden Sie im Looker-Communitybeitrag: Ist die Anzahl der API-Anfragen, die Sie gleichzeitig senden können, begrenzt?

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.

Bei dieser Fehlerantwort handelt es sich um eine allgemeine „catch-all“-Antwort. Normalerweise bedeutet dies, dass der Server keinen spezifischeren 5xx-Fehlercode für die Antwort finden kann. Jede 500-Antwort von Looker ist unerwartet. Wenn dieser Fehler immer wieder auftritt, wenn Sie versuchen, mit Looker zu interagieren, empfehlen wir Ihnen, eine Supportanfrage zu stellen.