C # Обнаружение сбоя удаленного приложения - PullRequest
1 голос
/ 30 июля 2009

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

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

Ответы [ 3 ]

0 голосов
/ 30 июля 2009

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

Учтите это:

 while(true);

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

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

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

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

0 голосов
/ 30 июля 2009

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

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

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

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

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

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

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

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

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

0 голосов
/ 30 июля 2009

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

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