Пару заметок по поводу апгрейда nagios в пределах ветки. Мануал здесь:
http://nagios.sourceforge.net/docs/3_0/upgrading.html#nagios3x
По порядку:
Меняем юзера, при этом не забываем что если мы уже скачали дистрибутив куда-то под рутом – то прав у нас на работу в директории может не быть. так что качаем тарболл под пользователем nagios:
Продолжить чтение →
Если мы после установки nagiosql поймали в админке ошибку при попытке перезапустить nagios, значит надо поправить пути и права доступа.
Ошибки могут выглядеть так:
Сервис Nagios не запущен, не могу отправить команду перезапуска!
Nagios daemon is not running, cannot send restart command!
Сбой перезапуска - не найден командный файл Nagios, либо нет прав на исполнение.В продолжение темы о мониторинге Windows серверов. Мониторим состояние сервиса на Windows машине.
Ставим NSClient++ на машину которую хотим мониторить. Настраиваем (см. мои статьи о настройке NSClient++).
Продолжить чтение →
Странная задача, но иногда возникает – изменить имя отправителя уведомлений от Nagios. Обычно уведомления приходят с адреса вида user@host, то есть, обычно nagios@servername.com
Чтобы изменить имя отправителя уведомления Nagios вносим изменения в определения notify-host-by-email, notify-service-by-email и подобные. В конец строки добавляем
-- -f your@address.com
Получаем что-то вроде такого:
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ -- -f your@address.com
Теперь в поле «от кого» будет заданный вами адрес.
Для того чтобы гибко управлять порядком проверок Nagios, есть возможность определять зависимости между проверками. Для чего это нужно? Например, мы мониторим состояние служб и хостов за пределами нашей сети, nagios работает на машине во внутренней сети и маршрутизируемого адреса не имеет. Теперь представим ситуацию когда наш шлюз упал и nagios пытается провести прверку удалённого хоста. Проверка звершается ошибкой, хост помечается как DOWN и, после того как сеть восстановлена администратор получает уведомление о том что внешний сервер якобы упал.
Вот для того чтобы этого не происходило (помимо грамотного планирования топологии проверок) есть взможность определить зависимости проверок внешних хостов от состояния шлюза (в нашй ситуации).
Продолжить чтение →
Периодически получали ошибку Service Check Timed Out при проверке Вин машины через NRPE (NSClient++). На хосте выполнялся скрипт проверки, выполнялся в течение, примерно 2-3 минут.
В логах примерно такое:
SERVICE ALERT: TASK;name_of_the_task;CRITICAL;HARD;3;(Service Check Timed Out)Пытались изменить время проверки ключом -t:
$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 600
Результата не было. С настройками NSClient++ особо не игрались, но на проверяемой машине висели процессы в состоянии FIN_WAIT.
В результате наткнулся в сети на описание переменной в конфиге nagios:
Format: service_check_timeout=seconds
Example: service_check_timeout=60This is the maximum number of seconds that Nagios will allow service checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned. A timeout error will also be logged.
There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each service check normally finishes executing within this time limit. If a service check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
Увеличиваем значение переменной для решения проблемы с таймаутом.
Если мы настраиваем Nagios к примеру через Nagiosql и получили после конфигурирования уведомлений ошибку типа:
Error: Contact 'nagiosadmin' has no service notification commands defined!
Error: Contact 'nagiosadmin' has no host notification commands defined!значит мы не определили команду проверки для сервисов и хостов.
Уведомления -> Данные контактов -> Выбираем контакт -> Изменить -> И смотрим:
Команда уведомления, хосты*
Команда уведомления, сервисы*
Обязательно надо прописать команду уведомления и для хостов и для сервисов, или поотключать соответствующую проверку.
Если мы получаем предупреждение:
Warning: Contact 'nagiosadmin' has no service notification time period defined!
Warning: Contact 'nagiosadmin' has no host notification time period defined!Значит мы не задали там же период проверки (и для хостов и для сервисов!).
После настройки клиента – unix машины с NRPE поймал стандартную ошибку после проверки с локалхоста:
# /usr/local/nagios/libexec/check_nrpe -H localhost
CHECK_NRPE: Error - Could not complete SSL handshake.Сачала готовим машину, которую мы хотим проверять. Ставим на неё NSClient++ и правим конфиг NSC.ini. Раскомментируем модуль:
CheckExternalScripts.dll
Опция use_file=1 нужна для того, чтобы NSClient++ хранил свои параметры в NSC.ini.
Если мы хотм передавать аргументы комманд передвая их с сервера Nagios – то раскомментируем строку – allow_arguments=1.
Но как правило лучше не разрешать передавать аргументы, а настраивать алиас комманды здесь же в конфиге. В дефолтном конфиге уже есть блок готовых прверок с алиасами:
[External Alias]
alias_cpu=checkCPU warn=80 crit=90 time=5m time=1m time=30s
alias_cpu_ex=checkCPU warn=$ARG1$ crit=$ARG2$ time=5m time=1m time=30s
alias_disk=CheckDriveSize MinWarn=10% MinCrit=5% CheckAll FilterType=FIXED
alias_service=checkServiceState CheckAll
alias_process=checkProcState $ARG1$=started
alias_mem=checkMem MaxWarn=80% MaxCrit=90% ShowAll type=physical
....Для внешних комманд – создаём скрипт (батник, vbs и т.д.) и кладем в папку C:\program Files\NSClient++\scripts
Далее задаём алиас по которому будем вызывать скрипт:
[External Scripts]
check_test=scripts\check_ok.batИтак, с конфигурированием прверяемой машины закончили. Идём на прверяющий сервер c Nagios.
Запускаем проверку:
#/usr/local/nagios/libexec/check_nrpe -H 10.0.0.14
I (0.3.8.75 2010-05-27) seem to be doing fine...Или так (запускаем тест):
/usr/local/nagios/libexec/check_nrpe -H 10.0.0.14 check_nrpe -c check_ok
Everythingisfine!Если что-то не так – смотрим лог на провереяемой машине – лежит в папке C:\program Files\NSClient++
Важно! Не забываем перезапускать сервис NSCLient++ на windows машине после каждого внесённого изменения в NSC.ini!
Если пользуемся nagiosql – сначала добавлем опреление команды в: Команды -> Определения (там определяем общий шаблон команды check_nrpe), а потом добавляем сервис в: Наблюдение -> Сервисы (задаём аргументы команды check_nrpe: $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ собствнно в поле $ARG1$ задаем атрибут команды (проверку определённую в NSC.ini – например alias_disk).
Итак, в предыдущей статье мы настроили механизм монитроинга unix машин с помощью NRPE. Осталось настроить хосты и сервисы, чтобы Nagios мог собирать с клиентов результаты проверок.
Для мониторинга unix машин можно использовать snmp, NRPE и ssh. NRPE расшифровывается как Nagios Remote Plugin Executor. Соответвенно модули check_snmp, check_nrpe, check_by_ssh. SNMP плох тем что если в MIB дереве нет нужной ветки – получаем затруднения. Два последних – позволяют выполнять проверки по сути на стороне проверяемой машины. NRPE имеет преимущество в том что позволяет отключить ssh и увеличить производительность.
Задача – настроить мониторинг windows серверов с помощью nagios. Будем использовать самый простой метод – поставим на windows машину клиент NSClient++
Качаем клиент здесь – http://www.nsclient.org/nscp/downloads
Устанавливаем, во время установки выбираем все модули, задаём айпи с которого nagios может обращаться к этой windows машине. Задаём пароль. Все эти настройки потом можно изменить в файле C:\Program Files\NSClient++\NSC.ini
Смотрим состояние сервиса nsclient если запущен, идём настраивать nagios. Если настраиваем с помощью nagiosql – идём в: Команды -> Определения и выбираем настройки команды check_nt.
В строку:
$USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$
Добавляем пароль с ключом -s:
$USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -s pass0rD -v $ARG1$ $ARG2$
Записываем конфиг. Перезагружаем nagios.
Вообще check_nt определяется в конфиге commands.cfg и если мы изменили пароль прямо в конфиге, но при этом используем nagiosql – импортировать сделанное нами изменение в базу nagiosql можно через импорт – nagiosql -> Дополнительно -> Импорт и выбираем конфиг commands.cfg. Всё изменённый пароль запишется в базу.
Теперь все проверки check_nt будут использовать заданный пароль.
Помле этого можно добавлять проверки, и через некоторе время получим состояние заданных сервисов windows машины.
Настраивать nagios руками, особенно если серверов достаточно много – занятие весьма утомительное. Поэтому для управления nagios есть вебинтерфейс – nagiosql.
Для понимания суть работы nagiosql следующая. Все настройки он хранит в базе и на их основе генерит файлы конфигурации нагиос. Сгенерированные файлы nagiosql раскладывает по директориям nagios. Куда складывать конфиги мы прописыввем в настройках «домена» nagiosql (эти данные храняться в базе в таблице tbl_domain). nagiosql может работать с несколькими экземплярами nagios – «доменами», по дефолту у нас один «домен» – localhost.