Быстрое развертывание решения на основе пакета Nagios 3 для мониторинга распределенных систем и сетей

В статье рассматривается возможность организации мониторинга распределенной ИТ-инфраструктуры с помощью пакета Nagios 3. В ней приводится пример типового решения для малого предприятия и даются советы по расширению возможностей системы.

Александр Зорин, специалист, ООО «Виртуальные инфраструктуры предприятий»

Александр Зорин - специалист компании SkyAdmin.ru (ООО «Виртуальные инфраструктуры предприятий»). Консультирует малые и средние предприятия по вопросам развертывания и обслуживания ИТ-инфраструктуры.



29.03.2011

Введение

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

Рисунок 1. Структура основного сервера Nagios
Рисунок 1. Структура основного сервера Nagios

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

Рисунок 2. Запуск плагинов 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. Руководством предприятия была поставлена задача осуществить мониторинг данной ИТ-инфраструктуры.

Рисунок 3. Структура гипотетической сети предприятия
Рисунок 3. Структура гипотетической сети предприятия

Для этого потребуется установить на каждый из серверов службу 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.

Рисунок 4. Главная страница Web-интерфейса Nagios
Рисунок 4. Главная страница Web-интерфейса Nagios

Прежде чем добавлять в конфигурацию другие узлы, необходимо указать 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              alexander-zorin@yandex.ru; 
    }

После этого необходимо зарегистрировать узлы, мониторинг которых будет осуществляться, в 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[check_load]=/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[check_usr]=/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. Отображение статистики изменений состояния.
Рисунок 5. Отображение статистики изменений состояния.

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

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

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

Расширение NagVis

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

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

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


Заключение

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

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=643820
ArticleTitle=Быстрое развертывание решения на основе пакета Nagios 3 для мониторинга распределенных систем и сетей
publish-date=03292011