Lire les logs d'un serveur : trouver l'erreur au milieu du bruit

Les logs d'un serveur défilent dans un terminal, mêlant lignes d'information et messages d'erreur à repérer

À la une

Un serveur Linux génère en moyenne plusieurs milliers de lignes de logs par jour, entre les accès HTTP, les connexions SSH, les requêtes de base de données et les messages système. Trouver la ligne qui explique une erreur 500 ou un service qui refuse de démarrer revient à chercher une phrase utile dans un roman de mille pages, sauf que les bons outils réduisent cette recherche à quelques secondes.

Sommaire

Quatre fichiers de logs à connaître avant tout le reste
grep, tail et journalctl : trois commandes qui filtrent le bruit
Lire un code HTTP dans access.log pour remonter à la cause
Erreur de serveur : ce que signifient vraiment les codes 5xx
Centraliser les logs quand on gère plus d’un serveur
Questions fréquentes

Quatre fichiers de logs à connaître avant tout le reste

Sur une distribution Debian ou Ubuntu, les logs système se trouvent dans /var/log/. Chaque service y dépose ses propres fichiers, mais quatre d’entre eux concentrent la majorité des informations utiles au diagnostic.

/var/log/syslog enregistre les messages du noyau et des services gérés par systemd. C’est le journal généraliste : si un démon plante au démarrage, la trace apparaît ici. /var/log/auth.log consigne les tentatives de connexion, réussies ou non, ce qui en fait le premier fichier à consulter après une suspicion d’intrusion. Pour un serveur web Apache, /var/log/apache2/error.log regroupe les erreurs PHP, les permissions refusées et les modules manquants. Nginx range les siennes dans /var/log/nginx/error.log. Enfin, /var/log/mysql/error.log (ou son équivalent MariaDB) signale les requêtes échouées et les arrêts anormaux du moteur de base de données.

Chaque ligne suit un format relativement stable : horodatage, nom du service, niveau de gravité (notice, warning, error, critical) et message. Repérer ce schéma permet de filtrer efficacement, on le verra plus bas.

grep, tail et journalctl : trois commandes qui filtrent le bruit

Ouvrir un fichier de log dans un éditeur de texte est rarement la bonne approche. Un fichier syslog peut peser plusieurs centaines de mégaoctets après quelques semaines sans rotation.

La commande tail -f /var/log/syslog affiche les nouvelles lignes en temps réel. C’est l’outil de première intention quand on reproduit un bug : on déclenche l’action dans le navigateur et on regarde ce qui tombe. Pour chercher une erreur passée, grep -i "error" /var/log/apache2/error.log filtre toutes les lignes contenant le mot, sans distinction de casse. Ajouter l’option -B 3 affiche les trois lignes précédentes, souvent indispensables pour comprendre le contexte.

Commande	Usage principal	Exemple concret
`tail -f`	Suivre un log en direct	`tail -f /var/log/nginx/error.log`
`grep -i`	Chercher un mot dans un fichier	`grep -i "fatal" /var/log/syslog`
`journalctl -u`	Filtrer par service sous systemd	`journalctl -u mysql --since "1 hour ago"`
`less +G`	Ouvrir un gros fichier à la fin	`less +G /var/log/auth.log`
`zgrep`	Chercher dans un log compressé (rotation)	`zgrep "502" /var/log/nginx/access.log.2.gz`

Sur les distributions récentes, journalctl remplace avantageusement la lecture directe des fichiers. La commande journalctl -p err --since "2 hours ago" isole toutes les entrées de niveau erreur ou supérieur des deux dernières heures, tous services confondus. La documentation officielle de systemd détaille l’ensemble des filtres disponibles.

Voir aussi Erreur de contenu mixte en HTTPS : la trouver et la corriger

Lire un code HTTP dans access.log pour remonter à la cause

Le fichier access.log d’Apache ou Nginx enregistre chaque requête reçue par le serveur. Une ligne typique au format Combined Log ressemble à ceci :

192.168.1.12 - - [13/Oct/2026:09:41:22 +0200] "GET /panier HTTP/1.1" 500 0 "-" "Mozilla/5.0"

Le chiffre 500 est le code de réponse HTTP. Quand un site renvoie des erreurs intermittentes, filtrer ce fichier par code permet de savoir exactement quelles URL sont touchées et à quelle fréquence. La commande awk '$9 == 500' /var/log/apache2/access.log extrait toutes les requêtes ayant reçu une réponse 500. En croisant l’horodatage avec error.log, on obtient la cause technique : un script PHP qui dépasse la mémoire allouée, un fichier .htaccess mal formé, ou un module absent.

Pour un site sous WordPress, la méthode de diagnostic d’une erreur 500 commence précisément par cette lecture croisée des deux fichiers. L’activation du mode debug complète le tableau en forçant PHP à écrire les avertissements dans le log plutôt que d’afficher un écran blanc.

Erreur de serveur : ce que signifient vraiment les codes 5xx

Une « erreur de serveur » désigne tout code de réponse HTTP compris entre 500 et 599. Le serveur a reçu la requête, l’a comprise, mais n’a pas réussi à la traiter. Selon le RFC 9110 de l’IETF qui définit la sémantique HTTP, ces codes indiquent que le problème vient du serveur, pas du client.

Code	Nom	Cause la plus courante en hébergement mutualisé
500	Internal Server Error	Erreur PHP, .htaccess invalide, limite mémoire atteinte
502	Bad Gateway	Le proxy (Nginx) ne reçoit pas de réponse du backend (PHP-FPM)
503	Service Unavailable	Surcharge ou maintenance planifiée
504	Gateway Timeout	Script trop long, la connexion au backend expire

Un point souvent négligé : le code 503 est le seul qui devrait être renvoyé lors d’une maintenance volontaire, car les moteurs de recherche savent qu’il est temporaire et ne désindexent pas la page. Renvoyer un 500 par erreur pendant une mise à jour peut coûter des positions. Un outil de monitoring configuré pour alerter sur les codes 5xx permet de détecter ces situations avant qu’elles ne durent.

Centraliser les logs quand on gère plus d’un serveur

Dès qu’un projet repose sur deux machines (un serveur web et un serveur de base de données, par exemple), lire les logs en SSH sur chaque nœud devient vite ingérable. La centralisation consiste à envoyer tous les journaux vers un point unique.

rsyslog, installé par défaut sur la plupart des distributions, peut transmettre les logs vers un serveur distant via le protocole syslog (port 514 en UDP ou TCP). Pour des besoins plus avancés, des solutions comme la pile ELK (Elasticsearch, Logstash, Kibana) ou Grafana Loki indexent les logs et offrent une interface de recherche. Le principe reste le même : on filtre par service, par niveau de gravité et par plage horaire, mais sans ouvrir de terminal sur chaque machine.

Même sur un serveur unique, la rotation des logs mérite attention. Le service logrotate, configuré dans /etc/logrotate.conf, compresse et archive les anciens fichiers pour éviter de saturer le disque. Un /var/log/ plein à 100 % empêche l’écriture de nouveaux logs, et par effet de bord, certains services refusent de démarrer. Le budget technique annuel d’un site devrait inclure cette vérification périodique de l’espace disque.

Questions fréquentes

C’est quoi un log ?

Un log (ou journal) est un fichier texte dans lequel un système ou un logiciel enregistre chronologiquement ses événements : démarrages, requêtes reçues, erreurs rencontrées, connexions acceptées ou refusées. Chaque entrée comporte au minimum un horodatage et un message. Sur un serveur Linux, ces fichiers se trouvent dans le répertoire /var/log/.

Comment voir les logs d’un serveur ?

En SSH, la commande tail -f /var/log/syslog affiche le journal système en temps réel. Pour un serveur web, consulter /var/log/apache2/error.log ou /var/log/nginx/error.log. Sur les hébergements mutualisés qui ne donnent pas d’accès SSH, le panneau d’administration (cPanel, Plesk) propose généralement une section « Logs » ou « Journaux d’erreurs » accessible depuis le navigateur.

Que signifie « erreur de serveur » ?

L’expression désigne un code HTTP de la famille 5xx. Le serveur a bien reçu la requête du navigateur mais n’a pas pu y répondre correctement, à cause d’un script défaillant, d’un service arrêté ou d’une surcharge. Le code le plus fréquent, 500 Internal Server Error, signale une erreur côté application (souvent PHP) sans préciser laquelle : c’est dans le fichier error.log que se trouve le détail.

Comment relancer un serveur ?

La commande sudo systemctl restart apache2 (ou nginx, mysql, selon le service concerné) redémarre le processus sans redémarrer toute la machine. Avant de relancer, consulter les logs pour identifier la cause de l’arrêt : un redémarrage masque le problème sans le résoudre. La commande systemctl status apache2 indique si le service tourne et, en cas d’échec, affiche les dernières lignes du journal.

À retenir

Commencer par tail -f sur le fichier error.log du service concerné, puis reproduire le bug.
Croiser access.log et error.log en se repérant par l’horodatage pour relier un code 5xx à sa cause technique.
Utiliser journalctl -p err --since "1 hour ago" pour un diagnostic rapide tous services confondus.
Vérifier régulièrement que logrotate fonctionne : un disque plein empêche l’écriture des logs et peut bloquer des services.

Pour aller plus loin sur les sujets connexes : comprendre la propagation DNS aide à distinguer un problème de résolution d’un vrai dysfonctionnement serveur, et le passage de FTP à SFTP sécurise la connexion utilisée pour consulter les logs à distance.

Damien Roux

Damien Roux est l'hébergement web. de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress