Распределенного мониторинг: данные и actions!

[titov]

Стоит zabbix 1.8.1, Настроен распределенный мониторинг.
Данные между нодами ходят более-менее нормально (иногда есть провалы, совершенно непонятные, лечится перезагрузкой zabbix-server).
Тоже было и в 1.6.8, с чем это связано?
База везде mysql

Плюс проблема с отправкой писем по тригерам в action на главной ноде по событиям в дочерних.

Почему-то в 1.6.8 если информация в главной ноде есть от дочерних, то action отправки писем (настроенные только в главной ноде) отрабатывает по тригеру, и письма отправляются.
А в 1.8.1 не работает.
В каждой ноде нужно делать свой экшн, а иначе никак, письма отправляются только по событиям той ноды, в которой создан action.
Это баг какой-то? или так задумано?
Если задумано, то зачем нужен фильтр по нодам в conditions?

[solo]

Стоит zabbix 1.8.1, Настроен распределенный мониторинг.

Плюс проблема с отправкой писем по тригерам в action на главной ноде по событиям в дочерних.

Почему-то в 1.6.8 если информация в главной ноде есть от дочерних, то action отправки писем (настроенные только в главной ноде) отрабатывает по тригеру, и письма отправляются.
А в 1.8.1 не работает.
В каждой ноде нужно делать свой экшн, а иначе никак, письма отправляются только по событиям той ноды, в которой создан action.
Это баг какой-то? или так задумано?
Если задумано, то зачем нужен фильтр по нодам в conditions?

Зачем нужен фильтр, не скажу. Но по результатам раскопок у меня сложилось впечатление что в 1.8.[0-2] мастер нода вообще не может обрабатывать данные дочерних... Хотя она их и хранит.

Подход к снаряду с напильником показал что:

1. Для триггеров данная ситуация вообще не лечится (в структуру БД упёрся).
2. Для вычисляемых данных решение есть -- синтаксис указания ключа вполне расширяем
   с [<имя_хоста>:]<ключ>
   до [[<имя_ноды>:]<имя_хоста>:]<ключ>.
   (см. ZBXNEXT-451 и I: Zabbix: Патч для обращения к данным дочерний ноды).

[ruswold]

Зачем нужен фильтр, не скажу. Но по результатам раскопок у меня сложилось впечатление что в 1.8.[0-2] мастер нода вообще не может обрабатывать данные дочерних... Хотя она их и хранит.

Подход к снаряду с напильником показал что:

1. Для триггеров данная ситуация вообще не лечится (в структуру БД упёрся).
2. Для вычисляемых данных решение есть -- синтаксис указания ключа вполне расширяем
   с [<имя_хоста>:]<ключ>
   до [[<имя_ноды>:]<имя_хоста>:]<ключ>.
   (см. zbxnext-451 и i: Zabbix: Патч для обращения к данным дочерний ноды).

Подтверждаю, с 1.8.2 аналогичная ситуция.
1. Приходилось создавать дублирующие действия
2. тоже самое с шаблонами через экспорт-импорт.
3. ИТ услуги не понимали триггеры с других нод
4. Пришлось дублировать пользователей.
5. Веб мониторинг созданный в мастер ноде для дочерней не распространялся на дочернюю, хотя должен быть
6 и тд, не то что ожидал во-общем

В общем устал и из дочерней ноды сделал прокси.