Gestion des logs d’un site autonome : collecte et analyse des logs d’accès, d’erreur et applicatifs
1. Chaque type de log a un rôle précis, ne les mélangez pas
Beaucoup traitent tous les fichiers .log du serveur comme « les logs » et les parcourent un par un en cas d’incident. En réalité, les trois types de logs répondent à trois questions totalement différentes. Les logs d’accès (access.log de Nginx/Apache) répondent à « qui a demandé quoi et quand » ; les logs d’erreur (error.log de Nginx, erreurs PHP-FPM) répondent à « où le serveur a signalé une erreur » ; les logs applicatifs (les log écrits dans votre propre code) répondent à « où en est cette commande, pourquoi elle a échoué ».
Le jugement contre-intuitif est ici :En cas d’incident en production, le log d’accès est le dernier à consulter. Les logs d’accès sont volumineux et bruyants : les consulter en premier, c’est se noyer sous des milliers de lignes 200. Le bon ordre : d’abord les logs d’erreur pour localiser le point de rupture, puis les logs d’accès pour mesurer l’impact (combien d’utilisateurs, quelles URL), enfin les logs applicatifs pour reconstituer le processus métier. C’est la même logique que Analyse des logs de crawlers IA qui insiste sur « identifier d’abord qui vous lit » : classer avant d’analyser.
| Type de log | Question à laquelle il répond | Emplacement typique | Conservation conseillée |
|---|---|---|---|
| Log d’accès | Qui, quand, quelle requête | Nginx access.log | 90 jours en données chaudes |
| Log d’erreur | Où le serveur a signalé une erreur et pourquoi | Nginx error.log / erreurs PHP | 1 an |
| Log applicatif | Où en est le processus métier, où il bloque | log personnalisé dans le code | 30 jours |
| Log système | Événements du serveur lui-même | /var/log/messages | 30 jours |
2. Pipeline de collecte : de « fichiers éparpillés » à « un seul endroit consultable »
Dans une équipe d’une personne, la situation est souvent la suivante : un log Nginx, un log PHP, un log écrit par l’application, dispersés dans des répertoires différents ; au redémarrage du serveur ou au changement de machine, l’historique est perdu. La première étape de la gestion des logs n’est pas l’analyse, mais de les centraliser.
Un pipeline se fait en quatre étapes : l’application écrit les fichiers, on les découpe par jour, on les centralise, et on met une alerte sur les erreurs. Pour le découpage, logrotate s’en charge jour par jour avec compression gzip, pour éviter un fichier unique de plusieurs Go impossible à ouvrir ; pour la centralisation, on peut commencer simple : rsyslog ou un agent léger envoie les logs vers une machine dédiée ou un service de logs cloud.
Une équipe d’une seule personne n’a pas besoin de déployer d’emblée une usine à gaz comme ELK : un stockage centralisé avec une interface de recherche suffit, et on envisagera plus lourd quand le volume augmentera. Pour un site derrière un CDN, il faut aussi collecter les logs de l’edge et ceux de l’origine, voir Accélération mondiale par CDN.
| Étape | Mise en œuvre | Outil / configuration | Conséquence si on ne le fait pas |
|---|---|---|---|
| Écriture des fichiers | Sortie au format unifié | format combined | Champs incomplets, scripts d’analyse difficiles à écrire |
| Découpage | Découpage quotidien avec compression | logrotate | Fichier trop volumineux qui sature le disque |
| Centralisation | Regroupement sur un seul stockage | rsyslog / logs cloud | Historique perdu au changement de machine |
| Alertes | Notification sur seuil de taux d’erreur | Règles de la plateforme de supervision | On ne découvre le problème que quand un utilisateur se plaint |
Trois. Les logs d’erreur : la catégorie à surveiller en priorité dans une équipe d’une seule personne
Sur les trois catégories, les logs d’erreur ont la plus forte densité d’information par ligne et méritent d’être surveillés en premier. Les logs d’accès font plusieurs centaines de milliers de lignes par jour, les logs d’erreur peut-être quelques centaines, mais chaque ligne correspond à un échec réel. Les centraliser à part et leur dédier des alertes offre le meilleur rapport effort/résultat.
Fixez des seuils chiffrés : un taux d’erreur 5xx supérieur à 1 % pendant 10 minutes consécutives déclenche une alerte immédiate ; une erreur anormale isolée (échec de connexion à la base de données, échec de callback de paiement) déclenche une alerte dès la première occurrence, sans attendre le cumul. Les logs d’erreur doivent être hiérarchisés : les warning se consultent régulièrement, les error et critical exigent une notification en temps réel. Pour les applications comme PHP, il faut aussi isoler les erreurs fatales et les requêtes lentes.
Exemple concret : Un matin, l’alerte se déclenche : le taux d’erreur 5xx passe de 0,1 % à 3 %. Vous ouvrez d’abord les logs d’erreur et voyez une masse de « PHP-FPM: unable to connect », ce qui pointe vers un pool de processus backend saturé ; vous regardez ensuite les logs d’accès pour identifier les URL déclencheuses et découvrez qu’une nouvelle API en production a saturé le pool à cause d’une requête lente ; vous consultez enfin les logs applicatifs pour confirmer quelle requête SQL en est la cause. Diagnostic en dix minutes : c’est la valeur d’avoir traité les logs d’erreur en premier.
| Niveau d’erreur | Exemple | Mesure à prendre | Seuil d’alerte |
|---|---|---|---|
| critique | Base de données inaccessible, paiement échoué | Notification immédiate | Alerte dès la première occurrence |
| erreur | 5xx, erreurs fatales | Notification en temps réel | > 1 % sur 10 minutes |
| avertissement | Requêtes lentes, tentatives de reconnexion | Consultation dans le récapitulatif quotidien | Récapitulatif au-delà de 2 fois la baseline |
| notification | Messages métier normaux | Archivage sans alerte | Pas d’alerte |
Quatre. Les logs applicatifs : rendre le parcours métier traçable
Les logs d’accès et d’erreur sont des enregistrements « objectifs » du serveur, mais ils ne répondent pas à une question métier du type « pourquoi cette demande n’est pas arrivée dans le CRM ». C’est là qu’interviennent les logs applicatifs : vous écrivez vous-même des logs aux étapes clés du parcours métier — demande soumise, écrite en base de données, poussée vers le CRM, échec du retour du CRM.
Pour que les logs applicatifs soient utiles, chaque entrée doit porter un identifiant métier, par exemple un ID de demande ou un numéro de commande. Ainsi, en cas de problème, il vous suffit de rechercher cet ID pour reconstituer tout le parcours de la demande, de sa soumission à sa clôture. N’écrivez pas de logs inutiles (“exécution ligne 10”) : chaque entrée doit répondre à une question métier. Limitez le volume à quelques dizaines de Mo par jour, et n’incluez pas le corps complet des requêtes : c’est lent et cela expose des données personnelles.
Le lien entre lenteur et logs mérite aussi d’être mentionné : trop de logs, ou une écriture disque synchrone à chaque requête, ralentit les réponses. Pour savoir comment analyser les indicateurs de lenteur, voir Core Web Vitals. Pour le cadre général de la surveillance et des alertes, voir Surveillance et alertes du site.
| Étape métier | À journaliser | Identifiant associé | Comment enquêter en cas de problème |
|---|---|---|---|
| Soumission de la demande | Champs du formulaire, page source | ID de demande | Rechercher la soumission par ID |
| Enregistrement en base | Écriture réussie / échouée | ID de demande | Vérifier si la donnée est en base |
| Envoi vers le CRM | Code de retour de l’API, durée | ID de demande | Vérifier si le CRM a reçu |
| Notification par e-mail | Envoi réussi / échoué | ID de demande | Vérifier si le commercial a reçu |
5. Pièges à éviter : les trois erreurs les plus courantes dans la gestion des logs
Premier piège : “ni rotation ni rétention”. Si les logs s’écrivent toujours dans un seul fichier, au bout de trois mois il pèse plusieurs Go, un simple grep prend une éternité, ou pire, il remplit le disque et fait tomber votre site. La rotation quotidienne avec une politique de rétention est le minimum.
Deuxième piège : “garder seulement le temps réel sans archiver”. Quand le disque est plein, on supprime les plus anciens, et au moment de chercher l’origine d’une panne survenue deux mois plus tôt, il n’y a plus rien. Conservez les données chaudes 90 jours, puis compressez et archivez au moins un an : cela coûte très peu. Troisième piège : “écrire des données sensibles dans les logs”. Mettre les mots de passe utilisateurs ou des numéros de carte bancaire complets dans les logs, c’est créer une source de fuite supplémentaire dans votre base de logs. Masquez systématiquement les champs sensibles, ou ne les écrivez pas sur disque.
| Erreur fréquente | Symptôme visible | Vrai problème | Bonne pratique |
|---|---|---|---|
| Pas de rotation | Le fichier unique grossit sans fin | Disque plein, recherche lente | Rotation quotidienne avec logrotate |
| Pas d’historique | Suppression des plus anciens quand le disque est plein | Aucune donnée pour revenir en arrière | 90 jours en chaud, 1 an en archive |
| Écriture de données sensibles | Les logs facilitent le débogage | La base de logs devient une source de fuite | Masquage des champs sensibles |
| Les trois types mélangés | Il faut tout fouiller en cas d’incident | Localisation lente, beaucoup de bruit | Priorité aux erreurs, recherche par catégorie |
FAQ — Questions fréquentes
Faut-il absolument une plateforme de logs type ELK pour un site indépendant ?
Pourquoi ne pas mélanger les logs d’accès, d’erreur et applicatifs ?
Combien de temps conserver chaque type de log ?
Comment définir les seuils d’alerte des logs d’erreurs ?
Quel niveau de détail pour les logs applicatifs, et quel impact sur les performances ?
Peut-on consigner les mots de passe et les informations de paiement dans les logs ?
Pour conclure
La valeur de la gestion des logs ne tient pas au volume stocké, mais à la capacité à localiser un incident en trois minutes. Pour un site indépendant géré par une seule personne, séparer les trois types de logs, les centraliser avec une rotation quotidienne et alerter au-delà de 1 % d’erreurs : une fois cette base en place, le temps de diagnostic quotidien passe de « des heures à fouiller les logs » à « un coup d’œil à l’alerte ». Les plateformes de logs lourdes viendront avec l’échelle, elles ne sont pas nécessaires au démarrage.
Trois étapes pour passer à l’action. Premièrement, séparez le stockage des trois types de logs (accès, erreurs, application) et définissez une durée de rétention pour chacun, avec une rotation quotidienne. Deuxièmement, centralisez-les avec rsyslog ou un service de logs cloud, pour pouvoir les rechercher par identifiant métier. Troisièmement, déclenchez une alerte dès que le taux d’erreur dépasse 1 % sur 10 minutes, ou dès qu’une erreur critique apparaît, même une seule fois. Une fois ces trois étapes en place, votre vision de la production passe de « on découvre le problème quand un utilisateur se plaint » à « on le sait avant lui ». Pour le rythme de maintenance, référez-vous à calendrier de maintenance du site et planifiez le tout ensemble.
Une phrase à retenir : un log n’est pas un fichier qu’on garde par nostalgie sur un disque, c’est la boîte noire de l’accident. Sans classification ni centralisation au quotidien, le jour où ça casse, il ne reste que des impressions et des suppositions.