C# Détecter l'échec de l'application distante

Question

Est-ce que quelqu'un connaît un moyen de détecter si une application distante a échoué/s'est écrasé? Je veux dire quand il devient inutilisable - vous verriez habituellement "Ne répond pas" 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 trouver le processus qui ne fonctionne plus.

WMI ne prend pas en charge l'utilisation de System.Diagnostics.Process.Responding sur un ordinateur distant .. et leur semble être aucune autre propriété WMI je peux interroger dans Win32_Process pour ce type d'information.

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 «proxy» simples sont superficiellement attrayantes en raison de leur simplicité, mais ne mesurent fondamentalement pas l'aspect important.

Peut-être les plus courantes sont la « Est-ce le processus vivant » et « fil de diffusion de rythme cardiaque séparé » probablement parce qu'il est si simple à faire:

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

ces deux ont cependant un grave défaut, si la le vrai fil (s) de travail dans votre application se verrouille (disons aller dans une boucle infinie ou un blocage) alors vous continuerez à envoyer joyeusement des messages OK. Pour la surveillance basée sur les processus, vous continuerez à voir le processus «vivant», même s'il n'effectue plus sa véritable tâche.
Vous pouvez améliorer le thread de plusieurs façons (en augmentant considérablement la complexité et les problèmes de threading) en superposant des tests de progression sur le thread principal mais cela prend la mauvaise solution et essaie de le pousser vers le bon.

Ce qu'il y a de mieux, c'est de faire en sorte que la ou les tâches effectuées par le programme fasse partie du contrôle de vivacité. Peut-être pour pulser directement depuis le thread principal après chaque sous-tâche (avec un seuil pour s'assurer que cela n'arrive pas trop souvent) ou simplement regarder la sortie (si elle existe) et s'assurer que les entrées résultent en sorties.

Il est préférable de valider ceci à la fois en interne (dans le programme) et en externe (en particulier s'il y a des utilisateurs/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énements: déclenchez les événements auxquels il doit répondre (et vérifiez que la sortie est correcte). Tout ce qui est fait considère toujours que vous voulez vérifier que utile et le comportement correct est en train de se produire plutôt que de simplement 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 allez vérifier plus du système plus vous vous mettez de l'état interne, si vous exécutez votre processus de contrôle sur la boîte, vous pouvez seulement vérifier le bouclage local, en cours d'exécution la boîte valide beaucoup plus de la pile réseau incluant des aspects oubliés . Inévitablement, cela rend la vérification plus difficile, car vous pensez à une tâche spécifique plutôt qu'à une solution générale, les avantages de cette approche devraient être suffisamment pris en compte pour que cette approche soit sérieusement envisagée dans de nombreux cas.

Answer 2

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

Answer 3

Il est difficile de savoir si une application a planté ou est en train de faire quelque chose d'utile.

Considérez ceci:

while(true); 

Le processeur est (très) occupé. Et il pourrait même répondre si cela est fait dans un fil séparé. Cependant, c'est un comportement vraiment indésirable puisque l'application ne fonctionne plus.

La meilleure façon d'y remédier est de périodiquement (sur certains points du logiciel) d'ajouter certains compteurs et de les diffuser. Une application de surveillance peut écouter ces diffusions et si elles n'arrivent plus ou n'a plus de sens (le compteur ne s'additionne pas), vous pouvez tuer le processus et le redémarrer.

La diffusion peut être effectuée de plusieurs façons. Le plus simple consiste simplement à écrire les compteurs dans un fichier (assurez-vous que le fichier est verrouillé lorsque vous l'écrivez afin qu'un processus de lecture n'obtienne pas un fichier moitié déchiré quand il le lit exactement)

plus moyens avancés est d'utiliser des tuyaux nommés, ou d'utiliser un socket. La prise UDP est très facile à installer et à utiliser dans ce cas. Ne vous inquiétez pas du 'packetloss' car sur un réseau local, cela n'arrive presque jamais