Установка nagios. Установка Nagios в Ubuntu

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

Инварианты

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

Load average на одной из машин стал больше X;
Свободной памяти на одной из машин осталось меньше X;
Свободного места на диске у одной из машин осталось меньше X;
Слишком много открытых файловых дескрипторов на машине X;
Сильно греется проц, скоро развалится диск , малый заряд UPS;
Высокий сетевой трафик, disk io, кончается своп, ну и так далее;
Один из хостов не пингуется или пингуется со слишком большим RTT;
Что-то перестало резолвиться по DNS;
Доступны более новые версии установленных пакетов;
На одну из машин залогинилось подозрительно много юзеров;
Есть критические ошибки в логах за последние X минут;
Число некритичных ошибок за последние X минут превысило Y;
Лежит или медленно отвечает PostgreSQL , Redis , RabbitMQ , …;
SSL-сертификат скоро истекает;
99-ый процентиль времени ответа сервиса сильно больше обычного;
Не ходит почта, SMS, пуши, …;
Нужно пополнить баланс в стороннем сервисе (AWS , Logentries , …);
Подозрительно большие расходы в стороннем сервисе;
В тестовом окружении не удалось восстановиться из бэкапа с прода;
Сервис стал недоступен из Зеленограда и ЮАР;
По внутренним хелсчекам сервиса мы уперлись в один из трэдпулов;

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

Установка Nagios

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

А чем вы мониторите вашу систему?

Для начала на server01 необходимо установить пакет nagios. Для этого введите в терминале:

Sudo apt-get install nagios3 nagios-nrpe-plugin

Вам будет предложено ввести пароль для пользователя nagiosadmin . Учетные записи пользователя находятся в /etc/nagios3/htpasswd.users. Для смены пароля пользователя nagiosadmin или добавления других пользователей для выполнения CGI скриптов Nagios используйте утилиту htpasswd , которая является частью пакета apache2-utils .

Например, для смены пароля пользователя nagiosadmin введите в терминале:

Sudo htpasswd /etc/nagios3/htpasswd.users nagiosadmin

Для добавления пользователя:

Sudo htpasswd /etc/nagios3/htpasswd.users steve

Sudo apt-get install nagios-nrpe-server

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

Обзор файлов настройки

Существует несколько директорий, содержащих конфигурационные файлы Nagios, а также файлы проверок.

1. /etc/nagios3: содержит конфигурационные файлы для работы демона nagios, файлы CGI , описания компьютеров и т.д.

2. /etc/nagios-plugins: файлы конфигурации для служебных проверок.

3. /etc/nagios: содержит конфигурационные файлы на удаленном компьютере nagios-nrpe-server .

4. /usr/lib/nagios/plugins/: тут находятся бинарные проверки. Для просмотра опций проверки используйте ключ "-h".

Например: /usr/lib/nagios/plugins/check_dhcp -h

Существует множество проверок Nagios, которые могут быть настроены для выполнения на любом компьютере. В этом примере Nagios будет настроен на проверку дискового пространства, службы DNS , а также группы пользователей MySQL. Проверка DNS будет осуществятся на server02 , а группа компьютеров MySQL будет включать в себя как server01 так и server02 .

Смотрите раздел HTTPD - Apache2 Web Server для более детальных настроек Apache, Служба Доменных Имен (DNS) для настройки DNS , а также MySQL для настройки MySQL .

В дополнение к этому будут приведены несколько терминов, которые помогут вам облегчить настройку Nagios:

Компьютер (хост): сервер, рабочая станция, сетевое устройство и т.д., которое отслеживается.

Группа компьютеров: группа подобных компьютеров. Например вы можете сгруппировать все веб-сервера, файловые сервера и т.д.

Служба: служба, которая отслеживается на компьютере. Например HTTP , DNS , NFS и т.д.

Группа служб: позволяет объединить несколько служб вместе. Например это будет полезным для объединения нескольких веб-серверов.

Контакт: человек, который будет уведомлен при каком-либо событии. Nagios может быть настроен на отправку email, SMS-сообщений и т.д.

По умолчанию Nagios настроен на проверку HTTP , дискового пространства, SSH , текущих пользователей, процессов и слежение за уровнем загрузки на локальном компьютере. Nagios также выполняет проверку шлюза посредством команды ping .

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

Настройка

1.1. Для начала необходимо создать конфигурационный файл для server02 . Если не указанно иное, выполните все эти команды на server01 . Введите в терминале:

Sudo cp /etc/nagios3/conf.d/localhost_nagios2.cfg \ /etc/nagios3/conf.d/server02.cfg

В вышеуказанном, а также следующем примере замените «server01», «server02» 172.18.100.100 и 172.18.100.101 на имя и ip-адрес ваших серверов.

Define host{ use generic-host ; Name of host template to use host_name server02 alias Server 02 address 172.18.100.101 } # check DNS service. define service { use generic-service host_name server02 service_description DNS check_command check_dns!172.18.100.101 }

1.3. Перезагрузите демон nagios для активации новых настроек:

2.1 Теперь добавим служебное описание для проверки MySQL путем добавления следующих строк в /etc/nagios3/conf.d/services_nagios2.cfg:

# check MySQL servers. define service { hostgroup_name mysql-servers service_description MySQL check_command check_mysql_cmdlinecred!nagios!secret!$HOSTADDRESS use generic-service notification_interval 0 ; set > 0 if you want to be renotified }

2.2. Сейчас должны быть определены сервера группы mysql. Отредактируйте /etc/nagios3/conf.d/hostgroups_nagios2.cfg добавив следующее:

# MySQL hostgroup. define hostgroup { hostgroup_name mysql-servers alias MySQL servers members localhost, server02 }

Mysql -u root -p -e "create user nagios identified by "secret";"

Пользователь nagios должен присутствовать на всех компьютерах рабочей группы серверов mysql.

2.4. Перезагрузите nagios для проверки сервера MySQL.

Sudo /etc/init.d/nagios3 restart

3.1. Наконец необходимо настроить NRPE для проверки дискового пространства на server02 .

На server01 добавим служебную проверку в /etc/nagios3/conf.d/server02.cfg:

# NRPE disk check. define service { use generic-service host_name server02 service_description nrpe-disk check_command check_nrpe_1arg!check_all_disks!172.18.100.101 }

3.2. Теперь на server02 отредактируем /etc/nagios/nrpe.cfg:

Allowed_hosts=172.18.100.100

А в строку объявления команды добавим:

Command=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -e

3.3. В конце перезагрузим nagios-nrpe-server:

Sudo /etc/init.d/nagios-nrpe-server restart

3.4. На server01 также необходимо перезагрузить nagios:

Sudo /etc/init.d/nagios3 restart

Теперь вы должны видеть ваши сервера и служебные проверки в файлах Nagios CGI . Для доступа к ним наберите в строке браузера http://server01/nagios3 . Вам будет предложено ввести имя пользователя и пароль для nagiosadmin.

Ссылки

В этом разделе были описаны лишь незначительные возможности Nagios. nagios-plugins-extra и nagios-snmp-plugins содержит намного больше файлов проверки служб.

1. Для более детальной информации обратитесь к документации на официальном сайте Nagios .

2. Узконаправленная документация по Nagios .

3. Существует несколько книг посвященных Nagios и мониторингу сети.

4. Страница Nagios Ubuntu Wiki также содержит достаточно документации.

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

Краткое описание Nagios

Главный компонент Nagios, базовый сервер, может быть развернут практически на любом Linux/Unix сервере. Он входит практически во все распространенные дистрибутивы Linux и Unix. При необходимости с сайта проекта можно загрузить исходный код и собрать на его основе собственную версию Nagios. Также вместе с основным пакетом Nagios устанавливается и документация для него.

Nagios обладает модульной архитектурой с возможностью расширения. Для увеличения возможностей Nagios можно использовать компоненты следующих типов: плагины (Nagios plugins) и расширения (Nagios addons).

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

Термин «расширение» (addon) был введен, чтобы избежать путаницы с плагинами, так как расширения используются для добавления в Nagios принципиально новой функциональности или интеграции с другими внешними продуктами.

Возможность быстрого написания плагинов превратила Nagios в универсальное средство для сетевого мониторинга. Существуют плагины для опроса узлов по SNMP, проверки доступности удаленного узла по множеству сетевых протоколов. В проекте Nagios Exchange можно выполнить поиск среди уже написанных плагинов или расширений, или добавить туда плагин собственной разработки.

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

На рисунке 1 представлена структура основного сервера Nagios.

На рисунке 2 показан механизм запуска плагинов Nagios на удаленном узле.

Ключевыми компонентами на рисунке 2 являются плагин check_nrpe на стороне узла мониторинга и расширение NRPE на удаленном узле. Между плагином check_nrpe и NRPE -демоном устанавливается зашифрованное SSL соединение, по которому nagiosd отправляет команды для запуска плагинов и получает результаты их выполнения. NRPE «проецирует» плагины на удаленном узле в основной сервер Nagios (nagiosd ), благодаря чему можно запускать любые плагины на любом удаленном узле.

Для удаленного мониторинга Windows узлов можно использовать расширение NSClient++ . В данном случае со стороны nagiosd должен использоваться плагин check_nt .

Пример использования Nagios

Для примера будет взято малое торговое предприятие, имеющее 3 точки присутствия: склад, магазин и офис. У каждой точки присутствия имеется свое подключение к местному ISP. В качестве шлюза на каждой из площадок установлен Linux/Unix сервер. Между всеми площадками организован VPN. В офисе Интранет-сеть - 10.1.0.0/24. На складе - 10.2.0.0/24. В магазине - 10.3.0.0/24. Руководством предприятия была поставлена задача осуществить мониторинг данной ИТ-инфраструктуры.

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

Для установки nagiosd и NRPE можно использовать штатные средства системы. Эта процедура зависит от выбранной платформы и обычно трудностей не представляет. Также вместе с nagiosd или NRPE устанавливается базовый комплект плагинов. Еще потребуется установить и настроить Web-интерфейс для отображения состояния узла c установленным Nagios сервером. В некоторых дистрибутивах он выделен в отдельный пакет. Наконец, необходимо создать файл htpasswd с пользователем nagiosadmin, прописанным в файле cgi.conf. При желании вместо этого имени можно внести изменения в конфигурацию и использовать другого пользователя.

После этого можно запустить Nagios-сервер и Web-сервер и войти на локальный ресурс Nagios, введя имя пользователя и пароль. Пока он осуществляет мониторинг только одного узла localhost и показывает несколько его параметров (load average (средняя загрузка), current users (активные пользователи) , disk space (дисковое пространство)). В одном из разделов этого ресурса находится документация, так что для доступа к ней не потребуется расходовать Интернет-трафик. Описание узла находится в файле localhost.cfg.

Прежде чем добавлять в конфигурацию другие узлы, необходимо указать e-mail адреса людей, отвечающих за их администрирование. Это делается в файле contacts.cfg. Крайне рекомендуется выбирать e-mail адреса независимых провайдеров электронной почты. Например, можно установить на мобильный телефон почтовый клиент Yandex и указать в описании адрес на yandex.ru. Если Интернет в офисе, где установлен корпоративный почтовый сервер, будет отключен, то даже в нерабочее время Nagios сервер со склада уведомит администратора об этом через мобильный телефон.

В листинге 1 показано, как добавить контактную информацию в файл contacts.cfg.

Листинг 1. Добавление контактной информации.

define contact{ contact_name zorin; // короткое имя пользователя // значения по умолчанию будут унаследованы от шаблона generic-contact use generic-contact; alias Alexander N. Zorin; // полное имя пользователя email [email protected]; }

После этого необходимо зарегистрировать узлы, мониторинг которых будет осуществляться, в Nagios. В листинге 2 показано, как по аналогии с файлом localhost.cfg, создать описание складского узла в файле warehouse-gw.cfg.

Листинг 2. Добавление узлов в Nagios.

define host{ // название шаблона, используемого для описания узла. // определение этого узла унаследует все параметры, // объявленные в шаблоне узла linux-server. use linux-server host_name warehouse-gw alias warehouse display_name Warehouse contacts zorin, worehouse-admin address 140.14.22.4 } define service{ // название шаблона, используемого для описания службы. use local-service ; host_name warehouse-gw service_description SSH check_command check_ssh notifications_enabled 1 } define host{ use linux-server; host_name warehouse-intra alias warehouse-intra display_name Warehouse local net contacts zorin, warehouse-admin address 10.2.0.1 } define service{ // название шаблона, используемого для описания службы. use local-service; host_name warehouse-intra service_description SMTP check_command check_smtp notifications_enabled 1 }

Узел warehouse-gw намеренно зарегистрирован дважды, чтобы отслеживать состояние как внешних, так и внутренних служб локальной сети. В данном примере SMTP-сервер обслуживает только локальную сеть. В сводках на Web-интерфейсе Nagios будут показываться два узла warehouse-gw и warehouse-intra . Если пропадет узел warehouse-intra и будет доступен только warehouse-gw – это значит, что произошло отключение VPN-канала.

Часть плагинов будет запускаться через расширение NRPE (load average - check_load, disk space - check_disk, current users - check_users) для получения информации, которую невозможно или сложно получить, находясь вне узла. Для этого потребуется установить плагин check_nrpe2 на Nagios серверах и расширение NRPE на всех серверах. Это можно сделать с помощью стандартных средств системы.

В конфигурационном файле nrpe.cfg обязательно нужно прописать адрес, к которому будет прикреплен NRPE -демон и доверенные узлы, от которых он будет принимать запросы. Для магазина (узел shop-gw) будут использоваться следующие параметры:

server_address=10.3.0.1 allowed_hosts=10.1.0.1,10.2.0.1

Трафик NRPE намеренно направляется через VPN. Доверенными узлами для NRPE-демона в магазине являются офис и склад. На Nagios-серверах мониторинг данных служб будет настроен, как показано в листинге 3:

Листинг 3. Настройка мониторинга для удаленной службы

define service{ // название шаблона, используемого для описания службы. use local-service; host_name warehouse-intra service_description Load average index check_command check_nrpe2!-c check_load notifications_enabled 1 }

В данном случае NRPE -демону узла warehouse-intra отправляется команда check_load . В ответ будет прислано текущее значение load average для этого узла. Следует обратить внимание, что параметры для плагина (а их может быть несколько) должны быть разделены восклицательными знаками. В представленном примере параметром является -c check_load .

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

Работа с плагинами

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

В листинге 4 показано, как описывается плагин check_smtp , проверяющий доступность SMTP-сервера на удаленном узле и время его отклика.

Листинг 4. Настройка плагина check_smtp

define command{ command_name check_smtp command_line /usr/lib/nagios/plugins/check_smtp -H $HOSTADDRESS$ }

Здесь явно указаны путь к плагину check_smtp и необходимость добавлять к запросу через опцию -H IP адрес проверяемого узла, который подставляется автоматически на основании директивы define service , приведенной выше. Если запустить данный плагин из командной строки, то будет выведена следующая информация:

/usr/lib/nagios/plugins/check_smtp -H 192.168.4.1 SMTP OK - 0.038 sec. response time|time=0.037518s;;;0.000000

Параметры запуска могут быть различными, главное правильно добавить их в описание команды. Формат вывода подробно описан в документации, установленной вместе с Web-интерфейсом.

При установке NRPE -демона в файле nrpe.conf прописывается лишь незначительная часть плагинов, среди них - приведенная выше команда chесk_load :

command=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20

В приведенной строке указан путь к плагину check_load и параметры его запуска. Если плагин запустить без параметров, то он выведет список допустимых параметров. Например, необходимо создать команду check_usr для NRPE , которая бы возвращала на сервер мониторинга информацию о разделе /dev/md2, смонтированном на пути /usr. Данную функциональность можно реализовать с помощью стандартного плагина check_disk . Если запустить его без параметров, то будет выведено описание стартовых параметров.

Usage: check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x device} [-C] [-E] [-e] [-g group ] [-k] [-l] [-M] [-m] [-R path ] [-r path ] [-t timeout] [-u unit] [-v] [-X type]

На основании представленной информации можно подготовить команду check_usr и поместить ее в файл nrpe.conf:

command=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/md2

Пробный запуск этой команды выдаст результат:

/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/md2 DISK OK - free space: /usr 20295 MB (86% inode=92%);| /usr=3061MB;19684;22145;0;24606

Как видно, в Nagios можно легко создавать плагины для выполнения самых разных задач и подключать их к NRPE-демону.

Расширения Nagios

Обсуждая возможности Nagios, обязательно нужно рассмотреть наиболее интересные расширения, значительно повышающие возможности Nagios.

Расширение pnp4nagios

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

Как показано на рисунке 5, красным цветом выделен период критичного состояния, а зеленым - периоды нормального функционирования. Такое решение подходит для параметров логического типа (да/нет), например, целостности RAID массива. Для численных параметров было бы полезнее отслеживать динамику изменений.

Расширение pnp4nagios , регулярно получая от nagiosd значения параметров, сохраняет историю их изменений и формирует отчет в графической форме. Графики можно произвольно комбинировать и при необходимости конвертировать полученную Web-страницу в PDF-файл. На рисунке 6 продемонстрирован отчет об изменении параметра load average для конкретного узла.

Рисунок 6. Web-страница расширения pnp4nagios

Заключение

Особенно стоит отметить низкую ресурсоёмкость этого решения. В одной из компаний Nagios используется для мониторинга 14 узлов и 140 служб на них, при этом NRPE-демон занимает 512КБ оперативной памяти, а сервер nagiosd всего 140КБ оперативной памяти. Потребление ресурсов процессора обоими компонентами и их дочерними процессами на CPU Pentium-IV не превышает 1%. Среди отслеживаемых параметров: температура винчестеров и материнских плат, состояние дисковых разделов, размеры почтовых очередей, скорости вращения вентиляторов, целостность RAID массивов и многое другое.

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

Nagios (Nagios Ain"t Gonna Insist On Sainthood) - программа с открытым кодом, предназначенная для мониторинга компьютерных систем и сетей. Она производит наблюдения, контроль состояния узлов и служб, оповещения администратора в том случае, если какие-то из служб прекращают (или возобновляют) свою работу.

В сегодняшней статье мы расскажем, как установить Nagios 4.1 на Ubuntu 15.04 .

Протестировать и посмотреть, что же из себя представляет Nagios и другие программы/сервисы/АТС вы можете перейдя в раздел .

Подготовка

Убедитесь, что на вашем сервере установлен полностью рабочий LAMP , если не установлен, то прежде чем продолжать, установите LAMP сервер. Установим следующие компоненты:

Sudo apt-get install build-essential libgd2-xpm-dev apache2-utils unzip

Создадим пользователя и группу Nagios

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

Sudo useradd -m nagios
sudo passwd nagios
sudo groupadd nagcmd
sudo usermod -a -G nagcmd nagios
sudo usermod -a -G nagcmd www-data

Скачиваем Nagios и плагины для него

На официальном сайте последняя версия значится как 4.1.0 release candidate 2 , ее и скачаем.

Cd /usr/src
sudo wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.1.0rc2.tar.gz

Скачиваем плагины

Sudo wget http://nagios-plugins.org/download/nagios-plugins-2.0.3.tar.gz

Установка Nagios

Переходим в папку, куда мы скачали Nagios и плагины и разархивируем с помощью команды:

Sudo tar xzf nagios-4.1.0rc2.tar.gz

Cd nagios-4.1.0rc2/

Выполняем следующие команды для компиляции и установки Nagios :

Sudo ./configure --with-command-group=nagcmd
sudo make all
sudo make install
sudo make install-init
sudo make install-config
sudo make install-commandmode

Устанавливаем Web-интерфейс Nagios :

Sudo make install-webconf

Если в процессе установки вы получили следующую ошибку:

/usr/bin/install -c -m 644 sample-config/httpd.conf /etc/httpd/conf.d/nagios.conf
/usr/bin/install: cannot create regular file ‘/etc/httpd/conf.d/nagios.conf’: No such file or directory
Makefile:296: recipe for target "install-webconf" failed
make: *** Error 1

Nagios пытается создать файл nagios.conf внутри /etc/httpd.conf/directory , но в системах Ubuntu файлы nagios.conf должны быть помещены в /etc/apache2/sites-enabled/directory . Используем тогда другую команду вместо sudo make install-webconf

Sudo /usr/bin/install -c -m 644 sample-config/httpd.conf /etc/apache2/sites-enabled/nagios.conf

Создадим учетную запись Nagiosadmin для входа в Web-интерфейс Nagios . Обязательно запомните задаваемый вами пароль, он вам понадобится при входе в Web-интерфейс.

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

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

Sudo systemctl restart apache2

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

Cd /usr/src
tar xzf nagios-plugins-2.0.3.tar.gz

Переходим в разархивированный каталог:

Cd nagios-plugins-2.0.3/

Выполняем следующие команды для компиляции и установки плагинов:

Sudo ./configure --with-nagios-user=nagios --with-nagios-group=nagios
sudo make
sudo make install

Запускаем Nagios

Проверяем nagios.conf на наличие ошибок:

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

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

Sudo service nagios start
sudo ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Если при запуске Nagios вы увидели следующую ошибку:

Failed to start nagios.service: Unit nagios.service failed to load: No such file or directory.

[....] Starting nagios (via systemctl): nagios.serviceFailed to start nagios.service: Unit nagios.service failed to load: No such file or directory.failed!

Чтобы ее исправить нужно скопировать /etc/init.d/skeleton в /etc/init.d/nagios

Sudo cp /etc/init.d/skeleton /etc/init.d/nagios

Отредактируем /etc/init.d/nagios :

Sudo nano /etc/init.d/nagios

Добавив в самый конец следующее:

DESC="Nagios"
NAME=nagios
DAEMON=/usr/local/nagios/bin/$NAME
DAEMON_ARGS="-d /usr/local/nagios/etc/nagios.cfg"
PIDFILE=/usr/local/nagios/var/$NAME.lock

Сохраняем и выходим.

Финальный штрих - даем права на исполнение:

Sudo chmod +x /etc/init.d/nagios

и запускаем Nagios :

Sudo /etc/init.d/nagios start

Теперь в браузере вводим http://nagios-server-ip/nagios , в поле username вводим nagiosadmin и пароль, который мы задавали в процессе установки.

Нажмите на “Host” в левой панели консоли . Вы увидите, что на данный момент Nagios не мониторит ни одного хоста кроме самого себя.

На этом наша установка завершена. Пройдя по всей инструкции мы установили Nagios 4.1 на Ubuntu 15.04

Преимущества и новые возможности для мониторинга систем

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

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

ПО Nagios реализует функциональность для подготовки отчетов о количестве времени, потерянного из-за простоев, что может быть полезным для отслеживания качества предоставления услуг согласно соглашению об уровне сервиса (service level agreement - SLA). Как будет показано в последующих статьях, Nagios также предлагает возможности для учета времени простоя и создания зависимостей от служб и систем. Эта вводная статья показывает, как легко можно создавать небольшие персонализированные решения для конкретных требований по мониторингу.

Установка

Большинство дистрибутивов Linux® поставляются с встроенной версией Nagios. В этом случае продукт легко интегрируется с Web-сервером Apache. Для активизации или обновления такой конфигурации необходимо выполнить команду:

yum install nagios

или apt-get install nagios-text . Исполняемые файлы для платформы AIX® доступны для загрузки с Web-сайта NagiosExchange (см. раздел ).

Для других платформ исходный код Nagios можно загрузить с Web-сайта Nagios.org (см. раздел ). Для создания Nagios "с чистого листа" необходимы следующие инструменты разработчика.

Инструменты:
- autoconf
- automake
Исполняемые файлы:
- libgd
- openssl
Пакеты (библиотек и заголовочных файлов)

Многие плагины, связанные с SNMP (Simple Network Management Protocol - простой протокол сетевого управления) также потребуют наличия Perl и пакета Net::SNMP.

После установки и настройки Nagios можно получить к нему доступ через стандартный URL http://your.host.name/nagios . На показано, какие системы и службы включены или отключены.

Настройка Nagios

По умолчанию все конфигурационные файлы Nagios находятся в каталоге /etc/nagios . Конфигурационные файлы, связанные с Apache, можно для удобства связать с конфигурационным каталогом Apache c помощью ссылок. Конфигурация разделена на несколько файлов, каждый из которых предназначен для отдельных фрагментов конфигурации.

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

Контакты хранятся в файле contacts.cfg и определяются, как показано в листинге 1.

Листинг 1. Конфигурация 1: Базовая информация о контактах

define contact{ contact_name jdoe alias John Due service_notification_commands notify-by-email host_notification_commands host-notify-by-emailes email [email protected] }

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

Листинг 2. Конфигурация 2: Группировка контактов

define contactgroup{ contactgroup_name server-admins alias Server Administrators members jdoe,albundy }

Следующий шаг - это настроить системы, за которыми Nagios будет осуществлять мониторинг. Необходимо добавить каждый компьютер, на котором имеются службы, которые предстоит отслеживать или периодически проверять на активность. Конфигурационный файл для хранения система - это файл hosts.cfg . В листинге 3 приведен пример определения компьютера.

Листинг 3. Конфигурация 3: Добавление нового компьютера

define host{ host_name ubuntu_1_2 alias Ubuntu test server address 192.168.1.2 check_command check-host-alive max_check_attempts 20 notifications_enabled 1 event_handler_enabled 0 flap_detection_enabled 0 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 notification_interval 60 notification_period 24x7 notification_options d,u,r }

Последний этап конфигурации Nagios - это определение служб для сконфигурированных систем. Показанный в листинге 4 пример использует заранее определенный ping-плагин для Nagios, который отправляет эхо-запросы по протоколу ICMP (Internet Control Message Protocol), чтобы определить, отвечает компьютер или нет.

Листинг 4. Конфигурация 4: Добавление новой службы

define service{ use service-template host_name ubuntu_1_2 service_description PING check_period 24x7 contact_groups server-admins notification_options c,r check_command check_ping!300.0,20%!1000.0,60% }

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

Написание плагинов для Nagios

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

OK - код возврата 0 - означает, что сервис работает нормально;
WARNING - код возврата 1 - это предупредительный сигнал о том, что у сервиса могут быть проблемы;
CRITICAL - код возврата 2 - критическое состояние сервиса;
UNKNOWN - код возврата 3 - неизвестное состояние сервиса.

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

В листинге 5 приведен пример сценария на языке Python, который проверяет среднюю загрузку ОС UNIX®. В нем предполагается, что уровень выше 2.0 соответствует предупредительному состоянию, а уровень выше 5.0 -критическому состоянию. Эти значения "вшиты" в код, и также всегда используется среднее значение загрузки за последнюю минуту.

Листинг 5. Python плагин - пример работающего плагина

#!/usr/bin/env python import os,sys (d1, d2, d3) = os.getloadavg() if d1 >= 5.0: print "GETLOADAVG CRITICAL: Load average is %.2f" % (d1) sys.exit(2) elif d1 >= 2.0: print "GETLOADAVG WARNING: Load average is %.2f" % (d1) sys.exit(1) else: print "GETLOADAVG OK: Load average is %.2f" % (d1) sys.exit(0)

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

Это довольно просто: сначала создается файл /etc/nagios-plugins/config/mygetloadavg.cfg с содержимым, приведенным ниже, и добавляется служба в файл services.cfg , как показано в примере ниже. Напомню, что localhost должен присутствовать в конфигурационном файле hosts.cfg .

Листинг 6. Пример плагина - регистрация в Nagios

define command{ command_name check_mygetloadavg command_line /path/to/check_getloadavg }

Листинг 7. Создание службы, использующей пример плагина

define service{ use service-template host_name localhost service_description LoadAverage check_period 24x7 contact_groups server-admins notification_options c,r check_command check_mygetloadavg }

Написание полноценного плагина

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

Другой полезный прием - это перехватывание всех исключительных ситуаций и возврат в отчет о состоянии службы значения UNKNOWN , чтобы Nagios мог соответствующим образом оповестить об этом событии. Плагины, которые допускают "выход" исключительных ситуаций за свои границы, чаще всего возвращают значение 1, которое трактуется Nagios как WARNING -состояние. Важно чтобы плагин правильно отличал состояние WARNING (предупредительное) от UNKNOWN (неизвестное). Стоит заметить, что обычно извещения об отдельных состояниях WARNING отключаются, но не стоит отключать извещения о состоянии UNKNOWN .

Написание Python-плагина

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

Листинг 8. Python-плагин - полноценный плагин для получения данных о средней загрузке

#!/usr/bin/env python import os import sys import getopt def usage(): print """Usage: check_getloadavg [-h|--help] [-m|--mode 1|2|3] \ [-w|--warning level] [-c|--critical level]" Mode: 1 - last minute ; 2 - last 5 minutes ; 3 - last 15 minutes" Warning level defaults to 2.0 Critical level defaults to 5.0""" sys.exit(3) try: options, args = getopt.getopt(sys.argv, "hm:w:c:", "--help --mode= --warning= --critical=",) except getopt.GetoptError: usage() sys.exit(3) argMode = "1" argWarning = 2.0 argCritical = 5.0 for name, value in options: if name in ("-h", "--help"): usage() if name in ("-m", "--mode"): if value not in ("1", "2", "3"): usage() argMode = value if name in ("-w", "--warning"): try: argWarning = 0.0 + value except Exception: print "Unable to convert to floating point value\n" usage() if name in ("-c", "--critical"): try: argCritical = 0.0 + value except Exception: print "Unable to convert to floating point value\n" usage() try: (d1, d2, d3) = os.getloadavg() except Exception: print "GETLOADAVG UNKNOWN: Error while getting load average" sys.exit(3) if argMode == "1": d = d1 elif argMode == "2": d = d2 elif argMode == "3": d = d3 if d >= argCritical: print "GETLOADAVG CRITICAL: Load average is %.2f" % (d) sys.exit(2) elif d >= argWarning: print "GETLOADAVG WARNING: Load average is %.2f" % (d) sys.exit(1) else: print "GETLOADAVG OK: Load average is %.2f" % (d) sys.exit(0)

Для использования нового плагина необходимо зарегистрировать его в файле /etc/nagios-plugins/config/mygetloadavg2.cfg , как показано в листинге 9.

Листинг 9. Python-плагин - регистрация в Nagios

define command{ command_name check_mygetloadavg2 command_line /path/to/check_getloadavg2 -m $ARG1$ -w $ARG2$ -c $ARG3$ }

Также необходимо добавить или изменить запись об этой службе в файле services.cfg , как показано в листинге 10. Стоит отметить, что восклицательный знак! разделяет параметры плагина. Как и прежде, необходимо, чтобы localhost был определен в конфигурационном файле hosts.cfg .

Листинг 10. Создание сервиса, использующего плагин Python

define service{ use service-template host_name localhost service_description LoadAverage2 check_period 24x7 contact_groups server-admins notification_options c,r check_command check_mygetloadavg2!1!3.0!6.0 }

Написание плагина Tcl

Последний пример - это плагин, написанный на Tcl и проверяющий курсы валют с сайта xmethods.net с помощью протокола SOAP (Simple Object Access Protocol) и технологии WSDL (Web Services Description Language). SOAP предоставляет плагину текущие значения курсов валют, чтобы сравнить их с конфигурированными значениями. Если значение находится внутри предупредительного диапазона, то считается, что это состояние OK . Если значение выше или ниже предупредительного уровня, но не выходит за критический предел, то считается, что это состояние WARNING . В противном случае состояние считается как CRITICAL , если не происходит сетевого сбоя, в случае которого состояние устанавливается в UNKNOWN .

Плагин распознает конфигурируемые параметры, так что можно проверять различные курсы с различными диапазонами для проверки. Также его можно использовать для проверки курсов валют различных стран (листинг 11).

Листинг 11. Tcl-плагин - проверка текущих значений курсов обмена валют

#!/usr/bin/env tclsh # parse arguments package require cmdline set options { {country1.arg "" "Country 1"} {country2.arg "" "Country 2"} {lowerwarning.arg "" "Lower warning limit"} {upperwarning.arg "" "Upper warning limit"} {lowercritical.arg "" "Lower critical limit"} {uppercritical.arg "" "Upper critical limit"} } array set opt }] # если пользователь не предоставил все аргументы, # то показать справочное сообщение for each necessary { if {$opt($necessary) == ""} { set argv "-help" catch {cmdline::getoptions argv $options {: }} usage puts stderr $usage exit 3 } } # загрузить пакет TclWebServices package require WS::Client if { 1] } error]} { # если по какой-либо причине не удалось загрузить курс, то сообщить об этом puts "EXCHANGERATE UNKNOWN: $error" exit 3 } if {($result < $opt(lowercritical)) || ($result > $opt(uppercritical))} { puts "EXCHANGERATE CRITICAL: rate is $result" exit 2 } if {($result < $opt(lowerwarning)) || ($result > $opt(upperwarning))} { puts "EXCHANGERATE WARNING: rate is $result" exit 1 } puts "EXCHANGERATE OK: rate is $result" exit 0

Теперь необходимо зарегистрировать эту команду, чтобы Nagios знал, как вызывать ее. Для того чтобы сделать это, надо создать файл /etc/nagios-plugins/config/exchangerate.cfg с содержимым, похожим на предыдущие конфигурации и следующим определением команды:

command_line /path/to/check_exchangerate -country1 $ARG1$ -country2 $ARG2$ -lowercritical \ $ARG3$ -lowerwarning $ARG4$ -upperwarning $ARG5$ -uppercritical $ARG6$

Имя команды check_exchangerate используется в примере, приведенном ниже.

Затем необходимо создать службу, которая будет использовать созданный плагин для отслеживания курсов валют. Ниже приведен пример определения службы, ассоциирующий службу с сервером localhost . Хотя проверка на самом деле не связана с каким-либо реальным компьютером, ее все равно необходимо привязать к системе. Если проверка включает вызов SOAP-методов серверов внутри контролируемой сети, то необходимо добавить реальный сервер, для которого будет выполняться мониторинг, и привязать службу к этому серверу. Код в проверяет, что курс британского фунта по отношению к японской йене находится в диапазоне от 225 до 275.

Листинг 12. Добавление Tcl-плагина в качестве новой службы

define service{ use service-template host_name localhost service_description EXCHANGERATE check_period 24x7 contact_groups other-admins notification_options c,r check_command check_exchangerate!England!Japan!200!225!275!300 }

Заключение

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

Опытный системный администратор может расширить SOAP-пример с помощью Tcl или любого другого языка для взаимодействия с Web-службами в Интранет-сети и написания плагинов для проверки правильности функционирования этих служб.

Также можно использовать С-плагины или возможности С-программирования, встроенные в используемый динамический язык (Pyinline в Python, Inline в Perl или Critcl в Tcl) для комбинирования сочетания системных API ОС на языке С с плагином, написанном на языке высокого уровня.

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

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