Quelle est la meilleure façon de gérer la journalisation des erreurs pour les exceptions?

introduction

Si une erreur se produit sur un site Web ou un système, il est bien sûr utile de l'enregistrer et de montrer à l'utilisateur un message poli avec un code de référence pour l'erreur.

Et si vous avez beaucoup de systèmes, vous ne voulez pas que ces informations soient disséminées - il est bon d'avoir un seul emplacement centralisé pour cela.

Au niveau le plus simple, tout ce qui est nécessaire est un identifiant d'incrémentation et un vidage sérialisé des détails de l'erreur. (Et peut-être le "lieu centralisé" étant une boîte de réception de courrier électronique.)

À l'autre extrémité du spectre se trouve peut-être une base de données entièrement normalisée qui vous permet également d'appuyer sur un bouton et de voir un graphique des erreurs par jour, ou d'identifier le type d'erreur le plus courant sur le système X, si le serveur A a plus de base de données des erreurs de connexion que le serveur B, etc.

Je fais référence ici à la journalisation des erreurs / exceptions au niveau du code par un système distant - et non au suivi des problèmes "basé sur l'homme", comme cela est fait avec Jira, Trac, etc.

Des questions

Je suis à la recherche de réflexions de développeurs qui ont utilisé ce type de système, en particulier en ce qui concerne:

• Quelles sont les fonctionnalités essentielles dont vous ne pourriez pas vous passer?
• Quels sont les avantages d'avoir des fonctionnalités qui vous font vraiment gagner du temps?
• Quelles fonctionnalités peuvent sembler une bonne idée, mais ne sont-elles pas vraiment utiles?

Par exemple, je dirais qu'une fonction "afficher les doublons" qui identifie l'occurrence multiple d'une erreur (sans se soucier des détails "sans importance" qui pourraient différer) est assez essentielle.
Un bouton pour "créer un problème dans [Jira / etc] pour cette erreur" sonne comme un bon gain de temps.

Juste pour réitérer, ce que je recherche, ce sont des expériences pratiques de personnes qui ont utilisé de tels systèmes, de préférence avec les raisons pour lesquelles une fonctionnalité est géniale / terrible.
(Si vous allez théoriser de toute façon, marquez au moins votre réponse comme telle.)

J'ai été dans un projet où avec des erreurs client enregistrées à l'aide de la bibliothèque Microsoft Enterprise . Toute exception où envoyer à notre boîte aux lettres. Dans l'objet du courrier, nous avons ajouté un code de hachage d'erreur sérialisé pour éviter les messages en double. On pourrait bien sûr stocker des messages sérialisés dans une base de données et ainsi de suite.

Je vous recommande de consulter la bibliothèque Microsoft Enterprise et Log4Net .

Quelques fonctionnalités de Log4Net

• Prise en charge de plusieurs cadres
• Sortie vers plusieurs cibles de journalisation
• Architecture de journalisation hiérarchique
• Configuration XML
• Configuration dynamique
• Contexte de journalisation
• Architecture éprouvée
• Conception modulaire et extensible • Haute performance et flexibilité

Dans le cas des applications de base de données, une sorte d'ID (comme <TABLE>:<PrimaryKeyID>) qui vous permet de suivre les enregistrements dans la base de données liés à l'étendue où l'exception a été interceptée.

Je l'ai fait avec Oracle et PL / SQL, en enregistrant l'ID dans une table de base de données dans l'application, à partir du gestionnaire d'exceptions.

Une grande partie de ce que vous décrivez (c'est-à-dire les parties spécifiques de la journalisation) sont implémentées dans la bibliothèque d'entreprise comme l'a noté Amir Rezaei. Tout le reste semble être davantage de la partie analytique (c'est-à-dire que faire des journaux par la suite).

Dans mon cas, j'ai créé de petites applications et des scripts SQL qui ont facilité certaines choses. Voici certaines des choses que j'ai vraiment aimées:

• Le regroupement des mêmes erreurs (c.-à-d. 100 utilisateurs ont tous rencontré le même bogue à la même époque correspond à 1 rapport de bogue avec une note du nombre d'occurrences)
• Dépôt automatique d'un ticket dans le cas tracker (jamais réussi à le faire «au clic d'un bouton» mais toujours voulu)
• Nom d'utilisateur de l'utilisateur du logiciel (pas seulement la machine, qui est disponible avec la plupart des enregistreurs). Dans certains cas, les comptes d'utilisateurs automatisés ont causé des problèmes tandis que dans d'autres, des utilisateurs spécifiques ont été la cause de problèmes. "Je dois regarder Mike faire un peu de travail, il continue de provoquer une erreur spécifique."
• "Actions de l'utilisateur" - J'avais une pile globale qui garderait une trace de chaque clic / bouton actionnable lorsque l'utilisateur le ferait et que cela serait ajouté aux journaux d'erreurs. La reproduction de l'erreur consistait souvent à parcourir cette trace et à effectuer les mêmes étapes que l'utilisateur (j'avais espéré créer un générateur de test CodedUI qui analyserait la trace et effectuerait les étapes automatiquement, mais ne l'a jamais fait)

Parfois, les informations du journal sont tout simplement trop volumineuses pour être stockées sur le disque. Une approche que j'ai vue consiste à écrire vos entrées de journalisation dans un firehose (dans, disons, perl) quelque chose comme ceci:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

alors un analyste peut comprendre ce qu'il veut regarder.

Voici certaines choses que j'ai apprises de la surveillance des erreurs dans nos applications:

• Être capable de suivre un fichier journal roulant (j'utilise généralement log4net / log4j pour se connecter aux applications et BareTail pour suivre le journal) est vraiment utile pour pouvoir vérifier la santé actuelle d'un système
• Pour voir quand des problèmes ont été introduits et la fréquence à laquelle les problèmes surviennent, il est agréable de les avoir dans une base de données avec des horodatages pour que vous puissiez exécuter des rapports.
• La possibilité d'envoyer des alertes par e-mail / SMS / voix est très utile pour s'assurer que les systèmes restent en place, mais vous devez avoir la possibilité de personnaliser facilement les types d'erreurs qui vous alertent. Si vous recevez 800 e-mails d'erreur par jour, vous risquez de manquer celui "Oh non, le centre de données est en feu".

J'ai obtenu d'excellents résultats pour log4net, car il est très facile de se connecter à plusieurs endroits et d'apporter également des modifications à la configuration de la journalisation.

elmah est un système de journalisation des erreurs open source pour les applications ASP.NET et peut être ajouté à un système existant (à l'aide de NuGet http://nuget.codeplex.com/ ) rapidement et facilement. Il prend en charge divers backends et fonctions de notification.

Je ne connais personne qui l'ait ajouté à une application de bureau car il s'exécute en tant que site Web, mais rien ne vous empêche de l'exécuter en tant que service et de publier vos exceptions sur le Web.

http://code.google.com/p/elmah/

ELMAH (modules et gestionnaires de journalisation des erreurs) est une fonction de journalisation des erreurs à l'échelle de l'application qui est complètement enfichable. Il peut être ajouté dynamiquement à une application Web ASP.NET en cours d'exécution, ou même à toutes les applications Web ASP.NET sur une machine, sans avoir besoin de recompiler ou de redéployer.

Une fois que ELMAH a été déposé dans une application Web en cours d'exécution et configuré correctement, vous obtenez les fonctionnalités suivantes sans modifier une seule ligne de votre code:

• Journalisation de presque toutes les exceptions non gérées.
• Une page Web pour afficher à distance l'intégralité du journal des exceptions recodées.
• Une page Web pour afficher à distance tous les détails de toute exception enregistrée, y compris les traces de pile colorées.
• Dans de nombreux cas, vous pouvez consulter l' écran de décès jaune d' origine généré par ASP.NET pour une exception donnée, même avec le customErrorsmode désactivé.
• Une notification par e-mail de chaque erreur au moment où elle se produit.
• Un flux RSS des 15 dernières erreurs du journal ...