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 können die Client-ID sehen und auf das Augensymbol klicken, um den Clientschlüssel 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.

Wenn Sie eine Looker (Google Cloud Core)-Instanz verwenden, gehen Sie so vor, um Ihre API-Anmeldedaten aufzurufen:

  1. Rufen Sie in Looker Ihre Kontoseite auf, indem Sie auf Ihr Nutzersymbol klicken und Konto auswählen.
  2. Klicken Sie auf der Seite Ihres Kontos im Bereich Authentifizierung auf den Button 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 Show secret (Schlüssel anzeigen) klicken, um den Clientschlüssel 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 für Nutzer angeben.

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 Hauptmenü  und wählen Sie Admin aus, um den Bereich Admin zu öffnen.
  2. Klicken Sie im Bereich Verwaltung auf API.

  3. API-Host-URL ansehen

    Wenn das Feld API-Host-URL leer ist, wird in Ihrer Looker-Instanz das Standardformat verwendet:

    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. Bei Instanzen, die in Google Cloud oder Microsoft Azure gehostet werden, und bei Instanzen, die in Amazon Web Services (AWS) gehostet werden und am oder nach dem 07.07.2020 erstellt wurden, wird für den Standard-Looker API-Pfad 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 standardmäßigen 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 in der Browserkonsole nachsehen, ob Sie die API erreicht haben. 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 Angaben 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 in der Regel 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, sieht das Format einer API-Endpunkt-URL so aus:

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.

In der Referenz zur API 4.0 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 wäre 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 darauf achten, 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 aber 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 den richtigen 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 behoben.

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 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 können. Häufig ist fehlerhaftes oder ungültiges JSON die Ursache, 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 403-Fehler zurück, wenn ein Nutzer versucht, auf ein LookML-Objekt oder andere Inhalte zuzugreifen, für die er keine Berechtigung hat. Wenn anstelle eines 404-Fehlers ein 403-Fehler zurückgegeben wird, kann in einigen Fällen die Existenz eines bestimmten Explores, Dashboards oder LookML-Objekts bestätigt werden, 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. Entweder ist er nicht vorhanden oder Sie sind nicht berechtigt, ihn anzusehen.“

Je nach Umgebung, in der Ihre Looker-Instanz gehostet wird, und der 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 der Fehler 403 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 Startoptionen für vom Kunden gehostete Instanzen, in denen Sie den API-Port definieren können, finden Sie hier.

Das kann auch passieren, wenn Sie eine veraltete Version des Ruby SDK-Gems verwenden. Achte darauf, dass du sie regelmäßig aktualisierst. Weitere Informationen finden Sie unter https://rubygems.org/gems/looker-sdk.

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)

Der Fehler 404 Not Found 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 so gewollt, da Personen mit falschen Anmeldedaten oder unzureichenden Berechtigungen 404‑Fehler 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, prüfen Sie, ob der Wert für base_url korrekt ist:

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

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

  • Bei Looker SDK-Implementierungen, die ein looker.ini verwenden, sollte der Wert von api_version 4.0 sein und der Wert von base_url sollte mit der URL der API Ihrer Looker-Instanz 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>

Möglicherweise erhalten Sie auch nach der Anmeldung einen 404-Fehler. Wenn Sie angemeldet sind und einen 404-Fehler erhalten, haben Sie keine Berechtigungen für den API-Befehl, 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 weist auf einen Konflikt zwischen einer Anfrage und dem aktuellen Status der Zielressource hin.

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, tritt beim Hochladen einer Datei auf, die älter ist als die vorhandene Datei auf dem Server. Dies führt zu einem Versionsverwaltungskonflikt.

Dieser Fehler kann in Looker auftreten, wenn Sie versuchen, einen neuen Git-Branch ü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 bei den durchgeführten Datenprüfungen ein Fehler in der Anfrage festgestellt 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 Details dazu, welche Felder möglicherweise fehlen oder erforderlich sind oder welche Felder ungültige Werte enthalten. In der Antwortnachricht werden alle Validierungsfehler gleichzeitig angezeigt. 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 das Feld db_timezone enthielt einen ungültigen Wert.

Fehler vom Typ „Too Many Requests“ (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 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 Fehlerantwort ist eine allgemeine „Auffangantwort“. Normalerweise bedeutet das, dass der Server keinen spezifischeren 5xx-Fehlercode finden kann, der als Antwort zurückgegeben werden soll. Jede 500-Antwort von Looker ist unerwartet. Wenn dieser Fehler also immer wieder auftritt, wenn Sie mit Looker interagieren möchten, empfehlen wir Ihnen, eine Supportanfrage zu stellen.

Fehler „Gateway Timeout“ oder „Upstream Request Timeout“ (504)

Ein 504 Gateway Timeout- oder 504 Upstream Request Timeout-Fehler weist darauf hin, dass ein Load-Balancer oder Proxy vor Ihrer Looker-Instanz die Verbindung geschlossen hat, bevor Looker die API-Anfrage verarbeitet hat. Dieses Problem tritt häufig bei lang andauernden Abfragen oder Anfragen auf, die eine umfangreiche Nutzlastwiedergabe erfordern, z. B. bei Aufrufen von /result_format-Endpunkten.

Bei Looker (Google Cloud Core)-Instanzen, auf die über einen Cloud Load Balancing-Load Balancer zugegriffen wird, hat der Backend-Dienst des Load Balancers ein standardmäßiges Zeitlimit für den Backend-Dienst von 30 Sekunden. Wenn die kombinierte Ausführungszeit der Datenbankabfrage und die Looker-Rendering-Zeit dieses Limit überschreiten, schließt der Load Balancer die Verbindung und gibt einen 504-Fehler zurück.

Verwenden Sie eine oder beide der folgenden Methoden, um dieses Problem zu beheben:

  • Zeitlimit des Load Balancers erhöhen: Erhöhen Sie den Zeitlimitwert für den Backend-Dienst des Load Balancers, der mit Ihrer Looker-Instanz verknüpft ist, z. B. von 30 Sekunden auf 300 Sekunden. Eine Anleitung für Looker (Google Cloud Core)-Instanzen finden Sie unter Fehlerbehebung bei Netzwerkproblemen in Looker (Google Cloud Core).
  • Asynchronen API-Workflow verwenden: Anstatt auf eine synchrone API-Antwort zu warten, rufen Sie create_query_task auf, um die Abfrage asynchron zu starten, und fragen Sie dann query_task_results ab, um die Ergebnisse nach Abschluss der Abfrage abzurufen.