Discussion :

[le Daoud]

Bonjour,

Afin d'améliorer le suivi et la maintenance d'une application, j'ai integré un système de log (log4net).
Cependant je manque cruellement de recul à ce niveau et avance un peu trop à l'aveugle. Pourriez-vous vous, à travers votre expérience, m'éclairer sur vos méthodes dans ce domaine ? Notamment :

- quels sont les éléments qui selon vous doivent figurer dans un fichier de log
- créez vous plusieurs fichiers de log ? (comme un fichier avec les connexions, un avec les erreurs, ...)
- quelles différences faites-vous entre la prod et le dev ?
- Utilisez-vous d'autres types de sortie que les fichiers ?
- Quels éléments vous sont utiles dans un événement (heure, thread,...)

Merci

[Marco85]

Pardon de répondre de cette façon mais ça dépend considérablement du type d'application que tu développes.

Personnellement, je développe en embarqué et au vu des ressources extrêmement limitées, le log est vraiment succinct.

Marco85

[le Daoud]

Pas de pb, en soit ta réponse est intéressante.
Merci.

[BugFactory]

Ca dépend aussi du but du log. Si je cherche un déboguer un programme, il est classique qu'au début d'une méthode complexe j'enregistre le nom de la méthode et ses paramètres. Si je cherche à surveiller le fonctionnement d'une application en production, je vais surveiller de près les entrées-sorties.

Un détail important peut-être de toujours respecter un format donné pour un enregistrement. Ceci peut permettre d'extraire rapidement les enregistrements pertinents d'un journal de grande taille. Par exemple "date;fonction;type;message".

La date et l'heure devraient toujours figurer dans chaque enregistrement. Si c'est une erreur, la position dans le code (classe, méthode, fichier, ligne) devrait également s'y trouver.

Dans une application console, l'écran peut être une autre sortie. Remarquez que quand c'est possible, cette sortie se retrouve souvent redirigée vers un fichier de toute façon. Ceci permet néanmoins d'avertir l'utilisateur immédiatement.

N'oubliez pas d'effacer les logs très vieux, ou de prévenir l'utilisateur de le faire si vous voulez lui éviter de se demander pourquoi son disque dur rétrécit.

[mhooreman]

Il faut tout d'abord savoir que presque tous les systemes de logs proposent divers niveaux.

Il faut utiliser les niveaux: debug, info, warning, critical, ..., ce qui permettra à tes utilisateurs d'être plus ou moins verbeux.

Quant à ce que tu loggues, il est évident qu'il y aura moins à logger pour un traitement de texte que pour une application critique, du style transferts banquaires.

D'un autre coté, trop d'informations nuit à l'information. Il faut que tu vois quel publique tu cible, et quelle est la capacité des disques durs du public en question...