BC/NW 2010;
№2 (17):3.1
РАЗРАБОТКА ПРОГРАММНОЙ
СИСТЕМЫ ДИСТАЦИОННОГО МОНИТОРИНГА СЕТЕВЫХ КОМПОНЕНТ
Городничев С.В., Артюхов О.И., Крепков И.М.
(Москва, Московский
энергетический институт (технический университет), Россия)
Любая корпоративная компьютерная сеть, даже
небольшая, требует постоянного внимания к себе. Как бы хорошо
она ни была настроена, насколько бы надежное ПО не было установлено на серверах
и клиентских компьютерах – нельзя полагаться лишь на внимание системного
администратора; необходимы автоматические и непрерывно действующие средства
контроля состояния сети и своевременного оповещения о возможных проблемах.
Даже случайные сбои аппаратного или программного
обеспечения могут привести к весьма неприятным последствиям. Существенное
замедления функционирования сетевых сервисов и служб – еще наименее неприятное
из них (хотя в худших случаях и может оставаться незамеченным в течение
длительных промежутков времени). Гораздо хуже, когда критично важные службы или
приложения полностью прекращают функционирование, и это остается незамеченным в
течение длительного времени. Типы же «критичных» служб могут быть весьма
разнообразны (и, соответственно, требовать различных методов мониторинга) [3].
От корректной работы веб-серверов и серверов БД может
зависеть работоспособность внутрикорпоративных приложений и важных внешних
сервисов для клиентов; сбои и нарушения работы маршрутизаторов могут нарушать связь между различными
частями корпорации и ее филиалами; серверы внутренней почты и сетевых мессенджеров, автоматических обновлений и резервного
копирования, принт-серверы – любые из этих элементов могут страдать от
программных и аппаратных сбоев.
Для обеспечения непрерывной проверки
функционирования удалённого сервера необходимо организовать работу планировщика заданий, который будет с
определённой периодичностью запускать проверки параметров этого сервера. Сами
проверки целесообразно выполнить в виде исполняемых файлов (скриптов),
это позволит выполнять их запуск без
применения дополнительных инструментов. Кроме того, в этих скриптах
должны содержаться все необходимые команды для получения нужных данных. Таким
образом, для осуществления проверок не потребуется устанавливать дополнительное
клиентское программное обеспечение на удалённых серверах, что позволяет
существенно упростить ввод в эксплуатацию данной системы мониторинга. Такой
подход является главной отличительной особенностью по сравнению с другими
системами мониторинга, предлагаемыми на современном рынке [1].
Система мониторинга не только отображает состояние
удалённых серверов на текущий момент, но и хранит все полученные данные. Эта
информация необходима для анализа функционирования систем с целью их возможной
оптимизации для повышения качества работы. Например, собранная статистика по
динамике заполнения дискового пространства за счёт роста объёма лог-файлов позволяет эффективно
настроить работу утилит ротации этих файлов (архивирование и перемещение на
другой массив) [2]. Для решения вышеописанной задачи требуется использование
базы данных. Структура БД для системы мониторинга достаточно проста, в ней
должна храниться информации о количестве и параметрах (например, тип ОС, IP) удалённых серверов, обо всех
типах проверок, которые проводятся для каждого сервера и о результате всех
произведённых проверок. Последние данные целесообразно хранить в разных
таблицах (каждая проверке соответствует отдельная таблица). Это обусловлено
тем, что мониторинг состояния серверов производится непрерывно с достаточно
частым интервалом, что приведёт к резкому росту объёма таблицы, если в ней будут
находиться все проверки конкретного сервера, и, как следствие, к существенному
замедлению процесса поиска нужной информации в ней.
Для удобного
и наглядного графического представления результатов проверок серверов необходим
web-сервер.
Его функциональность позволяет оперативно извлекать текущую информацию из базы
данных, отображать её в понятном виде и запускать необходимые проверки вручную,
не дожидаясь, пока это сделает планировщик заданий. Интерфейс отличается простой навигацией и
высоким быстродействием. Для обеспечения этих требований минимизировано число web-страниц, а также оптимизированы
запросы к базе данных (поиск текущей информации о работе удалённых серверов),
создан отдельный файл с настройками подключения HTTP-сервера к базе данных –
во-первых, это позволит избежать повторяющихся строк в программном коде
страниц, а во-вторых, обеспечит более высокий уровень безопасности.
Для организации оперативного оповещения в случае
выявленных сбоев система мониторинга должна обладать средствами автоматической
отправки электронных писем. Адресатами этих писем могут быть как администраторы
системы мониторинга, так и администраторы удалённого сервера. Такой подход
позволяет существенно снизить время между обнаружением сбоя и реакцией на этой
сбой. В общем случае для реализации такой структуры необходим полноценный
почтовый сервер, однако в подавляющем большинстве случаев не требуется его
создавать самостоятельно, так как обычно в любой компании уже существует
готовый почтовый сервер. Для реализации отправки писем нужно установить на
сервер мониторинга почтовый клиент MTA (Mail Transport Agent) и указать в его настройках адрес
cервера исходящей почты корпоративной
сети. Общая структура системы мониторинга представлена на рис. 1:
Рис. 1.
Структура системы мониторинга
Для демонстрации функционирования
системы мониторинга далее приведён алгоритм проверки дискового пространства. Проверка
свободного места на удалённом сервере осуществляется с помощью встроенной в
Unix-подобные системы команды df,
которая показывает список всех файловых систем по именам устройств,
сообщает их размер, занятое и свободное пространство и точки монтирования. Ключ
h или --human-readable отображает размер в человеко-читабельном формате. Схема
проверки дискового пространства приведена на рис. 2:
Рис. 2.
Схема проверки дискового пространства
Система мониторинга фиксирует процент
свободного дискового пространства и сравнивает это значение с пороговым. Численное значение порога – 95%. При таком
заполнении дискового пространства вероятность сбоя в работе сервисов удалённого
сервера увеличивается на порядок. Если этот порог превышен, то система
уведомляет ответственных лиц (администратора системы мониторинга и
администратора удалённого сервера) по электронной почте (рис.3). Результат проверки записывается в
базу данных системы мониторинга, откуда он уже становится доступным через
web-интерфейс (рис.4). В системе мониторинга предусмотрена функция расширения
свободного пространства за счёт архивирования «старых» логов (в частности,
логов apache), однако такую операцию система не
выполняет автоматически, это
решение принимает администратор (во-первых, заполнение места
может быть не связано с логами, тогда требуется дальнейший анализ ситуации, а,
во-вторых, логи могут использоваться на удалённом
сервере для каких-либо целей, и их архивирование может повлечь за собой
нежелательные последствия).
Рис. 3. Реакция системы на
критическое заполнение дискового пространства
Рис. 4.
Оповещение системы мониторинга по электронной почте
1. Олифер В. Г., Олифер Н.А. Компьютерные сети. Принципы, технологии,
протоколы. – СПб.: Питер, 1999. С. 374.
2. Форум OpenNet. Пример мониторинга свободного места, 10 апреля
2007.
http://www.opennet.ru/openforum/vsluhforumID3/37151.html
3. Security Lab. Методы мониторинга и обеспечения
безопасности для поддержания работоспособности корпоративной сети, 24 августа
2007.
http://www.securitylab.ru./analytics/301808.php