C # Detect Fail Remote Application Failure

Question

Est-ce que quelqu'un connaît un moyen de détecter si une application distante a échoué / est tombée en panne? Je veux dire quand cela devient inutilisable - vous verrez généralement " pas de réponse " dans la barre de titre, dans ce cas - mais la clé est que l'application est toujours en cours d'exécution; il ne suffit donc pas de constater que le processus ne fonctionne plus.

WMI ne prend pas en charge l’utilisation de System.Diagnostics.Process.Responding sur une machine distante .. et il ne semble y avoir aucune autre propriété WMI que je puisse interroger dans Win32_Process pour obtenir ce type d’informations.

Answer 1

Pour déterminer la "vivacité" d'un programme, il est important de mesurer cet aspect afin de le définir de manière utile.

Plusieurs approches simples de "procuration" sont superficiellement séduisantes en raison de leur simplicité, mais ne mesurent pas fondamentalement l’aspect important.

Les plus courants sont peut-être le "Le processus est-il en vie"? et "fil de diffusion de pulsation séparé". probablement parce que c'est si simple à faire:

bool keepSending = true; // set this to false to shut down the thread
var hb = new Thread(() => 
    {
         while (true)
             SendHeartbeatMessage();   
    }).Start();

Cependant, ces deux problèmes présentent un grave inconvénient: si le ou les threads actifs de votre application se bloquent (par exemple, passer dans une boucle infinie ou une impasse), vous continuerez à envoyer joyeusement des messages OK. Pour la surveillance basée sur le processus, vous continuerez à voir le processus 'en vie' alors qu'il ne remplit plus sa tâche réelle.
Vous pouvez améliorer le thread de nombreuses manières (en augmentant considérablement la complexité et les problèmes de thread de hasard) en superposant des tests de progression sur le thread principal, mais cela prend la mauvaise solution et tente de la pousser vers la bonne.

Le mieux est de faire en sorte que la ou les tâches exécutées par le programme fassent partie du contrôle d’activité. Peut-être battre directement à partir du thread principal après chaque sous-tâche effectuée (avec un seuil pour s'assurer que cela ne se produit pas trop souvent) ou simplement regarder la sortie (si elle existe) et s'assurer que les entrées donnent des sorties.

Il est toujours préférable de valider cela à la fois en interne (au sein du programme) et en externe (surtout s'il y a des consommateurs / utilisateurs externes du programme). Si vous avez un serveur Web: essayez de l'utiliser, si votre application est un système basé sur une boucle d'événement: déclenchez les événements auxquels elle doit répondre (et vérifiez que la sortie est correcte). Quoi que vous fassiez, considérez toujours que vous souhaitez vérifier que utile et que le comportement correct se produit plutôt que n'importe quelle activité du tout.

Plus vous vérifiez non seulement l'existence du programme, mais aussi actions , plus votre vérification sera utile. Vous contrôlerez davantage le système à mesure que vous vous éloignerez de l'état interne. Si vous exécutez votre processus de contrôle sur la boîte, vous ne pouvez vérifier que le bouclage local. Exécuter à partir de la boîte valide beaucoup plus la pile réseau, y compris les aspects souvent oubliés tels que DNS. .

Inévitablement, cela rend la vérification plus difficile à effectuer, car vous pensez de manière inhérente à une tâche spécifique plutôt qu’à une solution générale, les bénéfices en résultant devraient générer des avantages suffisants pour que cette approche soit sérieusement prise en compte.

Answer 2

Il est difficile de savoir si une application s'est écrasée ou est en train de faire quelque chose d'utile.

Considérez ceci:

 while(true);

Le processeur est (très) occupé. Et cela pourrait même répondre si cela est fait dans un thread séparé. Cependant, il s’agit là d’un comportement vraiment indésirable, car l’application ne fonctionne plus.

La meilleure façon de s’y attaquer est d’ajouter périodiquement (sur certains points du logiciel) certains compteurs et de les diffuser. Une application de surveillance peut écouter ces émissions et si elles n'arrivent pas ou n'ont plus de sens (le compteur ne s'additionne pas), vous pouvez alors arrêter le processus et le redémarrer.

La diffusion peut se faire de plusieurs manières. Le plus simple est d’écrire les compteurs dans un fichier (assurez-vous que le fichier est verrouillé lorsque vous écrivez dessus afin qu’un processus de lecture n’obtienne pas un fichier demi-mutilé quand il le lit au même moment)

plus avancé consiste à utiliser des canaux nommés ou à utiliser un socket. Le socket UDP est très facile à configurer et à utiliser dans ce cas. Ne vous inquiétez pas de la perte de paquets, car cela ne se produit presque jamais sur un réseau local

Answer 3

Vous pouvez utiliser le mécanisme d'interrogation et demander périodiquement le statut de l'application distante.