Nagios установка и настройка сервера мониторинга
Настройку начинаем на машине, которая будет выполнять роль nagios сервера. Установим необходимые пакеты:
yum install -y wget httpd php gcc glibc glibc-common gd gd-devel make net-snmp unzip
nagios работает через Apache, поэтому в списке устанавливаемых пакетов присутствует httpd
Переходим в корневой каталог с временными файлами и скачиваем в него при помощи wget последние релизы nagios и nagios-plugins
Создаем системных пользователя и группу
Добавляем пользователя nagios в группу nagcmd
usermod -a -G nagios,nagcmd apache
Поскольку используем CentOS httpd работает не от имени пользователя www-data, а от имени пользователя apache
Чтобы в дальнейшем не возникло конфликтов прав добавляем пользователя apache в группы nagios,nagcmd
Извлекаем содержимое скачанного архива
Переходим в каталог с файлами nagios
Установку как nagios, так и nrpe в дальнейшем будем производить из исходников
В качестве опции при сборке указываем группу nagcmd
Рекурсивно копируем каталог с библиотеками в /usr/local на сервере
cp -R contrib/eventhandlers /usr/local/nagios/libexec
Также рекурсивно меняем владельца и группу владельца каталогов и файлов на nagios
chown -R nagios:nagios /usr/local/nagios/libexec/eventhandlers
Пробуем запустить и посмотреть версию nagios указывая путь к основному конфигурационному файлу
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Добавляем nagios в автозагрузку — система будет каждый раз запускать его при старте
Аналогичные операции проделываем с веб-сервером
Задаем пароль пользователя nagios
При помощи htpasswd генерируем файл, который будет ограничивать доступ для пользователя nagiosadmin
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Установка основного пакета на этом завершена. Открываем интернет браузер и вводим в поисковую строку ip-адрес сервера, затем /nagios и попадаем в веб-интерфейс
Настройка мониторинга сервиса на удаленном хосте
Идем на другую серверную машину, которая будет выполнять роль nagios-клиента
Переходим в каталог /tmp/
Компилируем указывая пользователя и группу nagios
./configure —with-command-user=nagios —with-nagios-group=nagios
Теперь устанавливаем nrpe plugin
Сначала дополнительно ставим из репозитория openssl-devel, если он уже установлен — шаг пропускаем (необходимо также присутствие пакета и на nagios сервере)
Можно установить и из репозитория
yum install nagios-plagins-all nagios-plagins-nrpe
Если нужна свежая версия, что так
Скачиваем пакет
Компилируем тем же способом, что и ранее
Идем на сервер nagios
Пробуем подключиться с сервера указывая после ключа -H IP адрес клиента
/usr/local/nagios/libexec/check_nrpe -H 10.11.27.44
Получаем connection refused и отправляемся производить конфигурацию плагина
Стартуем nrpe на клиенте и добавляем сервис в автозагрузку
Открываем основной конфигурационный файл и в качестве значения в секции allowed_hosts указываем IP адрес сервера
Возвращаемся на сервер
/usr/local/nagios/libexec/check_nrpe -H 10.11.27.44
Теперь наша попытка успешна и мы видим версию nagios
Снова открываем основной конфиг
Снимаем знак комментария со строки с cfg_dir (cfg_dir=/usr/local/nagios/etc/servers)
Создаем директорию и переходим в нее
Определяем хосты, мониторинг которых будет производиться. У хостов могут быть любые названия, nagios увидит все файлы с расширением cfg
Прописываем параметры хоста, значения директив понятно из названия. Этих директив может быть значительно больше в случае необходимости тонких настроек мониторинга, здесь рассматираем базовую рабочую конфигурацию
define host <
use linux-server
host_name cenos11
alias just nagios client
address 10.11.27.44
max_check_attempts 5
check_period 24×7
notification_interval 30
notification_period 24×7
Добавляем конфиг для сервиса, который мониторим. Сейчас ограничимся проверкой наличия пинга до хоста
<
use generic-service
host_name cenos11
service_description PING
check_command check_ping!100.0,20%!500.0,50%
>
Использована команда check_command, выдержка из мануала относительно нее говорит следующее:
check_ping -H -w ,% -c ,%
[-p packets] [-t timeout] [-4|-6]
Соответственно, при потере 20% пакетов мы будем получать предупреждение, при потере 50% — ALERT
Снова запускаем и убеждаемся в том, что ошибок нет
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Идем в веб-интерфейс и видим, что там отображается сервис на удаленном хосте, который мы мониторим (в конфигурации, приведенной на скриншоте, настроен мониторинг еще ряда ресурсов ). Настройка сервера мониторинга с базовым функционалом завершена.
Настройка ALERT-ов в nagios
Открываем основной конфигурационный файл и при необходимости раскомментируем строку cfg_file=/usr/local/nagios/etc/objects/contacts.cfg:
В файле определяем контактный адрес электронной почты для отправки уведомлений:
define contact <
contact_name nagiosadmin
use generic-contact
alias Nagios Admin
email valdes101@example.ru
Также может использоваться дополнительное программное обеспечение с помощью которого могут отправляться, например, SMS-сообщения с ALERT-ами касающимися принципиально важных сервисов. Получен рабочий сервер Nagios, установка и настройка на этом завершены.
Для серверов можно устанавливать Nagios сервер и клиент на одной машине, однако намного проще использовать другой пакет — например, Monitorix.
Nagios — система мониторинга и некоторые самодельные плагины
Когда я выбирал системы мониторинга, я сравнивал кактус, нагиос и забикс. И выбрал нагиос. Сейчас моей истории мониторинга уже десяток лет, накопилось самописных решений, аналоги части из которых можно найти в интернете, а части и нет. Поэтому решил собрать всё в одно место, пусть лежит. Если вы сами плотно много лет используете нагиос, то вряд ли найдёте здесь какие-нибудь откровения, но в копилку может что и пригодится. А для начинающих может оказаться полезно.
Итак, поехали. Пара говорок — я описываю мониторинг со стороны nagios, поэтому как и что настраивать на серверах, которые надо мониторить — упоминаю в общем виде. И второе — я не люблю имена mibs, стараюсь использовать oid, циферки. Если по ним искать в гугле, то вы найдёте и их имена, и соседние мибы. Собственно, знать нужный oid — это 2/3 дела в случае snmp-мониторинга.
В качестве языка программирования в данном случае я предпочитаю perl — его проще отлаживать и переносить между платформами.
Я обязательно буду приводить примеры плагинов (иначе для чего бы я эту статью затеял), в том числе может быть стандартных, потому что уже не помню, что шло в комплекте, что искалось с миру по нитке и допиливалось. Помню лишь, что писал сам с нуля, там мои копирайты стоят.
Для самостоятельного осмотра дерева oid рекомендую стандартную утилиту snmpwalk. Сам нагиос у меня а) версии 3.x, б) установлен на FreeBSD, поэтому пути часто будут типичные для Free и нетипичные для linux.
Мониторинг windows-серверов
Используем банальный встроенный snmp (который есть в windows-серверах начиная с windows 2000). Сервис этот по-умолчанию не стоит, его надо добавить, настроить community name (snmp пароль) и ip адреса, с которых можно обращаться к сервису (по-умолчанию пароль public и разрешен только локальный ip). Описание windows mibs можно легко найти в инете.
Стандартный плагин check_disk_snmp.pl позволяет мониторить диски по имени (что важно, потому что порядок дисков в дереве snmp может менять после перезагрузки; если мы говорим именно о сервере, который перезагружают 1-2 раза в год; за это время у него может нарасти слой «внешних» — fibrechannel или iscsi — дисков. Буквы у них сохраняться после перезагрузки, а вот порядок в дереве snmp — не факт). А так же он позволяет мониторить состояние ОЗУ — свободно, занято, swap.
Стандартный плагин check_snmp_load.pl позволяет мониторить нагрузку cpu на сервере, а стандартные же плагины check_tcp и check_udp — доступность сетевых портов. Ибо для чего еще нужен сервер, как не для обслуживания сетевых запросов!
Описание стандартных oid, на которые отзывается windows доступно здесь. Там есть и CPU, и ОЗУ, и устройства хранения данных (в том числе по типу — CDROM, Floppy, HDD), запущенные процессы и установленные программы.
Мониторинг unix-серверов
Тут тоже всё просто. Устанавливаете на сервере пакет net-snmp, настраиваете snmpd.conf. В последних версиях там ад и хаос, я предпочитаю (вот такой я консерватор)
без всякого новомодного ужаса, но это на любителя. Перезапускаете snmpd и извольте мониторить.
Вышепомянутый check_disk_snmp.pl умеет мониторить и unix-сервера. Плюс есть альтернатива — плагин check_snmp_storage.pl. У меня исторически сложилось так, что windows-сервера мониторятся через check_disk_snmp.pl, а unix-сервера — через check_snmp_storage.pl. Он использует ту же 25 ветку oid и тоже позволяет мониторить дисковые разделы по имени (точке монтирования). Потому что всем, кроме админа самого сервера, совершенно не интересно, что именно у него прицеплено в точку /data, или /var, или /opt, или /mnt/disk0101019084. Важно — сколько там места всего, сколько занято, сколько свободно.
Вышеупомянутый же check_snmp_load.pl умеет мониторить cpu на unix-серверах, check_tpc и check_udp — доступность сетевых портов.
Кроме того, у нагиоса есть полезный плагин check_by_ssh. Суть его в том, что он устанавливает ssh-соединение с хостом и запускает там заданную программу. Программа должна отвечать в формате nagios (код завершения 0 — успешно, 1 — warning, 2 — critical, 3 — unknown) и может выполнять любые угодные вам (и админу того сервера) проверки.
На почтовых серверах бывает полезно мониторить состояние почтовой очереди. Для этого можно использовать check_by_ssh, но так исторически сложилось, что я использую расширение snmp (напоминаю, у меня старая, обросшая ракушками система мониторинга — но это и хорошо, можно на живых примерах показать разные способы получить один и тот же результат). Плюс подхода «без ssh» очевиден — сервер мониторинга не имеет возможности подключиться к исследуемому серверу по ssh и не создает дырку в безопасности.
Итак, расширяем snmp. На исследуемом сервер в snmpd.conf пишем строчку вида extend mailq /root/getmailq.sh , где extend — команда, mailq — название ветки,
На сервере мониторинга
Собственно магия кроется в запросе NET-SNMP-EXTEND-MIB::nsExtendOutLine.\«mailq\».1 — это мы читаем, что нам отдает скрипт с наблюдаемого сервера.
Ну и стандартное для нагиоса описание команды
Это хорошая альтернатива check_by_ssh с одной оговоркой. snmpd на сервере по-умолчанию работает от рута. А check_by_ssh может работать от другого юзера, с меньшими полномочиями. Решать вам.
Теперь о dns. Очень часто мониторинг dns сводят к банальному check_udp!53. Это очень блаародно, но малоинформативно. Сервер может работать, но не разрешать имена. Сервер может работать и быть корневым для ваших имен, но регистрация вашего домена могла протухнуть. Ничего этого вы из проверки доступности порта не увидите. Поэтому пара скриптов проверки ДНС.
Первый скрипт позволяет мониторить ваш(и) домен(ы) и не проспать необходимость их продления. Даже если домен вам продлевает провайдер автоматом, проконтролировать этот факт всегда полезно.
Используется он банально
По-умолчанию 36 дней до окончания срока регистрации — warning, 10 дней — critical.
Второй скрипт служит для проверки работоспособности dns-сервера
Этот скрипт можно использовать двумя способами. Первый — проверка через ваш сервер доступность нужных вам адресов и вообще работы dns. Например, так:
Если ваш сервер резолвит google.com — то dns на нём работает. В случае, если нет доступа в инет, резолвинг не сработает, но это вы увидите по другим проверкам (пинги gateway провайдера, пинг того же 8.8.8.8).
Так же вы можете проверять, что резолвятся нужные вам внутренние имена (например, AD становится плохо, если её собственный dns не распознает имена).
Второй способ — проверка через гарантированно работающий dns ваших имен, которые должны быть доступны из интернета.
Если ответ есть — ваши имена из инета доступны (с оговоркой о доступности Интернет в данный момент для вашей системы мониторинга).
Мониторинг Netware
Да-да, я знаю, некрофилия фу, но даже сегодня у меня из примерно 200 серверов в системе есть 2 (два!) Netware. Оба в далеких ДО, настроенные в одна тыща восемьсот затертом году и с тех пор работают, работают и работают. У одного из uptime сегодня 834 дня. Это к слову. Поэтому — мониторинг.
На последней netware 6.5.8 есть snmp. Честно скажу — не знаю, не ел. С версии 4.11 для netware есть программка mrtgext.nlm, которая позволяет мониторить кучу параметров сервера. Вот её-то обычно и используют и для отрисовки статистики сервера через mrtg или rrdtool, ну и для мониторинга через нагиос она вполне годится. К тому же один из этих двух моих NW имеет версию 5.1 (гусары, молчать!).
mrtgext слушает tcp-порт 9999, поэтому не забудьте поставить его на мониторинг. Поскольку Netware — это прежде всего файловый сервер, то нам интереснее всего, что происходит с томами. Для это есть скриптик:
Он, в свою очередь, использует скрипт nwstat.pl, когда-то шедщий в комплекте mrtgext. Идет ли он сейчас — не знаю, поэтому выложу его сюда.
Использовать его легко и просто:
Для рисования статистики:
Из него понятно, как можно мониторить процессор, ОЗУ, буфера на Netware-сервере через mrtgext, если это кому-нибудь еще надо.
Мониторинг Novell (уже не, но не суть) OES
OES — это Open Enterprise Server. В основе OES лежит SUSE Linux, поэтому базовый мониторинг тут те же, что и для linux, а вот как мониторить дополнительные сервисы сейчас опишу.
Опять же на первом месте будет мониторинг томов:
Скрипт этот у меня универсальный для nagios и для mrtg, поэтому с параметром -m mrtg он выдает циферки размера (занято и всего) тома, как их ждет mrtg, а без оного или с параметром -m nagios выдает ответ, типичный для плагина nagios.
В качестве параметров он принимает имя или ip сервера и имя тома. Тома ищутся в списке смонтированных, точки монтирования .pools/ИМЯТОМА (технические для OES) игнорируются. Если том не найден, возвращается размер 0 и ситуация CRITICAL (у нас много «внешних» — fc или iscsi — томов и надо ловить случаи их отпадения).
По-умолчанию анализируется том SYS (тяжкое наследие Netware, есть у каждого OES-сервера, но совершенно не нужен и не интересен).
Используется в nagios обычным образом
Теперь о сервисе печати. Принтеры можно мониторить самостоятельно, но если у вас iPrint, то интересно мониторить принтеры «с точки зрения сервера». И для этого есть скриптик:
Скрипт не мой, но чертовски полезный. В нагиос его можно использовать так:
Когда принтеров у вас несколько десятков (у меня их ближе к сотне), вести такой список непросто, но зато вы сразу видите, где кончилась бумага или картридж, какой принтер уже 40+ дней отключен (у нас 40 дней отключения — порог на снятие принтера) или стоит много дней без бумаги или картриджа. Польза есть.
Фух, много получилось. Пока остановлюсь. Если статья понравится, будет вторая часть — про мониторинг ИБП, Synology, vmware и принтеров, но уже как принтеров, а не как объектов iPrint.