Настройка SNMP на удаленных хостах
Чтобы иметь возможность проводить мониторинг по протоколу SNMP, на сетевом оборудовании необходимо предварительно настроить агентов этого протокола. Схема работы SNMP в связке с ядром системы сетевого мониторинга показана на рисунке ниже.
Рис. 4.5 - Схема мониторинга посредством протокола SNMP
Конфигурационные параметры хостов представлены в Приложении З. Безопасность осуществляется путем индивидуальной настройки пакетного фильтра на каждом из хостов в отдельности и посредством организации защищенных системных подсетей, в которые имеет доступ только авторизованный персонал предприятия. Кроме того настройка произведена таким образом, что посредством SNMP протокола можно производить только чтение параметров, а не их запись [18, с. 58].
Настройка агента на удаленных хостах
Для получения возможностей расширенного мониторинга хостов и служб, необходимо установить на них агента Nagios, который называется nagios-nrpe-server:
# aptitude install nagios-nrpe-server
Конфигурация агента представлена в Приложении Л. Схема работы агента показана на Рисунке 4.5 выше.
Установка и настройка модуля отслеживания загрузки
MRTG (Multi Router Traffic Grapher) - сервис, позволяющий посредством протокола SNMP получать из нескольких устройств информацию и отображать в окне вашего браузера графики загруженности канала (входящий трафик, исходящий, максимальный, средний) с шагом в минуты, часы, дни и за год.
|
|
|
Требования к установке
Для работы MRTG требуются следующие библиотеки:
§ gd - graph drawing library. Библиотека, ответственная за формирование графики (http://www.boutell.com/gd/);
§ libpng - требуется gd для создания графики в формате png (http://www.libpng.org/pub/png/src/);
§ zlib - данная библиотека используется для компрессии созданной графики (<ftp://sunsite.cnlab-switch.ch/mirror/infozip/zlib/>).
В нашем случае установка сводится к выполнению одной команды, т.к. выбран способ установки предкомпиленного пакета из репозитория:
# aptitude install mrtg
Создавать конфигурационные файлы можно вручную, а можно воспользоваться идущими в составе пакета генераторами конфигураций:
# cfgmaker <community string>@<hostname> > <config path>
После генерации конфигурационного файла рекомендуется проверить его, т.к. в нем могут находится описания интерфейсов, которые нам не нужно анализировать на загруженность. В таком случае определенные строки в файле комментируются или удаляются. Пример конфигурационного файла MRTG приведен в Приложении М. Из-за большого объема этих файлов приведен лишь пример одного файла.
Далее необходимо сгенерировать индексные файлы будущих веб страниц, делается это также при помощи специального генератора:
|
|
|
# indexmaker <config path> > <index path>
Индексные страницы представляют собой обычные html файлы и их содержимое особого интереса не представляет, поэтому приводить их примеры не имеет смысл. В Приложении Н показан пример отображения графиков загрузки интерфейсов.
В завершение необходимо организовать проверку загруженности интерфейсов по расписанию. Достигнуть этого проще всего средствами операционной системы, а именно параметрами crontab.
Установка и настройка модуля сбора системных журналов событий
В качестве модуля сбора системных журналов событий был выбран пакет syslog-ng.ng (syslog next generation) - это многофункциональная служба протоколирования системных сообщений. По сравнению со стандартной службой syslogd, он имеет ряд отличий:
§ усовершенствованная схема конфигурации
§ фильтрация сообщений не только по приоритетам, но и по их содержанию
§ поддержка regexps (regular expressions)
§ более гибкое манипулирование и организация логов
§ возможность шифрования канала передачи данных с помощью IPSec/Stunnel
В следующей таблице представлены поддерживаемые аппаратные платформы.
Таблица 4.1 - Поддерживаемые аппаратные платформы
| x86 | x86_64 | SUN SPARC | ppc32 | ppc64 | PA-RISC | |
| AIX 5.2 & 5.3 | Нет | Нет | Нет | Да | По запросу | Нет |
| Debian etch | Да | Да | Нет | Нет | Нет | Нет |
| FreeBSD 6.1 * | Да | По запросу | По запросу | Нет | Нет | Нет |
| HP-UНет 11i | Нет | Нет | Нет | Нет | Нет | Да |
| IBM System i | Нет | Нет | Нет | Да | Нет | Нет |
| Red Hat ES 4 / CentOS 4 | Да | Да | Нет | Нет | Нет | Нет |
| Red Hat ES 5 / CentOS 5 | Да | Да | Нет | Нет | Нет | Нет |
| SLES 10 / openSUSE 10.0 | Да | По запросу | Нет | Нет | Нет | Нет |
| SLES 10 SP1 / openSUSE 10.1 | Да | Да | Нет | Нет | Нет | Нет |
| Solaris 8 | Нет | Нет | Да | Нет | Нет | Нет |
| Solaris 9 | По запросу | Нет | Да | Нет | Нет | Нет |
| Solaris 10 | По запросу | Да | Да | Нет | Нет | Нет |
| Windows | Да | Да | Нет | Нет | Нет | Нет |
Примечение: * Доступ к базе данных Oracle не поддерживается
|
|
|
Подробное сравнение технических особенностей приведено в Приложении П.
Файлы описания правил и фильтров, а также конфигурация удаленных хостов приведены в Приложении Р.
Существует документ RFC, детально описывающий протокол syslog, в общем виде работу модуля сборщика системных журналов можно представить следующей схемой
Рис. 4.6 - Схема работы модуля сбора системных журналов
На клиентском хосте каждое отдельное приложение пишет свой журнал событий, образуя тем самым источник. Далее поток сообщений для журналов проходит через определение места для хранения, далее через фильтры определяется его сетевое направление, после чего, попадая на сервер логирования, для каждого сообщения вновь определяется место хранения. Выбранный модуль имеет большие возможности масштабирования и усложненной конфигурации, например фильтры могут разветвляться, таким образом, что сообщения о системных событиях будут отправляться в несколько направлений в зависимости от нескольких условий, как показано на рисунке ниже.
|
|
|
Рис. 4.7 - Ветвление фильтров
Возможность масштабирования подразумевает, что в целях распределения нагрузки, администратор будет развертывать сеть из вспомогательных фильтрующих серверов, так называемых релеев.
Рис. 4.8 - Масштабирование и распределение нагрузки
В конечном итоге, максимально упрощенно, описать работу модуля можно так - клиентские хосты передают сообщения журналов событий разных приложений разгружающим серверам, те, в свою очередь могут передавать их по цепочке релеев, и так до центральных серверов сбора.
Рис. 4.9 - Обобщенная схема работы модуля
В нашем случае поток данных не столь велик чтобы развертывать систему разгружающих серверов, поэтому было решено использовать упрощенную схему работы клиент - сервер [31, с. 64].
Рис. 4.10 - Принятая схема работы
5. РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА
В целом системному администратору рекомендуется придерживаться существующей иерархии расположения конфигурационных файлов и каталогов. Добавление в систему мониторинга новых хостов и служб сводится к созданию новых конфигурационных файлов и инициализационных скриптов, как было показано в разделе 5 - Разработка программного обеспечения, поэтому повторно описывать параметры и принципы конфигурирования системы в этой работе смысла нет, однако стоит более подробно остановиться на описании интерфейсов отдельных модулей системы.
Дата добавления: 2019-09-13; просмотров: 197; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!