Мониторинг служб Windows

Для мониторинга и управления службами Windows можно применять доступную в консоли ММС оснастку Services (Службы), которая находится в узле Computer Management (Управление компьютером). Кроме того, в состав любой системы Windows входит утилита командной строки net.ехе, которая тоже позволяет управлять службами, и более функциональная утилита sc.exe. Управлять службами также можно и прямо из окна Server Explorer в Visual Studio.

В этой статье будет показано, как с помощью класса System.ServiceProcess.ServiceController создать свое небольшое приложение Windows специально для осуществления мониторинга и управления службами.

Оснастка Services консоли ММС

С помощью оснастки Services (Службы), которая предлагается в консоли ММС (Microsoft Management Console — консоль управления Microsoft), можно просматривать информацию о состоянии всех служб:

Кроме того, она позволяет отправлять службам управляющие запросы для их останова, включения или отключения, а также изменять их конфигурацию. Оснастка Services представляет собой программу для управления и конфигурирования служб.

Двойной щелчок на службе QuoteService в окне этой оснастки приводит к открытию диалогового окна Properties (Свойства). В этом диалоговом окне можно будет увидеть имя службы, ее описание, путь к ее исполняемой программе, режим запуска и состояние. В настоящий момент служба находится в запущенном состоянии. На вкладке Log On (Вход в систему) этого окна при желании можно изменить учетную запись, от имени которой должно осуществляться управление процессом службы:

Утилита net.ехе

Оснастка Services (Службы) довольно проста в применении, но автоматизировать ее работу системный администратор не может, поскольку ее использование внутри административного сценария не поддерживается. Для управления службами с помощью средства, работа которого может быть автоматизирована с применением сценариев, можно использовать утилиту командной строки net.ехе.

Например, команда net start позволяет просмотреть список запущенных служб, команда net start — запустить любую необходимую службу, а команда net stop — отправить запрос на останов указанной службы. Приостанавливать и возобновлять работу интересующей службы можно с помощью, соответственно, команд net pause и net continue (разумеется, данная служба поддерживает такое поведение).

Утилита sc.eхе

Утилита sc.ехе представляет собой еще одну поставляемую в составе операционной системы утилиту, о которой мало кому известно. Это замечательный инструмент для работы со службами. С ее помощью можно делать гораздо больше, чем посредством утилиты net.ехе. Она позволяет проверять текущее состояние службы, а также конфигурировать, удалять и добавлять службы. Кроме того, она упрощает удаление службы в случае ее некорректного функционирования.

Окно Server Explorer в Visual Studio

Управлять службами можно также с помощью предлагаемого в Visual Studio окна Server Explorer, выбрав в нем элемент Services (Службы). Этот элемент находится внутри элемента с именем текущего компьютера, который, в свою очередь, расположен в дереве под элементом Servers (Серверы). Выделив внутри этого элемента желаемую службу и открыв контекстное меню, можно запускать и останавливать службу. Также с помощью этого контекстного меню можно добавлять в проект класс ServiceController.

Чтобы добавить в приложение класс ServiceController для конкретной службы, необходимо перетащить интересующую службу из окна Server Explorer в область конструктора; экземпляр этого класса будет автоматически добавлен в приложение. Свойства этого экземпляра автоматически настраиваются так, чтобы открыть доступ к выбранной службе. В код также добавляется ссылка на сборку System.ServiceProcess. После этого данный экземпляр можно использовать для управления службой так, как описано в следующем разделе.

Создание специального класса ServiceController

В настоящем разделе рассматривается пример создания небольшого приложения Windows, в котором используется класс ServiceController для мониторинга и управления службами Windows. Создаваемое приложение представляет собой приложение WPF, пользовательский интерфейс которого имеет вид, показанный на рисунке:

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

XAML-разметка данного окна выглядит следующим образом:

С помощью класса ServiceController можно получать подробную информацию о каждой службе. В таблице приведено краткое описание свойств этого класса:

Свойство	Описание
CanPauseAndContinue	Возвращает true, если службе могут отправляться запросы на приостановку и возобновление работы.
CanShutdown	Возвращает true, если служба имеет обработчик для завершения работы системы.
CanStop	Возвращает true, если служба может быть остановлена.
DependentServices	Возвращает коллекцию зависимых служб. В случае останова службы сначала останавливаются все ее зависимые службы.
ServicesDependentOn	Возвращает коллекцию служб, от которых зависит данная.
DisplayName	Специфицирует имя, которое должно отображаться для данной службы.
MachineName	Специфицирует имя машины, на которой выполняется служба.
ServiceName	Специфицирует имя службы.
ServiceType	Специфицирует тип службы. Служба может запускаться как внутри разделяемого процесса, который могут использовать несколько служб (вроде Win32SharedProcess), так и внутри отдельного процесса, который может использовать только одна служба (наподобие Win320wnProcess). Если служба способна взаимодействовать с рабочим столом, тогда ее тип будет interactiveProcess.
Status	Отражает состояние службы. Состояние может принимать следующие значения: работает (running), остановлена (stopped), временно приостановлена (paused), находится в некотором промежуточном состоянии — в процессе запуска (start pending), в процессе останова (stop pending) и т.п. Все возможные значения состояния определены в перечислении ServiceControllerStatus.

В создаваемом здесь приложении для отображения информации о службах используются свойства DisplayName, ServiceName, ServiceType и Status, а для включения и отключения доступа к кнопкам Pause (Пауза), Continue (Продолжить) и Stop (Остановить) — свойства CanPauseAndContinue и CanStop.

Для отображения текущей информации о службе в классе ServiceControllerInfo предусмотрены доступные только для чтения свойства DisplayName, ServiceName, ServiceTypeName и ServiceStatusName. В реализации свойств DisplayName и ServiceName просто производится доступ к свойствам DisplayName и ServiceName лежащего в основе класса ServiceController. В реализации свойств ServiceTypeName и ServiceStatusName выполняется немного больше работы: информация о состоянии и типе службы не может быть возвращена столь же просто, поскольку вместо чисел, которые возвращает класс ServiceController, должны отображаться строки.

Свойство ServiceTypeName возвращает строку, отражающую тип службы. Значение ServiceType, получаемое из свойства ServiceController.ServiceType, представляет собой набор флагов, которые могут объединяться с помощью битовой операции «ИЛИ». Бит InteractiveProcess может устанавливаться вместе с Win320wnProcess и Win32ShareProcess. Поэтому перед проверкой остальных значений проверяется, был ли установлен бит InteractiveProcess. В случае служб возвращаемые строки выглядят как «Win32 Service Process» или «Win32 Shared Process»:

Управление службами из кода описывается в следующей статье.

Мониторинг работы windows-службы с помощью Zidium

Всем привет. В этой статье я расскажу, как контролировать работу windows-службы с помощью системы мониторинга Zidium.

Зачем мониторинг?

Сначала о том, что такое мониторинг и зачем вообще он нужен. Был у меня заказ на приложение, которое должно собирать данные с нескольких систем, выполнять аналитику, и отправлять данные в систему отчётов. Приложение я реализовал в виде windows-службы, развернул на хостинге. Заказчик передал дальнейшее сопровождение службы мне на аутсорс, то есть я отвечаю за её работоспособность и за исправление ошибок.

Но возник вопрос — как мне отслеживать возможные проблемы со службой?

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

Какую информацию о состоянии службы я хочу иметь:

• Отслеживание сигнала активности (так называемое “биение сердца”, heartbeat). Если служба остановится, сигнал перестанет поступать и станет понятно — что-то не так.
• Сбор подробной информации об ошибках. Мне же их исправлять. Так что нужно как можно больше данных — время, сообщение, стек и т.п.
• Ведение лога в облаке. Почему не файл? Служба работает на боевом сервере, туда доступ только у админа. Админ человек занятой, логи ему некогда искать и присылать мне. Или оказывается, что логи слишком большие и не отправляются через корпоративную почту. В общем, сложно всё с файлом.
• Уведомления о проблемах по email и, хорошо бы, по sms. Мне — об ошибках, админу — об остановке службы.
• Некоторая статистика по производительности — замер времени выполнения ключевых участков обработки данных. Это мне пригодится для оптимизаций.
• Ну и крайне желательно всё это иметь в одном месте, а не в разных системах учёта.

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

Как это работает

Посмотрим сначала на исходный код службы, без мониторинга. Служба написана на C# в среде VS 2015.

Тут всё стандартно для windows — поток, бесконечный цикл с прерыванием работы, некоторая задержка в конце итерации.

Цикл выполняет методы, которые собирают, обрабатывают и отправляют данные. Что конкретно они делают, для этой статьи неважно.

Подключим Zidium к проекту. Это делается с помощью Nuget-пакета. Он добавляет dll и файл zidium.xml с настройками. В xml-файле я задал параметры доступа к аккаунту. Можно не использовать файл, а задавать всё программно, но мне показалось, что такой конфиг — это более правильно.

Все примеры использования я брал из документации на сайте Zidium.

Сначала создадим вспомогательный класс, который будет соединяться с системой и получать “компонент”. В моём случае компонент — это сама служба и есть. Здесь всё как рекомендуется в документации, поправил только названия.

Чтобы проверить создание компонента, я вставил получение компонента в метод запуска сервиса и вызывал у него метод IsFake (дело в том, что компонент на стороне Zidium создаётся только когда с ним будет выполнена какая-то реальная работа). Для обычной работы это не нужно, после теста этот вызов можно удалить.

После запуска в личном кабинете появился компонент.

Цвет у него серый, потому что никаких данных мы пока не передавали.

Сигнал активности (HeartBeat)

Добавим теперь сигнал активности. Для этого используются так называемые “проверки” (“unittests”).

В самом начале нужно создать для “компонента” саму проверку и запомнить её в переменной.

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

У меня данные собираются раз в час, поэтому я указал актуальность 2 часа — запас на 1 цикл работы. По хорошему, конечно, надо учитывать реальное время работы методов, но я решил не усложнять.

Запускаем службу, и в личном кабинете видим зелёный компонент и зелёную проверку. Всё хорошо.

Для теста я указал время актуальности 1 минуту (чтобы долго не ждать) и остановил службу.

Через минуту компонент с проверкой стали красными, и мне на почту пришло письмо с уведомлением об отсутствии сигнала.

Все уведомления довольно гибко настраиваются, и можно получать их на email и по sms. У каждого пользователя свои контакты и свои настройки уведомлений. Отлично, эта задача решена.

Ошибки

Теперь разберёмся с ошибками. Здесь всё проще.

try <> и в catch отправляем ошибку. Есть удобный готовый метод, который из Exception выделяет сообщение, стек и т.п. и формирует ошибку.

Для теста я просто вызвал throw new Exception() в теле цикла. Вот как выглядит ошибка в личном кабинете:

Опять же, я получаю о ней уведомление, если мне это надо.

Надо сказать, что Zidium довольно интеллектуально понимает, что несколько ошибок являются на самом деле одной и той же. Такие ошибки соединяются в одну, что очень удобно. И спама из уведомлений тоже не будет.

Далее у нас лог. Работа с логом сделана аналогично другим библиотекам логирования, таким как nLog или Log4Net. Просто пишем что хотим, указывая уровень (важность) записи.

Бонус — к каждой записи лога можно прикрепить любое количество допсвойств, в которые можно поместить что угодно — например, xml. Они не замусоривают сам лог, но их всегда можно посмотреть.

Вот так выглядит лог в личном кабинете:

Для меня это гораздо удобнее, чем читать огромные тестовые файлы.

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

Производительность

Наконец, статистика по производительности. Для этого используются “метрики”. Я замеряю общее время работы интересующих меня методов.

У метрики есть название и значение, и отправляется она так:

В личном кабинете можно посмотреть детально всю историю метрики.

Сразу же считаются основные агрегаты за выбранный период — максимум, минимум и среднее.

Жаль, нельзя скачать данные в формате xlsx или csv, это могло бы пригодиться для собственного анализа.

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

Итого

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

Я получу уведомление, если служба вдруг остановится или зависнет. Я получу уведомление, если возникнет любая ошибка.

Теперь я спокоен за сделанную мной работу и за выполнение обязательств перед заказчиком )