Поддержка разнородного оборудования - скорее желаемое, чем реально существующее свойство сегодняшних систем управления. К числу наиболее популярных продуктов сетевого управления относятся четыре системы: Spectrum компании CabletronSystems, OpenView фирмы Hewlett-Packard, NetView корпорации IBM и Solstice производства SunSoft - подразделения SunMicrosystems. Три компании из четырех сами выпускают коммуникационное оборудование. Естественно, что система Spectrum лучше всего управляет оборудованием компании Cabletron, OpenView - оборудованием компании Hewlett-Packard, а NetView- оборудованием компании IBM.

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

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей. Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании BayNetworks, CiscoWorks компании CiscoSystems, Transcend компании 3Com. Система Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании BayNetwork, полностью используя все их возможности и свойства. Оборудование других производителей под-держивается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNetManager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими системами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью [9, с. 76].

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

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как Oracle, Ingres или Informix. Использование универсальных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

2. ПОСТАНОВКА ЗАДАЧИ

С ростом клиентской базы, а как следствие и числа активного оборудования, возникла необходимость оперативного отслеживания состояния сети в целом и отдельных её элементов в подробности. До внедрения системы сетевого мониторинга сетевому администратору приходилось подключаться посредствам протоколов telnet, http, snmp, ssh и т.п. к каждому интересующему узлу сети и пользоваться встроенными средствами мониторинга и диагностики. На данный момент емкость сети составляет 5000 портов, 300 коммутаторов 2-го уровня, 15 маршрутизаторов и 20 серверов внутреннего пользования.

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

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

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

2.1 Техническое задание

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

2.2 Уточненное техническое задание

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

Система должна удовлетворять следующим требованиям:

§ минимальные требования к аппаратным ресурсам;

§ открытые исходные коды всех составляющих комплекса;

§ расширяемость и масштабируемость системы;

§ стандартные средства предоставления диагностической информации;

§ наличие подробной документации на все используемые программные продукты;

§ способность работать с оборудованием различных производителей.

сетевой администратор ядро загрузка

3. ПРЕДЛАГАЕМАЯ СИСТЕМА

3.1 Выбор системы сетевого мониторинга

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

§ имеются средства генерирования диаграмм;

§ имеются средства генерирования отчетностей;

§ есть возможность логического группирования;

§ существует встроенная система записи трендов и их прогнозирования;

§ имеется возможность автоматического добавления новых устройств (Autodiscovery) при помощи официального плагина;

§ имеется возможность расширенного мониторинга хоста с использованием агента;

§ поддержка протокола SNMP через плагин;

§ поддержка протокола Syslog через плагин;

§ поддержка внешних скриптов;

§ поддержка самописных плагинов и возможность их быстрого и простого создания;

§ встроенные триггеры и события;

§ полнофункциональный веб-интерфейс;

§ возможность распределенного мониторинга;

§ инвентаризация через плагин;

§ возможность хранения данных как в файлах, так и в базах данных SQL, что очень важно при увеличении объемов;

§ лицензия GPL, а следовательно бесплатная базовая поставка, поддержка и открытые исходные коды ядра системы и сопровождающих компонентов;

§ динамические и настраиваемые карты;

§ управление доступом;

§ встроенный язык описания хостов, сервисов и проверок;

§ возможность отслеживания пользователей.

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

Nagios позволяет производить мониторинг таких сетевых сервисов как SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и многих других. Кроме этого, можно следить за использованием ресурсов серверов, таких как расход дискового пространства, свободная память и загруженность процессора. Существует возможность создавать свои собственные обработчики событий. Эти обработчики будут выполняться при возникновении тех или иных событий, инициированных проверками сервисов или серверов. Такой подход позволит активно реагировать на происходящие события и пытаться автоматически решать возникшие проблемы. К примеру, можно создать обработчик событий, который будет самостоятельно перезапускать повисший сервис. Еще одним достоинством системы мониторинга Nagios является возможность управлять ею удаленно с помощью wap интерфейса мобильного телефона. Используя концепцию "родительских" хостов, легко описать иерархию и зависимости между всеми хостами. Такой подход чрезвычайно полезен для больших сетей, потому что позволяет производить сложную диагностику. А это качество, в свою очередь, помогает отличить не работающие хосты, от тех, что недоступны в данный момент из-за неполадок в работе промежуточных звеньев. Nagios умеет строить графики работы наблюдаемых систем и карты контролируемой сетевой инфраструктуры.

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

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

В документации, поставляемой с Nagios, говорится, что он будет стабильно работать и со многими другими Unix подобными системами. Для отображения web-интерфейса Nagios нам понадобится сервер Apache. Вы вольны, использовать любой другой, но в данной работе будет рассматриваться именно Apache, как наиболее распространенный на Unix платформах web-сервер. Можно установить систему мониторинга вообще без web-интерфейса, но мы так делать не станем, потому что это существенно уменьшает удобство пользования [35, с. 52].

4. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В качестве аппаратной части внедряемой системы можно использовать обычный IBM-совместимый компьютер, однако с учетом возможности дальнейшего повышения нагрузки и требований надежности и наработки на отказ, а также ГосСвязьНадзора, было приобретено сертифицированное серверное оборудование фирмы Aquarius.

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

Linux (полное название GNU/Linux, произносится «гну слэш лимнукс», также в некоторых языках «GNU+Linux», «GNU-Linux» и др.) -- общее название UNIX-подобных операционных систем на основе одноимённого ядра и собранных для него библиотек и системных программ, разработанных в рамках проекта GNU.

GNU/Linux работает на PC-совместимых системах семейства Intel x86, а также на IA-64, AMD64, PowerPC, ARM и многих других.

К операционной системе GNU/Linux также часто относят программы, дополняющие эту операционную систему, и прикладные программы, делающие её полноценной многофункциональной операционной средой.

В отличие от большинства других операционных систем, GNU/Linux не имеет единой «официальной» комплектации. Вместо этого GNU/Linux поставляется в большом количестве так называемых дистрибутивов, в которых программы GNU соединяются с ядром Linux и другими программами. Наиболее известными дистрибутивами GNU/Linux являются Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Российские дистрибутивы -- ALT Linux и ASPLinux.

В отличие от Microsoft Windows (Windows NT), Mac OS (Mac OS X) и коммерческих UNIX-подобных систем, GNU/Linux не имеет географического центра разработки. Нет и организации, которая владела бы этой системой; нет даже единого координационного центра. Программы для Linux -- результат работы тысяч проектов. Некоторые из этих проектов централизованы, некоторые сосредоточены в фирмах. Многие проекты объединяют хакеров со всего света, которые знакомы только по переписке. Создать свой проект или присоединиться к уже существующему может любой и, в случае успеха, результаты работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую, что позволяет быстро находить и исправлять ошибки и реализовывать новые возможности.

История развития UNIX-систем. GNU/Linux является UNIX-совместимой, однако основывается на собственном исходном коде

Именно такая гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность[источник не указан 199 дней] GNU/Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение людей из разных стран, обладающих разным видением проблем, защита кода лицензией GPL -- всё это стало причиной успеха свободных программ.

Конечно, такая высокая эффективность разработки не могла не заинтересовать крупные фирмы, которые стали открывать свои проекты. Так появились Mozilla (Netscape, AOL), OpenOffice.org (Sun), свободный клон Interbase (Borland) -- Firebird, SAP DB (SAP). IBM способствовала переносу GNU/Linux на свои мейнфреймы.

С другой стороны, открытый код значительно снижает себестоимость разработки закрытых систем для GNU/Linux и позволяет снизить цену решения для пользователя. Вот почему GNU/Linux стала платформой, часто рекомендуемой для таких продуктов, как СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Сообщество GNU/Linux поддерживает связь посредством групп пользователей Linux.

Большинство пользователей для установки GNU/Linux используют дистрибутивы. Дистрибутив -- это не просто набор программ, а ряд решений для разных задач пользователей, объединённых едиными системами установки, управления и обновления пакетов, настройки и поддержки.

Самые распространённые в мире дистрибутивы:

Ubuntu -- быстро завоевавший популярность дистрибутив, ориентированный на лёгкость в освоении и использовании.

openSUSE -- бесплатно распространяемая версия дистрибутива SuSE, принадлежащая компании Novell. Отличается удобством в настройке и обслуживании благодаря использованию утилиты YaST.

Fedora -- поддерживается сообществом и корпорацией RedHat, предшествует выпускам коммерческой версии RHEL.

Debian GNU/Linux -- международный дистрибутив, разрабатываемый обширным сообществом разработчиков в некоммерческих целях. Послужил основой для создания множества других дистрибутивов. Отличается строгим подходом к включению несвободного ПО.

Mandriva -- французско-бразильский дистрибутив, объединение бывших Mandrake и Conectiva (англ.).

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

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

Archlinux -- ориентированный на применение самых последних версий программ и постоянно обновляемый, поддерживающий одинаково как бинарную, так и установку из исходных кодов и построенный на философии простоты KISS, этот дистрибутив ориентирован на компетентных пользователей, которые хотят иметь всю силу и модифицируемость Linux, но не в жертву времени обслуживания.

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

Каждый из них имеет свою концепцию, свой набор пакетов, свои достоинства и недостатки. Ни один не может удовлетворить всех пользователей, а потому рядом с лидерами благополучно существуют другие фирмы и объединения программистов, предлагающие свои решения, свои дистрибутивы, свои услуги. Существует множество LiveCD, построенных на основе GNU/Linux, например, Knoppix. LiveCD позволяет запускать GNU/Linux непосредственно с компакт-диска, без установки на жёсткий диск.

Для желающих досконально разобраться с GNU/Linux подойдёт любой из дистрибутивов, однако довольно часто для этой цели используются так называемые source-based дистрибутивы, то есть предполагающие самостоятельную сборку всех (или части) компонентов из исходных кодов, такие как LFS, Gentoo, ArchLinux или CRUX [9, с. 94].

4.1 Установка ядра системы

Nagios можно устанавливать двумя способами - из исходных кодов и из собранных пакетов. У обоих способов есть преимущества и недостатки, рассмотрим их.

Плюсы установки пакета их исходных кодов:

§ возможность детального конфигурирования системы;

§ высокая степень оптимизации приложения;

§ наиболее полное представление работы программы.

Минусы установки пакета их исходных кодов:

§ требуется дополнительное время на сборку пакета, часто превышающее время на его настройку и наладку;

§ невозможность удалить пакет вместе с конфигурационными файлами;

§ невозможность обновить пакет вместе с конфигурационными файлами;

§ невозможность централизованного контроля за установленными приложениями.

При установке Nagios из предварительно собранного пакета, достоинства «сырого» метода установки становятся недостатками, и наоборот. Однако, как показала практика, собранный заранее пакет удовлетворяет всем требованиям, предъявляемым к системе и нет смысла тратить время на ручную сборку пакета [29, с. 35].

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

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

Требуемые пакеты.

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

· Apache 2

· PHP

· GCC компилятор и библиотеки разработчика

· GD библиотеки разработчика

Можно использовать утилиту apt-get (лучше aptitude) для их установки следующим образом:

% sudo apt-get install apache2

% sudo apt-get install libapache2-mod-php5

% sudo apt-get install build-essential

% sudo apt-get install libgd2-dev

1) Создание нового пользовательского непривилигированного аккаунта

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

Станем суперпользователем:

% sudo -s

Создадим новую учетную запись пользователя nagios и дадим ей пароль:

# /usr/sbin/useradd -m -s /bin/bash nagios

# passwd nagios

Создадим группу nagios и добавим в неё пользователя nagios:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

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

# /usr/sbin/groupadd nagcmd

# /usr/sbin/usermod -a -G nagcmd nagios

# /usr/sbin/usermod -a -G nagcmd www-data

2) Скачаем Nagios и плагины к нему

Создадим директорию для хранение скаченных файлов:

# mkdir ~/downloads

# cd ~/downloads

Качаем сжатые исходные коды Nagios и его плагинов (http://www.nagios.org/download):

# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.0.tar.gz

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz

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

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

# cd ~/downloads

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Запускаем конфигурационный скрипт Nagios, передав ему имя группы, которую мы создали ранее:

# ./configure --with-command-group=nagcmd

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

#./configure --help

`configure' configures this package to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as

VAR=VALUE. See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:

-h, --help display this help and exit

--help=short display options specific to this package

--help=recursive display the short help of all the included packages

-V, --version display version information and exit

-q, --quiet, --silent do not print `checking...' messages

--cache-file=FILE cache test results in FILE [disabled]

-C, --config-cache alias for `--cache-file=config.cache'

-n, --no-create do not create output files

--srcdir=DIR find the sources in DIR [configure dir or `..']

Installation directories:

--prefix=PREFIX install architecture-independent files in PREFIX[/usr/local/nagios]

--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX[PREFIX]

By default, `make install' will install all the files in `/usr/local/nagios/bin', `/usr/local/nagios/lib' etc. You can specify an installation prefix other than `/usr/local/nagios' using `--prefix', for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:

--bindir=DIR user executables [EPREFIX/bin]

--sbindir=DIR system admin executables [EPREFIX/sbin]

--libexecdir=DIR program executables [EPREFIX/libexec]

--datadir=DIR read-only architecture-independent data [PREFIX/share]

--sysconfdir=DIR read-only single-machine data [PREFIX/etc]

--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]

--localstatedir=DIR modifiable single-machine data [PREFIX/var]

--libdir=DIR object code libraries [EPREFIX/lib]

--includedir=DIR C header files [PREFIX/include]

--oldincludedir=DIR C header files for non-gcc [/usr/include]

--infodir=DIR info documentation [PREFIX/info]

--mandir=DIR man documentation [PREFIX/man]

System types:

--build=BUILD configure for building on BUILD [guessed]

--host=HOST cross-compile to build programs to run on HOST [BUILD]

Optional Features:

--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)

--enable-FEATURE[=ARG] include FEATURE [ARG=yes]

--disable-statusmap=disables compilation of statusmap CGI

--disable-statuswrl=disables compilation of statuswrl (VRML) CGI

--enable-DEBUG0 shows function entry and exit

--enable-DEBUG1 shows general info messages

--enable-DEBUG2 shows warning messages

--enable-DEBUG3 shows scheduled events (service and host checks... etc)

--enable-DEBUG4 shows service and host notifications

--enable-DEBUG5 shows SQL queries

--enable-DEBUGALL shows all debugging messages

--enable-nanosleep enables use of nanosleep (instead sleep) in event timing

--enable-event-broker enables integration of event broker routines

--enable-embedded-perl will enable embedded Perl interpreter

--enable-cygwin enables building under the CYGWIN environment

Optional Packages:

--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]

--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)

--with-nagios-user=<user> sets user name to run nagios

--with-nagios-group=<grp> sets group name to run nagios

--with-command-user=<user> sets user name for command access

--with-command-group=<grp> sets group name for command access

--with-mail=<path_to_mail> sets path to equivalent program to mail

--with-init-dir=<path> sets directory to place init script into

--with-lockfile=<path> sets path and file name for lock file

--with-gd-lib=DIR sets location of the gd library

--with-gd-inc=DIR sets location of the gd include files

--with-cgiurl=<local-url> sets URL for cgi programs (do not use a trailing slash)

--with-htmurl=<local-url> sets URL for public html

--with-perlcache turns on cacheing of internally compiled Perl scripts

Some influential environment variables:

CC C compiler command

CFLAGS C compiler flags

LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a

nonstandard directory <lib dir>

CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have

headers in a nonstandard directory <include dir>

CPP C preprocessor

Use these variables to override the choices made by `configure' or to help

it to find libraries and programs with nonstandard names/locations.

Компилируем исходный код Nagios.

# make all

Установим бинарные файлы, скрипт инициализации, примеры конфигурационных файлов и установим разрешения на директорию внешних команд:

# make install

# make install-init

# make install-config

# make install-commandmode

4) Изменим конфигурацию

Примеры конфигурационных файлов установлены в директорию /usr/local/nagios/etc. Они должны сразу быть рабочими. Нужно сделать лишь одно изменение перед тем, как продолжить.

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

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

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

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

# make install-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

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

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

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

% sudo aptitude install nagios

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

4.2 Конфигурирование ядра системы

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

4.2.1 Описание работы ядра системы

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

Рис. 4.1 - Ядро системы

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

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

Рис. 4.2 - Алгоритм оповещений Nagios

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

В директории /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 задаются новые хосты и сервисы.

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

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

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

Файл 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. Ниже представлена схема его работы

Рис. 4.3 - Схема мониторинга Windows хостов

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

Рис. 4.4 - Схема мониторинга *nix хостов

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

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

+-- 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. Исходные тексты плагинов, не входящих в комплект поставки и использованных в системе, представлены в Приложении И.

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

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

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

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

4.2.6 Настройка агента на удаленных хостах

Для получения возможностей расширенного мониторинга хостов и служб, необходимо установить на них агента Nagios, который называется nagios-nrpe-server:

# aptitude install nagios-nrpe-server

Конфигурация агента представлена в Приложении Л. Схема работы агента показана на Рисунке 4.5 выше.

4.4 Установка и настройка модуля отслеживания загрузки

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.

4.5 Установка и настройка модуля сбора системных журналов событий

В качестве модуля сбора системных журналов событий был выбран пакет syslog-ng.

syslog-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 - Разработка программного обеспечения, поэтому повторно описывать параметры и принципы конфигурирования системы в этой работе смысла нет, однако стоит более подробно остановиться на описании интерфейсов отдельных модулей системы.

5.1 Описание веб-интерфейса системы

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

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



Рис. 5.1 - Стартовая страница веб-интерфейса системы

Слева находится навигационная панель, справа результаты различного представления данных о состоянии сети, хостов и служб. Нас будет интересовать в первую очередь раздел Monitoring. Посмотрим на страницу Tactical Overview.

Рис. 5.2 - Стартовая страница веб-интерфейса системы

На этой странице располагается суммирующая информация по всем параметрам мониторинга и состоянию хостов и служб, при этом никаких подробностей не приводится, однако, если возникают какие-либо проблемы, то они выделяются особым цветом и становятся гиперссылкой, ведущей к подробному описанию возникшей проблемы. В нашем случае на текущий момент среди всех хостов и служб имеется одна неразрешенная проблема, перейдем по этой ссылке (1 Unhandled Problems).

Рис. 5.3 - Обнаруженная проблема службы

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

Перейдем по ссылке службы CPU Load.

Рис. 5.4 - Подробное описание состояния службы

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

Перейдем на страницу Service Detail.

Рис. 5.5 - Детальное представление всех служб

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

Перейдем по ссылке Host Detail.

Рис. 5.6 - Полный подробный список хостов

В данной таблице представлен полный подробный список хостов, их статусы, время последней проверки, продолжительность текущего статуса и дополнительная информация. В нашей системе принято, что статус хоста проверяется при помощи проверки доступности хоста по протоколу ICMP (8), то есть командой ping, однако в общем случае проверка можно быть какой угодно. Значки в колонке справа от имени хоста говорят о группе, к которой он принадлежит, сделано это для удобства восприятия информации. Значек светофора это ссылка, ведущая к подробному списку служб данного хоста, описывать эту таблицу отдельно не имеет смысла, она точно такая же, как и на рисунке 10.4, только информация представлена о единственном хосте.

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

Рис. 5.7 - Полная круговая карта сети

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

Рис. 5.8 - Карта сети - режим сбалансированного дерева

Рис. 5.9 - Карта сети - шарообразный режим

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

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

Step 1: Select Report Type: Service

Далее выбираем саму службу и переходим к следующему шагу.

Третьим шагом выбираем период подсчета и генерируем отчет.

Рис. 5.10 - Тренд

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

5.2 Описание веб-интерфейса модуля отслеживания загрузки интерфейсов

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

Рис. 5.11 - Стартовая страница модуля отслеживания загрузки интерфейсов

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



Рис. 5.12 - Индексная страница графиков модуля отслеживания загрузки интерфейсов

5.3 Описание модуля сбора системных журналов событий

В данный момент не требуется улучшенная фильтрация системных журналов и возможность поиска по ним через единый веб-интерфейс, т.к. проблемы, требующие просмотра этих журналов возникают достаточно редко. Поэтому разработка базы данных под эти журналы и веб-интерфейса отложена. В настоящее время доступ к ним осуществляется посредством ssh и просмотра директорий в файловом менеджере mc [26, с. 213].

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

/var/log

+-- apache2

+-- apt

+-- asterix

+-- bgp_router

+-- db

+-- dbconfig-common

+-- dr

+-- exim4

+-- fsck

+-- installer

¦ L-- cdebconf

+-- isp

+-- len58a_3lvl

+-- mail

+-- main

+-- monitoring

+-- mrtg

+-- mysql

+-- nagios3

¦ L-- archives

+-- news

+-- ocsinventory-client

+-- ocsinventory-server

+-- pppoe

+-- quagga

+-- router_krivous36b

+-- router_lenina58a

+-- router_su

+-- router_ur39a

+-- samba

+-- shaper

+-- ub13_router

+-- univer11_router

L-- voip

Каждый каталог является хранилищем журналов событий для каждого отдельного хоста.

Рис. 5.13 - Просмотр данных, собранных модулем сбора системных журналов событий

6. ТЕСТИРОВАНИЕ РАБОТЫ

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

1) Установка и наладка ядра на базе Nagios;

2) Наладка мониторинга удаленных хостов базовым функционалом Nagios;

3) Наладка модуля отслеживания загрузки сетевых интерфейсов посредством MRTG;

4) Расширение функционала ядра системы и интеграция её с модулем MRTG;

5) Наладка модуля сбора системных журналов;

6) Написание скрипта инициализации пакетного фильтра системы мониторинга в целях обеспечения безопасности системы.

7. Информационная безопасность

7.1 Характеристика рабочего места

К вредным факторам, влияющим на работу при использовании ПЭВМ относятся:

· повышенное значение напряжения электрического тока;

· шум;

· электромагнитное излучение;

· электростатическое поле.

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

7.2 Безопасность труда

7.2.1 Электробезопасность

Проектируемое программное средство создается в расчете на работу на имеющемся сервере, расположенном в специально оборудованном техническом помещении. Оно оборудовано кабельными коробами для прокладки кабелей. К каждому серверу подведено электропитание ~220В, частотой 50Гц, с рабочим заземлением. Перед вводом электропитания в помещение установлены автоматы, отключающие электропитание в случае короткого замыкания. Отдельно проведено защитное заземление.

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

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