Comment enregistrer les erreurs (exceptions) dans vos applications ASP.NET ?

Question

Je recherche le meilleur moyen de consigner les erreurs dans une application ASP.NET.Je souhaite pouvoir recevoir des e-mails lorsque des erreurs surviennent dans ma candidature, avec des informations détaillées sur l'exception et la demande en cours.

Dans mon entreprise, nous avions notre propre ErrorMailer, capturant tout ce qui se trouvait dans Global.asax Application_Error.C'était "Ok" mais pas très flexible ni configurable.

Nous sommes récemment passés à NLog.C'est beaucoup plus configurable, on peut définir différentes cibles pour les erreurs, les filtrer, les tamponner (pas encore essayé).C'est une très bonne amélioration.

Mais j'ai découvert dernièrement qu'il existe tout un Namespace dans le framework .Net à cet effet : Système.Web.Management et il peut être configuré dans le Surveillance de la santé section du web.config.

Avez-vous déjà travaillé avec la surveillance de la santé .Net ?Quelle est votre solution pour la journalisation des erreurs ?

Answer 1

j'utilise elmah.Il a des fonctionnalités vraiment intéressantes et voici un CodeProjet article à ce sujet.Je pense que l'équipe StackOverflow utilise également elmah !

Answer 2

j'ai utilisé Log4net, configuré pour envoyer par courrier électronique les détails des erreurs fatales.Il est également configuré pour tout enregistrer dans un fichier journal, ce qui est inestimable lorsque vous essayez de déboguer des problèmes.L'autre avantage est que si cette fonctionnalité standard ne fait pas ce que vous souhaitez, il est assez facile d'écrire un appender personnalisé qui peut traiter les informations de journalisation selon les besoins.

Cela dit, je l'utilise en tandem avec un gestionnaire d'erreurs personnalisé qui envoie un e-mail HTML avec un peu plus d'informations que celles incluses dans les e-mails log4net standard - page, variables de session, cookies, variables de serveur http, etc.

Celles-ci sont toutes deux liées à l'événement Application_OnError, où l'exception est enregistrée comme une exception fatale dans log4net (ce qui entraîne ensuite son envoi par e-mail à une adresse e-mail spécifiée), et également gérées à l'aide du gestionnaire d'erreurs personnalisé.

J'ai entendu parler pour la première fois Elma de l'entrée du blog Coding Horror, Crash de manière responsable, et bien que cela semble prometteur, je n'ai pas encore mis en œuvre de projets.

Answer 3

J'utilise les objets Logging de l'Enterprise Library.Il permet d'avoir différents types de journalisation (fichier plat, e-mail et/ou base de données).Il est assez personnalisable et possède une très bonne interface pour mettre à jour votre web.config pour la configuration de la journalisation.Habituellement, j'appelle ma journalisation à partir de On Error dans Global.asax.

Voici un lien vers le MSDN

Answer 4

J'utilise log4net et partout où je attendre une exception, je l'enregistre au niveau approprié.J'ai tendance à ne pas relancer l'exception car elle ne permet pas vraiment une expérience utilisateur aussi agréable, il y a moins d'informations que vous pouvez fournir dans l'état actuel.

Application_Error sera également configuré pour intercepter toute exception non attendue et l'erreur est enregistrée en tant que priorité fatale via log4net (enfin, les 404 sont détectés et enregistrés en tant qu'informations car ils ne sont pas si graves).

Answer 5

Mon équipe utilise log4net d'Apache.C'est assez léger et facile à installer.Mieux encore, il est entièrement configurable à partir du fichier web.config, donc une fois que vous avez les points d'ancrage dans la configuration de votre code, vous pouvez complètement changer la façon dont la journalisation est effectuée simplement en modifiant le fichier web.config.

log4net prend en charge la journalisation vers une grande variété d'emplacements : base de données, courrier électronique, fichier texte, journal des événements Windows, etc.Mon équipe l'a configuré pour envoyer des informations détaillées sur l'erreur à une base de données, ainsi qu'envoyer un e-mail à toute l'équipe avec suffisamment d'informations pour que nous puissions déterminer de quelle partie du code l'erreur provient.Nous savons alors qui est responsable de ce morceau de code, et ils peuvent accéder à la base de données pour obtenir des informations plus détaillées.

Answer 6

J'ai récemment créé un service Web asp.net avec NLog, que j'utilise pour toutes mes applications de bureau.La journalisation fonctionne correctement lorsque je débogue dans Visual Studio, mais dès que je passe à IIS, le fichier journal n'est pas créé ;Je n'ai pas encore déterminé pourquoi, mais le fait que je doive chercher une solution me donne envie d'essayer autre chose pour mes besoins asp.net !

Answer 7

Nous utilisons EnterpriseLibrary.ExceptionHandling.Logging.Je l'aime un peu mieux que log4net car non seulement nous contrôlons complètement la journalisation, mais nous pouvons également contrôler la décision Throw/NoThrow dans la configuration.

Answer 8

Nous utilisons un utilitaire de journalisation personnalisé que nous avons écrit.Cela vous oblige à implémenter vous-même la journalisation partout où vous en avez besoin.Mais cela vous permet également de capturer bien plus que la simple exception.

Par exemple, notre code ressemblerait à ceci :

Try
  Dim p as New Person()
  p.Name = "Joe"
  p.Age = 30
Catch ex as Exception
  Log.LogException(ex,"Err creating person and assigning name/age")
  Throw ex
End Try

De cette façon, notre enregistreur écrira toutes les informations dont nous avons besoin dans une base de données SQL.Nous avons configuré des alertes par e-mail au niveau de la base de données pour rechercher certaines erreurs ou des erreurs fréquentes.Cela nous aide à identifier exactement d’où viennent les erreurs.

Ce n'est peut-être pas exactement ce que vous recherchez.Une autre approche similaire à l'utilisation de Global.asax est pour nous une technique d'injection de code comme AOP avec PostSharp.Cela vous permet d'injecter du code personnalisé au début et à la fin de chaque méthode ou à chaque exception.C'est une approche intéressante mais je pense qu'elle peut entraîner une lourde surcharge en termes de performances.