Содержание ВступлениеС увеличением размера подконтрольных сетей перед каждым администратором встает вопрос о создании единой системы мониторинга серверов и сервисов. Внедрение такой системы позволит повысить производительность работы компании, уменьшить время простоя оборудования и повысить удовлетворенность руководства результатами вашей работы. Несмотря на свои неоспоримые достоинства, коммерческие системы вроде Solar Winds, 3COM Network Superviser и HP OpenView в данной статье рассматриватся не будут из-за своих довольно высоких цен и трудоемкости внедрения. В соответствии со стандартом e-tom задача сбора аварийных сообщений с элементов сетей, серверов и сервисов и диагностика первопричин называется Fault managemet. Для выполнения этой функции мы будем использовать инструмент по имени Nagios. В тоже время необходимо четко понимать что Nagios как и многие другие решения с открытым кодом не предназначен быть полноценной заменой коммерческим системам технологической поддержки OSS (Operations Support Systems) и значительно уступает им по функционалу во многих областях. Стоит отметить что кроме Nagios существует множество других бесплатных систем способных в той или иной степени выполнять озвученые задачи. Наиболее известными являются Big Brother, Angel Network Monitor, HiWayS, MARS, Autostatus, NocMonitor, RITW, Zabbix, NetXMS, OpenNMS и множество других. Давайте рассмотрим главные задачи системы мониторинга. Она должна оповещать администратора с помощью электронной почты, пейджера или sms сообщений, если с наблюдаемыми объектами случаются какие-либо неприятности. Также оповещения должны отсылаться, когда состояние объекта возвращается в норму. Вдобавок ко всем способам, перечисленным выше, Nagios позволяет использовать в качестве инструмента оповещения программы, разработанные пользователями. К примеру таким образом можно реализовать механизм оповещения через SMS. Перед тем, как мы станем более подробно обсуждать возможности Nagios, Вам стоит посмотреть на демонстрационную систему, которую Tom Welsh установил специально для этих нужд. Быстренько идем на сайт http://nagios.square-box.com/. Для авторизации используем имя пользователя guest и пароль guest. Набродившись по разным меню и полюбовавшись на все красоты web-интерфейса давайте поговорим о достоинствах Nagios. На основе увиденного мы можем сделать вывод: Nagios позволяет производить мониторинг таких сетевых сервисов как SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и многих других. Еще можно следить за использованием ресурсов серверов, таких как расход дискового пространства, свободная память и загруженность процессора. Существует возможность создавать свои собственные обработчики событий. Эти обработчики будут выполняться при возникновении тех или иных событий, инициированных проверками сервисов или серверов. Такой подход позволит активно реагировать на происходящие события и пытаться автоматически решать возникшие проблемы. К примеру, можно создать обработчик событий, который будет самостоятельно перезапускать повисший сервис. Еще одним достоинством системы мониторинга Nagios является возможность управлять ею удаленно с помощью wap интерфейса мобильного телефона. Используя концепцию "родительских" хостов, легко описать иерархию и зависимости между всеми хостами. Такой подход чрезвычайно полезен для больших сетей, потому что позволяет производить сложную диагностику. А это качество, в свою очередь, помогает отличить не работающие хосты, от тех, что недоступны в данный момент из-за неполадок в работе промежуточных звеньев. Nagios умеет строить графики работы наблюдаемых систем и карты контролируемой сетевой инфраструктуры. Из своей практики работы с Nagios приведу пример, показывающий, насколько полезен он оказался для меня. На внешнем сетевом интерфейсе нашего брандмауэра с периодичность в несколько часов начиналась потеря пакетов. Из-за неисправности терялось до 20 процентов проходящего трафика. По истечении минуты - другой интерфейс снова начинал работать как положено. По причине плавающего характера этой неполадки несколько недель я не мог понять, почему при работе с Интернет периодически происходят кратковременные сбои. Без Nagios поиск неисправности затянулся бы надолго. Многим из администраторов хорошо знаком предок Nagios по имени NetSaint. Несмотря на то, что сайт проекта NetSaint все еще исправно функционирует, новые разработки базируются уже на исходном коде Nagios. Поэтому всем рекомендуется потихоньку перебираться на Nagios. Изначально проект Nagios разрабатывался для Linux, но наша система мониторинга будет работать на основе FreeBSD 4.5. В документации, поставляемой с Nagios, говорится, что он будет стабильно работать и со многими другими Unix подобными системами. Для отображения web-интерфейса Nagios нам понадобится сервер Apache. Вы вольны, использовать любой другой, но в данной статье будет рассматриваться именно Apache, как наиболее распространенный на Unix платформах web-сервер. Можно установить систему мониторинга вообще без web-интерфейса, но мы так делать не станем, потому что это существенно уменьшает удобство пользования. Для создания графиков нам понадобится библиотека GD Graphics, которую написал Thomas Boutel. Она необходима для создания изображений в формате PNG, JPEG и WBMP. Последний чаще всего используется клиентами беспроводных устройств. Подавляющее большинство браузеров пока не умеет работать с WBMP, поэтому для нас он интереса не представляет. До перехода на версию 2.0.6 была возможность работать с форматом GIF, но от нее пришлось отказаться из-за проблем с патентным законодательством. Для сжатия информации внутри изображений GIF используется алгоритм LZW. Эксклюзивными правами на него обладает Unisys. В связи с вышеуказанными проблемами, сетевому сообществу рекомендуется использовать свободные от подобных неудобств форматы PNG и JPEG. В свою очередь, библиотека GD опирается на библиотеки zlib, LibPng и jpeg. У нас есть три пути, следуя которыми мы можем установить все необходимые библиотеки. В статье они будут подробно описаны по очереди. Я люблю все собирать и устанавливать вручную, потому, как подобный подход дает более полное понимание происходящих процессов и возможность использовать самое свежее программное обеспечение. Итак, начнем нашу эпопею со способа красноречиво называемого в народе "закат солнца вручную". Установка компонентовПервый ингредиент - библиотека zlib, написанная двумя программистами- Jean-loup Gailly и Mark Adler. Она проектировалась как API общего назначения для сжатия данных без потерь. Как ни странно, но в нашем проекте она будет использоваться по своему прямому назначению, то есть для сжатия изображений. Берем новейшую версию http://www.gzip.org/zlib. На момент написания это была весрия 1.1.4. Распаковываем и компилируем. # tar zvxf zlib-1.1.4.tar.gz # cd zlib-1.1.4 # ./configure # make test # make install Как Вы могли бы предположить, LibPng служит для создания изображений в формате PNG. Я использовал версию 1.2.5. Взять ее можно тут: http://www.graphicswiz.com/png/libpng.html. Собирается LibPng довольно-таки странным и нестандартным путем. # tar zxvf libpng-1.2.5.tar.gz # cd libpng-1.2.5 Ориентируясь на тип операционной системы, из директории scripts выбираем нужный нам makefile и копируем его в коневую директорию с исходными файлами. Для нашего случая исходный файл называется makefile.freebsd. # cp ./scripts/makefile.freebsd Makefile Затем создаем директорию zlib и кладем в нее из дистрибутива zlib все файлы с расширением *.h # mkdir zlib Вот теперь можно проводить компилляцию. Что мы с радость выполняем. # make all # make test В результате на экране вы должны увидеть что-то вроде этого: Testing pngtest.png: Pass 0: rwrwrwrwrwrwrwrwrw Pass 1: rwrwrwrwrwrwrwrwrw Pass 2: rwrwrwrwrwrwrwrw Pass 3: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw Pass 4: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw Pass 5: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw Pass 6: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw PASS (9782 zero samples) Filter 0 was used 21 times Filter 1 was used 15 times Filter 2 was used 52 times Filter 3 was used 10 times Filter 4 was used 33 times tIME = 7 Jun 1996 17:58:08 +0000 Current memory allocation: 0 bytes Maximum memory allocation: 337346 bytes Total memory allocation: 1023516 bytes Number of allocations: 198 libpng passes test Создаем директорию /usr/local/include/libpng/ # mkdir /usr/local/include/libpng И наконец пришло время инсталляции. Тут уж все должно пройти легко и просто. # make install Теперь берем по адресу http://www.ijg.org/files/ библиотеку jpeg версии 6b. Я надеюсь, самые догадливые читатели уже поняли, что она понадобится нам для создания изображений в формате jpeg. Поверив моим заявлениям о том, что процедура установки довольно проста, начнем ее выполнение. # tar zxvf jpegsrcv6b.tar.gz # cd jpeg-6b # ./configure # make После тестовой сборки должны увидеть такую картину: # make test rm -f testout* ./djpeg -dct int -ppm -outfile testout.ppm ./testorig.jpg ./djpeg -dct int -bmp -colors 256 -outfile testout.bmp ./testorig.jpg ./cjpeg -dct int -outfile testout.jpg ./testimg.ppm ./djpeg -dct int -ppm -outfile testoutp.ppm ./testprog.jpg ./cjpeg -dct int -progressive -opt -outfile testoutp.jpg ./testimg.ppm ./jpegtran -outfile testoutt.jpg ./testprog.jpg cmp ./testimg.ppm testout.ppm cmp ./testimg.bmp testout.bmp cmp ./testimg.jpg testout.jpg cmp ./testimg.ppm testoutp.ppm cmp ./testimgp.jpg testoutp.jpg cmp ./testorig.jpg testoutt.jpg Следующей командой устанавливаем библиотеку jpeg. # make install Наконец, после всех этих мытарств можно заняться инсталляцией библиотеки GD. Скачиваем исходные тексты с сайта проекта http://www.boutell.com/gd/. Как всегда, распаковываем и конфигурируем дистрибутив. # tar zxvf gd-2.0.6.tar.gz # cd gd-2.0.6 # ./configure --x-includes=/usr/local/include --x-libraries=/usr/local/lib Ключи --x-includes и --x-libraries указывают скрипту конфигурации, где у нас находятся заголовочные и библиотечные файлы всех установленных ранее библиотек. # make all Если компиляция завершилась с ошибками, то нам необходимо удалить временные файлы, созданные в процессе работы команды make. # make devclean Для версий библиотеки GD выше 2.0.11 нужно делать вот так. # make distclean После выполнения чистки нужно принять меры к устранению причин возникновения ошибок. При необходимости подправьте ключи команды configure, а затем проведите повторную компиляцию. И если предыдущие шаги завершились нормально, запускаем инсталляцию. # make install Теперь давайте обсудим второй способ установки. При наличии устойчивого соединения с Интернетом можно попытаться установить библиотеки GD, zlib, LibPng и jpeg с помощью механизма портов. Мы запустим установку GD, а она, в свою очередь, автоматически выполнит скачивание, компиляцию и установку всех необходимых библиотек на основе зависимостей между ними. # cd /usr/ports/graphics/gd # make install Третий способ установки не требует подключения к сети Интернет. Скорее всего, он является самым простым и, видимо, лучше всего подходит для начинающих администраторов. Как и во втором способе, все необходимое будет автоматически установлено из пакетов, поставлявшихся вместе с операционной системой FreeBSD. По аналогии со вторым способом за удобство придется заплатить свежестью устанавливаемого программного обеспечения. В CD привод кладем компакт диск с пакетами и запускаем программу sysinstall. # /stand/sysinstall А затем, последовательно пройдя через все перечисленные ниже меню, выполняем инсталляцию. Configure->Packages->CD/DVD->graphics->gd-1.8.4_3->ok->install->ok Аналогичного эффекта можно добиться, используя команду pkg_add. Посмотрим, куда у нас все это установилось. Файлы библиотек лежат в /usr/local/lib, а заголовочные файлы в /usr/local/include/gd. Не стоит огорчаться, если, несмотря на все попытки, библиотеку не удалось установить ни одним из трех способов. Хотя я с трудом представляю, как такое возможно. Отложите установку до лучших времен. Наличие вышеназванных библиотек необходимо только для правильной работы модулей построения графиков и генерирования сетевой карты. Nagios работает стабильно и остается очень полезным инструментом даже без этих модулей. Пришло время детально разобраться с архитектурой системы мониторинга. Обычно комплекс на основе Nagios состоит из двух частей - главной программы, в документации чаше всего называемой core program, и подключаемых модулей соответственно plugins. Модульный дизайн позволяет отделить логику основной программы от процесса выполнения проверок. Это в свою очередь дает возможность всем желающим без особых усилий расширять область применения Nagios через написание собственных подключаемых модулей. Скачиваем последнюю версию главной программы и подключаемых модулей с официального сайта проекта http://www.nagios.org/download/. На момент написания статьи были доступны версии nagios-1.0b6 и nagiosplug-1.3-beta1. Засучив рукава, приступим к установке главной программы. # tar zxvf nagios-1.0b6.tar.gz # cd nagios-1.0b6 Теперь нужно решить, в какой каталог мы хотим инсталлировать Nagios. По умолчанию предполагается каталог /usr/local/nagios/. Думаю, нам тоже стоит придерживаться его, потому что в прилагающейся к дистрибутиву документации указан именно этот каталог. При последующем устранении ошибок или проблем с конфигурированием будет гораздо проще читать документацию. Создаем каталог, куда мы впоследствии будем проводить инсталляцию. Не совсем понятно, почему ее должен создавать администратор, а не программа инсталляции. Надеюсь, в следующих версиях этот недочет будет исправлен. # mkdir /usr/local/nagios С помощью скрипта adduser либо каким-нибудь другим способом создаем пользователя nagios, состоящего в группе nagios. # adduser nagios # ./configure --prefix=/usr/local/nagios --with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/ \ --with-nagios-user=nagios --with-nagios-grp=nagios --with-gd-lib=/usr/local/lib \ --with-gd-inc=/usr/local/include/gd Давайте быстренько разберемся с назначением используемых при конфигурировании ключей. --prefix=/usr/local/nagios - Сюда мы будем устанавливать файлы после компиляции. Вот и пригодилась созданная вручную директория /usr/local/nagios. --with-cgi-url=/nagios/cgi-bin - URL с помощью которого мы будем обращаться к CGI скриптам web-интерфейса nagios. В конце URL символ "/" добавлять не нужно. В качестве примера для вымышленного сайта somesite.ru можно привести абсолютный URL одного из CGI скриптов httt://somesite.ru/nagios/cgi-bin/statusmap.cgi. --with-html-url=/nagios/ - URL где будут находиться html файлы, в которых хранятся главное меню web-интерфейса и документация. --with-nagios-user=nagios - пользователь, которому будут принадлежать файлы инсталляции. --with-nagios-grp=nagios - соответственно группа этого пользователя. --with-gd-lib=/usr/local/lib - тут у нас лежит библиотека GD --with-gd-inc=/usr/local/include/gd - а здесь находятся ее заголовочные файлы. Осмыслив все прочитанное и разобравшись с опциями команды configure, проводим сборку и инсталляцию. # make all # make install Следующий шаг является необязательным, но желательно его все же выполнить. С помощью команды make install-init можно создать скрипт, который будет выполнять запуск Nagios после перезагрузки системы. Вдобавок к этому у нас появится возможность управлять работой процесса Nagios с помощью команд stop, reload, start, restart, reload, force-reload. Давайте подробнее рассмотрим каждую из этих команд.
Для FreeBSD файл скрипта должен располагаться в директории /usr/local/etc/rc.d и называться nagios.sh. В зависимости от типа операционной системы, инсталлятор должен сам выбрать подходящие права доступа, местоположение и имя скрипта. Например, для систем на основе Slackware должны получить соответственно /etc/rc.d/init.d и rc.nagios. Ну что же давайте, попытаемся выполнить установку скрипта. # make install-init Получаем следующие ошибки: /usr/bin/install -c -m 755 -d -o root -g root /usr/local/etc/rc.d install: unknown group root *** Error code 67 Stop in /tmp/nagios-1.0b6. Жаль, но установка с наскоку не удалась. Ну и ладно, вот исправим ошибки программистов, писавших скрипт, и все заработает как надо. С помощью любимого текстового редактора начинаем редактировать файл Makefile. Идем на строку 32 и ищем символы INIT_OPTS=-o root -g root Обдумав увиденную строку, понимаем, что под FreeBSD пользователь root входит в группу wheel. Вносим изменения. INIT_OPTS=-o root -g wheel Переходим на строку 154 $(INSTALL) -m 774 $(INIT_OPTS) daemon-init $(DESTDIR)$(INIT_DIR)/nagios Правильно задаем имя файла nagios.sh вместо nagios. Не стоит давать общий доступ на чтение для файла скрипта. Вполне хватит режима доступа 100. Измененная строка будет выглядеть так: $(INSTALL) -m 100 $(INIT_OPTS) daemon-init $(DESTDIR)$(INIT_DIR)/nagios.sh Сохраняем файл и снова выполняем команду инсталляции. # make install-init Итак, скрипт автозапуска создан, но он все еще не готов к работе. Все дело в том, что при перезагрузке файл nagios.sh будет выполнен без единого параметра командной строки, а для безукоризненной работы нужно запускать его с параметром start. Сейчас мы это исправим. Открываем файл для редактирования и выполняем поиск строки:
echo "Usage: nagios {start|stop|restart|reload|force-reload|status}"
Затем сразу после нее вставляем вот это: /usr/local/etc/rc.d/nagios.sh start Внесенными изменениями мы заставляем nagios.sh, запущенный без обязательных параметров, рекурсивно выполнить самого себя с параметром start. Для FreeBSD версии 4.6.2 и выше данные ухищрения уже не нужны скрипт должен работать с установками по умолчанию. Еще одна ошибка - это путь к файлу, в котором будут храниться внешние команды, переданные на выполнение процессу Nagios. После инсталляции подразумевается, что файл должен располагаться в /usr/local/nagios/var/rw/nagios.cmd. Но, к сожалению, директория /usr/local/nagios/var/rw/ автоматически не создается. К тому же, не совсем понятен смысл создания отдельной директории для единственного файла nagios.cmd. Чтобы исправить вышеуказанную ошибку, ищем строку
NagiosCmd=${prefix}/var/rw/nagios.cmd
и заменяем ее на такую:
NagiosCmd=${prefix}/var/nagios.cmd
Теперь файл nagios.cmd будет создаваться в директории /usr/local/nagios/var/. К сожалению, это не последняя проблема, связанная с файлом nagios.cmd. При каждом перезапуске процесса Nagios файл внешних команд сначала удаляется, а затем создается вновь. Беда в том, что создается nagios.cmd с правами процесса. Соответственно, он принадлежит пользователю nagios и группе nagios. На первый взгляд, здесь нет никакой проблемы. Поразмышляв некоторое время, мы понимаем, что главным поставщиком внешних команд для процесса Nagios будет web-интерфейс. Сервер Apache обычно запускается с правами пользователя nobody группы nogroup. А это значит, что процесс web-сервера не сможет вносить новые данные в файл nagios.cmd. Самым простым решением было бы дать доступ на запись всем, но с точки зрения безопасности такое решение выглядит довольно неприглядно. Вторым способом разрешения конфликта могло бы стать введение пользователя nobody в группу nagios. Но с безопасностью опять возникают неувязки. Самым лучшим выходом из этой ситуации является частичная передача прав на файл пользователю nobody. В результате такой операции файлом должен владеть пользователь nobody и группа nagios. Таким образом, доступ к файлу получат и процесс nagios, и web-сервер. Ищем в файле nagios.sh вот такие строки sleep 1 status_nagios nagios и добавляем сразу за ними команды touch $NagiosCmd chown nobody $NagiosCmd Покончив с файлом nagios.sh, можно быть уверенным, что уж теперь - то он будет работать, как положено. С помощью команды make install-config создаем файлы конфигурации, заполняем их значениями по умолчанию и помещаем в директорию /usr/local/nagios/etc/. # make install-config Заглянув в директорию /usr/local/nagios/, мы видим, что после инсталляции внутри нее образовалось еще 5 директорий. # ls /usr/local/nagios bin etc sbin share var Опишем, для чего нужна каждая из этих директорий.
Можете себя поздравить с окончанием установки главной программы Nagios. Можно было сделать все то же самое с помощью портов или пакетов. К сожалению, на такой способ установки времени у меня не хватило. Поэтому сказать об удобстве или подводных камнях такого пути ничего не могу. Есть подозрение, что возможно возникновение проблем с конфигурированием, да и свежесть установленного программного обеспечения будет весьма сомнительна. Еще одной причиной не использовать порты стало желание заняться русификацией системы. Подробнее о результатах этого эксперимента будет рассказано в следующей статье. Несмотря на то, что инсталляция главной программы закончена, толку нам от этого пока никакого. Без установленных модулей Nagios совершенно бесполезен, так как не имеет возможности взаимодействовать с объектами, за которыми нужно наблюдать. Настало время приняться за инсталляцию этих самых модулей. С помощью make, поставляющегося вместе с операционной системой, собрать их не удалось. Посему для компиляции будем пользоваться gmake. # tar zxvf nagiosplug-1.3-beta1.tar.gz # cd nagiosplug-1.3-beta1 # ./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-grp=nagios Значение ключей конфигурации аналогично тем, что мы использовали при компиляции главной программы. Почитать детальные объяснения о назначении каждого ключа можно с помощью команды ./configure help. # gmake all # gmake install После компиляции подключаемые модули устанавливаются в директорию /usr/local/nagios/libexec. Некоторые из них написаны на С, другие на perl. В принципе, модуль может быть написан на любом языке. Каждый модуль является выполняемым файлом. Это дает возможность использовать модули не только в комплексе с Nagios, но и с другими программами. Можно выполнять проверки даже из командной строки. Каждый модуль должен поддерживать опцию help или -h, иначе он не может считаться совместимым с Nagios. Такие жесткие требования позволяют легко разобраться с любым модулем. Давайте посмотрим, какие параметры командной строки должен получать модуль check_dns. # check_dns -h check_dns (nagios-plugins 1.3.0-alpha1) 1.1.1.1 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. Copyright (c) 1999 Ethan Galstad (nagios@nagios.org) Usage: check_dns -H host [-s server] [-t timeout] check_dns --help check_dns --version -H, --hostname=HOST The name or address you want to query -s, --server=HOST Optional DNS server you want to use for the lookup -t, --timeout=INTEGER Seconds before connection times out (default: 10) -h, --help Print detailed help -V, --version Print version numbers and license information This plugin uses the nslookup program to obtain the IP address for the given host/domain query. A optional DNS server to use may be specified. If no DNS server is specified, the default server(s) specified in /etc/resolv.conf will be used. Прочитав и обдумав вывод предыдущей команды, можно понять, что модуль check_dns принимает один обязательный параметр H и два необязательных параметра -s, -t. Итак, по порядку H имя или адрес проверяемого хоста. В параметре -s определяется адрес сервера DNS, используемого для перевода имени в адрес, если в первом параметре вместо адреса передано имя хоста. Затем -t устанавливает таймаут, по истечении которого служба считается нефункционирующей. Для проверки сервиса DNS машины с адресом 192.168.10.254 нужно выполнить следующую команду. # check_dns -H 192.168.10.254 DNS ok - 0 seconds response time, Address(es) is/are 192.168.10.254 Интуиция странным образом подсказывает мне, что DNS работает нормально. Закончив установку и разобравшись с механизмом работы подключаемых модулей, прейдем к настройке Nagios. Настройка NagiosДавайте осмотрим содержимое директории конфигурационных файлов. # cd /usr/local/nagios/etc # ll total 92 -rw-rw-r-- 1 nagios nagios 17028 Nov 11 15:41 cgi.cfg-sample -rw-rw-r-- 1 nagios nagios 4480 Nov 11 15:41 checkcommands.cfg-sample -rw-rw-r-- 1 nagios nagios 1577 Nov 11 15:41 contactgroups.cfg-sample -rw-rw-r-- 1 nagios nagios 1485 Nov 11 15:41 contacts.cfg-sample -rw-rw-r-- 1 nagios nagios 1651 Nov 11 15:41 dependencies.cfg-sample -rw-rw-r-- 1 nagios nagios 2022 Nov 11 15:41 escalations.cfg-sample -rw-rw-r-- 1 nagios nagios 1658 Nov 11 15:41 hostgroups.cfg-sample -rw-rw-r-- 1 nagios nagios 5774 Nov 11 15:41 hosts.cfg-sample -rw-rw-r-- 1 nagios nagios 4277 Nov 11 15:41 misccommands.cfg-sample -rw-rw-r-- 1 nagios nagios 21332 Nov 11 15:41 nagios.cfg-sample -rw-rw---- 1 nagios nagios 3074 Nov 11 15:41 resource.cfg-sample -rw-rw-r-- 1 nagios nagios 17668 Nov 11 15:41 services.cfg-sample -rw-rw-r-- 1 nagios nagios 1594 Nov 11 15:41 timeperiods.cfg-sample В названии каждого файла есть фрагмент -sample, значит, все вышеперечисленные файлы являются не полноценными конфигурациями, а всего лишь примерами. На случай, если нам вдруг захочется посмотреть, что там у них внутри, скопируем их в директорию sample. Может быть, когда-то они нам еще пригодятся. # mkdir sample # cp * ./sample Переименовываем все файлы, отсекая цепочку символов -sample. Таким образом, мы готовим файлы к тому, чтобы Nagios смог их заметить и правильно воспринять. В результате должно получиться что-то вроде: # ll total 94 -rw-rw-r-- 1 nagios nagios 17028 Nov 11 16:13 cgi.cfg -rw-rw-r-- 1 nagios nagios 4480 Nov 11 16:13 checkcommands.cfg -rw-rw-r-- 1 nagios nagios 1577 Nov 11 16:13 contactgroups.cfg -rw-rw-r-- 1 nagios nagios 1485 Nov 11 16:13 contacts.cfg -rw-rw-r-- 1 nagios nagios 1651 Nov 11 16:13 dependencies.cfg -rw-rw-r-- 1 nagios nagios 2022 Nov 11 16:13 escalations.cfg -rw-rw-r-- 1 nagios nagios 1658 Nov 11 16:13 hostgroups.cfg -rw-rw-r-- 1 nagios nagios 5774 Nov 11 16:13 hosts.cfg -rw-rw-r-- 1 nagios nagios 4277 Nov 11 16:13 misccommands.cfg -rw-rw-r-- 1 nagios nagios 21332 Nov 11 16:13 nagios.cfg -rw-rw---- 1 nagios nagios 3074 Nov 11 16:13 resource.cfg drwxr-xr-x 2 root nagios 512 Nov 11 16:07 sample -rw-rw-r-- 1 nagios nagios 17668 Nov 11 16:13 services.cfg -rw-rw-r-- 1 nagios nagios 1594 Nov 11 16:13 timeperiods.cfg К сожалению, файлы все еще не готовы к употреблению. Nagios даже не сможет стартовать, если мы попытаемся его запустить. Разобраться в содержимом файлов примеров, созданных во время инсталляции, довольно сложно. Самым лучшим выходом из подобной ситуации будет уничтожение всех конфигурационных данных и создание их вручную под моим чутким руководством. Такой подход принесет более глубокое понимание используемой методики настройки. Обнуляем все необходимые файлы. # cp /dev/null hosts.cfg services.cfg contacts.cfg contactgroups.cfg hostgroups.cfg # cp /dev/null dependencies.cfg escalations.cfg Начиная с версии 1.0b2, в Nagios появилась возможность использовать шаблоны внутри конфигурационных файлов. Такая методика настройки позволяет многократно снизить время создания рабочей конфигурации. Перед нами стоит задача описать два хоста mail.firma.ru и proxy.firma.ru. Каждый сервер, находящийся под наблюдением, должен быть описан в файле хостов. Поэтому первым делом заполняем именно этот файл. Содержимое файла hosts.cfg
# Описываем шаблон хоста
define host{
name generic-host
# Имя шаблона - будем ссылаться на него позже при описании каждого хоста
notifications_enabled 1
# Включаем уведомления
event_handler_enabled 1
# Включаем обработчик событий
flap_detection_enabled 1
# Включаем обнаружение мерцания
process_perf_data 1
# Собирать статистику об эффективности работы процесса
retain_status_information 1
# Сохранять статусную информацию между перезагрузками программы
retain_nonstatus_information 1
# Сохранять нестатусную информацию между перезагрузками программы
register 0
# Указываем, что все вышеописанное - это шаблон. Запрещаем регистрировать
# это описание как хост
}
# Описываем хост по имени mail
define host{
use generic-host
# Ссылка на используемый шаблон
host_name mail
# Имя хоста
alias Mail Server
# Псевдоним хоста
address mail.firma.ru
# Имя хоста в формате fqdn или его адрес
check_command check-host-alive
# Команда проверки хоста выполняется обычно с помощью ping. Подробнее можно
# почитать в файле checkcommands.cfg
max_check_attempts 10
# Количество попыток повторного тестирования после того, как одна из попыток
# возвратила ошибочный статус.
notification_interval 120
# Интервал в минутах, по прошествию которого нужно повторно отсылать
# уведомление, если сервер все еще не работает.
notification_period 24x7
# Период времени, в течение которого серверу разрешено беспокоить администратора
# своими уведомлениями. В данном случае это круглые сутки. Подробнее о периодах
# можно почитать в файле timeperiods.cfg.
notification_options d,u,r
# Список событий, при наступлении которых необходимо отсылать
# уведомления. Соответственно d,u,r (DOWN, UNREACHABLE, RECOVERY)
# означает события "работает", "недоступен", "восстановлен".
}
# Описываем хост по имени proxy
define host{
use generic-host
host_name proxy
# Имя хоста. Также стоит обратить внимание на изменившиеся записи alias и address.
alias Proxy Server
address proxy.firma.ru
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24x7
notification_options d,u,r
}
Каждый хост должен состоять хотя бы в одной группе хостов. Опираясь на группы хостов, Nagios сможет определить, какую из групп администраторов нужно оповещать. Данные, полностью описывающие группы хостов, находятся в файле hostgroups.cfg. Формат этого файла настолько прост, что механизм шаблонов применять смысла нет. Посмотрим, чем заполнен этот файл. Содержимое файла hostgroups.cfg
define hostgroup{
hostgroup_name firma-servers
# Имя группы
alias Firma Servers
# Псевдоним группы
contact_groups firma-admins
# Список групп контактов, которые нужно уведомлять
members mail proxy
# Список серверов, принадлежащих к группе
}
Пришло время вплотную заняться описанием сервисов, за которыми нужно наблюдать. Как и во всех остальных конфигурационных файлах, первым делом необходимо создать шаблон сервиса. Мы разберем его подробно. Затем, второй и третьей записью, будут описаны сервисы HTTP и PING, базирующиеся на хосте proxy.firma.ru. Соответственно, далее мы работаем с mail.firma.ru, на котором у нас базируются SMTP и IMAP. Содержимое файла services.cfg
# Описываем шаблон сервиса
define service{
name generic-service
# Имя шаблона
active_checks_enabled 1
# Включить активные проверки
passive_checks_enabled 1
# Принимать результаты пассивных проверок
parallelize_check 1
# Активные проверки лучше выполнять паралельно,
# такой подход повышает скорость работы
obsess_over_service 0
# Эту опцию стоит включать только при создании распределенной
# системы мониторинга.
check_freshness 0
# Следить за свежестью результатов проверок. По умолчанию отключено
notifications_enabled 1
# Уведомления включены
event_handler_enabled 1
# Включить обработчики событий
flap_detection_enabled 1
# Использовать обнаружение мерцания
process_perf_data 1
# Собирать данне об эффективности выполнения проверок
retain_status_information 1
# Сохранять информацию о статусе между перезапусками Nagios
retain_nonstatus_information 1
# Сохранять нестатусную информацию между перезапусками Nagios
register 0
# Запрещаем регистрировать это описание как сервис
}
# Описываем сервис HTTP для хоста proxy.firma.ru
define service{
use generic-service
# Имя используемого шаблона
hostname proxy.firma.ru
# Имя хоста
service_description HTTP
# Описание сервиса
is_volatile 0
# Для стандартных сервисов лучше оставить значение 0
# К нестандартным сервисам стоит относить те сервисы, которые
# после каждой проверки автоматически возвращаются в состояние "ОК"
# вне зависимости от режима, в котором они находились до проверки.
check_period 24x7
# Период, в течение которого можно выполнять проверки
max_check_attemps 3
# Максимальное количество повторных проверок
normal_check_interval 5
# Интервал между нормальными проверками
retry_check_interval 1
# Интервал между повторными проверками. Применяется, если
# нормальная проверка завершилась неудачно
contact_groups firma-admins
# Группа контактов, используемая для оповещения
notification_interval 120
# Интервал (в минутах), после которого нужно послать повторное уведомление,
# если сервис так и не восстановился
notification_period 24x7
# Период, в течение которого можно производить отправку уведомлений
notification_options w,u,c,r
# Список событий, при наступлении которых необходимо
# отсылать уведомления.
check_command check_http
# Имя команды, выполняемой для проверки сервиса
}
# Описываем сервис PING для хоста proxy.firma.ru
define service{
use generic-service
# Имя используемого шаблона
hostname proxy.firma.ru
# Имя хоста
service_description PING
# Описание сервиса
is_volatile 0
check_period 24x7
# Период, в течение которого можно выполнять проверки
max_check_attempts 3
# Максимальное количество повторных проверок
normal_check_interval 5
# Интервал между нормальными проверками
retry_check_interval 1
# Интервал между повторными проверками. Применяется, если
# нормальная проверка завершилась неудачно
contact_groups firma-admins
# Группа контактов, используемая для оповещения
notification_interval 120
# Интервал (в минутах), после которого нужно послать повторное уведомление,
# если сервис так и не восстановился
notification_period 24x7
# Период, в течение которого можно производить отправку уведомлений
notification_options w,u,c,r
# Список событий, при наступлении которых необходимо
# отсылать уведомления.
check_command check_ping
# Имя команды, выполняемой для проверки сервиса
}
# Описываем сервис SMTP для хоста mail.firma.ru
define service{
use generic-service
hostname mail.firma.ru
service_description SMTP
# Описание сервиса
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups firma-admins
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_smtp
# Имя команды, выполняемой для проверки сервиса
}
# Описываем сервис IMAP для хоста mail.firma.ru
define service{
use generic-service
hostname mail.firma.ru
service_description IMAP
# Описание сервиса
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups firma-admins
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_imap
# Имя команды, выполняемой для проверки сервиса
}
Как Вы, возможно, сумели догадаться, имена команд, вызываемых для выполнения проверки того или иного сервиса, определяются параметром check_command. Сами же команды описываются в файле checkcommands.cfg. По странному стечению обстоятельств команда check_imap в этом файле не описана, несмотря на то, что среди модулей, установленных в директорию /usr/local/nagios/libexec/, файл check_imap присутствует. Видимо, это еще одна ошибка программистов Nagios. Ну и ладно, нам не привыкать делать все собственными руками. Разместим в любом месте файла checkcommands.cfg следующие строки:
# 'check_imap' command definition
define command{
command_name check_imap
command_line $USER1$/check_imap -H $HOSTADDRESS$
}
Стоит отметить что имена хостов в файлах hosts.cfg и services.cfg должны быть идентичны. Мне казалось что это достаточно логично, но некоторые читатели почему то испытывают трудности с осознанием этого файкта. Создав описание сервисов, самое время перейти к определению списка людей, которым система будет отсылать оповещения. В терминологии Nagios каждая запись в файле contacts.cfg описывающая человека - это контакт. Формат записи довольно прост, поэтому и в данном случае шаблоны нам не пригодятся. Содержимое файла contacts.cfg
define contact{
contact_name tigrisha
# Имя контакта
alias Andrei Beshkov
# Имя человека
service_notification_period 24x7
# Период времени, в течение которого разрешено посылать уведомления
# о состоянии сервисов
host_notification_period 24x7
# Период времени, в течение которого разрешено посылать уведомления
# о состоянии хостов
service_notification_options w,u,c,r
# Список событий сервисов, при наступлении которых необходимо
# отсылать уведомления.
host_notification_options d,u,r
# Список событий хостов, при наступлении которых необходимо
# отсылать уведомления.
service_notification_commands notify-by-email, notify-by-epager
# Команды рассылки уведомлений о событиях сервиса
host_notification_commands host-notify-by-email, host-notify-by-epager
# Команды рассылки уведомлений о событиях хоста
email admin@firma.ru
# Почтовый адрес
pager 143652565@pager.icq
# Адрес системы пейджинга
}
define contact{
contact_name amon
# Имя контакта
alias Dmitry Larin
# Имя человека
service_notification_period 24x7
# Период времени, в течение которого разрешено посылать уведомления о состоянии сервисов
host_notification_period 24x7
# Период времени, в течение которого разрешено посылать уведомления о состоянии хостов
service_notification_options w,u,c,r
# Список событий сервисов, при наступлении которых необходимо
# отсылать уведомления.
host_notification_options d,u,r
# Список событий хостов, при наступлении которых необходимо
# отсылать уведомления.
service_notification_commands notify-by-email, notify-by-epager
# Команды рассылки уведомлений о событиях сервиса
host_notification_commands host-notify-by-email, host-notify-by-epager
# Команды рассылки уведомлений о событиях хоста
email amon@firma.ru
# Почтовый адрес
pager 177345865@pager.icq
# Адрес системы пейджинга
}
Каждый контакт должен принадлежать как минимум одной контактной группе. Давайте создадим такую группу для контактов, описанных выше. Содержимое файла contactgroups.cfg
define contactgroup{
contactgroup_name firma-admins
# Имя контактной группы
alias firma.ru Admins
# Псевдоним группы
members tigrisha amon
# Список контактов состоящих в группе
}
Файл dependencies.cfg отвечает за зависимости между хостами. Ну а файл escalations.cfg, в свою очередь, описывает эскалацию оповещений. В связи с тем, что рассматриваемый нами пример состоит всего из двух хостов, файлы зависимостей и эскалации нам не пригодятся. Отсюда вытекает приятный факт, говорящий, что необходимости заполнять их у нас нет. Возможно, в следующей статье я подробно опишу работу с файлами зависимостей и эскалации. Конфигурирование наконец-то завершено. Первый запускПеред пробным запуском стоит упомянуть, что Nagios может быть запущен четырьмя способами. Давайте, перечислим их.
Для проверки конфигурации воспользуемся третьим способом. Собравшись с духом, можно попытаться запустить систему и начать мониторинг. Воспользуемся для этих целей скриптом nagios.sh. # /usr/local/etc/rc.d/nagios.sh После этого должно произойти одно из двух: либо Nagios начнет работать, либо на экране появится следующая ошибка. Starting network monitor: nagios /bin/sh: -l: unrecognized option Не пугайтесь, если Вам довелось наступить на эти грабли. Приведенное выше сообщение об ошибке значит, что операционная система, на которой Вы работаете, не поддерживает опцию -l команды su. В случае с FreeBSD дело обстоит именно таким образом. Поэтому команда должна выглядеть так su -. В файле /usr/local/etc/rc.d/ nagios.sh ищем строку, содержащую символы su -l и удаляем из нее букву l. Вот теперь-то все должно работать, как положено. Снова запускаем Nagios. Проверяем, как он себя чувствует, с помощью ключа командной строки status.# /usr/local/etc/rc.d/nagios.sh status PID TT STAT TIME COMMAND 101 ?? Ss 0:20.81 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc Если, несмотря на все принятые предосторожности, Nagios продолжает кричать об ошибках, то стоит убедиться, что директория /usr/local/nagios/ вместе со всем свои содержимым принадлежит пользователю nagios и группе nagios. В случае ежели подобные ожидания не оправдываются, выполняем смену владельца. # chown -R nagios:nagios /usr/local/nagios/ Ну, если и это не помогло, то Вам стоит запустить Nagios в режиме отладки. # /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg В режиме отладки тексты сообщений обо всех найденных неполадках будут более подробными. Это обстоятельство поможет легче и быстрее обнаружить ошибки. Процедура исправления ошибок в таком случае довольно проста. Исходя из этого, я надеюсь, что у Вас все получится если не с первого, то со второго раза точно. Nagios уже выполняет мониторинг сервисов и при наступлении критических событий отправляет оповещения всем, кому положено. Но по одним оповещениям понять, что происходит, не так уж и легко. Согласитесь, что в интерактивном режиме смотреть статистику работы и разбираться с проблемами гораздо легче. Исходя из этого, давайте, обратим наши взоры к процедуре настройки web-интерфейса. В данной статье предполагается, что на машине, занимающейся системой мониторинга, работает web-сервер Apache. Он обязан быть хотя бы минимально настроен и должен функционировать достаточно стабильно. В файле настроек Apache httpd.conf ищем такой фрагмент текста:
Сразу же после них добавляем такие строки:
ScriptAlias /nagios/cgi-bin/ "/usr/local/nagios/sbin/"
Выполнив эту, процедуру мы создали два псевдонима. Первый - для cgi директории nagios, находящейся в "/usr/local/nagios/sbin/". Доступ к ней можно получить, выполнив подобный http запрос http://ваш сайт/nagios/cgi-bin/. Второй псевдоним указывает, что в директории /usr/local/nagios/share/ находятся html файлы web-интерфейса и справочной документации. Просмотреть эти страницы можно, посетив адрес http://ваш сайт /nagios/. При попытке посетить эти страницы, получаем ошибку. Для того чтобы псевдонимы и авторизация заработали, нужно создать файл .htaccess в директории /usr/local/nagios/sbin/ и внести в него следующие строки: AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users require valid-user Для вступления в силу выполненных изменений осталось лишь перезапустить Apache. # /usr/local/apache/bin/apachectl restart Таким образом, мы объясняем web-серверу, что доступ к файлам директории /usr/local/nagios/sbin/ может получить только авторизованный пользователь. Если есть желание, чтобы пользователи не смогли войти даже на главную страницу Nagios без ввода пароля, то нужно скопировать файл .htaccess из директории /usr/local/nagios/sbin/ в /usr/local/nagios/share/. Список паролей и имен пользователей должен находится в файле /usr/local/nagios/etc/htpasswd.users, который на данный момент еще не существует. Заводим нового пользователя и заодно с помощью ключа c создаем файл. # /usr/local/apache/bin/htpasswd -c /usr/local/nagios/etc/htpasswd.users tigrisha New password: ****** Re-type new password: ****** Adding password for user tigrisha С помощью той же команды, но без ключа с, создаем еще одного пользователя. # /usr/local/apache/bin/htpasswd /usr/local/nagios/etc/htpasswd.users amon New password: ****** Re-type new password: ****** Adding password for user amon Теперь давайте займемся конфигурационным файлом /usr/local/nagios/etc/cgi.cfg. Нам нужно изменить некоторые параметры: authorized_for_system_information=tigrisha, amon # Список пользователей, которым разрешен просмотр # информации о работе процесса Nagios authorized_for_configuration_information= tigrisha, amon # Список пользователей, которым разрешен просмотр # информации о конфигурации всех хостов и сервисов. # По умолчанию пользователь может смотреть # конфигурацию только хостов и сервисов, # принадлежащих к его контактной группе. authorized_for_system_commands=tigrisha, amon # Список пользователей, авторизованных для выполнения # через cmd.cgi команд управления процессом Nagios. authorized_for_all_services=tigrisha, amon authorized_for_all_hosts=tigrisha, amon # Эти два параметра определяют список пользователей, которым разрешен просмотр # информации обо всех наблюдаемых хоста и сервисах. # По умолчанию пользователь может видеть # только те хосты и сервисы, которые принадлежат к его контактной группе. refresh_rate=10 # Частота обновления (в секундах) информации, просматриваемой через web-интерфейс. # По умолчанию установлено 90 секунд, но нам такой большой интервал не подходит. # Поэтому поставим 10 секунд. Теперь в файл nagios.cfg вносим следующие изменения date_format=euro # Устанавливаем формат даты более привычный для России use_authentication=1 # Включаем аутентификацию пользователей check_external_commands=1 # Разрешаем обрабатывать команды, передаваемые процессу Nagios через web-интерфейс. command_file=/usr/local/nagios/var/nagios.cmd # Местоположение файла внешних команд. Для того чтобы внесенные изменения вступили в силу, перезапускаем процесс Nagios: # /usr/local/etc/rc.d/nagios.sh restart Если все сделали правильно, то теперь самое время наслаждаться отлично работающей системой мониторинга. Мы установили наблюдение за двумя тестовыми хостами. Процедуру добавления остальных хостов оставляю читателю в качестве самостоятельного упражнения.
|
|||
 |
LinuxShareКто владеет информацией - владеет всем! Документация по Linux! |
|
|
|
|