Quelle est la solution de journalisation la plus efficace et la plus performante pour ASP.NET?

Question

Je souhaite ajouter une connexion au site Web ASP.NET 2.0 dont j'ai hérité d'un développeur précédent. L'application crache simplement les exceptions lorsqu'elles se produisent, et il n'y a aucun enregistrement des transactions financières qui ont été exécutées.

J'ai regardé Log4net, que j'ai utilisé dans le passé, ainsi que NLog et BitFactory. Ce que je dois vraiment savoir, c'est comment implémenter au mieux un cadre de journalisation dans mon application, qui s'exécute dans SharePoint. J'ai besoin de quelque chose qui ne bloque pas l'application.

Existe-t-il un modèle de consignation généralement accepté pour ASP.NET? Comment avez-vous implémenté la connexion à votre site Web?

Answer 1

Le système que j'utilise dans beaucoup de mes applications ASP.NET est ELMAH (Error Logging Modules and Handlers). Je ne sais pas si elle offrira toutes les fonctionnalités que vous voulez, mais ce que j'aime vraiment, c'est obtenir l'écran jaune de la mort et la pile de trace par courriel chaque fois qu'une exception non gérée se produit.

Answer 2

Le meilleur que j'ai trouvé est log4.net. Nous l'utilisons pour consigner les erreurs non gérées et pour déboguer ASP.NET. C'est petit et ne plante pas. Nous l'utilisons sur un très grand site et je l'utiliserais à nouveau.

Answer 3

Toute journalisation que vous faites sera plus lente que de ne pas faire de journalisation. La journalisation ne concerne pas la performance, mais la fiabilité et la récupération. Le meilleur cadre de journalisation est celui que vous utilisez religieusement, le pire est celui que vous n'utilisez pas.

Nous utilisons log4net dans nos applications, rien à redire et n'avons jamais regardé en arrière. Y a-t-il des choses que j'aimerais modifier? Sûr. Mais nous ne sommes pas dans le secteur de l'exploitation forestière, nous écrivons des applications pour les clients, nous avons donc besoin d'un système de journalisation fiable *, et log4net convient. Cela dit, nous enveloppons nos journaux de débogage dans une vérification de la journalisation du débogage. Et dans les endroits de base seulement nous sommes allés au-delà de la vérification if (log.isDebugEnabled) typique et ajouté dans notre propre vérification de variable statique sur chaque instruction if. Au sommet des modules où nous soucions vraiment sur la performance (la plupart des parties de notre ORM ou d'autres pièces d'infrastructure), nous avons

#region Log4Net 
const string c_EnableDebugLogging = "com.techsoftinc.BusinessObjectsCore.EnableDebugLogging"; 
static readonly bool _EnableDebugLogging = Convert.ToBoolean(ConfigurationManager.AppSettings[c_EnableDebugLogging] ?? "false"); 

static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); 

//Do we support ultrafast logging? See What is REALLY the FASTEST way of (not) logging? in http://logging.apache.org/log4net/release/faq.html 
static bool debugLogging 
{ 
    get { return _EnableDebugLogging && log.IsDebugEnabled; } 
} 
#endregion 

et puis quand nous voulons déboguer nous avons (par exemple)

if (debugLogging) 
    log.DebugFormat("Executing sql: {0}", sql); 

Si _EnableDebugLogging est false alors le JIT va réduire la fonction debugLogging à false puis supprimer l'intégralité de l'instruction if (debugLogging) car elle ne peut jamais être vraie. Le JIT laisse littéralement tomber notre journalisation de débogage sur le sol si nous n'en avons pas besoin.

* fiable == fonctionne bien dans toutes les situations que nous avons rencontrées. Fiable ne signifie pas vraiment fiable au sens informatique du terme.