Surveillance et logging PHP : ne laissez aucun bug passer

Votre application reste silencieuse ? C'est mauvais signe

Avez-vous déjà découvert un bug en production grâce à un utilisateur furieux ? Si oui, vous savez à quel point c'est douloureux. Si non, vous avez de la chance (pour l'instant).

PHP est le langage qui propulse 78 % des sites web dans le monde. Mais il a une particularité : il est trop « discret ». Par défaut, PHP avale simplement l'erreur, affiche une page blanche ou, pire encore, continue de fonctionner avec des données erronées. Sans système de surveillance et de logging, vous travaillez à l'aveugle.

Dans cet article, nous allons voir comment transformer votre application PHP d'une « boîte noire » en un système transparent, où chaque erreur, chaque requête lente et chaque action suspecte sont enregistrées. C'est parti !

Pourquoi « echo $error » n'est pas du logging ?

Beaucoup de développeurs débutants écrivent :

try {\n    // du code\n} catch (Exception $e) {\n    echo $e->getMessage();\n}\n

Ce n'est pas du logging. C'est un cri dans le vide. Afficher dans le navigateur ne sauvegarde rien, ne structure rien et ne vous offre aucune analyse. Un vrai logging, c'est quand vous pouvez :

\n
• Voir une erreur 5 minutes après son apparition
\n
• Savoir sur quel serveur et dans quel environnement elle s'est produite
\n
• Filtrer des milliers d'entrées pour trouver la bonne
\n
• Recevoir une notification sur Telegram/Slack en cas de problème
\n

Passons aux outils qui font tout cela.

Monolog — le standard de facto pour PHP

Si vous codez en PHP et que vous n'utilisez pas Monolog, vous réinventez probablement la roue. Cette bibliothèque est devenue la référence pour le logging en PHP (oui, Laravel et Symfony l'utilisent en interne).

Installation et exemple simple

composer require monolog/monolog\n

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\n\n// Création d'un canal de logs\n$log = new Logger('mon_app');\n// Écriture dans le fichier /var/log/mon_app.log\n$log->pushHandler(new StreamHandler('/var/log/mon_app.log', Logger::WARNING));\n\n// Utilisation\n$log->warning('Ceci est un avertissement');\n$log->error('Erreur critique : base de données inaccessible');\n

C'est déjà mieux. Mais Monolog peut faire bien plus. Vous pouvez envoyer vos logs à plusieurs endroits simultanément :

\n
• Dans un fichier — pour le débogage local
\n
• Dans Elasticsearch — pour une recherche avancée
\n
• Sur Telegram/Slack — pour des alertes urgentes
\n
• Dans Syslog — pour l'administration système
\n

Exemple avancé avec plusieurs gestionnaires

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Handler\\ElasticsearchHandler;\nuse Monolog\\Formatter\\LineFormatter;\n\n$log = new Logger('production');\n\n// Toutes les erreurs dans un fichier\n$fileHandler = new StreamHandler('/var/log/app.log', Logger::DEBUG);\n$log->pushHandler($fileHandler);\n\n// Les erreurs critiques directement sur Telegram\n$telegramHandler = new TelegramBotHandler(\n    'VOTRE_TOKEN_BOT', \n    'VOTRE_ID_CHAT', \n    Logger::CRITICAL\n);\n$telegramHandler->setFormatter(new LineFormatter(\n    "[%datetime%] %channel%.%level_name%: %message% %context%\\n"\n));\n$log->pushHandler($telegramHandler);\n\n// Logging\n$log->critical('La base de données est tombée', ['serveur' => gethostname()]);\n

Maintenant, si la base de données plante en pleine nuit, vous le saurez grâce à une notification sur votre téléphone. Pas le matin par un client.

Sentry — surveillance des erreurs avec contexte

Monolog écrit très bien les logs, mais quand les erreurs se multiplient, lire des fichiers devient un enfer. C'est là qu'intervient Sentry, un système de collecte d'erreurs avec une interface web.

Sentry collecte automatiquement :

\n
• La pile d'appels (stack trace)
\n
• Les données de la requête (URL, en-têtes, corps)
\n
• Les informations sur l'utilisateur (si fournies)
\n
• L'état des variables
\n