WatchDog

  1. Введение
  2. Задачи
  3. Архитектура

·        Общая схема

·        WDServer

·        WDWorker

·        WDMetaServerManager

·        WDMetaServer

·        Взаимодействие модулей (схемы)

  1. Пользовательскийинтерфейс

 


1. Введение.

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

 

2. Задачи.

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

·        Надежная и быстрая работа, без задержек по времени

·        Своевременное уведомление пользователей системы о выходе из строя какого-либо сервера, при этом должны предлагаться на выбор различные способы уведомлений(e-mail, icq, smsetc)

·        Возможность управлять системой через клиента (видимо самый удобный вариант это через web-интерфейс)

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

·        Также ещё необходимо будет продумать способ быстрого, легкого, удобного запуска всей системы. Поскольку на первый взгляд огромное количество модулей потребует тщательной длительной настройки. Для этого во-первых необходима подробная документация, во-вторых, понятный интерфейс установки

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

·        Возможность управлять системой через консоль, поскольку среда использования это Unix-подобные системы, а, как правило, серверы, на которых такая система будет запускаться, работают в консольном режиме

 

3. Архитектура.

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

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

Взаимодействие модулей более подробно изображено на рисунке.

·        WDServer

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

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

Сразу после запуска всей системы и выполнения предыдущей функции запускаются несколько потоков. Один поток выполняет раздачу заданий, он периодично проходит по списку всех сервисов, выбирает те, которые в данный момент времени необходимо проверить и раздает доступным Worker’ам. Второй поток ожидает результатов от Worker’а. Третий – регистрирует вновь появившихся worker’ов. Четвёртый поток отвечает за управление сервером: он принимает команды от клиента и вызывает соответствующие методы.

·        WDWorker

Этот модуль может быть запущен сразу на нескольких различных машинах. Его функциями являются, получив задания от WDServer’а (по сети), найти свободный MetaServer и отдать ему задание. Для нахождения он обращается к MetaServerManager’у, на котором хранится и обновляется список MetaServer’ов. После этого, задание передается на обработку MetaServer’у. Также получив, результаты проверки сервиса от MetaServer’а, он перенаправляет их на WDServer.

·        WDMetaServerManager

Он создан для того, чтобы обеспечить надежную работу сразу нескольких MetaServer’ов. Таким образом, он может регистрировать их, также получать от них сообщения, о переполненности. При запросе WDWorker’а, он находит некоторый свободный MetaServer и передает его параметры. Возможно для оптимизации потребуется применить некий алгоритм, чтобы выбрать какой-то один из нескольких свободных MetaServer’ов. Этот модуль не может быть запущен более чем 1 раз, поскольку его функции достаточно просты, т.е. он вряд ли будет часто «падать» и синхронизация этих модулей будет достаточно сложной.

·        WDMetaServer

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

·        Взаимодействие модулей (схемы)

 

 

 

 

 

4. Пользовательский интерфейс.

 

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

-         посмотреть доступные отчёты

-         изменить способ оповещения о произошедших сбоях: Он может на разные сервера поставить разные способы оповещения, также он может указать, что оповещать его надо не при каждом сбое, а, например, после трёх подряд сбоев и т.п. Оповещение будет возможно по средствам e-mail, icq, sms (optional).

 

У администратора системы будут следующие возможности:

-         добавление новых и удаление уже существующих пользователей.

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

-         запуск и остановка проверяющей системы.

-         добавление новых и удаление старых задач: Для каждого нового host-a можно будет выбрать список проверяемых сервисов из базы уже существующих и/или предложить свой script написанный на Perl (optional), для каждого проверяемого сервиса можно будет установить периодичность проверки и timeout, по истечении которого, в случае отсутствия результата проверки, сервер начнёт бить тревогу.

-         редактирование уже существующих заданий

 

Схематически возможности пользователей и администратора показаны на диаграмме: