Comment supprimer de manière conditionnelle les exceptions d'application écrites dans le journal des événements?

Question

Je travaille sur un service Windows qui interroge une connexion à un périphérique réseau toutes les 15 secondes. Si le service n'est pas en mesure de se connecter à un périphérique, il déclenche une exception et réessaie dans 15 secondes. Tout cela fonctionne très bien. Mais, disons que l'un des appareils est en panne depuis un jour ou plus. Je remplis mon journal d'exception avec la même exception toutes les 15 secondes. Existe-t-il un moyen standard d'empêcher l'écriture d'une exception dans le journal des événements si l'exception renvoyée n'a pas changé depuis le dernier nombre d'heures?

Answer 1

Un bon moyen d'obtenir ce dont vous avez besoin est d'utiliser le motif de conception du disjoncteur. J'ai d'abord lu à ce sujet dans le livre "Release It! Design and Deploy Production Ready Software" de Michael T. Nygard, de la presse pragmatique, p104-107.

L'idée du disjoncteur est qu'il se trouve sur le chemin de la connexion entre les systèmes, en passant les connexions à travers, en surveillant la "condition de rupture". Par exemple, il peut se déclencher uniquement si cinq connexions d'affilée ont toutes échoué.

Une fois le circuit rompu, tous les appels passant par le disjoncteur échouent immédiatement, sans consulter le service externe. Cela continue jusqu'à ce qu'un délai expire, lorsque le disjoncteur passe à l'état semi-ouvert. L'appel suivant est tenté - un échec entraîne la réinitialisation du délai, la réussite de la fermeture du disjoncteur et la reprise du système.

Un google rapide trouvé a post by Tim Ross qui se lit bien et va dans plus de détails.

Dans votre cas, vous pouvez utiliser un disjoncteur avec un délai d'attente de 10 minutes et un déclenchement de 5 défaillances. Vos fichiers journaux contiendraient alors, dans le cas d'un échec de la journée, cinq exceptions enregistrées pour le problème d'origine, puis seulement six de plus par heure (par rapport à 240 à 15 secondes d'intervalle), indiquant que le problème persiste.En fonction de vos besoins, vous pouvez inclure une «réinitialisation» manuelle du disjoncteur, ou vous pouvez simplement le laisser se réinitialiser automatiquement lorsque le délai de 10 minutes révèle que les choses sont revenues à la normale. Cela peut être utile - généralement, moins les administrateurs sysadmins ont de choses à faire, mieux ils l'aiment.

Answer 2

Peut-être avoir un flux de travail qui si les interrogations échoue un certain nombre de fois, l'intervalle d'interrogation est augmenté. par exemple. interroge toutes les 15 secondes pendant 3 fois, si elle échoue, augmentez l'intervalle d'interrogation à une minute, si elle échoue pendant n fois puis augmentez le temps à une heure.

Pour être honnête, le flux de travail ci-dessus ne résout pas vraiment votre problème. Si j'étais vous, j'inverserais le workflow. Au lieu d'interroger le serveur pour les périphériques, pourquoi ne pas le faire dans l'autre sens? Lorsqu'un périphérique est connecté à une machine en réseau, votre service côté client envoie un message au serveur, de sorte que le serveur sache que le périphérique est connecté et actif.

Hope this helps ...

RWendi

Answer 3

Si vous utilisez dans votre application bloc de gestion des exceptions, je suppose que vous faites, vous pouvez basculer entre les différentes politiques de gestion des exceptions. D'abord, il s'agit d'une règle qui écrit des informations sur les exceptions dans le journal des événements, puis, après n tentatives ou période, vous pouvez passer à la stratégie qui ne se connecte pas au journal des événements.

Augmenter la durée entre tentatives de connexion résoudra probablement votre problème. E.g. newTimeout = n * atomicTimeout où n est le nombre d'attemts.

Answer 4

Qu'en est-il ...

int count = 0; 
while (true) 
{ 
     try 
     { 
      AttemptStuff() 
     } 
     catch (Exception ex) 
     { 
      if(count < 10) 
      { 
       EventLog.WriteEntry("my service", ex.ToString(), EventLogEntryType.Error); 
       count++; 
      } 
     } 
} 

Answer 5

modèles de disjoncteurs est une bonne id idée dire

départ une certaine conception de la mise en œuvre de PHP, mais peut être appliquée à toute langue

http://artur.ejsmont.org/blog/PHP-Circuit-Breaker-initial-Zend-Framework-proposal