Journaux d'accès serveur — L'histoire de chaque requête que votre application a reçue

Chaque requête HTTP que votre serveur gère laisse une ligne dans le journal d'accès. La plupart du temps, ces fichiers se trouvent sur disque, s'agrandissant silencieusement jusqu'à ce qu'un avertissement de disque soit déclenché ou qu'un problème survienne en production. Puis, tout le monde veut soudainement les lire.

Voici une ligne unique provenant d'un serveur exécutant le format de journal combiné :

203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Huit champs. Chaque champ est une preuve sur ce qui s'est produit. Examinons de gauche à droite.

Les Champs, un par un

1. IP du client — 203.0.113.42

L'adresse IP qui a ouvert la connexion TCP vers votre serveur. Cela est pas nécessairement l'adresse IP de l'utilisateur final. Si vous êtes derrière un équilibreur de charge, un CDN ou un reverse proxy (par exemple, Nginx placé en face d'une application Node), cela sera l'adresse IP du proxy. L'adresse IP réelle du client se trouve dans les X-Forwarded-For ou X-Real-IP en-têtes — et vous devez configurer explicitement votre format de journal pour les capturer.

Dans Nginx, cela correspond à l'ajout de $http_x_forwarded_for dans votre log_format instruction. Dans Apache, utilisez %{X-Forwarded-For}i. Si vous omettez cela et que vous recevez une plainte d'abus ou que vous devez bloquer un acteur malveillant, vous vous retrouverez à regarder l'adresse IP de votre équilibreur de charge dans chaque ligne de journal.

2. Ident — -

Toujours un trait de soulignement. Ce champ était destiné à contenir le résultat d'une requête identd — un protocole ancien (RFC 1413) qui permettait aux serveurs de demander à l'OS du client qui possédait le processus effectuant la connexion. Aucun serveur ne tourne plus sur identd. Ce champ existe car le format de journal commun a été standardisé quand identd était encore en vigueur. Omettez-le.

3. Utilisateur authentifié — jsmith

Le nom d'utilisateur, rempli lorsque l'authentification HTTP de base ou de digest est active. Pour la plupart des applications modernes — authentification par jeton, cookies de session, JWT — cela sera un trait de soulignement. Si vous protégez une zone d'administration avec htpasswd, les connexions échouées apparaissent comme - à côté d'un code 401 ; les connexions réussies montrent le nom d'utilisateur.

4. Heure de la requête — [09/May/2026:14:32:11 +0000]

L'heure à laquelle le serveur a terminé le traitement de la requête (et non quand elle a commencé). Le format est day/Mon/year:HH:MM:SS timezone. L'offset horaire est plus important que ce que les gens croient — si votre serveur d'application tourne en UTC mais que votre outil de surveillance ou d'alerte est dans un fuseau horaire local, la corrélation d'une augmentation des journaux avec un incident spécifique nécessite des calculs de conversion à chaque fois. Exécutez tout en UTC.

5. Ligne de requête — "GET /api/users/profile HTTP/1.1"

Le champ le plus riche en informations. Trois parties : la méthode HTTP, le chemin avec la chaîne de requête, et la version du protocole.

• Méthode — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Les méthodes inattendues sur une endpoint méritent d'être notées.
• Chemin + chaîne de requête — vous indique exactement ce qui a été demandé. Les chaînes de requête peuvent contenir des termes de recherche, des identifiants, et dans des API mal conçues, des tokens d'authentification. Enregistrez-le conformément.
• Protocole — les clients HTTP/1.0 dans vos journaux en 2026 sont soit des intégrations anciennes, soit quelque chose qui imite un client ancien. Les clients HTTP/2 et HTTP/3 sont enregistrés comme ces versions si votre serveur les supporte.

6. Code de statut — 200

Le code HTTP que le serveur a envoyé. C'est le champ de verdict.

• 2xx — succès. La requête a été traitée.
• 3xx — redirection. Le client doit aller ailleurs.
• 4xx — erreur client. Demande invalide, authentification manquante, non trouvé. Peut être une utilisation légitime ou une exploration.
• 5xx — erreur serveur. Votre application a planté, a dépassé le temps, ou a retourné du contenu corrompu. Examinez toujours ces cas.

Lors de l'analyse d'un incident, filtrez d'abord par 5xx puis regardez l'heure de la première réponse 500 — c'est là où le problème a commencé. Tout ce qui précède est la phase d'anticipation ; tout ce qui suit est la zone d'impact.

7. Octets envoyés — 1843

La taille du corps de réponse en octets, sans compter les en-têtes. Un trait de soulignement signifie zéro octets (typique pour 304 Not Modified de réponses — le client possède déjà le contenu). Des valeurs inattendument élevées sur des endpoints qui devraient retourner quelques centaines d'octets sont un signal d'alerte. Un utilisateur authentifié qui accède à un endpoint « obtenir mon profil » et reçoit 40 Mo est soit une erreur, soit une utilisation abusive d'une fonction de téléchargement de données.

8. Référent — "https://example.com/dashboard"

Où le client est venu avant de faire cette requête — l'URL dans l'entête du navigateur. (Le spécification HTTP a mal orthographié ce mot en 1996 et nous sommes coincés avec cela.) Les connexions directes, les raccourcis, et les requêtes provenant d'applications natives arrivent avec un référent vide. Ce champ existe uniquement dans le format de journal combiné ; le format de journal commun s'arrête à l'octet envoyé. Referer Le spam du référent — des en-têtes de référent faux dans des requêtes massives tentant d'apparaître dans vos analyses — était plus courant autrefois mais est aujourd'hui principalement un vestige. Il vaut encore mieux filtrer ces données dans vos statistiques agrégées.

9. Agent utilisateur —

L'identité du client. Les agents utilisateurs sont facilement faussés, donc considérez cela comme une piste, pas comme une vérité. Les robots légitimes identifient généralement honnêtement : "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"

. Les scrapers qui imitent les navigateurs envoient la chaîne Mozilla/5.0 Chrome complète. Curl envoie Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0sauf si quelqu'un l'override avec curl/8.x Des motifs à surveiller : des chaînes d'agents utilisateurs identiques frappant les mêmes endpoints à une vitesse de machine, ou un agent utilisateur affirmant être iOS Safari mais effectuant des requêtes selon un motif que n'aurait pas un navigateur humain (aucune image, aucune CSS, parcours séquentiel de pages de produit). -A.

Des motifs qui apparaissent dans chaque journal

L'analyse de vulnérabilité

Un IP unique ou une petite sous-réseau frappant des dizaines de chemins en succession rapide :

. Tous retournent 404. C'est un scanner automatisé effectuant une liste de vérification, pas une attaque ciblée. Ils s'exécutent constamment contre chaque IP publique. /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/configLa question appropriée n'est pas « pourquoi me scanne-t-il » — c'est « a-t-il retourné 200 sur l'un de ces chemins ? ». Si

retourne 200 sur votre serveur, c'est le problème réel. /.env L'essai de mots de passe

# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'

Des requêtes POST à grande vitesse vers votre point d'entrée de connexion, presque toutes retournant 401, provenant d'un ensemble distribué d'IPs. Le signe est le motif : même endpoint, taille de réponse constante (la page d'erreur), de nombreux IPs différents partageant un ASN. Les délais de réponse sont également constants — les tentatives d'authentification automatisées s'exécutent à un rythme régulier pour éviter les limites de vitesse.

L'augmentation des 404 après une déploiement

# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
  | sort | uniq -c | sort -rn | head -20

Vous déployez une nouvelle version. Le nombre de 404 augmente. Les liens anciens dans les e-mails, les raccourcis, et les sites externes pointent vers des URLs qui n'existent plus. C'est normal — mais si les 404 concernent des URLs qui

existent dans la nouvelle version, c'est une régression de routage. Comparez les chemins 404 avec vos définitions de route. devrait L'agrégation de réponses lentes

Le format standard de journal ne comprend pas le temps de réponse. Vous devez l'ajouter : dans Apache, ajoutez

(microsecondes) à votre %D ; dans Nginx, ajoutez LogFormatblock. Une fois que vous l'avez : $request_time dans votre log_format Si les requêtes lentes se regroupent autour d'une fenêtre de temps spécifique, c'est une contention — un job cron, un processus en lot ou une sauvegarde qui martèle la base de données. Si un chemin spécifique est constamment lent, indépendamment du temps, c'est une requête lente ou une appelle bloquant qui nécessite une analyse.

# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20

Dépanner un incident à partir des journaux

Le journal d'accès est une chronologie. Quand un utilisateur signale « quelque chose a mal fonctionné vers 15h », vous :

Filtrez pour la fenêtre 14h50–15h10

• Recherchez la première réponse 5xx — c'est là où le problème a commencé
• Vérifiez ce qui a changé dans les minutes précédant : y avait-il un déploiement ? Une mise à jour de configuration ? Une rénovation de certificat ?
• Regardez les chemins qui ont reçu des 5xx — est-ce tout ou un seul endpoint ?
• Vérifiez la taille des réponses réussies avant et après — a-t-il commencé à retourner des réponses tronquées ?
• Quelques signatures de panne à connaître :

Sursaut de 502

• — votre upstream est mort (crash de l'application, pool de connexions épuisé, base de données arrêtée). Les 502 commencent à un instant précis. Boucle de redirection
• — des redirections 301/302 provenant du même IP vers le même chemin en répétition. Généralement une mauvaise configuration d'une redirection HTTPS ou un paramètre SSL de Cloudflare en conflit avec le code de redirection de votre application. 200 avec zéro octets
• — statut 200 mais octets envoyés est 0 ou . Votre application a reçu la requête, a absorbé une exception, et a retourné un corps vide. Cas classique d'erreur non gérée. -Sursaut de 413
• — des clients envoient des corps de requête au-delà de votre limite. Soit votre limite est trop faible pour le cas d'usage, soit quelqu'un explore des vulnérabilités de téléchargement. Si vous gérez des journaux dans plusieurs formats — format commun d'Apache, format combiné d'Apache, format par défaut d'Nginx, formats personnalisés —

le Formateur de journal d'accès peut analyser et annoter les champs afin que vous ne deviez pas mentaliser les positions des champs chaque fois que vous passez d'un serveur à l'autre. Gestion des journaux que vous regretterez de ne pas avoir mise en place

Rotation des journaux

• configurée pour tourner quotidiennement, compresser et conserver 14 à 30 jours. Sans cela, — logrotate grandit jusqu'à ce que le disque soit plein. Cela se produit en production. access.log Journalisation centralisée
• — une fois que vous avez plus d'un serveur, le suivi de fichiers de journaux individuels ne s'adapte pas. Envoyez-les vers Loki + Grafana, Elasticsearch ou un service géré. Un format de journal structuré en JSON rend la requête beaucoup plus facile que le parsing du CLF avec awk. Contrôle d'accès sur les journaux bruts
• — les fichiers de journaux peuvent contenir des paramètres de requête avec des tokens, des données personnelles, et des chemins internes. Ne les rendez pas accessibles au monde. Soyez précis sur les périodes de conservation des journaux si vous êtes soumis à la RGPD ou à des réglementations similaires. Ne pas enregistrer des paramètres sensibles de requête
• — si votre application accepte des tokens d'authentification ou des mots de passe comme paramètres d'URL (ce qui ne devrait pas être le cas, mais certains API hérités le font), filtrez-les au niveau du journal avant qu'ils n'atteignent le disque. — si votre application accepte des tokens d'authentification ou des mots de passe comme paramètres d'URL (ce qui n'est pas recommandé, mais certains API hérités le font), filtrez-les au niveau des logs avant qu'ils n'atteignent le disque.

Vous aimerez peut-être aussi