Il y a deux types de gens. Ceux qui ne regardent jamais leurs logs. Et ceux qui regardent… trop tard, quand le disque est à 100 %, le service tombe, et tout le monde se demande pourquoi « ça marchait hier ».
Les logs, c’est vital. Mais si tu gardes tout, tout le temps, tu te fabriques une bombe à retardement. Et si tu ne gardes rien… tu n’as plus d’indices quand il faut comprendre une panne ou un incident.
Je te partage ici 9 règles de rétention très concrètes, celles qui marchent dans la vraie vie. Pas parfaites, mais efficaces. Et tu peux les appliquer autant sur Linux (journald, rsyslog, nginx) que sur des stacks type Docker, Kubernetes, ELK, Loki, ou même des apps SaaS.
1) Commence par une politique simple, quitte à l’affiner après
La meilleure politique de rétention, c’est celle qui existe. Pas celle que tu « feras plus tard ».
Un bon point de départ, très classique :
- logs applicatifs debug : 7 jours
- logs applicatifs info : 14 à 30 jours
- logs système : 30 jours
- logs sécurité et audit : 90 à 365 jours (selon contraintes)
- métriques agrégées (pas les logs) : 13 mois
Ce n’est pas une loi. Mais ça évite le grand n’importe quoi du genre « on garde tout depuis 2019 ».
2) Sépare par criticité, pas par outil
Erreur fréquente : définir une rétention « nginx 30 jours », « app 30 jours », « syslog 30 jours ». Alors que la vraie question c’est : qu’est ce qui est utile, et pour combien de temps.
Fais plutôt des classes :
- classe A : sécurité, paiement, auth, admin actions
- classe B : production standard (erreurs, timeouts, warnings)
- classe C : debug verbeux, traces temporaires, tests
Et derrière, tu relies tes outils à ces classes. Comme ça tu gardes la logique, même si tu changes de stack.
3) Règle d’or : garde brut peu longtemps, agrège longtemps
Les logs bruts coûtent cher. Mais les tendances coûtent peu.
Exemple simple :
- brut : 7 à 30 jours
- agrégé : 6 à 24 mois
Agrégé, ça veut dire : comptages par minute, top endpoints, taux d’erreurs, latence P95, nombre de 401, etc. Bref, ce que tu veux regarder dans 6 mois sans relire 200 Go de texte.
4) Mets une limite de taille, pas uniquement une limite de jours
La rétention « 30 jours » seule, c’est dangereux. Parce que 30 jours de logs en période de crise, ça peut être 10 fois plus volumineux qu’en période normale.
Ajoute toujours une deuxième barrière :
- limite de taille par service
- limite de taille par host
- limite de taille globale (avec purge automatique)
Sur Linux avec logrotate, tu peux penser « taille + rotations + compression ». Sur journald, tu as SystemMaxUse et SystemKeepFree. Et sur les stacks centralisées, tu as souvent des quotas par index ou par tenant.
5) Compresse dès que possible
Les logs textuels se compressent très bien. Gzip, zstd, peu importe, du moment que c’est automatique.
Bonne pratique :
- fichiers du jour en clair
- dès J+1 : compressé
- dès J+7 : déplacé sur stockage moins cher (si tu en as)
Le ratio est souvent énorme. Et ça repousse le moment où tu dois acheter du disque « juste pour des lignes de texte ».
6) Élimine le bruit à la source (oui, vraiment)
C’est tentant de dire « on filtre plus tard ». Sauf que plus tard, tu as déjà payé le coût : ingestion, stockage, indexation, transfert.
Quelques coupes nettes qui font du bien :
- logs d’accès trop verbeux en debug
- healthchecks qui spam toutes les 2 secondes
- endpoints statiques (images, css) si tu n’en fais rien
- stack traces dupliquées à l’infini
Attention quand même : filtre sans détruire l’info utile. Typiquement, tu peux garder un échantillon (sampling), ou ne conserver que les erreurs.
7) Masque et expire les données sensibles, sinon tu vas le payer
Si tes logs contiennent des emails, IP, tokens, numéros de commande, ou pire. Tu as deux problèmes : conformité et risque.
Deux règles simples :
- masquage à l’écriture (redaction) : tokens, secrets, mots de passe, headers sensibles
- rétention courte pour ce qui pourrait identifier une personne, sauf obligation
Si tu dois conserver longtemps pour audit : chiffre, contrôle d’accès strict, et garde un registre clair.
8) Prévois le mode incident : rétention adaptative
Le jour où ça chauffe, tu augmentes souvent le niveau de log. Et là tout explose.
Prévois un « plan incident » :
- debug activé max 1 à 4 heures
- rétention debug limitée (par taille)
- rotation accélérée
- export des logs clés vers un dossier d’enquête, séparé
Ça évite de « résoudre » l’incident en remplissant le disque et en créant un deuxième incident.
9) Teste ta rétention comme une fonctionnalité, pas comme un détail
Une règle de rétention non testée, c’est une règle imaginaire.
Checklist rapide :
- au bout de X jours, les fichiers disparaissent ils vraiment ?
- la compression se fait elle bien ?
- la purge respecte elle la taille max ?
- peux tu restaurer un log utile en moins de 10 minutes ?
- qui a accès à quoi ?
Et pense aussi à documenter. Même une page simple. Sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), je reviens souvent sur ce genre de « petites » pratiques qui évitent des grosses galères, donc si tu veux, garde le site dans tes favoris et repasse de temps en temps.
Mini configuration utile (Linux) : logrotate en version propre
Voici un exemple basique, pas magique, mais sain :
conf /var/log/monapp/*.log { daily rotate 14 size 100M compress delaycompress missingok notifempty copytruncate }
Ce que ça fait : rotation quotidienne, max 14 fichiers, ou plus tôt si ça dépasse 100 Mo, compression, et pas de crash si un fichier manque.
Conclusion : vise le contrôle, pas la perfection
Si je devais résumer :
- garde peu en brut, longtemps en agrégé
- impose des limites de taille
- coupe le bruit
- protège ce qui est sensible
- teste, et reteste
Les logs, c’est comme une cave. Si tu stockes tout sans trier, un jour tu n’oses même plus ouvrir la porte. Et c’est là que tu en as le plus besoin.
Questions fréquemment posées
Pourquoi est-il important de gérer la rétention des logs ?
La gestion de la rétention des logs est cruciale pour éviter d'avoir un disque saturé qui fait tomber les services, tout en conservant suffisamment d'informations pour diagnostiquer les pannes et incidents. Garder tous les logs indéfiniment crée une surcharge inutile, tandis que ne rien garder empêche toute analyse efficace.
Quelles sont les règles de base pour une politique simple de rétention des logs ?
Une politique simple peut commencer par : logs applicatifs debug conservés 7 jours, logs info entre 14 et 30 jours, logs système 30 jours, logs sécurité et audit entre 90 et 365 jours selon contraintes, et métriques agrégées conservées jusqu'à 13 mois. L'important est d'avoir une politique claire et applicable dès le départ.
Comment classer les logs pour une meilleure gestion de leur rétention ?
Il est recommandé de classer les logs par criticité plutôt que par outil. Par exemple : classe A pour sécurité, paiement, authentification ; classe B pour production standard (erreurs, warnings) ; classe C pour debug verbeux et tests. Cela permet d'appliquer des règles cohérentes même si la stack technologique évolue.
Quelle est la différence entre conserver les logs bruts et les données agrégées ?
Les logs bruts doivent être gardés peu longtemps (7 à 30 jours) car ils consomment beaucoup d'espace. En revanche, il est conseillé de conserver longtemps (6 à 24 mois) les données agrégées comme les comptages par minute ou les taux d'erreur, qui prennent moins de place mais permettent une analyse sur le long terme.
Pourquoi faut-il fixer une limite de taille en plus d'une limite temporelle pour la rétention des logs ?
Se baser uniquement sur une durée (ex: 30 jours) peut être risqué car en période de forte activité le volume peut exploser. Ajouter une limite de taille par service, par hôte ou globale permet d'éviter que le stockage ne soit saturé et déclenche automatiquement des purges avant que cela ne devienne critique.
Comment réduire le volume et le coût liés au stockage des logs ?
Il faut compresser les fichiers dès que possible (par exemple gzip ou zstd), garder les fichiers du jour en clair puis compresser dès J+1 et déplacer vers un stockage moins cher après J+7. Éliminer aussi le bruit inutile à la source en filtrant les accès trop verbeux ou répétitifs évite l'ingestion excessive et réduit considérablement l'espace utilisé.
0 Commentaires