Icinga/Nagios распределеный мониторинг

Автор: Сергей Кулешов

Создано 29.12.2015 11:36

Icinga или Nagios может быть сконфигурирована с поддержкой распределенного мониторинга сетевых ресурсов и услуг, оно же Distributed Monitoring

Цель в распределенной среде мониторинга - это разгрузить сервер (использование процессора и т. д.), который исполненяет служебные проверки. Большинство малых и средних контор не будут иметь реальную потребность в создании такой среды. Тем не менее, если вы хотите мониторить тысячи хостов данная схема становится весьма перспективной.

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

Функция распределенных серверов (воркеров) — выполнять активные проверки хостов и сервисов. На воркерах обычно устанавливается «голый» Icinga/Nagios. Т.е. он не должен иметь веб-интерфейса, не должен отправлять уведомления, не должен выполнять сценарии обработки событий, и не должен выполнять что-нибудь другое, кроме как выполнять сервисные проверки.

Цель центрального сервера (мастера) - просто принимать результаты проверок с воркеров. Поскольку центральный сервер получает результаты проверок из одного или более воркеров, то он служит в качестве координационного центра для всей логики мониторинга (т.е. он посылает уведомления, запускает скрипты обработчиков событий, имеет веб-интерфейс, и т.д. ).

Для того, чтобы передать результаты активных проверок пассивным проверкам на мастере, используется NSCA аддон. Аддон состоит из двух частей. Первым из них является программа-клиент (send_nsca), которая запускается с удаленного хоста и будет использоваться для отправки результатов служебной проверки на другой сервер. Вторая часть является NSCA демон (NSCA). После получения информации от клиента, демон заполняет информацию о проверках в Icinga на центральном сервере(мастере), вставив команду PROCESS_SVC_CHECK_RESULT во внешний файл external command file, наряду с результатами проверки.

Т.е схема работы основывается на:

  • Воркер серверы и включенный механизм OBSESSIVE COMPULSIVE PROCESSOR для сбора данных во временный файл.

  • Обвязка для передачи данных, собранных в предыдущем пункте, команде nsca client.

  • send-nsca + nsca_server.

  • external command processing на стороне мастер сервера.

  • freshness механизм на стороне мастер сервера.

Общий механизм потока данных в распределенной инсталляции:

 Разберем всё это добро подробнее.

1. OBSESSIVE COMPULSIVE PROCESSOR (сбор результатов проверок)

Данный механизм заставляет процесс nagios выполнять определенный скрипт после выполнения каждой проверки хоста или сервиса. Для его работы в конфигурации воркеров указано:

obsess_over_services=1

ocsp_command=submit_service_result

obsess_over_hosts=1

ochp_command=submit_host_result

Команды submit_service_result и submit_host_result скидывают информацию по определенному шаблону в файлы passive_service_event.log, passive_host_event.log.

define command {

command_name submit_service_result

command_line $USER1$/submit_service_result $SERVICESTATEID$ $HOSTNAME$ '$SERVICEDESC$' '$SERVICEOUTPUT$'

}

define command {

command_name submit_host_result

command_line $USER1$/submit_host_result $HOSTSTATEID$ $HOSTNAME$ '$HOSTOUTPUT$'

}

# cat /usr/local/libexec/nagios/submit_host_result
#!/bin/sh

echo -e "$2\t$1\t$3" >> /tmp/passive_host_event.log
exit 0
[root@std /usr/local/etc/nagios]# cat /usr/local/libexec/nagios/submit_service_result
#!/bin/sh

echo -e "$2\t$3\t$1\t$4" >> /tmp/passive_service_event.log
exit 0

На этом работа механизма закончена, данные готовы для отправки на мастер ноды.

2. Передача данных с воркеров на мастер сервер

Для передачи временных файлов со статусной информацией без перебоев чаще чем запуск по cron (несколько раз в минуту через равные интервалы), написано два простых скрипта-враппера для вызова send-nsca.

# cat /usr/local/etc/nagios/send_service_result.cfg

CMD="/usr/local/sbin/send_nsca"

CFG="/usr/local/etc/nagios/send_nsca.cfg"

PASSIVEHOST="10.10.10.20"

PORT="5667"

LOG="/var/spool/nagios/send_service_nsca.log"

OFTEN="4"

TMPSEND="/tmp/passive_service_event.log.$$"

TMPREC="/tmp/passive_service_event.log"

NSCATIME="60"

 

# cat /usr/local/sbin/send_service_result

#!/bin/sh

. /usr/local/etc/nagios/send_service_result.cfg

TIMESLICE=`expr 60 / ${OFTEN}`

SLEEP=1

TIMEOUT=`expr ${TIMESLICE} - ${SLEEP} \* 3`

j=0

echo . >> ${LOG}

echo "start at `date`" >> ${LOG}

echo slice = ${TIMESLICE}, timeout = ${TIMEOUT} >> ${LOG}

for i in `jot ${OFTEN}`; do

        if [ -f ${TMPREC} ]; then

            mv -v ${TMPREC} ${TMPSEND} >> ${LOG}

            for HOST in $PASSIVEHOST

            do

                echo sending to ${HOST} >> ${LOG}

                cat ${TMPSEND} | lockf -t0 -s /tmp/service_send_nsca.${HOST} ${CMD} -H ${HOST} -to ${TIMEOUT} -c ${CFG} >> ${LOG} &

            done

            sleep 1

            echo -n waiting >> ${LOG}

            j=0

            while [ `ls -1 /tmp/service_send_nsca.* 2>/dev/null|wc -l` -gt 0 ]

            do

                echo -n . >> ${LOG}

                sleep 1

                j=`expr $j + 1`

            done

            echo sended! >> ${LOG}

            rm ${TMPSEND}

        else

            echo "${TMPREC} not exist!" >> ${LOG}

        fi

        if [ $i -lt ${OFTEN} ]

        then

            NEEDSLEEP=`expr ${TIMEOUT} - $j + ${SLEEP}`

            echo need to sleep ${NEEDSLEEP} seconds, sleeping. >> ${LOG}

            sleep ${NEEDSLEEP}

        fi

done

echo "end at `date`" >> ${LOG}

 

# cat /usr/local/etc/nagios/send_host_result.cfg

CMD="/usr/local/sbin/send_nsca"

CFG="/usr/local/etc/nagios/send_nsca.cfg"

PASSIVEHOST="10.10.10.20"

PORT="5667"

LOG="/var/spool/nagios/send_host_nsca.log"

OFTEN="4"

TMPSEND="/tmp/passive_host_event.log.$$"

TMPREC="/tmp/passive_host_event.log"

NSCATIME="60"

 

# cat /usr/local/sbin/send_host_result

#!/bin/sh

. /usr/local/etc/nagios/send_host_result.cfg 

SLEEP=`expr 60 / ${OFTEN}` 

for i in `jot ${OFTEN}`; do

        if [ -f ${TMPREC} ]; then

        mv -v ${TMPREC} ${TMPSEND} >> ${LOG}

        for HOST in $PASSIVEHOST

        do

            cat ${TMPSEND} | ${CMD} -H ${HOST} -c ${CFG} >> ${LOG}

        done

        rm ${TMPSEND}

        else

            echo "${TMPREC} not exist!" >> ${LOG}

        fi

        if [ $i -lt ${OFTEN} ]

        then

            sleep ${SLEEP}

        fi

done

echo "end at `date`" >> ${LOG}

Запускаются по cron-у

* * * * * /usr/bin/lockf -t0 -s /tmp/send_service_result.lock /usr/local/sbin/send_service_result

* * * * * /usr/bin/lockf -t0 -s /tmp/send_host_result.lock /usr/local/sbin/send_host_result

Скрипт отправляет имеющиеся данные каждые 15 секунд (параметр OFTEN="4" указывает на количество отправок в минуту).

3. send-nsca + nsca server

Результатом работы вышеописанного скрипта является вызов send-nsca на воркере и передача данных по TCP на порт 5667 на мастер сервере. 

4. external command processing на стороне мастер сервера

nsca сервер, принявший очередную порцию данных с воркера пересылает информацию в pipe файл, открытый процессом nagios на мастер сервере

command_file=/var/spool/nagios/rw/nagios.cmd #файл в который будут записываться команды

Внешние команды, которые записываются в файл команд имеют следующий формат:

[time] command_id;command_arguments, где time это время (timestamp) в которое внешняя программа добавила команду в список команд.

Для работы так же необходимо иметь включенным на мастере

check_external_commands=1

command_check_interval=-1

external_command_buffer_slots=4096

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

После появления в pipe строки с командой, при ее успешном распознавании, данные поступают на обработку.

Следует заметить, что классический фронтенд nagios3/icinga1 использует этот же механизм для обратной связи (acknowledges, downtimes, notes, etc).

5. Freshness механизм

Нужен для выявления проблем в передаче данных с воркеров на мастер, в крайнем случае это может быть отказ воркера.

Для каждого из темплейтов хостов и сервисов указывается порог свежести (в секундах) в течение которого мы должны получить данные о проверке с воркера. По истечении этого порога мастер сервер запускает проверку самостоятельно, но т.к. мастер не должен делать активных проверок и у него нет доступа в сети проверяемых хостов, мастер выполняет проверку check_dummy с выводом результата UNKNOWN - No data from worker.

Настройки, необходимые в шаблонах:

check_freshness 1

freshness_threshold 240 ; 4 min

Время складывается из normal_check_interval * 2 + некоторая дельта (в среднем normal_check_interval / 2). Шедулер на воркерах, особенно загруженных, не всегда может выполнить проверку в указанное окно. Загрузка воркера должна отслеживаться. Если нагрузка повышается, то надо планировать разгрузку ноды. 

 

Обновлено 06.04.2016 21:52

unix-way