Lire les journaux de son application

Bots et applicatif · 4 min de lecture · Mis à jour le 16 octobre 2026

Quand une application ne démarre pas ou s'arrête sans prévenir, la réponse est presque toujours dans ses journaux. Ce guide montre où les lire selon votre service, comment les interpréter et comment écrire des messages qui vous aideront le jour où quelque chose casse.

Où sont les journaux ?

Sur l'hébergement applicatif

Tout se passe dans votre espace client : il n'y a pas d'autre interface à ouvrir.

Un déploiement a échoué

Un déploiement passe par deux étapes : la construction (installation des dépendances, compilation) puis le démarrage. Quand la construction échoue, l'encadré « Pourquoi ça a échoué » résume la cause sur la fiche de l'application. Les causes les plus courantes :

• fichier de dépendances absent ou invalide (package-lock.json désynchronisé, requirements.txt avec une version introuvable) ;
• commande de build en erreur (npm run build qui échoue en local aussi) ;
• branche ou adresse du dépôt erronée, dépôt privé non partagé.

L'application tourne mal

Cliquez sur « Journaux » : vous voyez ce que votre programme écrit sur sa sortie standard et sa sortie d'erreur. Si l'application plante, elle est relancée automatiquement ; les journaux montrent alors une succession de démarrages, et la dernière erreur avant chaque redémarrage est celle qui compte.

Si l'application ne répond plus du tout, essayez dans l'ordre : « Redémarrer », puis « Redéployer », puis « Reconstruire à neuf » (reconstruction sans le cache).

Sur un VPS

Un service systemd

journalctl -u mon-app -f          # suivre en direct (Ctrl+C pour quitter)
journalctl -u mon-app -n 100      # les 100 dernières lignes
journalctl -u mon-app --since "1 hour ago"
journalctl -u mon-app -p err      # seulement les erreurs
systemctl status mon-app          # état, code de sortie, dernières lignes

systemctl status indique si le service est relancé en boucle (activating (auto-restart)) et avec quel code il s'est arrêté. Un code 1 signale une erreur prévue par le programme ; status=9/KILL ou oom-kill signale un processus tué, souvent faute de mémoire.

Les guides discord.js et Python ont été vérifiés sur des VPS Debian 13 : un jeton invalide y apparaît clairement dans journalctl -u mon-bot, suivi des relances toutes les 5 secondes.

Mémoire insuffisante

journalctl -k | grep -i -E "out of memory|oom"
free -h

Un conteneur Docker

docker logs --tail 100 -f nom-du-conteneur
docker compose logs -f

Limitez la taille des journaux Docker, sinon ils remplissent le disque à la longue (voir Installer Docker sur un VPS KVM).

Garder les journaux systemd après un redémarrage

Sur Debian, le journal est conservé sur disque si le dossier /var/log/journal existe. Limitez sa taille :

mkdir -p /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/taille.conf <<'EOF'
[Journal]
SystemMaxUse=500M
EOF
systemctl restart systemd-journald
journalctl --disk-usage

Sur un serveur de jeu

L'onglet Console du panel de jeu affiche la sortie du serveur en direct. Les journaux plus anciens sont dans les fichiers : pour Minecraft, logs/latest.log et les archives logs/AAAA-MM-JJ-N.log.gz ; les rapports de plantage dans crash-reports/. Copiez les lignes autour de l'erreur, pas seulement la dernière.

Lire une erreur

• Remontez à la première erreur. Une erreur en entraîne souvent d'autres : la première ligne en ERROR ou Traceback est généralement la cause, les suivantes les conséquences.
• Lisez la pile d'appels de bas en haut en Python (la dernière ligne donne le type d'erreur), de haut en bas en Node.js (la première ligne donne le message).
• Cherchez vos propres fichiers dans la pile : la ligne de votre code la plus proche de l'erreur est l'endroit à corriger.
• Notez l'heure. Pour un ticket, l'heure exacte de l'incident nous fait gagner beaucoup de temps.

Écrire des journaux utiles

• Écrivez sur la sortie standard (console.log, print, module logging) : c'est ce que l'hébergement applicatif et systemd collectent. Un fichier de log écrit dans le dossier de l'application peut disparaître au redéploiement.
• En Python, réglez PYTHONUNBUFFERED=1 : sans lui, les messages arrivent par paquets, parfois après le plantage.
• Donnez un niveau à chaque message (info, avertissement, erreur) et réglez le niveau par une variable d'environnement (LOG_LEVEL=info).
• Journalisez le démarrage (version, port, connexion réussie) : c'est la première chose qu'on cherche.
• N'écrivez jamais de secret : ni jeton, ni mot de passe, ni process.env complet. Ce qui est journalisé finit dans des captures d'écran et des tickets.

import logging, os
logging.basicConfig(
    level=os.environ.get("LOG_LEVEL", "INFO"),
    format="%(asctime)s %(levelname)s %(name)s : %(message)s",
)
log = logging.getLogger("mon-app")
log.info("Démarrage, port %s", os.environ.get("PORT", "8000"))

Besoin d'aide ?

Ouvrez un ticket depuis votre espace client en joignant l'extrait des journaux autour de l'erreur (une trentaine de lignes), l'heure et le nom du service. Relisez l'extrait avant de l'envoyer : aucun secret ne doit y figurer.