Identification des exceptions en double pour le suivi des bogues

Question

J'ai développé une application «Proof of Concept» qui consigne les exceptions non gérées d'une application dans un système de suivi des bogues (dans ce cas, Team Foundation Server, mais ce pourrait être n'importe quel système de suivi des bogues) . Une limitation de cette idée est que je ne veux pas que les éléments de bogue dupliqués soient ouverts chaque fois que la même exception est levée (par exemple, beaucoup d'utilisateurs rencontrent l'exception - c'est toujours un "bogue" unique). Ma première tentative a été de stocker le type d'exception, le message et la trace de pile dans les champs du système de suivi des bogues. Le composant de journalisation faisait ensuite une requête sur le bogue "Store" pour voir s'il y avait un bogue ouvert. même information. (Cet exemple est .NET - mais je pense que le concept est indépendant de la plate-forme). Le problème est évidemment que ces champs peuvent être très grands (en particulier la trace de la pile) - et nécessite une implémentation de type "Full-Text" pour les stocker et la recherche est très coûteuse. Je me demandais quelles approches ont été définies pour ce problème. J'avais entendu dire que FogBugz par exemple avait une telle fonctionnalité pour le suivi automatique des bogues, et était curieux de savoir comment il a été mis en œuvre.

Answer 1

Vous pouvez créer un hachage de somme de contrôle de la trace de la pile et l'enregistrer en tant que colonne indexée. De cette façon, la requête sur le Bug Store serait assez rapide pour éviter les doublons lors de l'insertion.

Answer 2

Si vous avez la trace de la pile, vous pouvez trouver la dernière instruction dans la trace de la pile et la comparer avec celles déjà enregistrées. Si les symboles étaient inclus, vous obtiendriez également le numéro de ligne. Donc, maintenant vous avez deux choses à comparer, le numéro d'erreur réelle et la déclaration qui a échoué et, éventuellement, le numéro de ligne réelle. Si quelque chose a déjà été connecté avec tous ceux-ci, alors il est plus que probable (pas 100%, bien sûr) le même problème. En fait, vous pouvez probablement analyser la trace de la pile avec le mot "at", car chaque ligne dans la trace de la pile commence par "at". Donc, cherchez le dernier "at", obtenez cette ligne, comparez-la avec la dernière ligne "at" des traces de la pile stockée, et vous pourriez réellement avoir quelque chose.

HTH!

Answer 3

Vous pouvez consulter le code source de l'une des solutions Open Source existantes qui agrègent les exceptions.

Par exemple: https://github.com/getsentry/sentry/tree/master/src/sentry

Il est pas un problème simple et il y a des heuristiques complexes (par exemple même exception signalé de différentes façons sur les différents navigateurs, par exemple des exceptions dues à des extensions de navigateur sont communes et sont rarement importants).