Explications des niveaux de log¶

Les niveaux de log de Monolog suivent la norme PSR-3. Cette norme définit des niveaux de gravité pour les messages de log, allant des plus critiques (pannes système) aux plus informatifs (messages de débogage).

Voici les niveaux de log Monolog, du plus critique au moins important.

🔥 1. EMERGENCY (100)¶

Signification : Panne critique du système nécessitant une action immédiate.
Quand l'utiliser ? : Quand l'application ne peut plus fonctionner (par exemple, une base de données non accessible ou une panne critique).
Exemple d'usage :

$logger->emergency('La base de données principale est inaccessible !');

Contexte d'utilisation :
- Crash complet de l'application. - Panne système majeure (base de données inaccessible, serveur en panne, etc.). - Problème de sécurité critique.

🔥 2. ALERT (200)¶

Signification : Problème sérieux qui doit être traité immédiatement.
Quand l'utiliser ? : Problème sérieux qui demande une intervention immédiate mais ne provoque pas l'arrêt de l'application.
Exemple d'usage :

$logger->alert('Le service de paiement ne répond pas, tentative de basculement sur le service de secours.');

Contexte d'utilisation :
- Erreur d'un service critique (exemple : service de paiement indisponible).
- Problèmes de sécurité (comme une attaque détectée).
- Déclenchement d'un processus d'alerte (email, notification d'incident, etc.).

🔥 3. CRITICAL (300)¶

Signification : Erreur critique qui nécessite une intervention immédiate.
Quand l'utiliser ? : Erreurs non fatales, mais qui peuvent gravement affecter l'application.
Exemple d'usage :

$logger->critical('La table des utilisateurs est corrompue, intervention requise.');

Contexte d'utilisation :
- Pannes critiques de l'application, mais l'application continue de fonctionner.
- Échec de transactions critiques (paiements, envoi d'emails importants, etc.).
- Échec des dépendances critiques (API distante inaccessible).

🔥 4. ERROR (400)¶

Signification : Erreur d'exécution qui empêche le traitement d'une action.
Quand l'utiliser ? : Quand l'application ne peut pas effectuer une opération.
Exemple d'usage :

$logger->error('Impossible de se connecter au serveur SMTP pour l'envoi des emails.');

Contexte d'utilisation :
- Exceptions non fatales (qui ne font pas planter l'application).
- Échec de requêtes SQL ou de requêtes API.
- Violation des règles métier (exemple : tentative d'achat avec solde insuffisant).

🔥 5. WARNING (500)¶

Signification : Problème non bloquant mais qui doit être surveillé.
Quand l'utiliser ? : Quand une anomalie potentielle est détectée, mais l'application peut continuer.
Exemple d'usage :

$logger->warning('Le disque est presque plein (95% de capacité utilisée).');

Contexte d'utilisation :
- Problèmes de performance (exemple : temps d'exécution long).
- Utilisation de ressources proches des limites (disque plein, mémoire insuffisante, etc.).
- Erreurs de validation des données d'entrée (par exemple, une API reçoit des paramètres inattendus).

🔥 6. NOTICE (550)¶

Signification : Événement normal mais important à surveiller.
Quand l'utiliser ? : Quand un événement non critique mais notable se produit.
Exemple d'usage :

$logger->notice('L\'utilisateur a changé son mot de passe.');

Contexte d'utilisation :
- Changements de configuration utilisateur (modification d'email ou de mot de passe).
- Notifications d'audits (l'utilisateur s'est connecté, des paramètres de l'application ont changé, etc.).
- Succès inhabituels (quelque chose de notable s'est produit, mais il n'y a pas d'erreur).

🔥 7. INFO (600)¶

Signification : Information générale sur l'exécution normale de l'application.
Quand l'utiliser ? : Pour suivre les flux normaux de l'application (à usage informatif).
Exemple d'usage :

$logger->info('Un nouvel utilisateur s\'est inscrit avec l\'email exemple@example.com.');

Contexte d'utilisation :
- Enregistrement des événements normaux (connexion d'un utilisateur, enregistrement d'une nouvelle commande, etc.).
- Audit des événements courants (par exemple, nouvelle inscription, email envoyé, etc.).
- Tracking des actions de l'utilisateur (ce qu'il fait dans l'application).

🔥 8. DEBUG (700)¶

Signification : Détail d'exécution utile au débogage.
Quand l'utiliser ? : Pour déboguer ou suivre l'exécution d'un script.
Exemple d'usage :

$logger->debug('Requête SQL exécutée : SELECT * FROM users WHERE id = 42');

Contexte d'utilisation :
- Requêtes SQL (pour suivre les requêtes SQL exécutées).
- Suivi des performances (combien de temps une tâche prend).
- Suivi des valeurs d'objets, tableaux ou données de contexte.
- Trace des entrées/sorties API (quelles données ont été envoyées ou reçues).

🔥 Résumé des niveaux de log¶

Niveau	Méthode	Gravité	Exemple d'usage
EMERGENCY	`$logger->emergency()`	⚠️ Catastrophique	Crash total de l'application
ALERT	`$logger->alert()`	⚠️ Urgent	Service critique indisponible
CRITICAL	`$logger->critical()`	⚠️ Critique	Base de données corrompue
ERROR	`$logger->error()`	⚠️ Erreur	Requête SQL échouée
WARNING	`$logger->warning()`	⚠️ Avertissement	Disque presque plein (95%)
NOTICE	`$logger->notice()`	ℹ️ Notification	Changement de mot de passe
INFO	`$logger->info()`	ℹ️ Information	Nouvelle commande créée
DEBUG	`$logger->debug()`	🐛 Débogage	Suivi des requêtes SQL