Это из разряда паранои. У меня на трех объектах стоит заббикс, на двух - прокси, на одном - мастер. Всё отлично. Прокси накапливают данные только если нет связи с мастером, а так отсылают практически мгновенно. Так что с триггерами всё в порядке. На дочерней ничего не срабатывает, всё происходит на мастере.

blind_oracle> Это из разряда паранои. У меня на трех объектах стоит заббикс, на двух - прокси, на одном - мастер.

И если отвалится мастер, когда админ получит уведомление?

Поддерживаю

И если отвалится мастер, когда админ получит уведомление?

blind_oracle, Во во, когда?

Ну давайте сделаем еще мастера, который будет мониторить мастер, и еще мастера, который будет мониторить того, кто мониторит... бред.

Максимум что у меня было - это заббикс выпадал в сегфолт. Это легко лечится простейшим ватчдогом на баше, который его перезапускает и шлет уведомление об этом в почту. Но это случается крайне редко.

Так что смысла городить огород не вижу.

Так что с триггерами всё в порядке. На дочерней ничего не срабатывает, всё происходит на мастере.

Вот это как раз и ситуация когда проблема есть а о ней ни чего не известно. Если бы в случае не успеха передачи данных мастеру, триггеры срабатывали на дочерних узлах. Это был бы мониторинг 99,5% времени, а так....

Да нет достаточно было бы, если мастер помер, дочерней ноде сказать об этом и триггеры которые были на ней пусть на ней и срабатывают. А то что вы предложили это действительно огород, я против )))

У меня к примеру в мастера воктунут усб-гсм свисток, который панически-слёзные смс рассылает. Как триггеры будут отрабатывать на прокси, если свисток только в мастере? Еще один туда воткнуть?

В общем если хочется 99.999..(9)% мониторинга, то это делается так:
1. Создается 2 мастера, которые мониторят всё и друг друга.
2. Каждому мастеру на удаленных объектах создаем прокси
3. На каждом сервере устанавливаем по 2 заббикс-агента на разных портах для каждого мастера\прокси.

Но для моих задач это избыточно...

Йопрст, ну настрой мониторинг мониторинга. Я так и делал для нагиоса скриптом в баше который по крону пускался. Уведомления на мобилку слал смсками слал.

конечно, этот скрипт должен запускаться с другой тачки

Это для любых задач избыточно ))

Ааааа

Скрипт который проверяет функциональность zabbix сервера, котрый находится на zabbix сервере. И если все «Ок» то ни чего не шлет, а если плохо (zabbix сервер не работает и т.п.) то шлет. + К тому сам крон шлет если скрипт вызвать не может, так ?????

крон шлёт если отсылки настроена и скрипт что-то выводит на экран.

крон шлёт если отсылки настроена и скрипт что-то выводит на экран.

Ну естественно. Я про концепцию?

По моему так логично

Как триггеры будут отрабатывать на прокси, если свисток только в мастере? Еще один туда воткнуть?

Да, и именно эт осчитаю логичным, не смог передать тревогу мастеру, сообщи о проблеме сам

ну да, всё грамотно :)

Нагиос вообще прост, как топор. Я поднял второй сервер мониторинга, который мониторит всё то же самое + мастера, оповещения отключены. На событие master critical повешено enable_notifications. Пока админ сбивает пламя с основного сервера, резервный штатно мониторит сеть и шлёт уведомления.

Сделать по готовому рецепту занимает немногим больше времени, чем придумать скрипт. И красота :)

конфиги как синкаете?

Пока rsync по крону. Можно руками, на inotify вешать смысла нет.

Надо будет delete и exclude правильно заюзать, чтобы на резервном удалялись хосты, удалённые с основного, при этом случайно не удалить master.cfg, которого на основном нет.

Поддерживаю, так и склоняюсь сделать.

единственное смущает это «который мониторит всё то же самое + мастера». Вот это не устраивает. Буду думать

Это плохо?

Как-то не очень нравится. Если бы данные реплицировались между серверами то ладно, а так двойной опрос одних и тех же параметров.

>Может надо мониторить систему мониторинга?

Ага, а потом мониторить систему мониторинга мониторинга. А потом систему мониторинга мониторинга мониторинга... Это уже паранойя какая-то.

))))))

> двойной опрос одних и тех же параметров.

http://nagios.sourceforge.net/docs/nagioscore/3/en/redundancy.html

Там два варианта: мой первый (избыточный мониторинг), тебе, видимо, нужен второй (failover). Данные реплицируй, если надо.