Fehlerbehebung in der Looker API

Auf dieser Seite werden Schritte zur Behebung der folgenden Probleme mit der Looker API beschrieben:

API-Endpunkt ist nicht erreichbar

Falls Sie einen API-Endpunkt nicht erreichen können, versuchen Sie Folgendes:

API-Anmeldedaten überprüfen

Wenn Ihr 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 und können auf das Augensymbol klicken, um den Clientschlüssel für jeden von Ihnen konfigurierten API-Schlüssel aufzurufen. Prüfen Sie, ob Ihre API-Anmeldedaten mit den Anmeldedaten in Ihrem Skript übereinstimmen.

API-URL bestätigen

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. Für Looker-Installationen mit einem alternativen API-Pfad oder mit Looker-Installationen hinter einem Load-Balancer (z. B. einer Clusterkonfiguration) oder einem anderen Proxy wird möglicherweise nicht die Standard-URL verwendet. In diesem Fall muss die API-Host-URL den für Nutzer sichtbaren API-Hostnamen und -Port angeben.

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 Host-URL der API auf:

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

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

    Wenn das Feld API-Host-URL leer ist, verwendet die 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. Weitere Informationen zum Öffnen einer Konsole in Ihrem Browser finden Sie in diesem Artikel von ConcreteCMS.org.

  2. Geben Sie Ihre 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 in Google Cloud, Microsoft Azure und auf Amazon Web Services (AWS) gehostet werden und die am oder nach dem 07.07.2020 erstellt wurden, der Standard-Looker API-Pfad Port 443 verwendet:

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

    Für auf AWS gehostete Instanzen, die vor dem 07.07.2020 erstellt wurden, verwendet der Standard-Looker-API-Pfad Port 19999:

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

Wenn die URL des API-Hosts korrekt ist, führt diese URL zu einer leeren Webseite und nicht zu einer Fehlerseite.

Sie können auch prü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 möglicherweise daran, dass Sie die API falsch aufrufen oder dass andere Fehler in Ihrem Code auftreten. Prüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese korrekt sind, lesen Sie den nächsten Abschnitt über die Bestätigung der Rufnummernmitnahme.

API-Port überprüfen

Wenn die oben genannten 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. Bei vom Kunden gehosteten Looker-Bereitstellungen bitten Sie Ihren Netzwerkadministrator, die Einstellungen für den API-Port zu prüfen. Der API-Port ist meist 443 oder 19999. Der API-Port sollte die gleichen Konfigurationseinstellungen haben wie der Looker-Instanzport (standardmäßig 9999). Ihr Netzwerkadministrator sollte prüfen, ob die folgenden Einstellungen für den API-Port und für den Port der Looker-Instanz identisch sind:

  • Proxys
  • Load-Balancer
  • Firewalls

API-Aufruf-URL bestätigen

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

<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 über den API Explorer, das Entwicklerportal von Looker oder die API-Referenz abrufen.

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

/api/4.0/running_queries

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

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

API-Ergebnis ist unsinniger Text

Wenn die API eine Antwort mit nicht lesbarem Text zurückgibt, wird wahrscheinlich der binäre Inhalt einer PDF-, PNG- oder JPG-Datei angezeigt. Bei einigen HTTP-REST-Bibliotheken wird davon ausgegangen, dass API-Antworten Textdateien sind. Andere Dateitypen werden als Binärtext angezeigt.

In diesem Fall müssen Sie darauf achten, dass Ihre HTTP-REST-Bibliothek die API-Antwort nicht als Text, sondern als Binärdaten verarbeitet. In manchen Fällen bedeutet das beispielsweise, dass beim API-Aufruf ein Flag festgelegt wird, um die HTTP-REST-Bibliothek zu übergeben. Dies kann auch bedeuten, dass das Ergebnis auf eine spezielle Weise verarbeitet wird, z. B. als Stream von Byte oder als Array von Byte, anstatt das Ergebnis einer Stringvariable zuzuweisen.

API-Aufrufe reagieren nicht

Wenn Sie den API Explorer öffnen können, aber Ihre API-Aufrufe 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. Eine Beschreibung finden Sie auf der Dokumentationsseite Admin-Einstellungen – API.

Ungültige Codierungsfehler

Wenn Sie bei einem API-Aufruf einen Codierungsfehler erhalten, müssen Sie möglicherweise während der Anfrage den richtigen Content-Type im Header festlegen. Gemäß den HTTP-Protokollstandards muss 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.

Bei diesem Problem wird automatisch ein Looker SDK verwendet.

Fehler: Methode nicht gefunden

Wenn Sie den Fehler „Methode nicht gefunden“ erhalten, z. B. method not found: all_looks(), prüfen Sie zuerst Ihre API-Version. Einige API-Aufrufe sind in API 4.0 neu oder wurden in API 4.0 entfernt. Eine Liste der Aktualisierungen finden Sie in der Mitteilung Looker API 4.0 allgemein verfügbar.

Fehler aufgrund von fehlerhaften Anfragen (400)

Der Fehler 400 Bad Request gibt an, dass die in einem API-Aufruf bereitgestellten Daten nicht erkannt werden. Die Ursache ist oft ein fehlerhafter oder ungültiger JSON-Code, möglicherweise ein Parsing-Fehler. Bei 400-Fehlern ist die Authentifizierung größtenteils bereits erfolgt. Daher werden in der Fehlermeldung genauere Informationen zum Fehler angezeigt.

Verbotene Fehler (403)

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. Wenn ein 403-Fehler statt eines 404-Fehlers zurückgegeben wird, lässt sich in einigen Fällen das Vorhandensein eines bestimmten Explore-, Dashboard- oder LookML-Objekts überprüfen, wenn der Inhaber dies lieber hätte. Um das 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 aufzurufen.“

Je nach 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, variieren. 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 Verbinden mit https://mycompany.looker.com/api/4.0/login statt https://mycompany.looker.com:443/api/4.0/login ein 403-Fehler zurückgegeben. Für vom Kunden gehostete Instanzen finden Sie weitere Informationen unter Looker-Startoptionen, in denen Sie den API-Port definieren können.

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

Dies kann auch passieren, wenn du den /api/<version number>/-Teil der URL nicht angibst. Wenn ein Nutzer nun versucht, eine Verbindung zu https://mycompany.looker.com:443/login herzustellen, wird ihm die Antwort „403“ angezeigt.

Fehler vom Typ „Nicht gefunden (404)“

Ein 404 Not Found-Fehler ist der Standardfehler, wenn etwas schiefgeht, in der Regel mit Berechtigungen wie Berechtigungen. Die Antwort auf einen 404-Fehler enthält, falls vorhanden, nur minimale Informationen. Das ist beabsichtigt, weil 404-Fehler Nutzern mit falschen Anmeldedaten oder unzureichenden Berechtigungen angezeigt werden. Looker möchte keine spezifischen Informationen in 404-Antwortnachrichten angeben, da diese Informationen verwendet werden können, 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 Ihr Clientschlüssel ungültig ist. Weitere Informationen finden Sie oben auf dieser Seite unter API-Anmeldedaten überprüfen. Der REST-Endpunkt für die API-Anmeldung ist je nach verwendeter API-Version einer der folgenden:

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, muss der base_url-Wert korrekt sein:

  • Für einen Swagger-Codegen-Client sollte base_url je nach verwendeter API-Version eine der folgenden Optionen 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 und der Wert von base_url der URL Ihrer Looker Instanz-API im Format https://<your-looker-hostname>:<port> sein. 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>

Möglicherweise erhalten Sie nach der Anmeldung auch den Fehler 404. Wenn Sie angemeldet sind und der Fehler 404 angezeigt wird, sind Sie nicht berechtigt, den API-Befehl aufzurufen.

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

Das können Sie beispielsweise in Looker erreichen, wenn Sie versuchen, die Metadaten eines LookML-Dashboards mit dem update_dashboard()-Endpunkt zu aktualisieren. Das Ändern des id-Parameters eines LookML-Dashboards wird über die Looker API nicht unterstützt, daher tritt ein 405-Fehler auf.

Konflikt (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. Dieser Fehler tritt häufig auf, wenn eine Datei hochgeladen wird, die älter als die vorhandene auf dem Server ist. Dies führt zu einem Versionsverwaltungskonflikt.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, einen neuen Git-Zweig mit der API auszuprobieren oder Endpunkte wie create_group() oder create_dashboard() zu 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 etwas in der Anfrage die Datenprüfungen nicht bestanden hat. Die Anfrage weist einen oder mehrere der folgenden Fehlertypen auf. In der Fehlerantwort werden die genauen Fehler angegeben:

  • Fehlende Felder: Ein erforderlicher Parameter wurde nicht angegeben. In der Fehlermeldung wird angegeben, welches Feld fehlt.
  • Ungültig: Der angegebene Wert stimmt nicht mit einem vorhandenen Wert überein oder der Wert hat nicht das richtige 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: Der API-Aufruf versucht, ein Objekt mit einer ID oder einem Namen zu erstellen, die bereits auf der 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 eventuell fehlen oder erforderlich sind oder welche Felder ungültige Werte enthalten. Die Antwortnachricht enthält gleichzeitig alle Validierungsfehler. Wenn also Felder fehlen und auch inkorrekt sind, werden in der Fehlermeldung 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 im API-Aufruf das Pflichtfeld dialect und es wurde ein ungültiger Wert in db_timezone angegeben.

Fehler „Zu viele Anfragen“ (429)

Der Statuscode 429 Too Many Requests gibt an, dass der Nutzer zu viele Anfragen in einem bestimmten Zeitraum gesendet hat („Ratenbegrenzung“). Weitere Informationen zu den Ratenbegrenzungsrichtlinien von Looker finden Sie im Beitrag Looker-Community. Ist die Anzahl der API-Anfragen, die Sie gleichzeitig senden können, begrenzt?

Interner Serverfehler (500)

Der Antwortcode 500 Internal Server Error gibt an, dass der Server aufgrund einer unerwarteten Bedingung die Anforderung nicht ausführen konnte.

Diese Fehlerantwort ist eine allgemeine „Catch-all“-Antwort. Das bedeutet in der Regel, dass der Server keinen spezifischeren 5xx-Fehlercode findet, der zurückgegeben werden kann. Alle 500-Antworten von Looker sind unerwartet. Wenn Sie also ständig versuchen, mit Looker zu interagieren, sollten Sie sich an den Looker-Support wenden.