Lire les logs d'une application Node.js

Sur un VPS, vous lisez les journaux avec journalctl. Sur l'hébergement d'applications, vous n'avez ni root ni accès systemd : la console du panneau affiche ce que le processus écrit sur stdout et stderr. Savoir lire ce flux permet de distinguer une erreur de code, une dépendance manquante et une simple boucle de redémarrage.

Où se trouvent les logs

La fiche du service contient un onglet de console ou de journaux. Il reçoit la sortie standard et la sortie d'erreur du processus, dans l'ordre d'émission. Cette vue est temporaire : elle représente l'exécution en cours et les messages les plus récents, pas une archive complète. Pour conserver un historique, écrivez aussi dans un fichier du projet, en surveillant l'espace disque, ou exportez régulièrement.

stdout, stderr et niveaux

console.log écrit sur stdout ; console.warn, console.error et les erreurs non capturées vont sur stderr. Les deux arrivent dans la console, souvent sans distinction visuelle. Un journal structuré en JSON reste lisible par une machine et par vous :

const level = process.env.LOG_LEVEL || 'info';
console.log(JSON.stringify({ level, msg: 'server started', port: process.env.PORT }));

Choisissez un niveau par environnement : info en production, debug ponctuellement. Les bibliothèques comme pino ou winston gèrent les niveaux et le formatage, mais une fonction maison suffit pour une petite application. Ne journalisez jamais un jeton, un mot de passe, un cookie ou une chaîne de connexion complète. Si vous loggez les en-têtes, masquez Authorization et Cookie.

Reconnaître une boucle de redémarrage

Une boucle se voit à la répétition du même bloc toutes les quelques secondes : bannière de démarrage, puis sortie, puis retour. Cherchez la première erreur après le démarrage, pas la dernière ligne, souvent un simple message d'arrêt.

• Cannot find module : dépendance absente ou MAIN_FILE incorrect.
• SyntaxError : fichier non compilé ou mauvaise version de Node.
• ECONNREFUSED vers la base : hôte, port ou identifiants erronés.
• Code de sortie 137 : processus tué, souvent par manque de mémoire.
• Code 143 : arrêt demandé par la plateforme (SIGTERM).

Un code 137 mérite une vérification de la mémoire : un cache qui grandit ou une fuite finit par déclencher ce comportement même si le code semble correct.

Journaliser utilement

• Une ligne par requête avec méthode, chemin, statut et durée, sans le corps.
• Une trace complète pour les erreurs, pas seulement error.
• Un identifiant de requête pour relier plusieurs lignes.
• Pas de message périodique « toujours vivant » qui noie les incidents.
• Un plafond de taille si vous écrivez dans un fichier.

Vérifier

Redémarrez, confirmez qu'un seul bloc de démarrage apparaît, appelez la route de santé, puis provoquez un 404 géré : vous devez voir une ligne de requête et aucun redémarrage. Si la console reste vide, vérifiez que votre logger n'avale pas la sortie et que le processus atteint bien son point d'entrée.