Voir les logs
Les logs vous aident à comprendre ce que fait un déploiement, qu'il s'agisse d'un build qui a échoué ou d'une instance en cours d'exécution qui génère des erreurs. Skysize affiche les logs par déploiement.
Ouvrir les logs d'un déploiement
- Ouvrez votre projet et accédez à l'onglet Déploiements.
- Trouvez le déploiement que vous souhaitez inspecter et cliquez sur Voir les logs (ou ouvrez le déploiement pour accéder à sa page de détail).
- Sur la page de détail du déploiement, ouvrez l'onglet Logs.
La sortie de build et d'installation est diffusée ici pendant l'exécution d'un déploiement, et les logs restent disponibles par la suite.
Choisir le log à lire
L'onglet Logs dispose d'un sélecteur Fichier de log. Utilisez-le pour basculer entre les logs disponibles pour le déploiement :
| Fichier de log | Contenu |
|---|---|
odoo.log | Activité d'exécution de l'instance : requêtes HTTP, erreurs, tâches cron, tracebacks |
install.log | Sortie de l'installation des modules qui a créé le déploiement |
update.log | Sortie de la mise à jour des modules exécutée à chaque nouveau déploiement d'un code existant |
tests.log | Sortie de l'exécution des tests, lorsque les tests sont activés pour la branche |
requirements.log | Sortie du pip install du requirements.txt de votre dépôt, si vous en avez un |
Quand un déploiement échoue
Un déploiement en échec affiche la raison en une phrase directement sur sa carte dans l'onglet Déploiements, à côté d'un lien Voir le journal. Le lien ouvre le log qui montre l'échec, déjà sélectionné : vous n'avez pas à le chercher parmi les fichiers de log.
La raison indique ce qui n'a pas fonctionné et, quand c'est possible, où :
| Ce que vous voyez | Que faire |
|---|---|
| Un paquet Python n'est pas installé | Ajoutez-le au requirements.txt à la racine de votre dépôt. Voir Installer des paquets Python |
Les paquets du requirements.txt n'ont pas pu être installés | Ouvrez requirements.log : pip indique quel paquet a échoué et pourquoi |
| Des modules dépendent de modules indisponibles | Ajoutez les modules manquants à votre dépôt, ou corrigez la liste depends du manifeste |
| Un fichier de données n'a pas pu être chargé | Corrigez le fichier XML ou CSV indiqué dans le message, à la ligne donnée |
| Votre code a levé une erreur | Ouvrez le fichier et la ligne indiqués dans le message. Le log contient la trace complète |
| La base de données a refusé une modification | En général une nouvelle contrainte ou un champ obligatoire que des enregistrements existants ne respectent pas |
| Des tests ont échoué | Ouvrez tests.log pour voir lesquels |
| Un sous-module ou le dépôt n'a pas pu être lu | Vérifiez la clé de déploiement et, pour les sous-modules privés, Sous-modules privés |
Quand l'échec ne correspond à aucune cause connue, le message indique quelle étape a échoué et le lien ouvre tout de même le bon log.
Le message ne contient que des noms de modules, des chemins de fichiers de votre dépôt, des numéros de ligne et des types d'erreur. Le contenu de vos données et des messages d'erreur reste dans les logs.
Une mise à jour en échec ne laisse jamais la production cassée : la version précédente est restaurée automatiquement, et la raison vous indique quoi corriger avant de redéployer.
Désactiver la raison de l'échec
La raison est affichée par défaut. Un administrateur du projet peut la masquer : ouvrez l'onglet Paramètres du projet et désactivez Raison de l'échec sur les builds. Les déploiements en échec n'affichent alors que leur statut, et les logs restent disponibles comme avant.
Filtrer et rafraîchir
- Date de début / Date de fin : restreindre la vue à une plage horaire spécifique. Cliquez sur Effacer les dates pour supprimer le filtre et revenir à la vue complète.
- Rafraîchir les logs : récupérer les dernières lignes. L'indicateur « Last updated at » indique la date du dernier rafraîchissement de la vue.
- Faites défiler vers le haut pour charger les lignes antérieures ; les nouvelles lignes continuent de se charger au fur et à mesure que le déploiement les produit.
Les logs de build et de déploiement sont stockés de manière durable, ils restent donc disponibles après la fin du déploiement, et même après sa suppression ultérieure.
Conseils pour lire les logs
- Recherchez les tracebacks. Les erreurs Python apparaissent sous forme de tracebacks multi-lignes se terminant par le type d'exception et le message. Recherchez
Tracebackpour y accéder rapidement. - Concentrez-vous sur la bonne sévérité. Odoo journalise aux niveaux
DEBUG,INFO,WARNING,ERRORetCRITICAL. Examinez d'abordERRORetCRITICAL. - Le déploiement a échoué ? Partez de la raison affichée sur le déploiement en échec et suivez son lien Voir le journal (voir Quand un déploiement échoue). Sinon, ouvrez l'onglet Logs du déploiement en échec et sélectionnez le log de build/installation. Les erreurs XML/de parsing de modules, les champs manquants et les migrations échouées y apparaissent.
- Erreur 500 à l'exécution ou vue cassée ? Sélectionnez le log du serveur Odoo et examinez les entrées autour du moment de l'erreur.
- Un module échoue sur une bibliothèque Python manquante ? Sélectionnez
requirements.log. Il indique si pip a installé vos dépendances et, sinon, pourquoi. Voir Installer des paquets Python. - Une tâche cron / action planifiée se comporte mal ? Ses erreurs sont journalisées dans le log du serveur au niveau
ERROR.