Файл: Способы представления данных в информационных системах (Понятие, виды, классификация и способы предоставления данных в ИС).pdf

Отредактируем конфигурационный файл

/usr/local/nagios/etc/objects/contacts.cfg любым текстовым редактором и изменим email адрес привязанный к определению контакта nagiosadmin на адрес, на который мы собираемся принимать сообщения о неполадках.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Настройка веб-интерфейса

Установим конфигурационный файл веб-интерфейса Nagios в директорию Apache conf.d.

# make intall-webconf

Создадим учетную запись nagiosadmin для входа в веб-интерфейс Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Перезапустим Apache, чтобы изменения вступили в силу.

# /etc/init.d/apache2 reload

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

6) Компилируем и устанавливаем плагины Nagios

Распакуем сжатые исходные коды плагинов Nagios:

# cd ~/downloads

# tar xzf nagios-plugins-1.4.11.tar.gz

# cd nagios-plugins-1.4.11

Компилируем и устанавливаем плагины:

# ./configure --with-nagios-user=nagios --with-nagios-group=nagios

# make

#make install

7) Запускаем службу Nagios

Настроим Nagios на автоматическую загрузку при включении операционной системы:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Проверим синтаксическую правильность примерных конфигурационных файлов:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Если ошибок нет, то запускаем Nagios:

# /etc/init.d/nagios start

8) Входим на веб-интерфейс

Теперь можно войти в веб-интерфейс Nagios, используя следующий URL. Будет выдан запрос на ввод имени пользователя (nagiosadmin) и пароля, которые мы задали ранее.

http://192.168.10.2/nagios3/

9) Прочие настройки

Для получения напоминаний по email о событиях Nagios, необходимо установить пакет mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Необходимо отредактировать команды напоминаний Nagios файле /usr/local/nagios/etc/objects/commands.cfg и изменить все ссылки с '/bin/mail' на '/usr/bin/mail'. После этого необходимо перезапустить службу Nagios:

# sudo /etc/init.d/nagios restart

Подробная конфигурация почтового модуля описана в Приложении Г.

Рисунок 3. Ядро системы

Алгоритм и логика работы ядра сетевого мониторинга показаны ниже.

Рисунок 4.Алгоритм оповещений Nagios

Описание установки ядра системы из репозитария.

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

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

В этом случае установка сводится к вводу одной команды: % sudo aptitude install nagios

Менеджер пакетов самостоятельно удовлетворит все зависимости и установит необходимые пакеты.

Перед детальной настройкой следует понимать то, как работает ядро Nagios. Его графическое описание приведено ниже в иллюстрации 8.

На следующем рисунке показана упрощенная схема работы службы Nagios.

Служба Nagios читает основной конфигурационный файл, в котором помимо основных параметров работы службы имеются ссылки на файлы ресурсов, файлы описания объектов и конфигурационные файлы CGI [9, с. 94].

Диаграмма работы ядра сетевого мониторинга показана в Приложении Д.

Описание взаимодействия конфигурационных файлов.

В директории /etc/apache2/conf.d/ находится файл nagios3.conf, из которого веб-сервер apache берет настройки для nagios.

Конфигурационные файлы nagios находятся в директории /etc/nagios3.

Файл /etc/nagios3/htpasswd.users содержит пароли для пользователей nagios. Команда для создания файла и установки пароля для пользователя nagios по умолчанию приведена выше. В дальнейшем, необходимо будет опустить аргумент "-c" при задании пароля для нового пользователя, иначе новый файл затрет старый.

Файл /etc/nagios3/nagios.cfg содержит основную конфигурацию самого nagios. Например, файлы журналов событий или путь к остальным конфигурационным файлам, которые nagios зачитывает при старте.

В директории /etc/nagios/objects задаются новые хосты и сервисы.

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

Заполнение описаний хостов и служб

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

Созданная структура показана в Приложении З.

Файл hosts.cfg

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

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

Файл hostgroups.cfg

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

Файл contactgroups.cfg

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

Следующим шагом нужно указать контактную информацию и настройки оповещений.

Файл contacts.cfg

Помимо того, что в этом файле приводится дополнительная контактная информация пользователей, одно из полей, contact_name, имеет ещё одно назначение. CGI-cкрипты используют имена, заданные в этих полях для того чтобы определить, имеет пользователь право доступа к какому-то ресурсу или нет. Вы должны настроить аутентификацию, основывающуюся на .htaccess, но кроме этого нужно использовать те же имена, которые использованы выше, для того чтобы пользователи могли работать через Web-интерфейс.

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

Файл services.cfg

Здесь мы как и в файле hosts.cfg для хостов, задали лишь общие параметры для всех служб.

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

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

Стоит отметить, что Windows хосты проходят мониторинг посредством протокола SNMP и NSClient’a, поставляемого с Nagios. Ниже представлена схема его работы:

Рисунок 5. Схема мониторинга Windows хостов

В тоже время *nix хосты проходят мониторинг также посредством SNMP, а также NRPE плагина. Схема его работы показана на рисунке:

Рисунок 6. Схема мониторинга *nix хостов

Написание плагинов.

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

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

Большая часть их них поставляется вместе с пакетом Nagios.

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

Настройка SNMP на удаленных хостах.

Чтобы иметь возможность проводить мониторинг по протоколу SNMP, на сетевом оборудовании необходимо предварительно настроить агентов этого протокола. Схема работы SNMP в связке с ядром системы сетевого мониторинга показана на рисунке ниже.

Рисунок 7. Схема мониторинга посредством протокола SNMP

Конфигурационные параметры хостов представлены в Приложении З. Безопасность осуществляется путем индивидуальной настройки пакетного фильтра на каждом из хостов в отдельности и посредством организации защищенных системных подсетей, в которые имеет доступ только авторизованный персонал предприятия. Кроме того настройка произведена таким образом, что посредством SNMP протокола можно производить только чтение параметров, а не их запись [18, с. 58].

В следующей таблице представлены поддерживаемые аппаратные платформы.

Таблица 1

Поддерживаемые аппаратные платформы

Подробное сравнение технических особенностей приведено в Приложении П.

Файлы описания правил и фильтров, а также конфигурация удаленных хостов приведены в Приложении Р.

Существует документ RFC, детально описывающий протокол syslog, в общем виде работу модуля сборщика системных журналов можно представить следующей схемой:

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

Рисунок 8. Схема работы модуля сбора системных журналов

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

Рисунок 9. Ветвление фильтров

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

Рисунок 10. Масштабирование и распределение нагрузки

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

Рисунок 11. Обобщенная схема работы модуля

В нашем случае поток данных не столь велик чтобы развертывать систему разгружающих серверов, поэтому было решено использовать упрощенную схему работы клиент – сервер [31, с. 64].

Рисунок 12. Принятая схема работы

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