Fehlerbehebung für die Looker API

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

API-Endpunkt ist nicht erreichbar

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

API-Anmeldedaten prüfen

Wenn Ihr 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 Admin auf, indem Sie im linken Navigationsbereich die Option Administrator 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 klicken auf das Augensymbol, um den Client Secret (Clientschlüssel) für jeden von Ihnen konfigurierten API-Schlüssel aufzurufen. Überprüfen Sie, ob die 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, die einen alternativen API-Pfad oder Looker-Installationen hinter einem Load-Balancer (z. B. einer Clusterkonfiguration) oder einem anderen Proxy verwenden, wird jedoch möglicherweise nicht die Standard-URL verwendet. In diesem Fall muss die API-Host-URL den API-Hostnamen und den Port für den Nutzer angeben.

Looker-Administratoren können die API-Host-URL in den API-Administratoreinstellungen einsehen. Eine ausführliche Beschreibung dazu finden Sie auf der Dokumentationsseite Administratoreinstellungen – API. So rufen Sie die API-Host-URL auf:

  1. Rufen Sie den Verwaltungsbereich auf, indem Sie im linken Navigationsbereich die Option Verwaltung auswählen.
  2. Klicken Sie im Admin-Bereich 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:

    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 die 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 auf Amazon Web Services (AWS) gehostet werden und am oder nach dem 07.07.2020 erstellt wurden, verwendet der Looker API-Standardpfad beispielsweise Port 443:

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

    Für auf AWS gehostete Instanzen, die vor dem 07.07.2020 erstellt wurden, verwendet der Looker API-Standardpfad 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 anhand der Netzwerkantwort in der Browserkonsole 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. Überprüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese Angaben korrekt sind, 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.

Über den API-Port sollte eine Weiterleitung an den Looker-Server erfolgen. Bitten Sie bei kundenseitig gehosteten Looker-Bereitstellungen Ihren Netzwerkadministrator, die Einstellungen für den API-Port zu prüfen. Der API-Port ist in der Regel 443 oder 19999. Der API-Port sollte dieselben 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 und den Port Ihrer Looker-Instanz identisch sind:

  • Proxys
  • Load Balancer
  • Firewalls

API-Aufruf-URL 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, lautet das Format der API-Endpunkt-URL:

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

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

Die API 4.0-Referenz gibt beispielsweise den folgenden relativen Pfad für den Endpunkt aller laufenden Abfragen abrufen:

/api/4.0/running_queries

Daher würde die vollständige API-Endpunkt-URL für den Endpunkt aller laufenden Abfragen auf der Looker-Instanz docsexamples.dev.looker.com so aussehen:

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. 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 könnte dies bedeuten, dass ein Flag für den API-Aufruf festgelegt wird, um die HTTP REST-Bibliothek zu informieren, dass es sich um ein binäres Ergebnis handelt. Es könnte auch bedeuten, dass das Ergebnis auf eine bestimmte Weise verarbeitet wird, z. B. als Stream von Byte oder als Array von Byte, anstatt das Ergebnis einer Stringvariablen zuzuweisen.

API-Aufrufe reagieren nicht

Wenn Sie den API Explorer öffnen können, die API-Aufrufe jedoch 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 einsehen (siehe Dokumentationsseite Administratoreinstellungen – API).

Fehler aufgrund einer ungültigen Codierung

Wenn Sie beim Versuch, einen API-Aufruf auszuführen, einen Codierungsfehler erhalten, müssen Sie während der Anfrage möglicherweise die richtige Content-Type in Ihrem Header festlegen. HTTP-Protokollstandards erfordern, dass 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.

Hinweis: Wenn Sie ein Looker SDK verwenden, wird dieses Problem automatisch für Sie bearbeitet.

Fehler vom Typ „Method Not Found“

Wenn Sie den Fehler „Method Not Found“ wie method not found: all_looks() erhalten, müssen 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 zu allgemein verfügbarer Looker API 4.0-Version.

Ungültige Anfrage (400)

Der Fehler 400 Bad Request gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkannt werden. Die Ursache ist oft ein fehlerhaftes oder ungültiges JSON-Format, z. B. ein Parsing-Fehler. In den meisten Fällen haben 400-Fehler die Authentifizierung bereits bestanden, sodass die Fehlermeldung genauere Informationen zum Fehler enthält.

Nicht autorisierte Fehler (401)

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 vom Typ „Unzulässig“ (403)

Die Looker API gibt nicht jedes Mal einen 403-Fehler zurück, wenn ein Benutzer versucht, auf ein LookML-Objekt oder einen anderen Inhalt zuzugreifen, für den er keine Berechtigung hat. Wenn Sie einen 403-Fehler anstelle eines 404-Fehlers zurückgeben, kann in einigen Fällen die Existenz eines bestimmten Explore, Dashboards oder LookML-Objekts bestätigt werden, wenn der Inhaber dies bevorzugt. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück und der zugehörige Fehler in der Looker-Benutzeroberfläche lautet: „Die von Ihnen angeforderte Seite konnte nicht gefunden werden. Entweder ist er nicht vorhanden oder Sie sind nicht berechtigt, ihn anzusehen.“

Abhängig von der Umgebung, in der Ihre Looker-Instanz gehostet wird, und der Konfiguration Ihrer Looker-Instanz können die Portnummer und die zugehörige URL, über die auf die API zugegriffen werden kann, unterschiedlich sein. 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 und eine Verbindung zu https://mycompany.looker.com/api/4.0/login statt mit https://mycompany.looker.com:443/api/4.0/login hergestellt wird, wird der Fehler 403 zurückgegeben. Für vom Kunden gehostete Instanzen finden Sie unter Looker-Startoptionen weitere Informationen, bei denen Sie den API-Port definieren können.

Dieser Fehler kann auch auftreten, wenn Sie eine veraltete Version des Ruby SDK-Gem verwenden. Halte diese Edelsteine auf dem neuesten Stand. Sie können das unter https://rubygems.org/gems/looker-sdk prüfen.

Das kann auch passieren, wenn du den /api/<version number>/-Teil der URL nicht einfügst. Wenn ein Nutzer versucht, eine Verbindung zu https://mycompany.looker.com:443/login herzustellen, sieht er in diesem Fall den Fehler 403.

Fehler „Nicht gefunden“ (404)

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

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

  • 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 mit looker.ini sollte der Wert von api_version 4.0 und der Wert von base_url mit der URL der Looker-Instanz-API im Format https://<your-looker-hostname>:<port> übereinstimmen. Im Folgenden finden Sie ein Beispiel für eine looker.ini-Datei:

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

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

Fehler „Method Not Allowed“ (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 in einer 405-Statuscodeantwort ein Allow-Headerfeld generieren. Das Feld muss eine Liste mit Methoden enthalten, die von der Zielressource unterstützt werden.

Dies trifft beispielsweise dann in Looker zu, wenn Sie versuchen, den Endpunkt update_dashboard() zu verwenden, um die Metadaten eines LookML-Dashboards zu aktualisieren. Das Ändern des id-Parameters eines LookML-Dashboards wird über die Looker API nicht unterstützt, sodass der Fehler 405 auftritt.

Konfliktfehler (409)

Der Antwortstatuscode 409 Conflict gibt an, dass die Anfrage mit dem aktuellen Status der Zielressource in Konflikt steht.

Konflikte treten am häufigsten bei einer PUT-Anfrage auf. Ein häufiges Nicht-Looker-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 über die 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 Element in der Anfrage die durchgeführten Datenprüfungen nicht bestanden hat. Die Anfrage enthält mindestens einen der folgenden Fehlertypen (in der Fehlerantwort werden die genauen Fehler angegeben):

  • Fehlende Felder: Ein erforderlicher Parameter wurde nicht angegeben. In der Fehlerantwort sehen Sie, welches Feld fehlt.
  • Ungültig: Der angegebene Wert stimmt mit keinem vorhandenen Wert überein oder der Wert hat nicht das richtige Format. Wenn Sie beispielsweise versuchen, einen Look zu erstellen, und die im API-Aufruf angegebene Abfrage-ID mit keiner vorhandenen Abfrage übereinstimmt, erhalten Sie einen Validierungsfehler.
  • Bereits vorhanden: Der API-Aufruf versucht, ein Objekt mit einer ID oder einem Namen zu erstellen, die bzw. der in Ihrer Looker-Instanz bereits vorhanden ist. Beispielsweise müssen Namen von Datenbankverbindungen 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 sehen Sie Details dazu, welche Felder möglicherweise fehlen oder erforderlich sind und welche Felder ungültige Werte enthalten können. Die Antwortnachricht enthält alle Validierungsfehler gleichzeitig. Wenn also Felder fehlen und auch falsche Felder vorhanden sind, werden in der Fehlerantwort alle Probleme mit Ihrem 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 erforderliche Feld dialect und die db_timezone enthielt einen ungültigen Wert.

Fehler „Zu viele Anfragen (429)“

Der Antwortstatuscode 429 Too Many Requests gibt an, dass der Nutzer in einem bestimmten Zeitraum zu viele Anfragen gesendet hat („Ratenbegrenzung“). Weitere Informationen zu den Looker-Richtlinien für Ratenbegrenzungen finden Sie im Looker-Communitybeitrag Is there a limit to the number of API requests you can send at a time?

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 „Catch-all“-Antwort. Normalerweise bedeutet dies, dass der Server keinen spezifischeren 5xx-Fehlercode finden kann, der als Antwort zurückgegeben werden kann. Looker-Antwort 500 ist unerwartet. Wenn dieser Fehler bei der Interaktion mit Looker immer wieder auftritt, empfehlen wir Ihnen, eine Supportanfrage zu stellen.