Question

Dans l'entreprise pour laquelle je travaille, j'ai créé une classe de journalisation des erreurs pour gérer les erreurs dans mon application ASP.net. C'est une classe personnalisée car nous ne sommes pas autorisés à installer de logiciel supplémentaire sur nos serveurs (nLog, log4net, etc.).

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

Le problème que je rencontre maintenant est que je reçois des erreurs que je ne sais pas trop comment les reproduire. Je n'ai entendu aucun rapport d'erreur d'aucun de mes utilisateurs. Je ne suis pas sûr de ce qu'ils font, ni même s'ils y voient une erreur.

Je songe à créer un journal des événements sur chaque page ou celles sur lesquelles je souhaite des informations supplémentaires. La conserver en tant que variable de session sur la page et y écrire des événements (début / fin de fonctions, modifications de variables, etc.). Alors seulement si une erreur est appelée pour que cet envoi soit accompagné du message d'erreur afin de voir s'il donne une meilleure image de ce qui se passe. J'espère que cette façon de procéder ne me fournira pas des tonnes de journaux des événements lorsque tous les utilisateurs accèderont à l'application;

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

Avez-vous des conseils sur les choses à rechercher?

Mise à jour:

@Saret: Je comprends où vous voulez en venir avec cette réponse et je suis d'accord. Je suis assez nouveau dans cette entreprise et j'ai toujours besoin d'apprendre comment faire les choses. Dans le passé, j'ai discuté avec mes collègues de la possibilité de disposer de ce produit ou d'utiliser ce projet open source. Le problème, c’est que nous travaillons sur des systèmes sécurisés et que l’obtention de l’approbation nécessaire prend beaucoup de temps, qu’il s’agisse d’une couverture supérieure et de la paperasserie. Je vais examiner la situation plus en profondeur car je pense qu’il est important d’avoir un bon système de journalisation des erreurs en place, actuellement rien n’est utilisé.

@Jim Blizard: Je voulais essayer d'éviter de consigner / stocker tout ce qui se trouve quelque part pour revenir sur ce qui est important pour la situation qui a provoqué l'erreur. Je ne voulais pas tomber dans une surcharge d'informations dont Roberto Barros avait parlé dans Artical. Ma méthode de réflexion actuelle consiste à conserver une chaîne en mémoire sur chaque page. Si une erreur est générée, lors de l'événement Page_Error de pages, saisissez cette chaîne et attachez-la à l'exception qui est consignée. De cette façon, je ne fais que consigner les erreurs / exceptions qui se sont produites et stocker le journal des événements avec cette erreur. Si rien ne se produit, le journal en cours de création est déposé dans le compartiment pour qu'il ne soit plus jamais vu.

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

Était-ce utile?

La solution

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

Je peux comprendre que vous n'êtes pas autorisé à installer de logiciel supplémentaire, mais que les bibliothèques de journalisation ne sont pas simplement des classes comme votre code personnalisé. Où est la différence fondamentale? Je pense que le temps passé à s’occuper de la mise en œuvre d’un cadre d’exploitation forestière serait peut-être mieux utilisé pour la promotion et la réalisation d’une analyse de rentabilisation en faveur d’une solution d’exploitation forestière raisonnable.

Autres conseils

J'ai déjà travaillé pour une agence qui n'autoriserait aucune installation autre que mon propre code ou leurs objets (horribles) COM. Si vous avez ce type de limitation, voyez si vous pouvez récupérer le source de log4net et l'inclure dans votre projet.

En ce qui concerne la journalisation, rien de mieux que log4net pour le moment.

J'ai personnellement adopté l'approche suivante pour consigner les erreurs (et consigner uniquement les erreurs) dans une application asp.net:

  • utiliser Void protégé Application_Error (expéditeur d'objet, EventArgs e) {     Server.Transfer ("~ / Support / ServerErrorSupport.aspx", true); } (Je fais un Server.Transfer pour conserver toutes les données de publication.)

  • Génère un ID d'erreur unique pour cette erreur (ainsi, les répétitions ultérieures de la même erreur peuvent être groupées). L'ID est un hachage calculé à partir d'une chaîne concaténée composée de: fichier, méthode, ligneNr et error.Message. Je récupère les valeurs de fichier, méthode et lineNr via une expression rationnelle sur la pile.

  • Je consigne toutes les données suivantes dans une structure xml (en fonction du type de données, je stocke la valeur différemment, value types = > ToString (), ISerializable = > sérialiser, ...):

    1. Nom de la machine: Application.Server.NomMachine
    2. PhysicalRoot: Application.Server.MapPath ("~ /")
    3. RequestUrl: Application.Request.Url.ToString ()
    4. Paramètres d'application: WebConfigurationManager.AppSettings
    5. Paramètres de connexion: WebConfigurationManager.ConnectionStrings
    6. QueryString: Application.Request.QueryString
    7. FormPost: Application.Request.Form
    8. Session: Application.Session
    9. HttpHeaders: Application.Request.Headers
  • 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 m'envoyer le rapport (fichier xml) par moi-même (lors du test / débogage très facile)
    • stockez-le localement ou dans une base de données pendant la production
    • parce que le fichier est juste une sauvegarde (sauvegarde sur hd), peu de choses peuvent se passer lors de la création du rapport d’erreur (comme une connexion au serveur, des problèmes de base de données, etc.), assurez-vous simplement que vous disposez des autorisations en é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 se tenir informé de l'évolution du bogue. Ceci est ajouté au document XML.
    • J'utilise un fichier xslt pour formater les données d'erreur (xml) dans un rapport d'erreur intéressant.

Pour les erreurs, je suis un grand fan de la journalisation BEAUCOUP. Lorsque les choses tournent mal, l'information est très utile. Je garderais l'intégralité du journal au même endroit (fichier texte ou table de base de données) avec un identifiant de session pour regrouper les événements pertinents.

Voici ce que j'aime enregistrer:

  • erreur / niveau de débogage (informations, débogage, problème, crash, etc ...)
  • heure
  • texte descriptif (généralement une ligne)
  • trace de pile (si possible)
  • données (utilisateur, session, valeurs de variable, etc ...)

La méthode la plus simple consiste à écrire dans un fichier texte, mais il peut être intéressant de l’avoir dans une base de données. Vous pouvez également utiliser le journal des événements Windows. Certaines choses à surveiller. Hmm ... Vous devrez vider vos journaux périodiquement.

Drôle d’histoire: une fois, un enregistreur d’erreur s’est connecté à la base de données, mais nous avions des informations d’identité de base de données erronées qui ont provoqué une erreur qui a ensuite été enregistrée ... Il a fini par avoir des débordements de pile dus à la récursion (IIRC).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top