Dans mon précédent article, j’ai parlé de rôle important des logs dans le cycle de vie d’une application. Je vais ici vous exposer les propriétés d’une bonne implémentation des logs.
Niveau de log
5 niveaux de log sont habituellement utilisés pour logs: TRACE, DEBUG, INFO, WARN, ERROR. TRACE est utilisé pour les informations les moins importantes, et ERROR pour les informations les plus importantes. Le niveau de logs utilisé doit être cohérent avec l’information contenu dans le message de log.
Le niveau TRACE est très verbeux et log a à peu près tout ce qui se passe dans l’application: réception des requêtes, entrée et sortie des méthodes, envoie de la réponse, etc.
Le niveau DEBUG log les informations utiles pour investiguer un bug.
Le niveau INFO log les informations offrant un feedback sur les opérations que fait l’application.
Le niveau WARN log les situations potentiellement problématiques mais qui n’empêchent pas l’application de fonctionner.
Le niveau ERROR est généralement réservé aux situations anormales, non prévues dans le cadre d’un fonctionnement normal. Il peut s’agir d’une base de données injoignable, une erreur réseau, une incohérence dans l’état du système. Un log a ce niveau consacre l’impossibilité du système à aller au bout de la requête. Les logs ERROR signalent qu’une intervention est nécessaire pour ramener l’application dans un état de fonctionnement normale.
Le niveau de log par défaut est INFO pour la plupart des systèmes. Ce niveau doit permettre d’avoir une compréhension acceptable du système, sans pour autant être inondé de log.
Granularité de l’information
Le message de log doit inclure la bonne granularité d’information: assez d’éléments pour que le log soit utile, mais pas plus que le nécessaire. Il faut éviter les données redondantes, et aussi celles qui n’apportent pas d’informations utiles.
Nombre de logs par opération
A partir du niveau INFO, il faut choisir avec précaution où, quand et quoi logguer. Lorsque chaque opération entraîne un nombre important de logs, alors les logs peuvent devenir difficiles à exploiter. Aussi, dans ce cas, l’administrateur peut être tenté de désactiver les logs ou de passer au niveau WARN ou même ERROR pour réduire drastiquement le nombre logs. Gitlab est un exemple d’application connue produire énormément de logs, au niveau INFO.
Informations personnelles
Il convient de manier les informations personnelles avec précaution. Si les logs ne peuvent pas être mis à disposition de ceux qui en ont besoin sans enfreindre une réglementation telle que le RGPD, alors les logs perdent une grande partie de leur utilité. Inclure le minimum d’éléments nécessaires pour que le log soit exploitable est une pratique à encourager.
Informations confidentielles
Il ne faut pas inclure d’ informations secrètes ou confidentielles dans les logs: mot de passe, code pin, numéro de carte bancaire, clés d’API… ces informations n’ont pas vocation à se retrouver dans un message de log. Les logs ne doivent pas fragiliser la sécurité globale du système.
Organisation Modulaire
Organisez vos logs de façon modulaire. Il doit être possible d’activer sélectivement les logs en cas de besoin. Quelques cas d’usages à prendre en compte:
- Activer les logs pour un module de l’application et les désactiver pour un autre
- Configurer simultanément un niveau de logs différent entre deux modules
- Combiner une configuration globale et une configuration par module. Par exemple, avoir WARN comme niveau de log global, mais DEBUG comme niveau de log pour le module xyz.
Ingestion et stockage
Optimiser la quantité globale d’information produite par les logs. Que ce soit le nombre de logs produits à un niveau donné ou la quantité d’information contenue dans un message de log, cela doit faire l’objet d’une décision réfléchie pour maximiser l’intérêt et l’utilité par rapport au coût. Une bonne implémentation de log ne produit qu’une quantité modérée de messages à partir du niveau INFO.
A la fin de la journée, les logs sont des données à ingérer, stocker et exploiter. Et cela à un coût financier.
Identifiant de corrélation
Lorsqu’une application est asynchrone ou distribuée, il est utile d’inclure un identifiant de corrélation aux logs pour chaque requête. Cela permettra de faire le lien entre tous les logs d’une même requête, ce qui facilitera l’exploitation de ces logs
Audit des opérations d’administration
Selon le type d’application ou le contexte d’utilisation, certaines opérations peuvent être sensibles. Si l’on ajoute à cela la menace cyber de plus en plus présente, il convient de prévoir des logs qui permettent d’auditer les opérations d’administration de l’application: changement de configuration, création ou suppression d’objets, octroi ou retrait de droits, etc. Avec des logs d’audit spécifiques, il sera possible de suivre ces opérations dans le temps, de les analyser et prendre des mesures de remédiation si nécessaire.
Conclusion
Les logs sont plus importants que ce qu’on peut penser à première vue. Consacrez un peu de temps au début de chaque projet pour échanger sur comment produire des logs adaptés pour ce projet. Ce petit temps sera largement rentabilisé lors de la phase d’exploitation.