Lire les logs serveur : erreurs 404, bots et lenteurs
Ce que révèle chaque partie d'une ligne de log serveur, comment repérer les erreurs 404 et les requêtes lentes, et distinguer visiteurs réels et bots.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Une ligne de log serveur contient l'adresse à l'origine de la requête, la date, la page demandée, le code de statut renvoyé par le serveur et l'information sur le navigateur, le tout sur une seule ligne. Les lire régulièrement répond à trois questions : quelles pages renvoient une erreur 404, quelle part du trafic vient de vrais visiteurs plutôt que de bots, et quelles requêtes répondent plus lentement que la normale. Les trois sont des signaux visibles bien avant de devenir un vrai problème à traiter.
Quand le site d'une société de gestion d'immeubles ne reçoit que quelques centaines de visiteurs par mois alors que le serveur enregistre des dizaines de milliers de requêtes par jour, cet écart vient presque toujours du trafic bot. Sans regarder les logs, il est difficile d'expliquer cette différence.
Comment lire une ligne de log ?
Un log serveur est l'enregistrement que le serveur conserve de chaque requête reçue ; le format « combined » utilisé par défaut par Nginx et Apache liste l'adresse IP à l'origine, la date, l'adresse demandée, la méthode HTTP, le code de statut, le nombre d'octets envoyés, la page référente et l'identité du navigateur, dans cet ordre.
Dans une ligne typique, l'adresse IP du visiteur apparaît en premier, suivie de la date et de l'heure entre crochets, puis l'adresse demandée entre guillemets commençant par GET ou POST, immédiatement suivie du code de statut à trois chiffres, 200 pour un succès, 404 pour une page introuvable, 500 pour une erreur serveur, la quantité de données envoyées et enfin l'identité du navigateur entre guillemets à la fin. Une fois cet ordre mémorisé, il devient possible de lire n'importe quel fichier de log.
Que montrent réellement les erreurs 404 ?
Une 404 signifie que la page demandée n'a pas été trouvée sur le serveur. Cela vient soit d'un lien cassé, d'une autre page pointant vers une adresse qui n'existe plus, soit d'une migration où les anciennes adresses n'ont jamais été redirigées, soit d'un bot qui teste une adresse au hasard.
Passer en revue les 404 dans les logs régulièrement montre quel lien cassé affecte réellement les visiteurs ; une 404 qui revient souvent et vient d'un vrai navigateur mérite une correction prioritaire, une tentative isolée de bot peut généralement être ignorée.
Comment distinguer visiteurs réels et trafic bot ?
Le premier réflexe est de regarder le champ user-agent ; les bots des moteurs de recherche connus s'identifient ouvertement. Mais un bot malveillant présente souvent un user-agent qui ressemble à un vrai navigateur, ce champ seul ne suffit donc pas.
- Plus d'une requête par seconde depuis la même adresse IP, ce qui ne correspond pas à un comportement humain
- Des requêtes répétées concentrées uniquement sur certaines pages, un formulaire de connexion, une barre de recherche
- Des requêtes qui vont directement vers des pages profondes sans jamais consulter robots.txt au préalable
- Un user-agent réaliste associé à des en-têtes manquants qu'un vrai navigateur enverrait normalement, langue, cookies
Comment repérer les requêtes lentes dans les logs ?
Le temps de réponse n'apparaît pas dans la plupart des formats de log par défaut, mais Nginx comme Apache proposent tous deux une variable séparée pour l'ajouter ; une fois ajoutée, chaque requête indique le temps qu'elle a mis à répondre, en millisecondes.
Une fois ce champ en place, filtrer les requêtes au-delà d'un seuil, disons une seconde, permet de trouver quelle page, quelle requête ou quelle intégration cause le ralentissement. C'est un signal qui peut être repéré avant qu'un client ne se plaigne que le site est lent.
Combien de temps garder les logs, et qui doit les consulter ?
Les fichiers de log ne sont pas conservés indéfiniment ; l'espace disque est limité et la plupart des hébergeurs appliquent une rotation par défaut de quelques semaines à quelques mois. Comme une analyse de sécurité après un incident peut nécessiter des logs plus anciens, ce délai mérite d'être fixé délibérément plutôt que laissé à la valeur par défaut de l'hébergeur.
Consulter les logs régulièrement peut être une habitude hebdomadaire de dix minutes pour une seule personne ; l'objectif n'est pas de lire chaque ligne, mais de repérer la répartition des codes de statut et les erreurs les plus fréquentes.
Obtenir un résumé rapide avec une seule commande
Un résumé rapide peut être obtenu à partir d'un fichier de log sans équipe technique dédiée. Une commande simple qui compte et trie les lignes par code de statut montre en quelques secondes la fréquence de chaque erreur ; les 404 ou 500 les plus fréquentes apparaissent en tête de liste.
La même logique, en triant par nombre total de requêtes par adresse IP, révèle immédiatement une source de trafic bot anormalement importante. Ces deux filtres donnent un résultat bien plus rapide que la lecture ligne par ligne du fichier entier.
Erreurs fréquentes
Les logs restent souvent un fichier qu'on n'ouvre que lorsqu'un problème s'est déjà produit ; sans regard régulier, l'alerte précoce est manquée.
- Ne consulter les logs qu'après la panne du site, en manquant les signaux d'alerte antérieurs
- Ne jamais passer en revue les erreurs 404, laissant des liens cassés inaperçus pendant des mois
- Lire les analytics comme si chaque visite venait d'un humain, sans jamais tenir compte de la part de trafic bot
- Ne jamais ajouter de champ de temps de réponse aux logs, ce qui empêche de connaître l'origine d'une lenteur
Les logs serveur montrent un site plus honnêtement qu'un tableau de bord analytics ; chaque requête, réelle ou bot, y est enregistrée. Une habitude hebdomadaire de dix minutes permet de repérer de nombreux problèmes avant qu'ils ne deviennent une plainte client. Un premier échange avec rabbitclip permet de lire ensemble vos propres logs serveur.
Questions fréquentes
Faut-il un outil spécial pour lire les fichiers de log ?
Pour un petit site, filtrer un fichier texte via la ligne de commande suffit. Quand le trafic augmente, un outil d'analyse de logs facilite le travail.
Une erreur 404 est-elle toujours un problème ?
Non. Un bot qui teste une adresse aléatoire n'ayant jamais existé est normal ; le vrai problème est un lien cassé que de vrais visiteurs rencontrent souvent.
Peut-on bloquer complètement le trafic bot ?
Pas complètement, mais les schémas de comportement malveillant connus peuvent être largement bloqués au niveau du serveur ou du CDN.
Le serveur est-il toujours à l'origine d'une requête lente ?
Non. La lenteur peut venir d'une requête base de données, d'une intégration tierce ou d'une image trop lourde ; le log montre seulement où ça ralentit, la cause reste à identifier séparément.
Peut-on obtenir un résumé rapide au lieu de lire ligne par ligne ?
Oui. Une commande simple qui compte et trie par code de statut ou adresse IP fait apparaître l'erreur la plus fréquente ou une source de bot inhabituelle sans lire chaque ligne.
