C # Обнаружение сбоя удаленного приложения

Question

Кто-нибудь знает способ обнаружения сбоя / сбоя удаленного приложения? Я имею в виду, когда он становится непригодным для использования - вы обычно видите "Не отвечает" в строке заголовка, в данном случае - но ключ в том, что приложение все еще работает; поэтому просто найти процесс, который больше не работает, недостаточно.

WMI не поддерживает использование System.Diagnostics.Process.Responding на удаленной машине ... и, похоже, что у них нет других свойств WMI, которые я могу запросить в Win32_Process для получения такой информации.

Answer 1

При определении «живучести» программы важно измерить этот аспект, чтобы определить, насколько она жива.

Несколько простых «прокси» подходов внешне привлекательны из-за своей простоты, но принципиально не измеряют важный аспект.

Пожалуй, наиболее распространенными из них являются "Жив ли процесс"? и " отдельную ветвь биения пульса " вероятно, потому что это так просто сделать:

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

Однако оба эти варианта имеют серьезный недостаток: если реальные рабочие потоки в вашем приложении блокируются (например, переходят в бесконечный цикл или тупик), то вы продолжите весело отправлять сообщения OK. Для мониторинга на основе процессов вы будете продолжать видеть процесс «живым», несмотря на то, что он больше не выполняет свою реальную задачу.
Вы можете улучшить поток одним из множества способов (значительно увеличивая сложность и вероятность проблем с многопоточностью), налагая слои на тесты прогресса в основном потоке, но это принимает неправильное решение и пытается подтолкнуть его к правильному.

Лучше всего сделать задачи, выполняемые программой, частью проверки живучести. Возможно, чтобы пульсировать непосредственно из основного потока после каждой выполненной подзадачи (с порогом, чтобы это не происходило слишком часто), или просто посмотреть на результат (если он существует) и убедиться, что входы приводят к выходам.

Лучше все же проверить это как внутренне (в рамках программы), так и внешне (особенно, если есть внешние потребители / пользователи программы). Если у вас есть веб-сервер: попытайтесь использовать его, если ваше приложение представляет собой систему, основанную на цикле событий: инициируйте события, на которые оно должно реагировать (и убедитесь, что выходные данные верны). Что бы ни делалось, всегда учитывайте, что вы хотите убедиться, что полезно и правильное поведение имеют место, а не какие-либо действия вообще.

Чем больше вы проверяете не только существование программы, но и действия , тем более полезной будет ваша проверка. Чем больше вы выйдете из внутреннего состояния, тем больше вы будете проверять систему. Если вы запускаете процесс мониторинга в окне, вы можете проверять только локальную петлю, запуск в этом окне проверяет гораздо больше сетевого стека, включая часто забытые аспекты, такие как DNS. .

Это неизбежно усложняет проверку, поскольку по сути вы задумываетесь о конкретной задаче, а не об общем решении. Дивиденды от этого должны принести достаточные преимущества для серьезного рассмотрения этого подхода во многих случаях.

Answer 2

Трудно понять, произошло ли сбой приложения или что-то действительно полезное.

Подумайте об этом:

 while(true);

Процессор (очень) занят. И он может даже ответить, если это будет сделано в отдельном потоке. Однако это действительно нежелательное поведение, так как приложение больше не работает.

Лучший способ решить эту проблему - периодически (в определенных точках программного обеспечения) добавлять определенные счетчики и транслировать их. Приложение-сторожевой таймер может прослушивать эти трансляции, и если они не приходят или больше не имеют смысла (счетчик не складывается), вы можете завершить процесс и перезапустить его.

Вещание может быть сделано несколькими способами. Проще всего просто записать счетчики в файл (убедитесь, что файл заблокирован, когда вы пишете в него, чтобы процесс чтения не получил наполовину искаженный файл, когда он читает его в одно и то же время)

более продвинутыми способами является использование именованных каналов или использование сокета. В этом случае UDP-сокет очень прост в настройке и использовании. Не беспокойтесь о «потере пакетов», так как в локальной сети этого почти не происходит

Answer 3

Вы можете использовать механизм опроса и периодически запрашивать состояние удаленного приложения.