[BP#103] Désactiver certains logs d’accès du serveur web

[ACTLEM]

Cette bonne pratique est bonne mais trop restrictive à mon avis. Elle devrait parler des différents serveurs du service web, ainsi de parler de durée de rétention, rotation pour les logs nécessaires (mais pour ce point cela peut être dans une nouvelle BP). Je la renommerai en "Réduire les logs d'accès ou applicatifs des serveurs"

[ACTLEM]

Issues: #255 et #254

[ddebarbieux]

Il y a déjà deux issues (174 et 175) sur la gestion du stockage de la donnée. Le sujet vaut-il autant d'éffort ? Il faut aussi éviter les redites.

[ACTLEM]

Bonne remarque. Cela peut être résumée en une seule BP (103). Le risque est de mélanger désactivation de logs et redondance/rotation de logs et d'en faire une BP lourde.
De mon retour terrain, avoir une politique de cycle de vie de la donnée nécessaire à l'application est en général bien assimilée une fois que l'on énonce les problématiques (le data driven est passé par là). Par contre, le raisonnement sur les volumes de logs applicatifs c'est une autre histoire. J'ai trop souvent vu des disques full dans des équipes e-commerce car il n'y avait aucune réflexion sur les logs...et je parle d'expériences assez récentes. Ceci entraîne des disques durs supplémentaires à court terme pour assurer le coup sinon cela cause des problèmes applicatifs (non démarrage voire arrêts de services).
De mon point de vue cela ne fait pas trop d'avoir 2 BP sur le stockage de données nécessaires au service et 1 ou 2 BP sur les logs applicatives.

[ACTLEM]

@rlemaire @tbroyer @DocRoms un avis, on reste sur une BP globale sur les logs applicatifs/serveurs ou deux (une pour désactiver et une pour une politique de retention et rotation)?

[tbroyer]

+1 pour une fusion: le but est le même, limiter l'engorgement du disque (pour cette BP, il y a avait aussi l'économie d'accès I/O, mais je ne suis pas sûr que ce soit le plus impactant).

Parlant de "désactiver certains logs", on pourrait préciser qu'il s'agit finalement de configuration des logs dans leur ensemble: régler le niveau de logs (e.g. uniquement info/warning/error voire warning/error, et désactiver tout ce qui est debug/trace/etc.), régler le niveau de détail des logs (s'il y a des patterns configurables pour les messages, ne logger que les informations pertinentes), voire configurer encore plus finement (dans une appli avec des loggers nommés, configurer des niveaux de logs différents pour certains loggers qui sont anormalement verbeux par exemple) ; et pas simplement "je désactive l'access log d'Apache par ce que je n'en ai pas besoin". I.e. désactiver un "fichier de log" dans son ensemble vs configurer son contenu plus finement. La formulation actuelle pourrait lasser penser qu'on ne s'intéresse qu'à la première.

[ACTLEM]

Ok merci @tbroyer @LGnord, j'ai "annulé" l'ajout d'une BP. Et n'ai gardé que la modification de l'existante.