Аннотация

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

Abstracts

   An article describes Nagios – network and host monitoring system. It gives understanding of how Nagios operates in problem situations. Also such questions as architecture, theory of operation and network outages are discussed. Notifications system, service and host checks, monitoring of remote hosts and services are showed in examples.

Сведения об авторе

Грунау Андрей

ICQ: 83456457

E-mail: andrey.grunau(at)2006.auditory.ru

Ключевые фразы

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

Мониторинг компьютерной сети при помощи Nagios.

• Введение

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

   Система мониторинга призвана обеспечивать постоянное наблюдение за состоянием узлов компьютерной сети: выполнять проверку доступности сетевых ресурсов, служб, следить за работой серверного и коммуникационного оборудования; в случае нарушения нормальной работы уведомлять администратора, используя различные средства оповещения. Например, чтобы проверить работоспособность web-сервера, программа, выполняющая мониторинг, может периодически отправлять http-запрос на получение web-страницы. Похожие операции могут осуществляться в отношении почтовых серверов и других служб. Помимо отправки уведомления администратору, система мониторинга может быть настроена таким образом, чтобы проводить обработку событий, т.е. отказов в работе элементов сети и принимать меры по их устранению путём перезапуска какого-либо приложения, выполнения заданного сценария и т.п.

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

• Система Nagios

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

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

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

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

• Активные и пассивные проверки

   В логике работы системы Nagios присутствуют два вида проверок: активные и пассивные. В первом случае система в назначенное время сама инициирует проверку, запуская соответствующий плагин, и обрабатывает полученный результат. Во втором случае проверки инициируются и выполняются внешними приложениями, а Nagios лишь обрабатывает данные, полученные от внешнего приложения. Пассивные проверки целесообразно использовать в тех случаях, когда хосты находятся за брандмауэром, или по каким-то причинам проверки не могут быть запущены непосредственно с хоста, на котором работает Nagios. Помимо этого, существуют проверки асинхронные по своей природе, так что их нельзя отнести к разряду активных проверок. Примерами таких сигналов являются так называемые “snmp-ловушки” (snmp-traps), когда данные отправляются не периодически, а только по необходимости при наступлении события, превышения параметром граничного значения и т.п.

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

[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<description>;<return_code>;<plugin_output>

Где:

• timestamp – это число секунд с начала эпохи (1 января 1970 г.) до момента проверки;

• host_name имя хоста, которое должно совпадать с описанным в конфигурационном файле Nagios-а для данного хоста;

• description – описание сервиса, согласно services.cfg;

• return_code – непосредственно результат проверки (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)

• plugin_output – текстовое поле, которое будет отображаться в web-интерфейсе наряду с результатом проверки для данного сервиса.

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

• NSCA

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

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

  Клиентская часть состоит из программы send_nsca, которая используется для отправки результатов проверок с удалённого хоста nsca-демону на основной машине мониторинга. Формат выходных данных программы был рассмотрен выше.

• NRPE

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

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

   Рис. 1.  Использование активных и пассивных проверок. 
На рисунке 1 изображена схема взаимодействия сервера мониторинга и двух удалённых хостов, за сервисами которых проводится наблюдение. Используется комбинация активных и пассивных проверок, а также применяются дополнения NSCA, NRPE. В качестве экспортируемого сервиса (работу которого можно проверить удалённо) может выступать работающий на удалённом хосте web-сервер, служба ssh, сервер баз данных, почтовый сервер и другие. Особенность такого сервиса в том, что проверить его работоспособность можно с другого хоста путём отправки запроса на соответствующий порт. Неэкспортируемые сервисы либо не взаимодействуют с сетью, либо это взаимодействие нежелательно, поэтому для получения информации об их состоянии используются модули, находящиеся на удалённом хосте, или стороннее приложение. В первом случае, согласно рисунку, проверки являются активными, так как инициируются сервером мониторинга путём запуска check_nrpe, во втором случае стороннее приложение взаимодействует с nsca-клиентом, который отправляет результаты серверу мониторинга. Последние трактуются системой Nagios как пассивные проверки.

• Конфигурация системы

   Вся настройка системы мониторинга осуществляется путём редактирования конфигурационных файлов. По своим функциям их можно разделить на группы:

• главный конфигурационный файл nagios.cfg, содержащий базовые параметры;

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

• файлы описания объектов, предназначенные для определения хостов, сервисов, групп хостов, контактов для оповещения, групп контактов, исполняемых команд (проверок) и т.п. В этих файлах описываются все объекты, подлежащие мониторингу, а также задаются параметры выполняемых проверок и настройка оповещений;

• конфигурационный файл cgi.cfg, задающий параметры и права доступа к web-интерфейсу.

• Описание объектов с использованием шаблонов

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

define someobjecttype{

            object-specific variables ...

            name  template_name

            use  name_of_template_to_use

            register [0/1]

            }

   В описании шаблона задаётся его имя, которое впоследствии будет использоваться при описании объекта мониторинга (разумеется, имена шаблонов должны быть уникальны), имя родительского объекта (шаблона), свойства которого наследует вновь создаваемый объект. Параметр “register” указывает системе на то, будет ли данный объект зарегистрирован как реально существующий. Дело в том, что допускается задавать описания объекта, не указывая обязательные параметры (например, имя). В этом случае шаблон будет описывать некий класс объектов с заданными свойствами, но сам по себе реальным объектом являться не будет. Поясним сказанное на примере:

 
 
 
 
define host{

            check_command  check-host-alive

            notification_options d,u,r

            max_check_attempts 5

            name   generichosttemplate

            register   0

            } 

define host{

            host_name  bighost1

            address   192.168.1.3

            max_check_attempts 3

            use   generichosthosttemplate

            }

   В первом блоке описывается шаблон для хоста (define host), в котором пропущено поле “host_name” и параметр register установлен в нуль. Далее в описании хоста bighost1 с помощью директивы “use” указывается имя родительского объекта, свойства которого наследуются. Параметр “max_check_attempts” в данном случае переопределяется, так как указан локально. Данная запись с использованием шаблона эквивалентна следующей:

define host{

            host_name  bighost1

            address   192.168.1.3

            check_command  check-host-alive

            notification_options d,u,r

            max_check_attempts 3

            }

Помимо того, что использование шаблонов существенно сокращает размер конфигурационного файла, это облегчает внесение изменений в логику проверок при большом числе сервисов.

• Зависимости между объектами

   Использование зависимостей для сервисов и хостов позволяет устанавливать связи с другими объектами мониторинга и таким образом контролировать ход выполнения проверок и отправки уведомлений.

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

   Существуют два вида зависимостей. Зависимость на выполнение проверки и зависимость на отправку уведомлений. Пример описания зависимости показан ниже.

define servicedependency{

      host_name   Host A

      service_description  Service1

      dependent_host_name  Host B

      dependent_service_description Service2

      execution_failure_criteria c

      notification_failure_criteria  w,c,u

      inherits_parent  1

      }

   В приведённом примере сервис 2 хоста B зависит от сервиса 1, расположенного на хосте A. Перед выполнением проверки сервиса 2, Nagios определит статус сервиса 1, и если окажется, что сервис 1 находится в состоянии CRITICAL (c), то зависимость будет не удовлетворена и проверка сервиса 2 проводиться не будет. Если сервис 1 находится в каком-либо другом состоянии, то Nagios перейдёт к проверке следующей зависимости. Так, например, если сервис 1 находится в одном из состояний WARNING, CRITICAL, UNKNOWN, то уведомления для сервиса 2 отправлены не будут. Параметр “inherit_parent 1” указывает на то, что зависимости, определённые для сервиса 1 хоста A будут наследоваться сервисом 2 хоста B, как если бы они были заданы явно.

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

• Расписание проверок

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

    На процедуры запуска и обработки результатов проверок влияют параметры, задаваемые в главном конфигурационном файле nagios.cfg.

• inter_check_delay_method;

• service_interleave_factor;

• max_concurrent_checks;

• service_reaper_frequency.

Между несколькими проверками, инициируемыми Nagios, разумеется, существует некоторый временной интервал. Изменяя значение параметра “inter_check_delay_method” можно влиять на способ вычисления этого интервала. По умолчанию используется режим “smart”. При этом задержка между запуском проверок вычисляется путём деления среднего значения частоты проверок “check_interval” всех сервисов на число сервисов. Допускается задавать значение этого параметра в секундах с точностью до сотых.

   Если на каком-либо удалённом хосте находится достаточно много сервисов и при проверках используется один и тот же порт, удалённый хост может расценить большое число подключений к одному порту как возможную DoS атаку. Принимая во внимание этот факт, а также учитывая то, что проверки могут занимать разное время и задействовать системные ресурсы удалённого хоста, Nagios позволяет изменять алгоритм составления расписания проверок. В простейшем случае для каждого хоста составляется список сервисов, и проверки для них назначаются последовательно. Сначала, в расписании будут заданы проверки всех сервисов одного хоста, затем все сервисы следующего и так далее. Когда же наступит время для запуска первой проверки, Nagios инициирует её, после этого по прошествии интервала времени, определяемого рассмотренным параметром “inter_check_delay_method” будет инициирована следующая проверка и так далее. Получится, что в единицу времени будет запущено несколько проверок для одного и того же хоста, что непременно скажется на загрузке процессора как удалённого узла, так и сервера мониторинга, когда результаты нескольких проверок поступят в очередь на обработку. Параметр “service_interleave_factor” указывает Nagios как составлять расписание, чтобы по возможности избегать запуска нескольких проверок для одного и того же хоста в узкий интервал времени. По умолчанию значение параметра задаёт режим “smart” подобно уже рассмотренному случаю. Значение рассчитывается путём округления частного от деления общего числа сервисов на число хостов.  Если, к примеру, значение равно четырём то Nagios добавит в расписание проверку сервиса первого хоста, затем пропустит описания трёх сервисов и после этого добавит в расписание проверку четвёртого сервиса (итого в расписании пока присутствуют проверки для двух сервисов). Процесс добавления проверок в расписание закончится, когда все проверки будут внесены. По сравнению с предыдущим примером изменится порядок, в котором проверки будут выполняться. Рисунок 2 иллюстрирует сказанное.  
 

Рис. 2. Изменение порядка проверок.

   Параметр “max_concurrent_checks” задаёт число проверок, которые могут проводиться в конкретный момент времени. При достижении этого числа новые проверки производиться не будут до тех пора, пока одна из уже запущенных не завершится. Изменяя значение этого параметра можно регулировать потребление Nagios системных ресурсов, однако стоит учитывать, что при недостаточном числе разрешённых проверок те, что не смогут быть запущены будут перенесены на более позднее время, что снизит оперативность системы.

   Даже если для проверки задано расписание, на практике её выполнение происходит с некоторой задержкой. Это связано с тем, что другие операции, такие как журналирование, обработка внешних команд, обработка очереди входных данных имеют более высокий приоритет по сравнению с выполнением проверок. С обработкой очереди входных данных, куда поступают результаты проверок, связан параметр “service_reaper_frequency”. Он задаёт частоту в секундах, с которой Nagios будет обрабатывать результат очередной проверки.  Так что даже если проверка уже вернула результат, он будет обработан только после того как истечёт очередной интервал ожидания между обработками значений очереди входных данных. При этом расписание следующей проверки этого сервиса будет назначено в соответствии с тем, когда она была запланирована в прошлый раз и какова величина интервала между проверками, т.е. фактически вне зависимости от того, когда проверка была в действительности выполнена.

   Для каждого сервиса требуется задавать два интервала между проверками: “normal_check_interval” и “retry_check_interval”. Первое значение актуально, когда проверка сервиса проходит удачно и повторяется через этот заданный промежуток времени. Когда же результат проверки сервиса становится отличен от “OK”, сервис переходит в “soft state” и последующие проверки выполняются с интервалом retry_check_interval”. Для каждого сервиса определено число попыток повторных проверок. Если по истечении числа попыток результат проверки сервиса всё ещё не вернулся в состояние “OK”, сервис переходит в “hard state”, генерируются уведомления и последующие проверки вновь производятся с интервалом “normal_check_interval”.

• Обработка событий

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

• Локализация неисправностей 

   Информация о хостах, задаваемая в конфигурационных файлах при добавлении хоста в мониторинг, позволяет Nagios построить топологию сети. При этом различаются два типа узлов. Локальными считаются те хосты (узлы), к которым Nagios может обратиться непосредственно без посредников. Иными словами, это узлы, находящиеся в той же подсети что и сервер мониторинга. Удалёнными считаются узлы, находящиеся в других сетевых сегментах. Более того, хосты различаются по степени удалённости от сервера мониторинга. Эта разница в числе промежуточных узлов, отделяющих удалённый хост от сервера мониторинга. Для описания иерархии в файле hosts.conf существует параметр “parent” в котором для удалённых хостов указывается имя ближайшего к нему промежуточного узла (их может быть и несколько).

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

   При возникновении серьёзных проблем в сети, начинает действовать механизм локализации неисправностей. Nagios выявляет потенциальные источники проблем в сети. Ими предположительно объявляются хосты, находящиеся в состоянии “DOWN” или “UNREACHABLE” при условии, что хотя бы один из непосредственных родительских хостов доступен. Окончательно заключение о том, что проблемный хост является причиной неполадок в сети делается в случае, если все дочерние хосты проверяемого хоста недоступны и у них нет других родительских хостов, которые находились бы в состоянии “OK”.

Заключение

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

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

В статье не были рассмотрены такие возможности системы как кластерный мониторинг, возможности по интеграции с другим программным обеспечением (Net-SNMP, RRDTool).