Combien d'informations à consigner des erreurs?

Question

Dans la société pour laquelle je travaille, j'ai créé une classe Error Logging pour gérer les erreurs dans mon application ASP.net. C'est une classe personnalisée car nous ne sommes pas autorisés à installer des logiciels supplémentaires sur nos serveurs (nLog, log4net, etc.).

Je l'utilise actuellement dans deux de mes projets et j'en ai vu de bons résultats. En ce moment, je piège les erreurs qui provoquent des erreurs de page et d'application. Il envoie et stocke le message d'erreur et toutes les exceptions internes.

Le problème que j'ai maintenant est, je reçois des erreurs que je ne suis pas sûr de savoir comment reproduire. Je n'ai pas entendu de rapports d'erreurs de la part de mes utilisateurs. Je ne suis pas sûr de ce qu'ils font, ou même s'ils voient cela comme des erreurs.

Je pense à créer un journal des événements sur chaque page, ou ceux sur lesquels je veux des informations supplémentaires. Le garder comme une variable de session sur la page, et en lui écrivant des événements (début/fin des fonctions, changements de variable, etc.). Alors seulement si une erreur est appelée pour que cela envoie avec le message d'erreur pour voir si cela donne une meilleure image de ce qui se passe. J'espère que le faire de cette façon ne me donnera pas beaucoup de journaux d'événements lorsque tous les utilisateurs accèdent à l'application, je veux juste que ça se passe juste avant que l'erreur n'arrive à un seul utilisateur.

Connaissez-vous des pièges que je devrais surveiller avec méthode?

Avez-vous un conseil pour les choses à rechercher?

Mise à jour:

@Saret: J'understnad où vous venez de cette réponse et je suis d'accord. Je suis relativement nouveau dans cette entreprise et j'ai encore besoin d'apprendre comment ils font les choses. Dans le passé, j'ai eu des conversations avec mes collègues sur ce que ce serait génial d'avoir ce produit, ou d'utiliser ce projet open source. Le problème vient du fait que nous travaillons sur des systèmes sécurisés et que l'obtention d'une approbation pour obtenir ces documents prend beaucoup de temps, de couverture et de paperasserie. Je vais examiner la situation plus en détail parce que je crois qu'il est important de mettre en place un bon système de consignation des erreurs, mais rien n'est actuellement utilisé.

@Jim Blizard: Je voulais essayer de sortir de la journalisation/stocker tout à un endroit pour revenir et découvrir ce qui est important pour la situation qui a causé l'erreur. Je ne voulais pas tomber dans la surcharge d'informations dont on parle dans l'artique que Roberto Barros a lié. Ma méthode de pensée actuelle est, en gardant une chaîne en mémoire sur chaque page, et si une erreur est levée, sur les pages de l'événement Page_Error, saisissez cette chaîne et attachez-la à l'exception qui est enregistrée. De cette façon, je ne consigne que les erreurs/exceptions qui se sont produites et stocke le journal des événements avec cette erreur. Si rien ne se passe, le journal en cours de création est déposé dans le compartiment de bits pour ne plus jamais être vu.

@Roberto Barros: Merci pour ce lien, je me souviens l'avoir lu quelque part mais j'ai oublié de le sauvegarder.

Answer 1

Cela peut ne pas être la réponse exacte que vous recherchez, mais pourquoi développer votre propre mécanisme de journalisation des erreurs lorsqu'il existe des outils puissants (que vous mentionnez) qui gèrent tous ces problèmes clés pour vous?

Je peux comprendre que vous n'êtes pas autorisé à installer un logiciel supplémentaire, mais ne consignez pas les bibliothèques uniquement dans des classes comme votre code personnalisé? Où est la différence fondamentale?Je pense que le temps passé à s'inquiéter de la mise en œuvre d'un cadre de journalisation pourrait être mieux dépensé en plaidant et en faisant une analyse de rentabilisation pour une solution de journalisation décente.

Answer 2

Pour les erreurs, je suis un grand fan de l'enregistrement d'un lot. Quand les choses tournent mal, l'information est très précieuse. Je conserverais l'ensemble du journal à un endroit (fichier texte ou table de base de données) avec un identifiant de session pour regrouper les événements pertinents.

Answer 3

J'ai déjà travaillé pour une agence qui ne permettait pas l'installation de tout ce qui n'était pas purement mon propre code ou de leurs (horribles) objets COM. Si vous avez ce type de limitation, vérifiez si vous pouvez récupérer la source de log4net et l'inclure dans votre projet.

Il n'y a rien de mieux que log4net en ce qui concerne la journalisation.

Answer 4

Voici ce que je veux vous connecter:

• erreur/niveau de débogage (info, debug, problème, accident, etc ...)
• temps
• texte descriptif (une ligne habituellement)
• trace de la pile (si possible)
• de données (utilisateur, session, les valeurs des variables, etc ...)

La manière la plus simple est d'écrire dans un fichier texte, mais cela peut être sympa de l'avoir dans une base de données. Vous pouvez également utiliser le journal des événements Windows. Certaines choses à surveiller. Hmm ... Vous aurez besoin de vider vos journaux périodiquement. Drole story: une fois, nous avions un logger d'erreurs connecté à la base de données, mais nous avions de mauvaises informations de base de données qui provoquaient une erreur qui était ensuite consignée ... Terminé obtenant des débordements de la récursion (IIRC).

Answer 5

Personnellement, je pris l'approche suivante sur erros d'exploitation forestière (et seulement enregistrer les erreurs) dans une application asp.net:

• utilisation protected void Application_Error(object sender, EventArgs e) { Server.Transfer("~/Support/ServerErrorSupport.aspx", true); } (je fais un Server.Transfer pour conserver toutes les données de poste.)

• Génère un ID d'erreur unique pour cette erreur (afin de regrouper les réponses ultérieures pour la même erreur). L'ID est un hachage calculé à partir d'une chaîne concaténée composée de: fichier, méthode, ligneNr et erreur.Message. Je reçois les valeurs file, method et lineNr via une regex sur la pile.

• je me connecte toutes les données suivantes à une structure XML (en fonction du type de données, je stocke la valeur différente, les types de valeur => ToString(), ISerializable => sérialisation, ...):

  1. MACHINENAME: Application.Server.MachineName
  2. PhysicalRoot: Application.Server.MapPath ("~ /")
  3. RequestUrl: Application.Request.Url.ToString()
  4. applicationSettings: WebConfigurationManager.AppSettings
  5. ConnectionSettings: WebConfigurationManager.ConnectionStrings
  6. QueryString: Application.Request.QueryString
  7. FormPost: Application.Request.Form
  8. Session: Application.Session
  9. httpHeaders: Application.Request.En-têtes

• Enregistrez la structure XML en tant que fichier local contenant l'ID d'erreur et un horodatage. J'ai choisi cette approche parce que:

  • Je peux envoyer le rapport (fichier XML) à moi-même (lors du test/débogage très facile)
  • magasin localement ou dans une base de données lors de la production
  • parce que la le fichier est juste un (dump vers hd) enregistrer pas beaucoup peut aller mal pendant la création du rapport d'erreur (comme une connexion au serveur, problèmes de DB, etc), assurez-vous juste que vous avez des autorisations d'écriture.
  • De plus, sur la page servererrorsupport.aspx, après avoir enregistré le fichier xml, l'utilisateur a la possibilité d'inclure des informations supplémentaires et d'ajouter une adresse électronique pour rester informé des progrès concernant le bogue. Cela est ajouté au document XML.
  • J'utilise un fichier xslt pour formater les données d'erreur (xml) dans un bon rapport d'erreur.