Surveillance et journalisation des applications PHP : comment ne pas manquer une erreur

Votre application PHP ne parle pas, on lui crie dessus

Imaginez que vous êtes le capitaine d'un vaisseau spatial. Votre mission est d'atteindre Mars. Mais le vaisseau n'a pas d'instruments, pas de capteurs, pas même un bouton "alarme d'urgence". Vous volez simplement en espérant le meilleur. C'est à peu près ce que ressent un développeur qui déploie une application PHP en production sans surveillance ni journalisation.

Les utilisateurs voient "500 Internal Server Error", et vous ne voyez qu'un écran de logs vide. Cela vous dit quelque chose ? Si ce n'est pas le cas, vous êtes soit un génie, soit vous n'avez tout simplement pas encore subi la chute d'un serveur de production à 3 heures du matin.

Dans cet article, nous allons voir comment transformer votre application PHP d'une "boîte noire" en un système transparent qui vous raconte lui-même où et pourquoi il a planté. Je vais vous montrer du code réel, les bonnes pratiques et les outils utilisés en production par les grands projets. C'est parti.

Pourquoi la journalisation en PHP n'est pas qu'un simple "echo"

Beaucoup de débutants pensent que la journalisation c'est :

echo "Erreur ici : " . $error;

Spoiler : ça ne fonctionne pas en production. L'utilisateur verra cette "beauté" à l'écran. Et si l'erreur est fatale, vous n'en saurez rien du tout.

La véritable journalisation est une collecte structurée de données que l'on peut analyser, rechercher et traiter en temps réel. PHP fournit des fonctions de base (error_log(), syslog()), mais dans le monde moderne, cela ne suffit pas.

Que doit contenir un bon log ?

\n
• Niveau de gravité — DEBUG, INFO, WARNING, ERROR, CRITICAL
\n
• Horodatage — heure précise de l'événement (de préférence en UTC)
\n
• Contexte — ID utilisateur, IP, URL, données de la requête
\n
• Trace d'appel — stack trace de l'erreur
\n
• Identifiant unique de requête — pour lier tous les logs d'une même action
\n

Monolog — le standard de journalisation en PHP

Si vous codez en PHP et que vous n'utilisez pas Monolog, vous perdez du temps. C'est le standard de facto pour la journalisation, supporté par Symfony, Laravel et la plupart des frameworks modernes.

Pourquoi Monolog est génial ?

\n
• Handlers flexibles — vous pouvez écrire dans un fichier, une BDD, Telegram, Slack, email
\n
• Formateurs — JSON, HTML, Syslog
\n
• Processeurs — ajoutent le contexte automatiquement
\n

Installation et exemple de base

composer require monolog/monolog

Et maintenant, écrivons un simple logger :

<?php\nrequire 'vendor/autoload.php';\n\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Level;\n\n// Création du logger avec un nom de canal\n$log = new Logger('my_app');\n\n// Écriture dans un fichier\n$log->pushHandler(\n    new StreamHandler(__DIR__ . '/logs/app.log', Level::Debug)\n);\n\n// Erreurs critiques — dans Telegram\n$log->pushHandler(\n    new TelegramBotHandler(\n        'YOUR_BOT_TOKEN',\n        'YOUR_CHAT_ID',\n        Level::Critical\n    )\n);\n\n// Utilisation\n$log->info('Utilisateur connecté', ['user_id' => 123]);\n$log->error('Base de données inaccessible', ['db_host' => 'localhost']);

Remarque : nous utilisons différents handlers pour différents niveaux. Tout est écrit dans le fichier (débogage), mais seul le critique va dans Telegram. Cela permet de ne pas spammer les notifications tout en ne manquant aucun vrai problème.

Surveillance PHP : comment voir ce qui est caché

La journalisation est une collecte passive de données. La surveillance est une observation active avec alertes. Si un utilisateur vous signale une erreur, vous êtes déjà en retard. Une bonne surveillance vous alertera avant que le problème n'affecte les utilisateurs.

Sentry — un must have pour le développeur PHP

Sentry est un système de suivi des erreurs en temps réel. Il intercepte les exceptions, collecte le contexte, la stack trace et même les données de session.