В качестве дополнительных параметров может выполняться поиск других атрибутов полученного JSON. Для этих атрибутов также требуется путь в формате JSONPath.

Значение атрибута JSON с веб страницы

Система загружает данные в формате JSON с веб страницы. В полученной структуре данных выполняется поиск необходимого элемента и анализ его значения.

Свойства запроса и дополнительные параметры аналогичны категории «Значение атрибута JSON из файла».

Поиск словосочетания в логах

Система получает файл из указанной директории с логами. В файле осуществляется поиск слова или сочетания слов, результатом проверки является количество найденных словосочетаний.

Свойства запроса:

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

Дополнительные параметры:

Не учитываются.

Код ответа web страницы

Система выполняет запрос к указанной странице и получает код ответа. Код ответа сравнивается с ожидаемым значением проверки.

Свойства запроса:

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

Дополнительные параметры:

Не учитываются.

Код ответа web API

Система выполняет запрос к указанному адресу web API и получает код ответа. Код ответа сравнивается с ожидаемым значением проверки.

Свойства запроса:

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

Дополнительные параметры:

Не учитываются.

Исходя из описания полученных категорий, можно выделить следующие свойства правил в системе мониторинга:

1) Тип проверки (правила) - определяет подход к анализу полученных данных и дополнительных атрибутов. На данном этапе проектирования системы можно выделить следующие типы проверок:

a) Значение из дейтаграммы;

b) Значение из данных в формате JSON;

c) Значение из логов (обычного текста);

d) Значение из таблицы с данными (набора);

e) Время выполнения запроса;

f) Доступность ресурса.

2) Тип ресурса - определяет способ подключения к объекту (компоненту инфраструктуры), на котором хранится информация для осуществления проверки. Для разрабатываемой службы можно выделить следующие типы ресурсов:

a) Файловый сервер;

b) База данных на MS SQL Server;

c) Web страница;

d) Web API.

3) Тип запроса - определяет способ выполнения запроса на ресурсе и получения данных для анализа. Пользователям системы доступны следующие типы запросов:

a) SQL запрос;

b) Поиск на основе XML Path;

c) Поиск на основе JSON Path;

d) HTTP запрос к веб ресурсу;

e) Поиск значения в тексте.

При проектировании системы необходимо учесть, что проверки мониторинга должны быть разделены на несколько групп по типам итоговых статусов. Например, проверки из категорий «код ответа web страницы» или «код ответа web API» могут завершиться успешно (веб ресурс ответил ожидаемым для проверки статус-кодом), либо кодом с ошибкой. Результат таких проверок будет принимать значение Passed или Failed в зависимости от полученного значения. Эти статусы относятся к группе статусов Binary.

Другие проверки могут переходить в различные состояния. Например, очереди синхронизации между системами могут обрабатывать определенное количество событий в штатном режиме. Если число событий в очереди превышает заданный порог, то это может означать либо передачу данных с задержкой, либо перегрузку и полный отказ одного из компонентов. В этом случае пользователи системы мониторинга могут заранее узнать о накоплении событий в очереди и устранить проблему до того, как она перейдет в критическое состояние. Такие проверки необходимо отнести к группе Stages и определять статус - Success, Warning или Critical - в зависимости от интервала, в который входит итоговое значение.

Возможны ситуации, когда служба мониторинга не может определить итоговое значение из-за сбоя при установлении соединения с ресурсом или неправильных настройках проверки. В данном случае проверка переходит в статус Unknown, относящийся к группе Errors.

В таблице «Таблица 1. Группы и типы статусов» отражены описанные типы статусов с разбиением по группам.

Таблица 1. Группы и типы статусов

Группа статусов	Тип статуса
Errors	Unknown (неизвестно)
Binary	Passed (проверка пройдена)
	Failed (проверка не пройдена)
Stages	Success (функционирование в штатном режиме)
	Warning (предупреждение о возможном сбое компонента)
	Critical (сбой компонента)

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

1) Ожидаемое значение проверки;

2) Ожидаемое значение, порог предупреждения (warning) и критический порог (critical);

3) Порог предупреждения (warning) и критический порог (critical).

Перечисленные наборы полей составлены именно таким образом на основе определенных на предыдущем этапе групп и типов статусов. Схематично логика определения группы статуса, возможного набора полей и операторов сравнения представлена на схемах - “Схема 1. Доступные операторы сравнения и наборы определяющих полей для группы Binary” и “Схема 2. Доступные операторы сравнения и наборы определяющих полей для группы Stages”.

Схема 1. «Доступные операторы сравнения и наборы определяющих полей для группы Binary»



Схема 2. «Доступные операторы сравнения и наборы определяющих полей для группы Stages»

Для обеспечения регулярной работы системы мониторинга необходимо определить интервал времени, с которым будет запускаться механизм на сервере. Пользователи также должны иметь возможность самостоятельно задавать этот интервал, останавливать и перезапускать инструмент мониторинга, вводить учетные данные, от имени которых будет осуществляться доступ к компонентам инфраструктуры организации. Всем перечисленным требованиям отвечает приложение службы Windows. При помощи интерфейса управления службами можно определять тип запуска службы, останавливать и запускать приложение вручную, передавать учетные данные для взаимодействия с внешними сервисами. Передачу интервала работы службы можно реализовать при помощи указания значения в миллисекундах в ключе Service Polling Interval в файле конфигурации приложения.

Другим плюсом использования приложения Windows службы является возможность создания журнала событий для логирования информации о состояниях механизма и сбоях в работе системы. Для этого журнала можно выделить три типа записей о событиях: информация (information), предупреждение (warning) и ошибка (error). Состав событий и их условия будут определены после построения диаграммы состояний службы в последующих разделах.

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

1) Последнее время запуска проверки - последние дата и время, когда служба обработала проверку.

2) Интервал запуска - целое число, определяющее периодичность запуска проверки.

3) Измерение - определяет показатель, в котором измеряется интервал запуска. Допустимые значения: секунды, минуты и часы.

4) Следующее время запуска проверки - дата и время, когда необходимо обработать проверку в следующий раз. Рассчитывается на основе текущей даты и времени и заданной периодичности запуска (интервала и его измерения).

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

Всю информацию о пользовательских проверках, их параметрах и историю удобно хранить в базе данных (БД) на сервере. В разрабатываемой системе используется среда Microsoft SQL Server для управления реляционными базами данных. Модель базы данных, созданная в этой среде, может быть использована для взаимодействия с технологией Entity Framework на основе подхода Database First. Использование этой технологии значительно упрощает взаимодействие с БД. Эта технология может также быть использована в дальнейшем при разработке пользовательского интерфейса для взаимодействия с системой мониторинга. Схематично архитектура будущей системы представлена на рис. 1 «Взаимодействие компонентов системы мониторинга».

Рис. 1 «Взаимодействие компонентов системы мониторинга»

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

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

На основе составленных требований к функционалу системы, её архитектуре и логике работы можно перейти к моделированию каждого из компонентов в отдельности, которые реализуются в рамках данной работы: базы данных и приложения службы Windows.

Модель базы данных системы мониторинга и её элементы

На диаграмме ниже (рис. 2 «Логическая модель базы данных») представлена логическая модель базы данных.

Рис. 2 «Логическая модель базы данных»

База данных состоит из следующего набора сущностей:

· MonitoringCheck (проверка мониторинга). Содержит в себе настройки пользовательских проверок (мониторов). Связь 1-М с сущностью History.

· MonitoringCheckType (тип проверки мониторинга). Словарь допустимых типов проверок. Добавление новых значений в эту таблицу должно сопровождаться реализацией соответствующего функционала в службе мониторинга. Связь М-1 к сущности MonitoringCheck.

· ResourceType (тип ресурса). Словарь реализованных типов ресурсов, на которых могут выполняться проверки. Например, файловая система, сервер баз данных и т.д. Связь М-1 с сущностью Resource.

· Resource (ресурс). Описывает ресурс, на котором выполняется пользовательская проверка. Связь М-1 с сущностью MonitoringCheckQuery.

· QueryType (тип запроса к ресурсу). Словарь реализованных в службе типов запросов к компонентам информационной инфраструктуры. Например, SQL запрос, XML дейтаграмма или JSON. Связь М-1 c MonitoringCheckQuery.

· MonitoringCheckQuery (запрос проверки). Содержит в себе информацию о запросе к ресурсу для определенной пользовательской проверки. Связь 1-1 с сущностью MonitoringCheck.

· MonitoringCheckScheduler (расписание проверки). Содержит в себе информацию о расписании, по которому проверяется конкретная проверка, и следующем времени запуска. Связь 1-1 с MonitoringCheck.

· ComparisonDictionary (оператор сравнения). Словарь операторов сравнения реального значения с ожидаемым значением, а также пороговыми значениями (warning и critical threshold) проверок связь М-1 с MonitoringCheck.

· StateTypeGroup (группа статусов проверок). Словарь допустимых групп типов статусов проверок. Например, проверка может быть бинарной и результат сравнивается только с ожидаемым значением или для неё настроены пороговые значения.

· StateType (статус проверки). Словарь статусов проверок по группам.

· History (история). Содержит в себе историю по результатам пользовательских проверок. Историю можно очищать при помощи настройки задания очистки данных из этой таблиц за определенный период.

В таблице «Таблица 2. Описание полей таблиц базы данных» представлена информация о полях базы данных: тип данных, допустимые значения и примеры.

мониторинг служба поддержка информационный

Таблица 2. Описание полей таблиц базы данных

Поле	Описание	Тип данных	Допустимые значения	Пример
Monitoring Check Type
MonitoringCheckTypeId	Идентификатор типа проверки (PK)	integer	Целочисленные положительные значения	1
MonitoringCheckTypeName	Название типа проверки	varchar(50)	Словарь содержит следующие типы проверок, реализованные в службе: o Value from data set o Query execution time o Value from datagram o Value from json o Value from text o Page availability	Value from data set - анализирует значение из полученного набора данных
Resource Type
ResourceTypeId	Идентификатор типа ресурса (PK)	integer	Целочисленные положительные значения	1
ResourceTypeName	Название типа ресурса	varchar(50)	Словарь содержит следующие типы ресурсов, реализованные в службе: o File Server o MS SQL server o Web Page o Web API	MS SQL server - сервер базы данных, на котором необходимо выполнить запрос
Query Type
QueryTypeId	Идентификатор типа запроса (PK)	integer	Целочисленные положительные значения	1
QueryTypeName	Название типа запроса	varchar(50)	Словарь содержит следующие типы запросов, реализованные в службе: o SQL query o XML path o JSON o HTTP request o Plain text	Plain text - получает текст из файла для поиска словосочетания
Resource
ResourceId	Идентификатор ресурса (PK, auto increment)	integer	Целочисленные положительные значения	1
ResourceTypeId	Идентификатор типа ресурса (PK, FK)	integer	Целочисленные положительные значения	1
ResourcePath	Путь к ресурсу, строка подключения или URL	varchar(250)	Символьные значения переменной длины (максимальная длина 250)	Data Source = LocalServer; Initial Catalog = LocalDb; Integrated Security = True - строка подключения к базе данных
Monitoring Check Query
MonitoringCheckQueryId	Идентификатор запроса для проверки (PK, auto increment)	integer	Целочисленные положительные значения	1
ResourceId	Идентификатор ресурса (FK)	integer	Целочисленные положительные значения	1
ResourceTypeId	Идентификатор типа ресурса (FK)	integer	Целочисленные положительные значения	1
QueryTypeId	Идентификатор типа запроса (FK)	integer	Целочисленные положительные значения	1
Query	Состав запроса к ресурсу	varchar(max)	Символьные значения переменной длины. Представляют из себя JSON с описанием параметров запроса для проверки.	{ "PathToFile" : "C:\Users\user\MonitoringService\req1.sql", "ParamName": "ResultValue" } - путь к файлу с SQL запросом
Additional Parameters
AdditionalParametersId	Идентификатор запроса дополнительного параметра (PK, auto increment)	integer	Целочисленные положительные значения	1
MonitoringCheckId	Идентификатор проверки мониторинга (FK)	integer	Целочисленные положительные значения	1
AttributeName	Название дополнительного атрибута (Unique)	varchar(50)	Символьные значения переменной длины (максимальная длина 50)	LastErrorDate
AttributeResourcePath	Путь (Path) к атрибуту в результирующем наборе значений (если формат набора XML или JSON)	varchar(max)	Символьные значения переменной длины в формате XML Path или JSON Path	//CCC/preceding-sibling::* - данные в формате XPath
Comparison Dictionary
ComparisonDictionaryId	Идентификатор оператора сравнения (PK)	integer	Целочисленные положительные значения	1
ComaprisonOperator	Оператор сравнения	varchar(5)	Символьные значения переменной длины (максимальная длина 5). Словарь содержит следующие значения: o = o != o > o >= o <=	“>” - представляет оператор “больше”
Description	Описание оператора сравнения	varchar(50)	Символьные значения переменной длины (максимальная длина 50) . Словарь содержит следующие значения: o Equal o Not Equal o Greater o Greater or equal o Smaller o Smaller or equal	Smaller or equal - меньше или равно
Monitoring Check Scheduler
MonitoringCheckSchedulerId	Идентификатор расписания проверки (PK)	integer	Целочисленные положительные значения	1
SchedulerSettings	Настройки расписания проверки	varchar(max)	Символьные значения переменной длины. Представляют из себя JSON с описанием параметров: o PollingInterval - интервал проверки o IntervalMeasurement - измерение интервала (допустимые значения: days, hours, minutes, seconds) o LastExecutionTime - последняя дата запуска (допустимо значение never, если проверка будет запущена впервые) o NextExecutionTime - следующая ожидаемая дата запуска	{"PollingInterval":"2", "IntervalMeasurement":"hours", "LastExecutionTime":"2017-04-22 11:22", "NextExecutionTime":"2017-04-22 13:22" } - проверка запускается раз в два часа
State Type Group
StateTypeGroupId	Идентификатор группы статусов (PK)	integer	Целочисленные положительные значения	1
StateTypeGroupName	Название группы статусов	varchar(50)	Словарь содержит следующие значения: o Binary - итоговый статус выводится, как прошел/не прошел o Stages - проверка может находится на разных стадиях o Errors - статус выводится, если не удалось обработать проверку	Stages - к этой группе статусов относятся Success, Warning и Critical
State Type
StateTypeId	Идентификатор типа статуса (PK)	integer	Целочисленные положительные значения	1
StateTypeGroupId	Идентификатор группы статусов (FK)	integer	Целочисленные положительные значения	1
StateTypeName	Название типа статуса	varchar(50)	Символьные значения переменной длины (максимальная длина 50) . Словарь содержит следующие значения: o Passed и Failed (для типа Binary) o Success, Warning, Critical (для типа Stages) o Unknown (для типа Errors)	Warning - итоговое значение проверки выходит за границы порога Warning Threshold, но находится в пределах Critical Threshold
Monitoring Check
MonitoringCheckId	Идентификатор проверки (PK, auto increment)	integer	Целочисленные положительные значения	1
MonitoringCheckName	Название проверки (Unique)	varchar(50)	Символьные значения переменной длины (максимальная длина 50) .	Test Monitoring Check
MonitoringCheckDescription	Описание проверки	varchar(max)	Символьные значения переменной длины.	Tests performance of monitoring service
MonitoringCheckTypeId	Идентификатор типа проверки (FK)	integer	Целочисленные положительные значения	1
ComparisonDictionaryId	Идентификатор оператора сравнения (FK)	integer	Целочисленные положительные значения	1
ExpectedValue	Ожидаемое значение (заполняется для проверок с группой статусов Binary)	varchar(250)	Символьные значения переменной длины (максимальная длина 250) .	200
WarningTreshold	Порог Warning для проверки (заполняется для проверок с группой статусов Stages)	varchar(250)	Символьные значения переменной длины (максимальная длина 250) .	50
CriticalTreshold	Порог Critical для проверки (заполняется для проверок с группой статусов Stages)	varchar(250)	Символьные значения переменной длины (максимальная длина 250) .	Critical - файлы вывода систем мониторинга могут содержать готовые статусы по проверкам
MonitoringCheckQueryId	Идентификатор запроса для проверки (FK)	integer	Целочисленные положительные значения	1
MonitoringCheckSchedulerId	Идентификатор расписания проверки (FK)	integer	Целочисленные положительные значения	1
Disabled	Флаг, определяющий состояние проверки	bit	Значение 0 для работающих проверок; 1 - для остановленных	1 - выполнение проверки временно остановлено пользователями
History
HistoryId	Идентификатор записи в истории (PK, auto increment)	integer	Целочисленные положительные значения	1
MonitoringCheckId	Идентификатор проверки (FK)	integer	Целочисленные положительные значения	1
StateTypeId	Идентификатор типа статуса (FK)	integer	Целочисленные положительные значения	1
StateTypeGroupId	Идентификатор группы статусов (FK)	integer	Целочисленные положительные значения	1
AdditinalParametrsValue	Значения дополнительных параметров в формате JSON	varchar(max)	Символьные значения переменной длины формате JSON (имя параметра : значение)	{"LastErrorDate":"2017-02-29"}
ActualValue	Реальное значение проверяемого параметра	varchar(250)	Символьные значения переменной длины (максимальная длина 250) .	2000
CheckDate	Дата и время исполнения проверки	datetime	Значение даты и времени в текущей временной зоне	2017-04-22 11:22:00
ErrorMessage	Текст ошибки в случае сбоя	varchar(300)	Символьные значения переменной длины (максимальная длина 300) .	Could not connect to database “LocalDB”.
ProcessedWithError	Флаг, определяющий наличие ошибок при обработке проверки	bit	0 - проверка обработана успешно 1 - во время обработки возник сбой	1 - службе мониторинга не удалось подключиться к серве ру с базой данных для выполнения запроса

Скрипт генерации базы данных получен при помощи средств моделирования ERWIN Data Modeling Tools и находится в Приложении 1 - «Скрипт базы данных».

2.2 Диаграмма состояний службы мониторинга

На диаграмме состояний (рис. 3 «Диаграмма состояний службы мониторинга») схематично изображен процесс обработки настроенных пользователями проверок службой мониторинга. После установки служба мониторинга запускается в режиме - Automatically. Запуск службы сопровождается созданием источника и журнала событий, если они не были настроены ранее, и записью о запуске службы.

Далее запускается таймер, интервал (в миллисекундах) которого регулируется настройкой «Service Polling Interval» в файле конфигурации службы. По истечении таймера служба мониторинга осуществляет чтение информации о настроенных проверках из базы. Строка подключения к базе также задается отдельной настройкой в файле конфигурации. Если проверок в базе нет, служба возвращается в первоначальное состояние.

Если проверки есть, осуществляется фильтрация полученных проверок по полю Disabled, то есть поиск активных проверок. Если активных проверок нет, служба возвращается в первоначальное состояние.

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



Рис. 3 «Диаграмма состояний службы мониторинга»

Если есть проверки, которые уже необходимо выполнить по расписанию, служба переходит в состояние определения категории проверки и обновляет параметр NextExecutionDate в расписании. Проверки делятся на категории в зависимости от типа проверки, ресурса и запроса:



Таблица 3. Категория проверки в зависимости от типа запроса, ресурса и проверки

Категория	Тип запроса	Тип ресурса	Тип проверки
Проверка времени выполнения SQL запроса на сервере	Query execution time	MS SQL Server	SQL Query
Проверка итогового значения SQL запроса на сервере	Value from dataset	MS SQL Server	SQL Query
Значение атрибута XML из файла	Value from datagram	File Server	XML path
Значение атрибута XML с веб страницы	Value from datagram	Web Page	XML path
Значение атрибута JSON из файла	Value from json	File Server	JSON
Значение атрибута JSON с веб страницы	Value from json	Web Page	JSON
Поиск словосочетания в логах	Value from plain text	File Server	Plain Text
Код ответа web страницы	Response Code	Web Page	HTTP Request
Код ответа web API	Response Code	Web API	HTTP Request

В зависимости от категории проверки происходит вызов соответствующих методов для получения результатов проверки - контрольного и дополнительных параметров. Если в результате группировки ни для одной категории не было выявлено ни одной проверки, служба переходит в первоначальное состояние. Если во время получения параметров проверки произошел сбой, для нее проставляется соответствующий флаг ProcessedWithError и фиксируется сообщение ошибки. Полученные значения дополнительных параметров преобразуются в JSON.

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

Полученные данные сохраняются в таблицу истории. Завершение очередной итерации службы мониторинга фиксируется в журнале событий.

На основе представленной диаграммы можно определить состав и тип записей в журнале событий, представленных в таблице 4 «Типы записей в журнале событий службы мониторинга».



Таблица 4. Типы записей в журнале событий службы мониторинга

Иконка	Тип события	Условие	Текст записи
	Информация (Information)	Запуск службы вручную	Monitoring service successfully started
		Очередная итерация службы по истечению таймера	Monitoring iteration after start {iteration}
		Начало обработки проверки	Start processing check: {Check name}
		Остановка службы вручную	Monitoring service stopped
	Предупреждение (Warning)	В системе нет активных проверок	No active Monitoring Checks retrieved
		Все проверки отложенные	No Monitoring Checks to be executed at {current timestamp} retrieved
		Не удалось определить категорию отдельной проверки	Could not define implemented category for check {Check Name}. Please ensure correct combination of resource, category and check types.
		Не удалось определить категорию ни для одной проверки	No Monitoring Checks categories could be defined. Check EventViewer log for more information.
	Ошибка (Error)	Не удалось определить группу статусов	Please make sure that the combination of expected value, War ning threshold, critical threshold and comparison operator have been set up correctly.
		Не удалось получить контрольное значение	В журнал записывается сообщение ошибки, inner exception и stack trace.
		Не удалось получить проверки из базы
		Не удалось записать историю в базу
		Другие ошибки при обработке методов службы мониторинга

2.3 Структура приложения службы мониторинга

Приложение службы мониторинга разрабатывается в среде Visual Studio 2017 на языке C# 7.0 с использованием шаблона проекта Windows Service. На основе требований, составленных в предыдущих разделах, приложение осуществляет взаимодействие со спроектированной базой данных при помощи технологии Entity Framework.

При помощи конструктора ADO.NET в проекте приложения службы загружена EMD модель Monitoring Service Model (рис. 4 «Модель данных в проекте приложения службы») на основе существующей базы. Полученная модель включает в себя классы, определяющие сущности базы данных, определения таблиц, столбцов и типов данных, а также сопоставление классов и таблиц из модели. Строка подключения к БД системы мониторинга задается в файле конфигурации приложения App.config в элементе ConnectionStrings с именем MonitoringServiceEntities.

Рис. 4 «Модель данных в проекте приложения службы»

Для установки службы мониторинга в системе и обозначения первоначальной конфигурации приложения в проекте реализован компонент ProjectInstaller, который состоит из serviceProcessInstallerMS и serviceInstallerMS (рис. 5 «Состав компонента установки приложения ProjectInstaller»).

Рис. 5 «Состав компонента установки приложения ProjectInstaller»

При помощи serviceProcessInstallerMS (рис. 6 «Настройки компонента serviceProcessInstallerMS») можно задать тип учетной записи, от которой будет работать служба. В данном случае используется тип учетной записи «User», то есть при установке приложения пользователю необходимо будет явно указать учетные данные.

Рис. 6 «Настройки компонента serviceProcessInstallerMS»



Компонент serviceInstallerMS позволяет настроить имя службы для отображения в системе, добавить описание службы и выбрать тип запуска (рис. 7 «Настройки компонента serviceInstallerMS»). В этом проекте используется тип запуска Automatic, так как служба запускается с заданной пользователями периодичностью.

Рис. 7 «Настройки компонента serviceInstallerMS»

Для каждого из состояний приложения службы реализован набор методов, представленных в таблице 5 «Описание методов для состояний службы мониторинга».

Таблица 5. Описание методов для состояний службы мониторинга

Состояние	Метод / Конструктор	Описание
Запуск службы	Program.Main()	В методе инициализируется объект класса MonService. Объект добавляется в массив типа ServiceBase. Выполняется регистрация исполняемого файла службы мониторинга.
	MonService.InitializeComponent()	В методе инициализируется объект eventLogMS типа System.Diagnostics.EventLog. Объект предназначен для записи в журнал событий службы мониторинга.
	MonService.MonService()	В конструкторе класса MonService создаются и/или определяются параметры журнал службы мониторинга и инициализируются поля класса _checks, _scheduledChecks, _categorizedChecks, _currentHistoryResults.
	MonService.OnStart(string[] args)	В методе инициализируется объект типа Timer. Интервал (interval) таймера задается при помощи ключа из файла конфигурации Service Polling Interval. Для объекта определяется поведение по истечении интервала времени (Elapsed) - делегату назначается метод T1_Elapsed(object sender, ElapsedEventArgs e).
	MonService. T1_Elapsed(object sender, ElapsedEventArgs e).	Метод вызывается по истечении таймера и задает поведение службы мониторинга, порядок и логику перехода к другим состояниям и записей в журнал событий службы.
Получение проверок из базы и фильтрация отключенных проверок	MonService.RetrieveData()	Метод возвращает коллекцию с типом MonitoringCheck, которая передается в _checks. Коллекция содержит данные по активным проверкам из базы. Фильтрация происходит по значению поля Disabled сущности MonitoringCheck.
Проверка настроек расписания	MonService.GetScheduledChecks()	Метод анализирует параметры расписания для объектов из коллекции _checks и возвращает коллекцию типа MonitoringCheck (_scheduledChecks). Для текущих проверок происходит присвоение новых значений параметров расписания и вызов метода UpdateDBSchedule() для обновления параметров расписания. При расчете нового значения NextExecutionTime используется метод GetTimeSpan(string intervalMeasurement, int pollingInterval).
	MonService.UpdateDBSchedule()	Метод обновляет параметры расписания - LastExecutionTime и NextExecutionTime - для проверки в базе.
	MonService.GetTimeSpan(string intervalMeasurement, int pollingInterval)	Метод возвращает объект типа TimeSpan для предоставленного интервала обработки проверки и его измерения. Этот объект используется для расчета нового значения параметра NextExecutionTime и передается в метод DateTime.Add().
Определение категории проверки	MonService.DefineCategory()	Метод инициализирует объекты классов, реализующих интерфейс IMonitoringCheckCategory. В каждый из объектов классов передается соответствующая данной категории проверка из _scheduledChecks. Категорированные проверки хранятся в коллекции _categorizedChecks.
Получение значений параметров проверки и получение статуса проверки	MonService.GetHistoryData()	Метод определяет необходимые значения параметров проверки для последующего сохранения в истории. Для каждого объекта коллекции _categorizedChecks происходит вызов метода ObtainActualValue(out proccessedWithError, out errorMessage), который определен в каждом классе, рализующем интерфейс IMonitoringCheckCategory. Далее для каждого объекта определяется его группа статусов и текущий тип статуса. Результаты сохраняются в коллекцию _currentHistoryResults.
	IMonitoringCheckCategory .ObtainActualValue(out proccessedWithError, out errorMessage),	Метод возвращает значение контрольного и дополнительного параметров проверки на текущий момент, а также определяет обработалась ли проверка успешно или с ошибками.
	MonService.GetStateType( string comaprisonOperator, string expectedValue, string warningThreshold, string criticalThreshold, string actualValue, bool processedWithError)	Метод возвращает идентификатор текущего статуса проверки на основе результата обработки одного из методов: CalculateStagesState(string expectedValue, string warningThreshold ,string criticalThreshold ,string actualValue ,string comaprisonOperator) или CalculateBinaryState(string expectedValue, string actualValue, string comaprisonOperator).
	MonService. CalculateStagesState(string expectedValue, string warningThreshold ,string criticalThreshold ,string actualValue ,string comaprisonOperator)	Метод возвращает идентификатор текущего статуса проверки группы Stages.
	MonService. CalculateBinaryState(string expectedValue, string actualValue, string comaprisonOperator)	Метод возвращает идентификатор текущего статуса проверки группы Binary.
	GetStateTypeGroup(int stateTypeId)	Метод возвращает идентификатор группы текущего статуса проверки.
Сохранения результатов	MonService.InsertHistory()	Метод сохраняет объекты типа History из коллекции _currentHistoryResults в базе данных.
Остановка службы мониторинга	MonService.OnStop()	Метод вызывается при остановке приложения службы вручную. В журнал событий записывается информацию об остановке работы службы мониторинга.

Для каждой из категорий должен быть определен свой класс, реализующий интерфейс IMonitoringCheckCategory. Соотношения классов, реализованных в приложении службы, и категорий приведены в таблице 6 «Соотношения классов приложения и категорий проверок».

Таблица 6. Соотношения классов приложения и категорий проверок

Класс	Категория
SQLQueryResult	Время выполнения SQL запроса на сервере
	Проверка итогового значения SQL запроса на сервере
XMLQueryResult	Значение атрибута XML из файла
	Значение атрибута XML с веб страницы
JSONQueryResult	Значение атрибута JSON из файла
	Значение атрибута JSON с веб страницы
ValueFromLogs	Поиск словосочетания в логах
WebResourceResponseCode	Код ответа web страницы
	Код ответа web API

Диаграмма классов и код проекта добавлены в Приложения 2 - «Диаграмма классов приложения службы» и 3 - «Код проекта службы мониторинга» соответственно.



3. Тестирование сценариев взаимодействия со службой мониторинга

3.1 Диаграмма вариантов использования

Рис. 8 «Диаграмма вариантов использования»

На рис.8 «Диаграмма вариантов использования» представлены возможные сценарии взаимодействия пользователя с системой мониторинга.

Для запуска и остановки службы мониторинга необходимо воспользоваться интерфейсом менеджера служб Windos. Запуск службы сопровождается созданием журнала событий и позволяет пользователю наблюдать за состоянием инструмента по записям в журнале.

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

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

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

3.2 Тестирование сценариев запуска и остановки службы

Компонент установки службы в системе настроен таким образом, что приложение устанавливается в системе с именем MonitoringService. При первом запуске службы в системе для нее создается отдельный журнал событий для записи информации о состоянии приложения. Приложение становится доступно в интерфейсе менеджера служб Windows после его установки на локальном компьютере / сервере под управлением Windows (рис. 9 «Служба мониторинга в интерфейсе менеджера служб Windows»).



Рис. 9 «Служба мониторинга в интерфейсе менеджера служб Windows»

Успешный запуск приложения через интерфейс сопровождается переходом службы в состояние «Выполняется» (рис. 10 «Состояние запущенной службы мониторинга»).

Рис. 10 «Состояние запущенной службы мониторинга»



Согласно составленным требованиям, в системе регистрируется журнал для ведения записей о событиях приложения мониторинга с именем MonitoringServiceLog (рис. 11 «Журнал событий службы мониторинга»). Журнал доступен в интерфейсе просмотра событий Windows.

Рис. 11 «Журнал событий службы мониторинга

Запуск и остановка службы мониторинга сопровождаются внесением соответствующих сообщений в журнал событий (рис. 12 «Сообщение о запуске службы в журнале» и рис. 13 «Сообщение об остановке службы в журнале»).



Рис. 12 «Сообщение о запуске службы в журнале»

Рис. 13 «Сообщение об остановке службы в журнале»

Успешная остановка приложения через интерфейс управления переводит службу в состояние «Остановлена» (рис. 14 «Состояние остановленной службы мониторинга»).

Рис. 14 «Состояние остановленной службы мониторинга»

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

3.3 Тестирование сценария просмотра статуса проверки

Для проверки сценария возможности просмотра статуса необходимо добавить в систему новое правило и заполнить справочники базы данных. Справочники базы данных заполняются при помощи скрипта из приложения 4 - «Скрипт заполнения справочников базы данных». Так как разработка пользовательского интерфейса не входит в задачи данной работы, новая проверка будет добавлена в базу данных системы мониторинга при помощи выполнения скрипта.

USE MonitoringService

GO

BEGIN TRY

BEGIN TRANSACTION

DECLARE @Table_ID INT

INSERT INTO dbo.[Resource]

VALUES

(3, 'https://www.w3schools.com/xml/plant_catalog.xml')

INSERT INTO dbo.MonitoringCheckQuery

VALUES

(IDENT_CURRENT('dbo.[Resource]'), 3

,'{ "XPath":"CATALOG/PLANT[COMMON=''Crowfoot'']/PRICE", "namespaces":{}}',2)

INSERT INTO dbo.MonitoringCheckScheduler

VALUES

('{

"PollingInterval":"5",

"IntervalMeasurement":"minutes",

"LastExecutionTime":"2017-04-29 11:22",

"NextExecutionTime":"2017-04-29 13:22"

}')

INSERT INTO dbo.MonitoringCheck

VALUES

(3,1,'$9.34',NULL,NULL,IDENT_CURRENT('dbo.MonitoringCheckQuery')

,'Test check for use case', 'My test check for use case'

,IDENT_CURRENT('dbo.MonitoringCheckScheduler'),0)

INSERT INTO dbo.AdditionalParametrs ([MonitoringCheckId], [AttributeName], [AttributeResourcePath])

VALUES

(IDENT_CURRENT('dbo.MonitoringCheck'),'Common name', 'CATALOG/PLANT[COMMON=''Crowfoot'']/BOTANICAL')

COMMIT

END TRY

BEGIN CATCH

ROLLBACK

END CATCH

При помощи данного скрипта в систему была добавлена проверка категории «Значение атрибута XML с веб страницы». Проверка относится к группе статусов Binary и считается успешной, если контрольное значение равно “$9.34”. У проверки также настроены дополнительный атрибут “Common name” и периодичность запуска каждые пять минут. После выполнения скрипта, в таблицы добавляются соответствующие значения свойств для новой проверки, и создается объект MonitoringCheck (рис. 15 «Объект MonitoringCheck в таблице базы»).

Рис. 15 «Объект MonitoringCheck в таблице базы»

При последующей итерации или запуске службы мониторинга в журнале событий появляется соответствующая запись об обработке настроенной проверки (рис. 16 «Запись об обработке проверки в журнале событий»).

Рис. 16 «Запись об обработке проверки в журнале событий»

Данные об актуальном статусе текущей проверки можно получить при помощи выполнения SQL запроса к таблице истории мониторинга History.

USE MonitoringService

GO

SELECT h.*

FROM dbo.History AS h

WHERE h.MonitoringCheckId = 9 --ID of the inserted rule

AND h.CheckDate = (SELECT MAX(h1.CheckDate)

FROM dbo.History AS h1

WHERE h1.MonitoringCheckId = 9)

Результатом выполнения запроса на момент выполнения тестового сценария были успешный статус для данной проверки и значение дополнительного атрибута “Ranunculus” (веб страница для загрузки XML содержит информацию о каталоге цветов).

Рис. 17 «Результат выполнения запроса на получение текущего статуса проверки»

Таким образом, в службе мониторинга реализован функционал обработки настроенных пользователем проверок, согласно описанным требованиям. На текущем этапе разработки системы мониторинга пользователи могут получать информацию о текущих статусах проверок из базы при помощи выполнения SQL запроса.

USE MonitoringService

GO

SELECT h.HistoryId, mc.MonitoringCheckName, mc.MonitoringCheckDescription

,st.StateTypeName, h.AdditinalParametrsValue, h.ActualValue

,h.CheckDate, h.ErrorMessage, h.ProcessedWithError

FROM dbo.History AS h

INNER JOIN dbo.StateType AS st

ON st.StateTypeId = h.StateTypeId

INNER JOIN dbo.MonitoringCheck AS mc

ON mc.MonitoringCheckId = h.MonitoringCheckId

WHERE h.CheckDate = (SELECT MAX(h1.CheckDate)

FROM dbo.History AS h1

WHERE h1.MonitoringCheckId = h.MonitoringCheckId)



3.4 Тестирование сценария отключения настроенной проверки

Как уже было отмечено ранее, отключение проверки представляет собой проставление соответствующего значения (true) флага Disabled для неё в базе данных. Для настроенной на предыдущем шаге проверки можно проставить флаг при помощи выполения SQL запроса.

USE MonitoringService

GO

UPDATE dbo.MonitoringCheck

SET [Disabled] = 1

WHERE MonitoringCheckId = 9;

В резальтате выполнения запроса запись в таблице MonitoringCheck для отключенной проверки будет содержать значение “1” для поля Disabled (рис. 18 «Результат выполнения запроса на отключение проверки»).

Рис. 18 «Результат выполнения запроса на отключение проверки»

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

Для выполнения тестирования данного сценария обновим настройки проверки и зададим параметры нереализованной в службе категории. Запущенная служба мониторинга не должна выдавать ошибок категоризации.

USE MonitoringService

GO

UPDATE dbo.MonitoringCheck

SET MonitoringCheckTypeId = 6--Web Resource Availability

WHERE MonitoringCheckId = 9;

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

Рис. 19 «Предупреждение об отсутствии активных проверок в журнале»

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



Заключение

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

В результате проведенного исследования были определены следующие категории проверок, которые необходимо реализовать на данном этапе проекта:

1. Проверка времени выполнения SQL запроса на сервере

2. Проверка итогового значения SQL запроса на сервере

3. Значение атрибута XML из файла

4. Значение атрибута XML с веб страницы

5. Значение атрибута JSON из файла

6. Значение атрибута JSON с веб страницы

7. Поиск словосочетания в логах

8. Код ответа web страницы

9. Код ответа web API

Для реализации перечисленных категорий были составлены требования к архитектуре разрабатываемой системы мониторинга, взаимодейтсвию ее компонентов, структуре данных и функциональному наполнению. На основе требований были разработы база данных для хранения информации о параметрах пользовательских проверок и истории и прототип службы мониторинга на базе приложения службы Windows. Функционал разработанных компонентов был успешно протестирован на основе диаграммы вариантов использования системы. В результате тестирования было определено, что разработанный прототип службы мониторинга и его интеграция с базой данных соответствуют составленным требованиям и решают задачи, поставленные перед системой мониторинга.

Таким образом, в рамках данной работы были решены все поставленные задачи и цели. Быстрое развертывание и конфигурация компонентов системы достигаются за счет использования наиболее распространенных платформ и технологий - Microsoft SQL Server для работы с базой данных и приложение службы Widnows для управления компонентом получения данных о текущем состоянии поддерживаемых систем. При помощи среды MS SQL Management Studio пользователи могут управлять составом проверок и их настройками, а также наблюдать за текущим состоянием компонентов инфраструктуры. За счет разработанной базы данных инженеры поддержки могут получать статистические данные (отчеты) о состоянии компонентов поддержки и использовать для выявления наиболее проблемных участков в структуре сервисов.

На последующих этапах развития проекта планируется разрабокта веб-интерфейса для добавления, изменения и отключения пользовательских проверок и отображения их текущего состояния на доске. Функционал системы может быть дополнительными категориями проверок на основе потребностей инженеров поддержки, выявленных после внедренияразработанной системы, а также сервисом оповещений о сработавших мониторах. Также для базы данных могут быть настроены отложенные задания по очистке устаревших исторических данных из таблицы History и отчеты на локальном сервере репортинга.

Список использованной литературы

1. Диго Светлана Михайловна. Базы данных: проектировние и создание. Учебник. М.:ФиС; 2005 г.; 36,4 п.л.

2. ИТ-аутсорсинг (рынок России). (2017). // TAdviser - портал об ИТ в госуправлении и бизнесе. Крупнейшая в РФ база знаний о технологиях, ИТ-проектах и профессионалах отрасли. [Электронный ресурс]. URL: http://tadviser.ru/a/145951

3. Константин Нарыжный. Разбираемся с определением ИТ-услуги. (5/10/2011). // Cleverics. [Электронный ресурс]. URL: https://cleverics.ru/subject-field/articles/321-servi

4. Манакова И.П. Обзор методов анализа и мониторинга сетевого трафика. (16/04/2017). // [Электронный ресурс]. URL: http://it-bloknot.ru/?q=content/обзор-методов-анализа-и-мониторинга-сетевого-трафика

5. Паттерн Adapter (адаптер, wrapper, обертка). (16/04/2017). // cpp-reference.ru - информационный ресурс, посвященный проектированию программных систем на языке программирования С++. [Электронный ресурс]. URL: http://cpp-reference.ru/patterns/structural-patterns/adapter/

6. Полякова Нина Владимировна, Поляков Владимир Владимирович, Обухова Анна Андреевна. ИТ-услуга: определение, свойства, структура // Известия Иркутской экономической академии. - 2013. - №5.

7. Рихтер Д. CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#. 4-е издание. - СПб.:Питер, 2013. - 896с.:ил. - (Серия «Мастер-класс»).

8. Руководство по Entity Framework. (13/10/2016). // METANIT.COM - сайт посвящен различным языкам и технологиям программирования, компьютерам, мобильным платформам и ИТ-технологиям. [Электронный ресурс]. URL: https://metanit.com/sharp/entityframework/

9. Статистика поставщика для SQL Server. (25/04/2017). // Библиотека MSDN - библиотека официальной технической документации для разработчиков под ОС Microsoft Windows. [Электронный ресурс]. URL: https://msdn.microsoft.com/ru-ru/library/7h2ahss8(v=vs.110).aspx

10. Уэнделл Одом. (2013). Официальное руководство Cisco по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 640-822. Диалектика-Вильямс.

11. Эдди Османи, Андрэ Хэнсон. Перевод: Антон Шувалов. (2011). // Паттерны для масштабируемых JavaScript-приложений. [Электронный ресурс]. URL: http://largescalejs.ru/

12. Dejan Sarka, Itzik Ben-Gan, Ron Talmage. Training Kit (Exam 70-461) Querying Microsoft SQL Server 2012. Microsoft Press; 1 edition (December 25, 2012).

13. Filipe de Sб-Soares, Delfina Soares, Josй Arnaud. (2014). Towards a theory of information systems outsourcing risk. Procedia Technology, 16, 623 - 637

14. G.P.A.J. Delen, R.J. Peters, C. Verhoef, S.F.M. van Vlijmen. (2016). Lessons from Dutch IT-outsourcing success and failure. Science of Computer Programming, 130, 37-68.