Journalisation dans les applications JavaScript : meilleures pratiques sur Node.js

Journalisation dans les applications JavaScript : meilleures pratiques en pratique

La journalisation ne se limite pas à écrire des messages dans la console. Dans un environnement de production, une journalisation bien configurée devient l'outil principal de surveillance, de débogage et d'audit. Sans elle, vous travaillez à l'aveugle. Dans cet article, nous allons analyser les meilleures pratiques de journalisation pour les applications JavaScript sur Node.js, du choix de la bibliothèque à la configuration de la rotation des fichiers. Tous les exemples de code sont prêts à l'emploi.

1. Pourquoi console.log est-il mauvais ?

En phase de développement, nous utilisons tous console.log. C'est rapide et pratique. Mais en production, cette approche est dangereuse :

• Pas de niveaux de journalisation. Vous ne pourrez pas filtrer les erreurs des messages d'information.
• Blocage synchrone. Le console.log standard peut ralentir l'application en cas de flux important de requêtes.
• Absence de structure. Les logs JSON ne peuvent pas être analysés sans bricolages supplémentaires.
• Pas de rotation. Le fichier de log grossira indéfiniment jusqu'à remplir le disque.

Utilisez plutôt des bibliothèques professionnelles. Les deux plus populaires dans Node.js sont Winston et Pino.

2. Choix de la bibliothèque : Winston vs Pino

Les deux bibliothèques résolvent le même problème, mais avec des priorités différentes.

Winston — universel et flexible

Winston est le « couteau suisse » de la journalisation. Il prend en charge de nombreux transports (fichiers, console, HTTP, bases de données) et se configure facilement.

const winston = require('winston');

const logger = winston.createLogger({  level: 'info',  format: winston.format.json(),  transports: [    new winston.transports.File({ filename: 'error.log', level: 'error' }),    new winston.transports.File({ filename: 'combined.log' }),  ],});

// En développement, on ajoute la sortie consoleif (process.env.NODE_ENV !== 'production') {  logger.add(new winston.transports.Console({    format: winston.format.simple(),  }));}

logger.info('Serveur démarré sur le port 3000');logger.error('Erreur de connexion à la base de données', { db: 'postgres' });

Pino — la vitesse avant tout

Pino se positionne comme le logger le plus rapide pour Node.js. Il est 5 à 6 fois plus rapide que Winston grâce à l'utilisation de sonic-boom (écriture asynchrone). Idéal pour les projets à forte charge.

const pino = require('pino');

const logger = pino({  level: process.env.LOG_LEVEL || 'info',  transport: {    target: 'pino/file',    options: { destination: './app.log' },  },});

logger.info({ user: 'admin' }, 'Utilisateur connecté');logger.error({ err: new Error('Timeout') }, 'La requête a dépassé la limite');

Conseil : Pour les microservices et les API à forte charge, choisissez Pino. Pour les configurations complexes avec plusieurs transports, choisissez Winston.

3. Niveaux de journalisation : n'écrivez pas tout dans info

Utilisez l'échelle standard des niveaux (par ordre croissant d'importance) :

• trace / debug — uniquement pour le développement. Débogage détaillé.
• info — fonctionnement normal de l'application : démarrage, requêtes réussies, événements métier.
• warn — problèmes potentiels : requêtes lentes, manque de mémoire, méthodes obsolètes.
• error — exceptions, pannes, plantages. Doivent toujours être dans un fichier séparé ou un système de surveillance.
• fatal — erreurs critiques après lesquelles l'application ne peut pas continuer à fonctionner.

Configurez la variable d'environnement LOG_LEVEL pour changer le niveau de filtrage sans redémarrer le code :

// Exemple avec Winstonconst logger = winston.createLogger({  level: process.env.LOG_LEVEL || 'info',  // ...});

// En