Nagios

Основной процесс Nagios опирается на объектно-ориентированную конфигурацию с выделением следующих сущностей:

Хосты

определяются в основном по IP-адресу,

Сервисы

свойства хоста, подлежащие мониторингу,

Команды

действия для мониторинга, оповещения или других целей,

Контакты

лица, которым отправляются уведомления при срабатывании тревоги.

Сервисом может быть как предоставляемый хостом сетевой сервис (например, HTTP, FTP, SSH), так и внутренняя характеристика (остаток свободного места, нагрузка на память или CPU, время безотказной работы, внутренние ошибки и др.), а также измеряемые аппаратно параметры среды (температура, влажность, уровень жидкости в резервуарах и пр.).

Для базовой установки Nagios необходимы сторонние компоненты:

• Apache HTTP Server c модулем PHP
• GCC и соответствующие библиотеки для сборки

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

Часть проверок реализуется на уровне сетевых протоколов (TCP, UDP, SNMP), благодаря чему поддерживается наблюдение за разнородными операционными системами, а также сетевыми и иными устройствами с подготовленным сетевым интерфейсом (например, ИБП).

Для мониторинга внутренних характеристик серверов плагины часто запускаются непосредственно на целевых хостах — через удалённый командный доступ (например, по SSH), что может привести к значительной нагрузке на CPU и требует соответствующих привилегий, что может быть рискованно с точки зрения безопасности. В качестве альтернативы предусматривается установка вспомогательных сервисов («дополнения») на хостах, запускающих безопасные локальные проверки системных метрик (типовой пример — NRPE^[3], Nagios Remote Plugin Executor, NSClient, NC_Net и др.). Передача команд и результатов между этими приложениями и сервером Nagios осуществляется через настраиваемые сетевые порты.

Менее тривиальный, но более гибкий вариант мониторинга — пассивный режим с применением расширения NSCA (Nagios Service Check Acceptor) или SNMP-трэпов (например, через фронтенд NagTrap).

Кроме стандартных и множества доступных бесплатных «Nagios-плагинов», возможно написание собственных модулей на различных языках программирования, таких как Perl, C, C++, Java, C#, Python, PHP. Требование к модулям — соблюдение стандарта Nagios для плагинов^[4]: модуль обязан выдавать POSIX-совместимый код возврата с результатом статуса (для сервера Nagios) и печатать вывод в стандартный поток вывода.

Возможные значения статуса:

• объект (сервис/хост) в порядке (OK, 0),
• предупреждение (WARNING, 1),
• критическая ошибка (CRITICAL, 2),
• не определено/неизвестно (UNKNOWN, 3).

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

Выведенная модулем информация (короткое сообщение о состоянии, расширенный текст, значения метрик) показывается в веб-интерфейсе Nagios. Метрики («performance data») могут быть записаны для долговременного анализа: многие сторонние утилиты строят графики на их основе.

При изменении статуса у сервиса или хоста и достижении заданного числа повторных проверок текущий статус считается «зафиксированным» (hard state); только после этого запускаются последующие действия:

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

Nagios извещает заданных лиц по разным каналам — email, SMS, пейджер, мгновенные сообщения^[5], телефон и т. д. Поддерживается механизм эскалации оповещений — последовательная рассылка уведомлений другим контактам при неустранённой проблеме.

Для отказоустойчивости, избыточности и защиты от ложных срабатываний Nagios поддерживает схемы распределённого (distributed) и резервного (redundant/failover) мониторинга. В режиме распределённого мониторинга несколько инстанций Nagios, развёрнутых на разных узлах, отправляют свои результаты через NSCA на центральный сервер, который учитывает их как пассивные проверки. В режиме резервного мониторинга пара Nagios-инстанций работает как узлы кластера, синхронизируя состояние через heartbeat. Помимо механизма NSCA существуют профильные расширения (Mod-Gearman, Merlin, DNX).

Nagios может быть расширен посредством различных дополнений, в том числе:

• Nmap2Nagios-NG: автоматическая генерация конфигов;
• Centreon: веб-интерфейс настройки и мониторинга;
• Nagvis: визуализация результатов мониторинга;
• monarch: (устаревшая) панель администрирования Nagios 1.x и 2.x;
• Groundwork Monitor Community Edition: панель для Nagios 2.x и 3.x (смена monarch);
• NConf: веб-интерфейс администратора для Nagios 3.x;
• NagiosQL: администрирование через веб для Nagios 2.x-4.x;
• PerfParse: обработка и хранение performance-данных;
• PNP: построение графиков по данным Nagios;
• Check MK: ускоренное SNMP‑ и мониторинг ОС;
• Nagios Business Process AddOns: мониторинг бизнес-процессов;
• NagiosGrapher: генерация графиков по performance-данным c автоподключением к веб-интерфейсу;
• NagiosEventDB: база событий (SNMP‑трэпы, syslog и др.);
• N2RRD: хранение performance-данных в RRD, просмотр — rrd2graph;
• Nagios-virt: мониторинг виртуальных машин через libvirt API;
• Thruk: расширенный веб-интерфейс для крупных и распределённых систем;
• Mod-Gearman: распределённый мониторинг.

Есть и утилиты для контроля состояния самого Nagios и генерации событий:

• Nagios-Checker: плагин для Mozilla Firefox;
• nagstamon: desktop‑монитор статуса Nagios;
• NagiosCenter: веб-приложение для наблюдения за несколькими серверами Nagios.

В мае 2009 года часть разработчиков Nagios создала форк под названием Icinga^[6]. Основные отличия: современный веб-интерфейс, новые коннекторы к БД (например, MySQL, PostgreSQL), более открытый и быстрый процесс разработки, активное сообщество.

Летом 2009 года Жан Габес начал переписывать Nagios на языке Python: этому способствовали замедление развития исходного C-кода и устаревшая архитектура. Новый проект — Shinken — строит систему мониторинга как набор независимых специализированных процессов и позволяет обслуживать куда больше целевых устройств, чем классический Nagios. В декабре 2009 года на рассылке nagios-devel Жан Габес предложил использовать Shinken как основу для будущей (4-й) версии Nagios^[7], однако этот подход вызвал споры (особенно по поводу совместимости с существующим ПО из-за смены языка). В итоге Shinken развивается как самостоятельный проект^[8].

В октябре 2013 года Андреас Эрикссон, ведущий разработчик Nagios Core 4, объявил о запуске собственного форка — Naemon (Networks, Applications and Event Monitor)^[9] после исключения из основной команды Nagios Enterprises^[10]. Как и классический Nagios, Naemon написан на C, но веб-интерфейс CGI заменён на Thruk (FastCGI/Perl). Проект распространяется под GNU GPL.

Nagios Enterprises нередко критикуют за жёсткую политику в отношении товарного знака. В ряде случаев open source‑проекты и сайты, использовавшие название Nagios, были вынуждены сменить имя под давлением правообладателя, в частности — из-за конфликтов вокруг форков Nagios.

• 23 февраля 2010: monitoring-fr.org (ранее nagios-fr.org)^[11]
• 23 мая 2012: monitoring-portal.org (ранее nagios-portal.de)^[12]
• 16 января 2014: monitoring-plugins.org (ранее nagios-plugins.org)^[13]

15 января 2014 года сайт независимого проекта Nagios-plugins был без согласования перенесён на серверы Nagios Enterprises LLC, после чего команда ушла и продолжила разработку под новым именем Monitoring-plugins на monitoring-plugins.org^[14]. Причиной названа разногласия по вопросу упоминания форков (Naemon, Icinga, Shinken) на сайте плагинов.