Ver logs
Los logs te ayudan a entender qué está haciendo un despliegue, ya sea un build que falló o una instancia en ejecución que arroja errores. Skysize muestra los logs por despliegue.
Abrir los logs de un despliegue
- Abre tu proyecto y ve a la pestaña Despliegues.
- Busca el despliegue que quieres inspeccionar y haz clic en Ver logs (o abre el despliegue para llegar a su página de detalle).
- En la página de detalle del despliegue, abre la pestaña Logs.
La salida del build y de la instalación se transmite aquí mientras un despliegue está en ejecución, y los logs siguen disponibles después.
Elegir qué log leer
La pestaña Logs tiene un selector de Archivo de log. Úsalo para cambiar entre los logs disponibles para el despliegue:
| Archivo de log | Qué contiene |
|---|---|
odoo.log | Actividad en tiempo de ejecución de la instancia: solicitudes HTTP, errores, trabajos cron, trazas |
install.log | Salida de la instalación de módulos que creó el despliegue |
update.log | Salida de la actualización de módulos que se ejecuta en cada nuevo despliegue de código existente |
tests.log | Salida de la ejecución de tests, cuando los tests están activados para la rama |
requirements.log | Salida del pip install del requirements.txt de tu repositorio, si tienes uno |
Cuando un despliegue falla
Un despliegue fallido muestra el motivo en una frase directamente en su tarjeta en la pestaña Despliegues, junto a un enlace Ver el registro. El enlace abre el log que muestra el fallo, ya seleccionado, así que no tienes que buscarlo entre los archivos de log.
El motivo indica qué salió mal y, cuando es posible, dónde:
| Lo que ves | Qué hacer |
|---|---|
| Un paquete de Python no está instalado | Añádelo al requirements.txt en la raíz de tu repositorio. Consulta Instalar paquetes de Python |
No se pudieron instalar los paquetes del requirements.txt | Abre requirements.log: pip indica qué paquete falló y por qué |
| Hay módulos que dependen de módulos no disponibles | Añade los módulos que faltan a tu repositorio, o corrige la lista depends del manifiesto |
| No se pudo cargar un archivo de datos | Corrige el archivo XML o CSV indicado en el mensaje, en la línea señalada |
| Tu código produjo un error | Abre el archivo y la línea indicados en el mensaje. El log tiene la traza completa |
| La base de datos rechazó un cambio | Suele ser una restricción nueva o un campo obligatorio que los registros existentes no cumplen |
| Fallaron pruebas | Abre tests.log para ver cuáles |
| No se pudo leer un submódulo o el repositorio | Revisa la clave de despliegue y, para submódulos privados, Submódulos privados |
Cuando el fallo no coincide con ninguna causa conocida, el mensaje indica qué paso falló y el enlace abre igualmente el log correcto.
El mensaje solo contiene nombres de módulos, rutas de archivos de tu repositorio, números de línea y tipos de error. El contenido de tus datos y de los mensajes de error se queda en los logs.
Una actualización fallida nunca deja producción rota: la versión anterior se restaura automáticamente, y el motivo te indica qué corregir antes de volver a desplegar.
Desactivar el motivo del fallo
El motivo se muestra de forma predeterminada. Un administrador del proyecto puede ocultarlo: abre la pestaña Configuración del proyecto y desactiva Motivo del fallo en los builds. Los despliegues fallidos solo muestran entonces su estado, y los logs siguen disponibles como antes.
Filtrar y actualizar
- Fecha de inicio / Fecha de fin: acota la vista a un rango de tiempo específico. Haz clic en Limpiar fechas para quitar el filtro y volver a la vista completa.
- Actualizar logs: obtén las líneas más recientes. El indicador "Última actualización" muestra cuándo se actualizó la vista por última vez.
- Desplázate hacia arriba para cargar líneas anteriores; las líneas más nuevas se siguen cargando a medida que el despliegue las produce.
Los logs de build y de despliegue se almacenan de forma duradera, por lo que siguen disponibles después de que el despliegue haya terminado, e incluso después de que se elimine más adelante.
Consejos para leer logs
- Busca trazas (tracebacks). Los errores de Python aparecen como trazas de varias líneas que terminan con el tipo de excepción y el mensaje. Busca
Tracebackpara saltar a ellas. - Enfócate en la severidad correcta. Odoo registra en
DEBUG,INFO,WARNING,ERRORyCRITICAL. Revisa primeroERRORyCRITICAL. - ¿Falló el despliegue? Parte del motivo que aparece en el despliegue fallido y sigue su enlace Ver el registro (consulta Cuando un despliegue falla). Si no, abre la pestaña Logs del despliegue fallido y selecciona el log de build/instalación. Los errores de XML/análisis de módulos, los campos faltantes y las migraciones fallidas aparecen allí.
- ¿Error 500 en tiempo de ejecución o vista rota? Selecciona el log del servidor Odoo y revisa las entradas alrededor del momento del error.
- ¿Un módulo falla por una biblioteca de Python que falta? Selecciona
requirements.log. Muestra si pip instaló tus dependencias y, si no, por qué. Consulta Instalar paquetes de Python. - ¿Una acción cron / programada se comporta mal? Sus errores se registran en el log del servidor con el nivel
ERROR.