Fehlerbehebung bei der Looker API

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

API-Endpunkt nicht erreichbar

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

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, wenn Sie eine Looker-Originalinstanz verwenden:

  1. Rufen Sie in Looker den Admin-Bereich 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 können auf das Augensymbol klicken, 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 Skript verwenden.

So rufen Sie Ihre API-Anmeldedaten auf, wenn Sie eine Looker (Google Cloud Core)-Instanz verwenden:

  1. Rufen Sie in Looker Ihre Kontoseite auf, indem Sie auf Ihr Nutzersymbol und dann auf Konto klicken.
  2. Klicken Sie auf der Seite Ihres Kontos im Abschnitt Authentifizierung auf die Schaltfläche Verwalten für API-Schlüssel. Dadurch wird die Seite API-Schlüssel geöffnet.
  3. Auf der Seite API-Schlüssel können Sie alle Ihre API-Schlüssel aufrufen. Für jeden API-Schlüssel wird die Client-ID angezeigt. Sie können auf das Symbol Secret anzeigen klicken, 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 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 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 jedoch möglicherweise nicht verwendet. In diesem Fall muss die API-Host-URL den API-Hostnamen und ‑Port angeben, die für den Nutzer sichtbar sind.

Looker-Administratoren können die Host-URL der API in den API-Administratoreinstellungen sehen (ausführlicher beschrieben auf der Dokumentationsseite Administratoreinstellungen – API). So rufen Sie die API-Host-URL auf:

  1. Klicken Sie auf das Symbol für das Hauptmenü  und wählen Sie Admin aus, um den Bereich Admin zu öffnen.
  2. Klicken Sie im Bereich Verwaltung 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 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. Für Instanzen, die in Google Cloud oder Microsoft Azure gehostet werden, und für Instanzen, die in Amazon Web Services (AWS) gehostet werden und am oder nach dem 07.07.2020 erstellt wurden, wird für den Looker API-Standardpfad beispielsweise der 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, wird für den Standard-Looker API-Pfad Port 19999 verwendet:

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

Wenn diese Prüfungen fehlschlagen, rufen Sie die API möglicherweise falsch auf oder es gibt andere Fehler in Ihrem Code. Überprüfen Sie Ihre API-Aufrufe und den Code in Ihrem Skript. Wenn diese korrekt sind, lesen Sie den nächsten Abschnitt zum Überprüfen des Ports.

API-Port prüfen

Wenn die vorherigen Prüfungen fehlschlagen und Sie eine von 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 am häufigsten 443 oder 19999. Der API-Port sollte dieselben Konfigurationseinstellungen wie der Looker-Instanzport (standardmäßig 9999) haben. 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

URL des API-Aufrufs 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, hat die URL eines API-Endpunkt 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 API 4.0-Referenz wird beispielsweise der folgende relative Pfad für den Endpunkt „Get All Running Queries“ angegeben:

/api/4.0/running_queries

Die vollständige API-Endpunkt-URL für den Endpunkt „Get All Running Queries“ in der docsexamples.dev.looker.com-Looker-Instanz lautet also:

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

Das API-Ergebnis ist unsinniger Text

Wenn die API eine Antwort mit unleserlichem Text zurückgibt, sehen Sie wahrscheinlich den binären Inhalt einer PDF-, PNG- oder JPG-Datei. Bei einigen HTTP REST-Bibliotheken wird davon ausgegangen, 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 dies bedeuten, dass Sie ein Flag für den API-Aufruf festlegen müssen, um der HTTP REST-Bibliothek mitzuteilen, dass es sich um ein binäres Ergebnis handelt. Möglicherweise müssen Sie das Ergebnis auch auf besondere Weise verarbeiten, z. B. als Byte-Stream oder als Byte-Array, anstatt es einer String-Variablen zuzuweisen.

API-Aufrufe werden nicht beantwortet

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

Fehler aufgrund ungültiger Codierung

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

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

Fehler vom Typ „Methode nicht gefunden“

Wenn Sie einen „Method Not Found“-Fehler erhalten, z. B. method not found: all_looks(), sollten Sie zuerst Ihre API-Version überprüfen. Es gibt mehrere API-Aufrufe, die in API 4.0 neu sind oder in API 4.0 entfernt wurden. Eine Liste der Updates finden Sie in der Ankündigung zur allgemeinen Verfügbarkeit der Looker API 4.0.

Fehler vom Typ „Bad Request (400)“

Ein 400 Bad Request-Fehler weist darauf hin, dass die in einem API-Aufruf bereitgestellten Daten nicht erkannt werden. Häufig ist die Ursache fehlerhaftes oder ungültiges JSON, z. B. ein Parsing-Fehler. In den meisten Fällen wurde die Authentifizierung bei 400‑Fehlern bereits bestanden. Die Fehlermeldung 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 richtig authentifiziert wurde. Weitere Informationen zur Fehlerbehebung finden Sie unter Wie behebe ich 401-Fehler? Community-Artikel

Fehler „Forbidden (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 in einigen Fällen ein 403-Fehler anstelle eines 404-Fehlers zurückgegeben wird, kann dies die Existenz eines bestimmten Explores, Dashboards oder LookML-Objekts bestätigen, obwohl der Inhaber dies möglicherweise nicht möchte. Um dies zu verhindern, gibt Looker in diesen Fällen einen 404-Fehler zurück. Der zugehörige Fehler in der Looker-Benutzeroberfläche lautet: „Die angeforderte Seite konnte nicht gefunden werden. Sie ist entweder nicht vorhanden oder Sie haben keine Berechtigung, sie aufzurufen.“

Je nach Umgebung, in der Ihre Looker-Instanz gehostet wird, und je nach 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 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 anstelle von https://mycompany.looker.com:443/api/4.0/login ein 403-Fehler zurückgegeben. Weitere Informationen zu Looker-Startoptionen, in denen Sie den API-Port definieren können, finden Sie für vom Kunden gehostete Instanzen.

Das kann auch passieren, wenn Sie eine veraltete Version des Ruby SDK-Gems verwenden. Achte darauf, dass du diese Gems immer auf dem neuesten Stand hältst. Sie können das unter https://rubygems.org/gems/looker-sdk prüfen.

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

Fehler „Nicht gefunden“ (404)

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 oder gar keine Informationen. Das ist beabsichtigt, da 404-Fehler Personen mit falschen Anmeldedaten oder unzureichenden Berechtigungen angezeigt werden. Looker möchte keine spezifischen Informationen in 404-Antwortnachrichten bereitstellen, da diese Informationen verwendet werden könnten, um die „Angriffsfläche“ der Looker API zu ermitteln.

Wenn bei API-Anmeldeversuchen 404-Fehler zurückgegeben werden, liegt das höchstwahrscheinlich daran, dass Ihre API-Client-ID oder Ihr Client-Secret ungültig ist (siehe API-Anmeldedaten überprüfen weiter oben auf dieser Seite). Der REST-Endpunkt für die API-Anmeldung lautet:

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

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

  • Für einen Swagger-Codegenerierungsclient sollte base_url Folgendes sein:

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

  • Bei Looker SDK-Implementierungen, die 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>

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

Fehler „Method Not Allowed“ (405)

Ein 405 Method Not Allowed-Fehler weist darauf hin, 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 von der Zielressource unterstützt werden.

Ein Beispiel dafür, wie dies in Looker auftreten kann, ist, wenn Sie versuchen, den update_dashboard()-Endpunkt zu verwenden, um die Metadaten eines LookML-Dashboards zu aktualisieren. Das Ändern des Parameters id eines LookML-Dashboards wird über die Looker API nicht unterstützt. Daher würde ein 405-Fehler auftreten.

Fehler vom Typ „Conflict (409)“

Der Antwortstatuscode 409 Conflict gibt an, dass ein Konflikt zwischen einer Anfrage und dem aktuellen Status der Zielressource besteht.

Konflikte treten am wahrscheinlichsten als Reaktion auf eine PUT-Anfrage auf. Ein häufiges Beispiel für diesen Fehler, das nicht mit Looker zusammenhängt, ist das Hochladen einer Datei, die älter ist als die vorhandene Datei auf dem Server, was zu einem Versionsverwaltungskonflikt führt.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, über die API einen neuen Git-Branch 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 bei den durchgeführten Datenprüfungen etwas in der Anfrage nicht bestanden wurde. Die Anfrage enthält einen oder mehrere 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 hat nicht das richtige Format. Wenn Sie beispielsweise versuchen, einen Look zu erstellen, und die im API-Aufruf angegebene Abfrage-ID 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. So müssen beispielsweise Namen von Datenbankverbindungen 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 Fehlermeldung finden Sie Informationen dazu, welche Felder möglicherweise fehlen oder erforderlich sind oder welche Felder ungültige Werte enthalten. Die Antwortmeldung enthält alle Validierungsfehler gleichzeitig. Wenn Sie also fehlende und falsche Felder haben, 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 im Feld db_timezone wurde ein ungültiger Wert angegeben.

Fehler vom Typ „Too Many Requests“ (429)

Der Antwortstatuscode 429 Too Many Requests gibt an, dass der Nutzer innerhalb eines bestimmten Zeitraums zu viele Anfragen gesendet hat („Ratenbegrenzung“). Weitere Informationen zu den Ratenbegrenzungsrichtlinien von Looker finden Sie im Looker-Community-Beitrag Is there a limit to the number of API requests you can send at one time?

Fehler vom Typ „Internal Server Error (500)“

Der Antwortcode 500 Internal Server Error gibt an, dass auf dem Server eine unerwartete Bedingung aufgetreten ist, die ihn daran gehindert hat, die Anfrage zu erfüllen.

Diese Fehlermeldung ist eine allgemeine „Auffangantwort“. Normalerweise weist sie darauf hin, dass der Server keinen spezifischeren 5xx-Fehlercode für die Antwort finden kann. Jede 500-Antwort von Looker ist unerwartet. Wenn Sie diesen Fehler also immer wieder sehen, wenn Sie versuchen, mit Looker zu interagieren, empfehlen wir Ihnen, eine Supportanfrage zu stellen.