Version imprimable
Dans ce cas ce n'est pas des logs mais de l'audit de perfmances, dans ce cas un fichier specialiser pour les performances peut etre utile ou carrement une table/base de donnees propre a l'audit qui peut etre requetee.Citation:
Imaginons un système de batch, j'ai sûrement envie de savoir dans mes logs, le temps qu'à pris un gros batch, quelques infos sur les fichiers reçus (genre la taille et qui les envoie)...
Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.Citation:
Envoyé par Angelsafrania
Je signale juste une typo dans le titre de l'article (enfin dans le fils des actualités) :
Pièce jointe 178519
Et les contrats représenteraient 90% du code, les coûts de développement seraient dix fois importants, la compilation durerait une minute, et les programmeurs débogueraient les contrats.Citation:
Envoyé par ddoumeche
Les contrats, comme les tests ou les spécifications, sont avant tout une autre façon, peu compacte et partielle mais intentionnelle et plus compréhensible, d'exprimer le programme. C'est avant tout la redondance de ces modes d'expression qui entraîne la fiabilité. Une bonne solution dans les domaines où l'on a besoin de garanties fortes mais une solution coûteuse et fastidieuse.
Entre autre à savoir que le flow normal ne s'est pas déroulé à cause d'une erreur de leur côté et non du tien. Et ça n'a rien à voir avec la validité des entrées. :weird:Citation:
Envoyé par mermich
Sauf celles qui font de l'I/O quand l'I/O est défaillant :) Et les erreurs de programmation genre récursion infinie.Citation:
Envoyé par ddoumeche
Mais je suis plutôt d'accord avec le billet de blog. Pour moi il y a deux grandes sortes de log : les logs d'erreur et les journaux applicatifs.
Dans certains domaines, il est obligatoire (légalement ou par politique interne) de journaliser les actions les plus importantes qui surviennent. Des transactions sont mêmes mises en place pour assurer l'atomicité de (exécution de l'opération + logging). Si on ne peut pas logger, on ne fait pas l'action.
J'aime bien les approches comme Event Sourcing, la partie journalisation est "gratuite" car la couche persistance stocke déjà une suite d'événements plutôt qu'un état en base de données. On a toute la frise chronologique du runtime, il n'y a plus qu'à exploiter les données.
De manière générale, je pense aussi qu'il faut faire basculer un maximum de choses du monde des exceptions vers le monde des événements business normaux dans la vie d'une application. Les exceptions sont en général plus coûteuses en termes de performances, plus fragilisantes pour l'exécution et plus difficiles à exploiter correctement. Avec une bonne analyse métier, il est souvent facile de changer une exception (sur des accès concurrents par exemple) en un déroulement applicatif normal qui peut s'inspirer de ce qui se passe dans la vie réelle (file d'attente, retry, etc.) Ca se retrouve aussi dans les logs mais c'est moins disruptif.
Quand je lis que lorsque on a fait un bon design alors le log des appels de méthode suffit je me marre.
nos amis de la Business Machine nous on pondu un tel truc
effectivement super facile de localiser l'endroit où se produit l'erreur.
J'avais (oui on à fini par les mettre à la porte et à développer sérieusement) tous le cheminement des appels successif jusqu'à l'erreur.
Je pouvais donc savoir où mais comme je n'avais que ça impossible de savoir pourquoi.
supposant que nous ayons disons 5 classes avec chacun 4 méthodes. et que pour toutes ces méthode nous aillons été très rigoureux et traçons chaque appel.
tout cela est plutôt simple. mais voilà le système instancie des milliers d'exemplaire de ces classes assure des centaines de traitement en parallèle le tout pour traiter des millions de données différentes.
du coup dans les logs les appels simultanés à ces quelque classes se retrouve dispersés.
et voila comment sur une simple exécution d'une requête on sait qu'on a à la ligne 35 de la méthode toto de la classe Titi une erreur SQL "Table or View dose not exist"
Mais on ne sais pas qu'elle table parmi les quelques dizaines de milliers qui sont présente dans les quelques centaine de bases, pas plus q'on ne sait quelle requête ni pour quelle donnée. ne riez pas c'est IBM qui a produit ça.
Alors on a envie de mettre des log bien plus précis et on se retrouve avec des fichier de log qui font plus d'une rotation par minute. et comment ils sont encore une fois inexploitable.
bref si les log permettaient à eux seul de faire du debug ça se saurait depuis longtemps.
A+JY
