C # Rileva errore dell'applicazione remota

Question

Qualcuno conosce un modo per rilevare se un'app remota è fallita / bloccata? Intendo quando diventa inutilizzabile - di solito vedresti " Non rispondere " nella barra del titolo, in questo caso - ma la chiave è che l'app è ancora in esecuzione; pertanto non è sufficiente trovare il processo in esecuzione.

WMI non supporta l'uso di System.Diagnostics.Process.Risposta su una macchina remota .. e le loro proprietà non sembrano essere altre proprietà WMI che posso interrogare in Win32_Process per questo tipo di informazioni.

Answer 1

Nel determinare la "vivacità" di un programma è importante misurare quell'aspetto che lo definisce essere vivo in modo utile.

Diversi semplici approcci 'proxy' sono superficialmente attraenti per la loro semplicità ma fondamentalmente non misurano l'aspetto importante.

Forse i più comuni sono " È il processo vivo " e "thread di trasmissione heartbeat separato" probabilmente perché è così semplice da fare:

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

Entrambi hanno tuttavia un grave difetto, se i thread funzionanti nella tua app si bloccano (diciamo andando in un ciclo infinito o in un deadlock), continuerai a inviare allegramente messaggi OK. Per il monitoraggio basato sul processo, continuerai a vedere il processo "attivo" nonostante non esegua più il suo vero compito.
Puoi migliorare il thread uno in molti modi (aumentando significativamente la complessità e i problemi di thread di probabilità) sovrapponendo i test per i progressi sul thread principale, ma questo prende la soluzione sbagliata e cerca di spingerlo verso quello giusto.

La cosa migliore è rendere le attività svolte dal programma parte del controllo del liveness. Forse battere il cuore direttamente dal thread principale dopo ogni operazione secondaria eseguita (con una soglia per garantire che non accada troppo spesso) o semplicemente guardare l'output (se esiste) e assicurarsi che gli input producano output.

È ancora meglio convalidarlo sia internamente (all'interno del programma) che esternamente (specialmente se ci sono consumatori / utenti esterni del programma). Se disponi di un server Web: prova a utilizzarlo, se la tua app è un sistema basato su loop di eventi: attiva eventi a cui deve rispondere (e verifica che l'output sia corretto). Qualunque cosa sia fatta, considera sempre che desideri verificare che si stia verificando utile e un comportamento corretto piuttosto che qualsiasi attività.

Più verifichi non solo dell'esistenza del programma, ma sono azioni più utile sarà il tuo controllo. Controllerai più sistema più ti allontani dallo stato interno, se esegui il processo di monitoraggio sulla scatola puoi solo controllare il loopback locale, l'esecuzione fuori dalla scatola convalida molto di più dello stack di rete inclusi aspetti spesso dimenticati come DNS .

Inevitabilmente questo rende più difficile fare il controllo, poiché stai intrinsecamente pensando a un compito specifico piuttosto che a una soluzione generale, i dividendi da questo dovrebbero produrre benefici sufficienti per questo approccio da considerare seriamente in molti casi.

Answer 2

È difficile sapere se un'app si è bloccata o sta effettivamente facendo qualcosa di utile.

Considera questo:

 while(true);

Il processore è (molto) occupato. E potrebbe anche rispondere se questo viene fatto in un thread separato. Tuttavia, questo è un comportamento davvero indesiderato poiché l'app non funziona più.

Il modo migliore per affrontare questo problema è aggiungere periodicamente (su alcuni punti del software) determinati contatori e trasmetterli. Un'app watchdog può ascoltare queste trasmissioni e se non arrivano o hanno più senso (il contatore non si somma) puoi terminare il processo e riavviarlo.

La trasmissione può essere effettuata in diversi modi. La cosa più semplice è scrivere i contatori su un file (assicurati che il file sia bloccato quando lo scrivi in ??modo che un processo di lettura non ottenga un file parzialmente rovinato quando lo legge nello stesso momento)

modi più avanzati è usare pipe nominate o usare un socket. Il socket UDP è molto semplice da configurare e utilizzare in questo caso. Non preoccuparti di "perdita di pacchetti" poiché su una rete locale questo non accade quasi mai

Answer 3

È possibile utilizzare il meccanismo di polling e chiedere periodicamente lo stato dell'applicazione remota.