Solución de problemas de la API Looker

.

En esta página se describen los procedimientos para solucionar los siguientes problemas que pueden surgir con la API de Looker:

No se puede acceder al endpoint de la API

Si no puedes acceder a un endpoint de API:

Verificar tus credenciales de API

Si no se puede acceder a tu endpoint de la API de Looker, primero comprueba que tus credenciales de la API sean correctas. Para ver tus credenciales de API, sigue estos pasos:

  1. En Looker, accede al panel Administrar seleccionando la opción Administrar en el panel de navegación de la izquierda.
  2. En el panel de la izquierda de la página Administrar, desplázate hacia abajo y haz clic en Usuarios.
  3. Busca tu nombre de usuario en la lista de usuarios y haz clic en él para editar tu página de usuario.
  4. Haz clic en Editar claves de API. Puedes ver el ID de cliente y hacer clic en el icono del ojo para ver el secreto de cliente de cada clave de API que hayas configurado. Verifica que las credenciales de la API coincidan con las que estás usando en tu secuencia de comandos.

Verificar la URL de la API

Otro problema habitual que se produce al acceder a un endpoint de API es que la URL del host de la API sea incorrecta. La mayoría de las instancias de Looker usan la URL predeterminada de la API. Sin embargo, las instalaciones de Looker que usen una ruta de API alternativa o que estén ubicadas detrás de un balanceador de carga (por ejemplo, una configuración de clúster) o de cualquier otro proxy podrían no usar la URL predeterminada. En ese caso, la URL del host de la API debe indicar el nombre de host y el puerto de la API que ven los usuarios.

Los administradores de Looker pueden ver la URL del host de la API en la configuración de administrador de la API (que se describe con más detalle en la página de documentación Configuración de administrador - API). Para ver la URL del host de la API, sigue estos pasos:

  1. Haz clic en el icono Menú principal de Looker y selecciona Administrar para abrir el panel Administrar.
  2. En el panel Administrar, haz clic en API.

  3. Consulta la URL del host de la API.

    Si el campo URL del host de la API está en blanco, tu instancia de Looker usará el formato predeterminado, que es el siguiente:

    https://<instance_name>.cloud.looker.com:<port>

Para probar la URL del host de la API, sigue estos pasos:

  1. Abre un navegador y, a continuación, abre la consola del navegador.

  2. Introduce la URL de host de la API seguida de /alive. Por ejemplo, si la URL del host de la API es https://company.cloud.looker.com, introduzca lo siguiente:

    https://company.cloud.looker.com/alive

    Si el campo URL de host de la API está en blanco, utilice la URL de la API predeterminada. Por ejemplo, en las instancias alojadas en Google Cloud y Microsoft Azure, así como en las instancias alojadas en Amazon Web Services (AWS) que se crearon a partir del 7 de julio del 2020, la ruta de la API de Looker predeterminada usa el puerto 443:

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

    En las instancias alojadas en AWS que se crearon antes del 7 de julio del 2020, la ruta de la API de Looker predeterminada usa el puerto 19999:

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

Si la URL del host de la API es correcta, esta URL mostrará una página web en blanco, no una página de error.

También puedes verificar que has llegado a la API consultando la respuesta de la red en la consola de tu navegador. La respuesta de red debe ser 200.

Si estas comprobaciones fallan, puede que estés llamando a la API de forma incorrecta o que tengas otros errores en el código. Comprueba las llamadas a la API y el código de tu secuencia de comandos. Si son correctos, consulta la siguiente sección sobre cómo verificar tu puerto.

Verificar el puerto de la API

Si las comprobaciones anteriores fallan y tienes una implementación de Looker alojada por el cliente, es posible que tengas que abrir el puerto de la API en la infraestructura de red.

El puerto de la API debe reenviar al servidor de Looker. En las implementaciones de Looker alojadas por el cliente, pide a tu administrador de red que compruebe la configuración del puerto de la API. El puerto de la API suele ser 443 o 19999. El puerto de la API debe tener la misma configuración que el puerto de la instancia de Looker (9999 de forma predeterminada). El administrador de tu red debe verificar que los siguientes ajustes del puerto de la API sean los mismos que los del puerto de tu instancia de Looker:

  • Proxies
  • Balanceadores de carga
  • Cortafuegos

Verificar la URL de la llamada a la API

Comprueba que estés usando la URL correcta en tu llamada a la API. El formato de una URL de endpoint de API es el siguiente:

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

Si usas la URL de host de la API predeterminada, el formato de una URL de endpoint de la API es el siguiente:

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

Puedes obtener el formato de URL de los endpoints de la API en el Explorador de APIs o en la documentación de la referencia de la API.

Por ejemplo, la referencia de la API 4.0 proporciona la siguiente ruta relativa para el endpoint Get All Running Queries:

/api/4.0/running_queries

Por lo tanto, la URL completa del endpoint de la API para el endpoint Get All Running Queries de la instancia de Looker docsexamples.dev.looker.com sería la siguiente:

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

El resultado de la API es un texto sin sentido

Si la API devuelve una respuesta con texto ilegible, es probable que estés viendo el contenido binario de un archivo PDF, PNG o JPG. Algunas bibliotecas REST de HTTP asumen que las respuestas de las APIs serán archivos de texto, por lo que otros tipos de archivos se muestran como texto binario.

En este caso, debes asegurarte de que tu biblioteca REST de HTTP gestione la respuesta de la API como datos binarios, no como texto. En algunos casos, esto puede significar definir una marca en la llamada a la API para indicar a la biblioteca REST HTTP que se trata de un resultado binario, o bien gestionar el resultado de una forma especial, como un flujo de bytes o una matriz de bytes, en lugar de asignar el resultado a una variable de cadena.

Las llamadas a la API no responden

Si puedes abrir el Explorador de APIs, pero tus llamadas a la API no responden, comprueba que el ajuste URL del host de la API de tu instancia de Looker esté configurado correctamente. Los administradores de Looker pueden ver la URL del host de la API en los ajustes de administrador de la API de Looker (descritos en la página de documentación Ajustes de administrador - API).

Errores de codificación no válida

Si recibe un error de codificación al intentar hacer una llamada a la API, puede que tenga que definir el Content-Type adecuado en el encabezado durante la solicitud. Los estándares del protocolo HTTP requieren que cualquier solicitud POST, PUT o PATCH contenga un encabezado Content-Type. Como la API de Looker usa JSON en todas partes, el encabezado Content-Type debe tener el valor application/json.

Ten en cuenta que, si usas un SDK de Looker, este problema se solucionará automáticamente.

Errores de método no encontrado

Si recibes un error Method Not Found, como method not found: all_looks(), lo primero que debes comprobar es la versión de la API. Hay varias llamadas a la API que son nuevas en la API 4.0 o que se han retirado en la API 4.0. Consulta la lista de actualizaciones en el anuncio de la disponibilidad general de la API Looker 4.0.

Errores de solicitud incorrecta (400)

Un error 400 Bad Request indica que los datos proporcionados en una llamada a la API no se pueden reconocer. El problema suele ser un JSON no válido o dañado, quizás un error de análisis. En la mayoría de los casos, los errores 400 ya han superado la autenticación, por lo que el mensaje de respuesta de error proporcionará información más específica sobre el error.

Errores de autorización (401)

Un error 401 Unauthorized en una llamada a la API significa que la llamada a la API no se ha autenticado correctamente. Para obtener más información sobre cómo solucionar problemas, consulta el artículo ¿Cómo soluciono los errores 401? Artículo de la comunidad.

Errores Forbidden (403)

La API de Looker no devuelve errores 403 cada vez que un usuario intenta acceder a un objeto LookML u otro contenido para el que no tiene permiso. Devolver un error 403 en lugar de un error 404 podría, en algunos casos, verificar la existencia de un Explore, un panel de control o un objeto LookML concretos cuando el propietario prefiera que no se sepa. Para evitarlo, Looker devuelve un error 404 en estos casos y el error correspondiente en la interfaz de usuario de Looker indica lo siguiente: "No se ha encontrado la página que ha solicitado. No existe o no tienes permiso para verlo".

En función del entorno en el que esté alojada tu instancia de Looker y de la configuración de la instancia, el número de puerto y la URL asociada a la que se puede acceder a la API pueden ser diferentes. Si usas un número de puerto incorrecto, puede que veas un error 403. Por ejemplo, si tu instancia de Looker está configurada con el puerto de API predeterminado 443, al conectarte a https://mycompany.looker.com/api/4.0/login en lugar de a https://mycompany.looker.com:443/api/4.0/login, se devolverá un error 403. En el caso de las instancias alojadas por el cliente, puedes consultar más información sobre las opciones de inicio de Looker, donde puedes definir el puerto de la API.

Esto también puede ocurrir si usas una versión obsoleta de la gema del SDK de Ruby. Asegúrate de mantener actualizadas esas gemas. Puedes consultarlo en https://rubygems.org/gems/looker-sdk.

Esto también puede ocurrir si no incluye la parte /api/<version number>/ de la URL. En este caso, si un usuario intenta conectarse a https://mycompany.looker.com:443/login, verá una respuesta 403.

Errores Not Found (404)

El error 404 Not Found es el error predeterminado si algo va mal, normalmente con elementos como los permisos. El mensaje de respuesta de un error 404 proporciona información mínima, si es que proporciona alguna. Esto es intencional, ya que los errores 404 se muestran a los usuarios que tienen credenciales de inicio de sesión incorrectas o permisos insuficientes. Looker no quiere proporcionar información específica en los mensajes de respuesta 404, ya que esta información se podría usar para mapear la superficie de ataque de la API de Looker.

Si los intentos de inicio de sesión con la API devuelven errores 404, lo más probable es que tu ID de cliente de la API o tu secreto de cliente no sean válidos (consulta la sección Verificar las credenciales de la API de esta página). El endpoint REST de inicio de sesión de la API es el siguiente:

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

Si usas una API de generación de código de Swagger o un SDK de Looker, asegúrate de que el valor de base_url sea correcto:

  • En el caso de un cliente de generación de código Swagger, el base_url debe ser el siguiente:

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

  • En las implementaciones del SDK de Looker que usan un looker.ini, el valor de api_version debe ser 4.0 y el valor de base_url debe ser el mismo que la URL de la API de tu instancia de Looker en el formato https://<your-looker-hostname>:<port>. A continuación, se muestra un archivo looker.ini de ejemplo:

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

También puedes recibir un error 404 después de iniciar sesión. Si has iniciado sesión y recibes un error 404, significa que no tienes permisos para el comando de la API que acabas de llamar.

Errores Method Not Allowed (405)

Un error 405 Method Not Allowed indica que el servidor conoce el método de solicitud, pero que el recurso de destino no lo admite.

El servidor debe generar un campo de encabezado Allow en una respuesta con el código de estado 405. El campo debe contener una lista de métodos que admita el recurso de destino.

Por ejemplo, esto puede ocurrir en Looker si intentas usar el endpoint update_dashboard() para actualizar los metadatos de un panel de LookML. No se puede cambiar el parámetro id de un panel de LookML mediante la API de Looker, por lo que se produciría un error 405.

Errores de conflicto (409)

El código de estado de respuesta 409 Conflict indica que hay un conflicto entre una solicitud y el estado actual del recurso de destino.

Es más probable que se produzcan conflictos en respuesta a una solicitud PUT. Un ejemplo habitual de este error que no está relacionado con Looker se produce al subir un archivo que es anterior al que ya está en el servidor, lo que provoca un conflicto de control de versiones.

Puede que te encuentres con este error en Looker al intentar extraer una nueva rama de Git mediante la API o al usar endpoints como create_group() o create_dashboard(). En estos casos, comprueba si el objeto que intentas crear ya existe.

Errores de validación (422)

Los errores de validación se producen cuando algo de la solicitud no supera las comprobaciones de datos realizadas. La solicitud tiene uno o varios de los siguientes tipos de errores (la respuesta de error especificará los errores exactos):

  • Faltan campos: no se ha proporcionado un parámetro obligatorio (en la respuesta de error se indicará qué campo falta).
  • No válido: el valor proporcionado no coincide con ningún valor o no tiene el formato correcto. Por ejemplo, si intentas crear un Look y el ID de consulta que proporcionas en la llamada a la API no coincide con ninguna consulta, se producirá un error de validación.
  • Ya existe: la llamada a la API intenta crear un objeto con un ID o un nombre que ya está presente en tu instancia de Looker. Por ejemplo, los nombres de las conexiones de bases de datos deben ser únicos. Si intentas crear una conexión de base de datos con el nombre de una conexión que ya existe, recibirás un error de validación con el código already_exists.

Consulta el mensaje de respuesta de error para obtener información sobre los campos que faltan o que son obligatorios, o sobre los campos que tienen valores no válidos. El mensaje de respuesta proporcionará todos los errores de validación al mismo tiempo. Por lo tanto, si faltan campos y también hay campos incorrectos, la respuesta de error mostrará todos los problemas de la llamada a la API.

Aquí tienes un ejemplo de respuesta:

{
  "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/"
    }
  ],
    ...

En este caso, faltaba el campo obligatorio dialect en la llamada a la API y también se había proporcionado un valor no válido en el campo db_timezone.

Errores Too Many Requests (429)

El código de estado de respuesta 429 Too Many Requests indica que el usuario ha enviado demasiadas solicitudes en un periodo determinado ("limitación de la frecuencia"). Puedes consultar más información sobre las políticas de limitación de frecuencia de Looker en la publicación de la comunidad de Looker ¿Hay un límite en el número de solicitudes de API que se pueden enviar a la vez?

Errores de servidor internos (500)

El código de respuesta 500 Internal Server Error indica que el servidor ha detectado una condición inesperada que le ha impedido completar la solicitud.

Esta respuesta de error es una respuesta genérica de "captación de todos los errores". Por lo general, esto indica que el servidor no encuentra un código de error 5xx más específico para devolverlo como respuesta. Cualquier respuesta 500 de Looker es inesperada, por lo que, si ves este error de forma constante al intentar interactuar con Looker, te recomendamos que abras una solicitud de asistencia.