En esta página, se muestran procedimientos de solución de problemas para los siguientes problemas que puedes encontrar en la API de Looker:
- No se puede acceder al extremo de la API
- El resultado de la API es un texto sin sentido
- Las llamadas a la API no responden
- Errores de codificación no válidos
- Errores del método no encontrado
- Errores de solicitud incorrecta (400)
- Errores prohibidos (403)
- Errores no encontrados (404)
- Errores del método no permitido (405)
- Errores (409) en conflicto
- Errores de validación (422)
- Demasiadas solicitudes (429) errores
- Errores de servidor interno (500)
No se puede acceder extremo de API
Si no puedes acceder a un extremo de API, haz lo siguiente:
- Verifica tus credenciales de API
- Verifique la URL del host de la API
- Verifica el puerto de la API
- Verifique la URL de llamada a la API
Verifica tus credenciales de API
Si no se puede acceder extremo de API de Looker, primero verifica que las credenciales de la API sean correctas. Para ver tus credenciales de API, sigue estos pasos:
- En Looker, selecciona la opción Administrador en el panel de navegación izquierdo para acceder al panel Administrador.
- En el panel izquierdo de la página Administrador, desplácese hacia abajo y haga clic en Usuarios.
- Busca tu nombre de usuario en la lista de usuarios y haz clic en él para editar la página.
- Haz clic en Editar claves de API. Puedes ver el ID de cliente y puedes hacer clic en el ícono del ojo para ver el Secreto del cliente de cada clave de API que configuraste. Verifica que tus credenciales de API coincidan con las credenciales que usas en tu secuencia de comandos.
Verifica la URL de la API
Otro problema común para llegar a un extremo de API es una URL de host de API incorrecta. La mayoría de las instancias de Looker usan la URL predeterminada para la API. Sin embargo, es posible que las instalaciones de Looker que usen una ruta de API alternativa o las instalaciones de Looker ubicadas detrás de un balanceador de cargas (por ejemplo, una configuración de clúster) o cualquier otro proxy no usen la URL predeterminada. Si este es el caso, la URL del host de la API debe indicar el puerto y el nombre del host de la API que se muestra al usuario.
Los administradores de Looker pueden ver la URL del host de la API en la configuración del administrador de la API (que se describe con más detalle en la página de documentación Configuración del administrador: API). Para ver la URL del host de la API, haz lo siguiente:
- Para acceder al panel Administrador, selecciona la opción Administrador en el panel de navegación izquierdo.
- Haga clic en API en el panel Administrador.
Consulta la URL del host de la API.
Si el campo URL del host de la API está en blanco, tu instancia de Looker usa 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:
- Abre un navegador y, luego, abre la consola. (Este artículo de ConcreteCMS.org puede resultarte útil si necesitas saber cómo abrir una consola en tu navegador).
Ingresa la URL de host de la API seguida de
/alive
. Por ejemplo, si la URL del host de la API eshttps://company.cloud.looker.com
, ingresa lo siguiente:https://company.cloud.looker.com/alive
Si el campo URL del host de la API está en blanco, utiliza la URL predeterminada de la API. Por ejemplo, para las instancias alojadas en Google Cloud, Microsoft Azure y en los servicios web de Amazon (AWS) que se crearon el 7 de julio de 2020 o después de esa fecha, la ruta predeterminada de la API de Looker usa el puerto
443
:https://<instance_name>.cloud.looker.com:443/alive
Para las instancias alojadas en AWS que se crearon antes del 7 de julio de 2020, la ruta predeterminada de la API de Looker usa el puerto 19999:
https://<instance_name>.cloud.looker.com:19999/alive
Si la URL del host de la API es correcta, se mostrará una página web en blanco, no una página de error.
También puedes verificar que llegaste a la API observando la respuesta de red en la consola del navegador. La respuesta de la red debe ser 200
.
Si estas verificaciones fallan, el problema puede ser que la llamada a la API sea incorrecta o que haya otros errores en tu código. Verifica tus llamadas a la API y el código en tu secuencia de comandos. Si la información es correcta, consulta la siguiente sección para verificar tu puerto.
Verifica el puerto de la API
Si las verificaciones anteriores fallan y tienes una implementación de Looker alojada por el cliente, es posible que el puerto de la API deba estar abierto en la infraestructura de red.
El puerto de la API debe reenviar al servidor de Looker. Para las implementaciones de Looker alojadas por el cliente, pídele a tu administrador de red que verifique 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 (de forma predeterminada, 9999
). Tu administrador de red debe verificar que la configuración es la misma para el puerto de la API y para el puerto de la instancia de Looker:
- Proxies
- Balanceadores de cargas
- Firewalls
Verifica la URL de llamada a la API
Verifica que estés usando la URL correcta para la llamada a la API. El formato de la URL de extremo de API es el siguiente:
<API Host URL>/api/<API version>/<API call>
Si usas la URL del host de la API predeterminada, el formato de la URL de extremo de API es el siguiente:
https://<instance_name>:<port>/api/<API version>/<API call>
Puedes obtener el formato de URL para los extremos de la API en el Explorador de API, en el Portal para desarrolladores de Looker o en la documentación de Referencia de la API.
Por ejemplo, la referencia de la API 4.0 proporciona la siguiente ruta relativa para el extremo Get All Running Queries:
/api/4.0/running_queries
Por lo tanto, la URL completa del extremo de API para el extremo Get All Running Queries en 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 texto sin sentido
Si la API muestra una respuesta de texto ilegible, es probable que estés viendo el contenido binario de un archivo PDF, PNG o JPG. Algunas bibliotecas REST de HTTP suponen que las respuestas de la API son archivos de texto, por lo que se muestran otros tipos de archivos como texto binario.
En este caso, debes asegurarte de que tu biblioteca de REST de HTTP maneje la respuesta de la API como datos binarios, no como texto. En algunos casos, esto puede implicar configurar una marca en la llamada a la API para indicarle a la biblioteca de REST de HTTP que es un resultado binario, o bien controlar el resultado de una manera especial, como una transmisión de bytes o un array de bytes, en lugar de asignar el resultado a una variable de string.
Las llamadas a la API no responden
Si puedes abrir el Explorador de API, pero tus llamadas a la API no responden, verifica que la URL del host de la API de tu instancia de Looker esté configurada correctamente. Los administradores de Looker pueden ver la URL del host de la API en la configuración de administrador de la API de Looker (que se describe en la página de documentación Configuración del administrador: API).
Errores de codificación no válidos
Si recibes un error de codificación cuando intentas realizar una llamada a la API, es posible que debas configurar 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 su totalidad, el encabezado Content-Type
debe establecerse en application/json
.
Ten en cuenta que usar un SDK de Looker automáticamente se encargará de esta preocupación.
Errores de métodos no encontrados
Si recibes un error de método no encontrado, como method not found: all_looks()
, lo primero que debes verificar es la versión de la API. Hay varias llamadas a la API que son nuevas en la API 4.0 o que se quitaron en la API 4.0. Consulte el anuncio de la API de Looker 4.0 disponible para el público general a fin de obtener la lista de actualizaciones.
Errores de solicitud incorrecta (400)
Un error 400 Bad Request
indica que los datos proporcionados en una llamada a la API son irreconocibles. La causa suele ser un archivo JSON no válido o no válido, quizás un error de análisis. En general, los errores 400 ya pasaron la autenticación, por lo que el mensaje de respuesta de error proporcionará información más específica sobre el error.
Errores prohibidos (403)
La API de Looker no muestra errores 403 cada vez que un usuario intenta acceder a un objeto LookML o a otro contenido para el que no tenga permiso. Mostrar un error 403 en lugar de un error 404 puede, en algunos casos, verificar la existencia de un objeto Explore, panel o LookML en particular cuando el propietario puede preferir que se desconozca. Para evitarlo, Looker muestra un error 404 en estos casos y el error adjunto en la IU de Looker indica “No se pudo encontrar la página que solicitaste. Es posible que no exista o que no tengas permiso para verla".
Según el entorno en el que esté alojada la instancia de Looker y la configuración de tu instancia de Looker, el número de puerto y la URL asociada a la que se puede acceder a la API pueden ser diferentes. Cuando uses un número de puerto incorrecto, es posible que veas un error 403. Por ejemplo, si tu instancia de Looker está configurada con el puerto de API predeterminado 443
, la conexión a https://mycompany.looker.com/api/4.0/login
, en lugar de https://mycompany.looker.com:443/api/4.0/login
, mostrará un error 403. Para las instancias alojadas por el cliente, puedes obtener más información sobre las opciones de inicio de Looker donde puedes definir el puerto de la API.
Esto también puede ocurrir cuando usas una versión desactualizada de la gema del SDK de Ruby. Asegúrate de mantener las gemas actualizadas. Puedes consultarlo en https://rubygems.org/gems/looker-sdk
.
Esto también puede ocurrir si no incluyes 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 no encontrados (404)
Un error 404 Not Found
es el error predeterminado si algo sale mal, por lo general, con permisos, por ejemplo. El mensaje de respuesta para un error 404 proporciona información mínima, si la hubiera. Esto es intencional, ya que los errores 404 se muestran a personas con credenciales de acceso incorrectas o permisos insuficientes. Looker no desea proporcionar información específica en los mensajes de respuesta 404, ya que esta información podría usarse para asignar la "superficie de ataque" de la API de Looker.
Si los intentos de acceso a la API muestran errores 404, lo más probable es que el secreto de cliente o el ID de cliente de la API no sean válidos (consulte Verifica tus credenciales de la API en esta página). Según la versión de API en uso, el extremo de REST de acceso a la API es uno de los siguientes:
https://<your-looker-hostname>:<port>/api/4.0/login
https://<your-looker-hostname>:<port>/api/3.1/login
Si usas una API de Swagger codegen o un SDK de Looker, asegúrate de que tu valor de base_url
sea correcto:
- Para un cliente de codegen de Swagger, el
base_url
debe ser uno de los siguientes, según la versión de la API en uso:https://<your-looker-hostname>:<port>/api/4.0/
https://<your-looker-hostname>:<port>/api/3.1/
Para las implementaciones del SDK de Looker que usan
looker.ini
, el valor deapi_version
debe ser4.0
o3.1
, y el valor debase_url
debe ser el mismo que la URL de la API de tu instancia de Looker en el formatohttps://<your-looker-hostname>:<port>
. A continuación, se muestra un archivolooker.ini
de ejemplo:# api_version should be either 4.0 or 3.1 api_version=4.0 base_url=https://<your-looker-hostname>:<port>
También puedes obtener un error 404 después de acceder. Si accedió y obtiene un error 404, significa que no tiene permisos para el comando de la API que acaba de llamar.
Errores de métodos no permitidos (405)
Un error 405 Method Not Allowed
indica que el servidor conoce el método de solicitud, pero el recurso de destino no admite este método.
El servidor debe generar un campo de encabezado Allow
en una respuesta de código de estado 405. El campo debe contener una lista de métodos que el recurso de destino admite actualmente.
Por ejemplo, una forma de encontrar esto en Looker sería si intentas usar el extremo update_dashboard()
para actualizar los metadatos de un panel de LookML. La API de Looker no admite cambiar el parámetro id
de un panel de LookML, por lo que se produciría un error 405.
Errores de conflicto (409)
El código de estado de respuesta 409 Conflict
indica un conflicto de solicitud con el estado actual del recurso de destino.
Lo más probable es que haya conflictos en respuesta a una solicitud PUT. Un ejemplo común de este error que no es de Looker se produce cuando se sube un archivo más antiguo que el existente en el servidor, lo que genera un conflicto de control de versión.
Es posible que encuentres este error en Looker cuando intentes verificar una rama de Git nueva con la API o cuando uses extremos como create_group()
o create_dashboard()
. En estos casos, verifica si el objeto que intentas crear ya existe.
Errores de validación (422)
Los errores de validación ocurren cuando algo en la solicitud no pasa las verificaciones de datos realizadas. La solicitud tiene uno o más de los siguientes tipos de errores (la respuesta de error especifica los errores exactos):
- Faltan campos: Hay un parámetro obligatorio que no se proporcionó (la respuesta de error indicará qué campo falta).
- No válido: El valor proporcionado no coincide con un valor existente o no tiene el formato correcto. Por ejemplo, si intentas crear una apariencia y el ID de consulta que proporcionas en la llamada a la API no coincide con una consulta existente, se mostrará un error de validación.
- Ya existe: La llamada a la API está intentando crear un objeto con un ID o un nombre que ya está presente en tu instancia de Looker. Por ejemplo, los nombres de conexión de la base de datos deben ser únicos. Si intentas crear una conexión de base de datos nueva que usa el nombre de una conexión existente, verás un error de validación con el código
already_exists
.
Consulta el mensaje de respuesta de error para obtener detalles sobre los campos que pueden faltar o ser obligatorios, o sobre qué campos pueden tener 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 campos incorrectos, la respuesta de error mostrará todos los problemas con las llamadas a la API.
Esta es una respuesta de ejemplo:
{
"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, a la llamada a la API le faltaba el campo dialect
obligatorio y también se proporcionaba un valor no válido en el db_timezone
.
Demasiadas solicitudes (429)
El código de estado de respuesta 429 Too Many Requests
indica que el usuario envió demasiadas solicitudes en un período determinado ("límite de frecuencia"). Puedes obtener más información sobre las políticas de límite de frecuencia de Looker en la publicación de Comunidad de Looker ¿Hay un límite en la cantidad de solicitudes a la API que puedes enviar a la vez?
Errores internos del servidor (500)
El código de respuesta 500 Internal Server Error
indica que el servidor encontró una condición inesperada que impidió que se completara la solicitud.
Esta respuesta de error es una respuesta genérica genérica. Por lo general, esto indica que el servidor no puede encontrar un código de error 5xx más específico para mostrar en respuesta. Cualquier respuesta 500 de Looker es inesperada, por lo que, si ves este error constantemente mientras intentas interactuar con Looker, te recomendamos que te comuniques con el equipo de asistencia de Looker.