Journalisation dans les applications PHP : meilleures pratiques en pratique
La journalisation ne consiste pas simplement à enregistrer des erreurs dans un fichier. C'est un outil stratégique de surveillance, de débogage et d'audit du fonctionnement de l'application. Dans cet article, nous allons voir comment organiser la journalisation en PHP dans la pratique, en utilisant des approches et des bibliothèques modernes. Vous apprendrez à éviter les erreurs typiques et à rendre les journaux vraiment utiles.
1. Choix de la bibliothèque et standard PSR-3
Dans la communauté PHP moderne, le standard de facto est l'interface PSR-3 (Logger Interface). Elle définit un ensemble unifié de méthodes de journalisation, ce qui permet de changer facilement de bibliothèque de journalisation sans réécrire le code de l'application.
L'implémentation la plus populaire de PSR-3 est la bibliothèque Monolog. Elle est flexible, performante et dispose de nombreux "gestionnaires" (handlers) pour envoyer les journaux vers des fichiers, des bases de données, Slack, Telegram, Email et des services cloud.
Installation de Monolog via Composer :
composer require monolog/monologExemple d'utilisation de base :
<?phprequire 'vendor/autoload.php';
use Monolog\\Logger;use Monolog\\Handler\\StreamHandler;
// Créer un canal (channel) de logs — généralement par nom d'application ou de module$log = new Logger('my_app');// Ajouter un gestionnaire : écrire les logs de niveau WARNING et supérieur dans un fichier$log->pushHandler(new StreamHandler(__DIR__ . '/logs/app.log', Logger::WARNING));
// Maintenant, on peut journaliser$log->warning('L\\'utilisateur {username} a tenté de se connecter avec un mot de passe incorrect', ['username' => 'ivan']);$log->error('Impossible de se connecter à la base de données : {error}', ['error' => $e->getMessage()]);?>Pourquoi est-ce important ? L'utilisation de PSR-3 rend votre code indépendant de la bibliothèque spécifique. Si demain vous souhaitez passer de Monolog à une autre implémentation (par exemple, Log4php), vous n'aurez à modifier que l'initialisation du logger, et non tous les endroits où $log->error() est appelé.
2. Niveaux de journalisation : quand utiliser quoi
PSR-3 définit 8 niveaux de journalisation (du moins prioritaire au plus élevé) : DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. L'utilisation correcte des niveaux est la base de journaux lisibles et utiles.
- DEBUG — informations de débogage détaillées, nécessaires uniquement au développeur (valeurs des variables, trace des appels). Activez uniquement sur l'environnement de développement.
- INFO — événements importants du fonctionnement de l'application : un utilisateur s'est inscrit, une commande a été créée, une tâche cron a été exécutée.
- NOTICE — événements normaux mais significatifs (par exemple, utilisation d'une API obsolète).
- WARNING — problèmes potentiels qui n'ont pas arrêté l'exécution du script (tentative de connexion échouée, requête lente à la base de données).
- ERROR — erreurs nécessitant une intervention : exceptions, défaillances de services externes.
- CRITICAL — pannes critiques : perte de connexion à la base de données, manque de mémoire.
- ALERT — une action immédiate de l'administrateur est requise (site inaccessible).
- EMERGENCY — l'ensemble du système est inutilisable.
Conseil pratique : Configurez différents gestionnaires pour différents niveaux. Par exemple, écrivez WARNING et supérieur dans un fichier, et ERROR et supérieur envoyez-les également dans Telegram/Slack.
// Exemple : deux gestionnaires pour un même logger$log->pushHandler(new StreamHandler(__DIR__ . '/logs/all.log', Logger::DEBUG));$log->pushHandler(new StreamHandler(__DIR__ . '/logs/errors.log', Logger::ERROR));// Pour les erreurs critiques — envoi dans Telegram$log->pushHandler(new TelegramBotHandler('TOKEN', 'CHAT_ID', Logger::CRITICAL));3. Journaux structurés et contexte
L'une des sa