Comment puis-je activer et désactiver une trace dans la bibliothèque d'entreprise sans redémarrer le service?

Question

Donc, dans notre projet, nous avons la bibliothèque d'entreprise en tant que notre enregistreur. Évidemment, en production, nous ne voulons pas que notre trace de débogage se déconnecte tout le temps, mais nous aimerions être en mesure d'activer cette trace de débogage sans redémarrer le pool d'applications, mais je ne suis pas tout à fait sûr comment s'y prendre.

Dans le passé, j'aurais écrit quelque chose qui se connecterait uniquement au fichier si le fichier était présent. Ainsi, par exemple, si je voulais activer la fonction de débogage, le NOC abandonnerait un fichier dans le dossier du journal, puis la prochaine fois que le logger serait appelé, il verrait que le fichier est là et commencerait à le faire. Semble un peu ringard, mais ça fonctionne. Cependant, avec un site web, je devais écrire un enregistreur asynchrone complet qui savait comment mettre en file d'attente des informations à écrire, et je ne veux pas vraiment le faire, et je ne sais pas comment y parvenir en utilisant Enterprise. enregistreur Toutes les idées sur celui-ci serait génial.

L'autre pensée était d'avoir un drapeau dans le fichier de configuration ou le registre qui pourrait être changé pendant que le site est en cours d'exécution qui permettrait cette même trace.

Je cherche des idées ou des solutions. La principale préoccupation est que nous devons être en mesure d'activer et de désactiver cette journalisation à la volée.

Answer 1

Donc, je n'ai pas été capable de trouver une solution intégrée pour faire cela avec EnterpriseLibrary, donc c'est ce que j'ai fini par faire et ça semble fonctionner; en fait, j'ai étendu l'idée un peu plus loin en ajoutant un contrôle de priorité prioritaire.

J'ai créé une classe proxy pour écrire dans EL LogWriter. Ce qu'il fait est de vérifier l'existence d'un fichier (priority_override.txt dans ce cas). Si le fichier est présent, il lira le fichier et recherchera le texte PriorityLevel={n} où n est le remplacement. S'il est en mesure d'obtenir ce numéro de remplacement, il remplacera le niveau de priorité fourni dans le code. J'utilise ceci pour forcer fondamentalement une priorité élevée sur toutes les déclarations de log pour qu'elles ne soient pas bloquées par le filtre.

Mon filtre par défaut empêche tout ce qui se trouve en dessous d'une priorité 5 de se rendre aux écouteurs; cette astuce me permet de surcharger cela en augmentant temporairement la priorité de tous les journaux. Donc, étant donné que le débogage est généralement la priorité 1, il n'est pas journalisé. Si je dépose un fichier dans le répertoire du journal appelé priority_override.txt qui a le contenu PriorityLevel=99, alors TOUTES les instructions du journal le rendront aux écouteurs configurés et seront traitées en conséquence. Tout le reste est juste une question normale de configuration de EL avec les catégories et les priorités appropriées etc Ainsi, par exemple, si ma plus haute priorité est 5 et qui déclenche un email, alors je passerais juste à 4 pour que tout soit enregistré mais les email ne être envoyé. Ensuite, lorsque nous avons terminé le dépannage en production, par exemple, nous supprimons simplement le priority_override.txt et tout revient à la normale. En outre, nous n'avons plus à gérer le changement des fichiers de configuration séparément pour nos environnements de test. Nous pouvons simplement laisser le priority_override.txt dans le dossier du journal dans chaque environnement respectif.