Не работают зависимости(1.8.4)

[swelf]

Схема такая zabbix server <--> hostA <--> Hosts(b,c,d,e).
Тригер доступупности работает на основе пинга, если simple ping дает 0 в 4 попытках подряд(попытка раз в 30 сек {host:icmpping.avg(#4)}=0 ), то тригер срабатывает. Что бы правильно работали зависимости в оповешениях, я включил ескалацию, и поставил задержку в 2 минуты(4 раза может провериться хост). В итоге у меня пропадает линк до hostA в 15:40 и на всех хостах срабатывают тригеры(судя по ивентам), а через 2 минуты приходит 5 штук нотификейшенов о том что узлы недоступны, хотя зависмости стоят. И 2х минут забиксу должно было хватить что бы понять что недоступен hostA, что бы не слать столько сообщений. Вопрос, кто виноват и что делать.

[dima_dm]

Как зависимость написали?
Написали, что триггеры Hosts(b,c,d,e) зависят от A?
Смотрите время срабатывания триггера A и всех других. Зависимость будет работать только если A сработает раньше других триггеров, поиграйте с интервалами опроса, эскалация нужна для других целей.

[swelf]

Написали, что триггеры hosts(b,c,d,e) зависят от a?

ато

поиграйте с интервалами опроса

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

эскалация нужна для других целей.

ну изначально да думаю да, но где-то читал (как бы не в документации забикса было написано) как уладить проблему зависимостей, именно о чем я говорю, ибо, как вы и сказали "Зависимость будет работать только если a сработает раньше других триггеров", а сделать это очень сложно, поэтому был описан хак с эскалацией, чтобюы к моменту когда надо отсылать нотификейшн, гарантированно все хосты были опрошены и лишние тригеры сняты с оповещения

[zalex_ua]

... поиграйте с интервалами опроса ...

и возьмите ко вниманию - последовательность опроса элементов данных с одинаковым интервалом опроса зависит от их ID, тоесть от последовательности создания.
Если же вы присоединяете шаблон к узлу сети, тогда элементы будут созданы в определенной последовательности - в алфавитом порядке по спаданию поля ключ элемента данных.
Этим можно иногда манипулировать чтобы добиться нужной и правильной работы зависимостей. Как минимум это действует в пределах одного узла сети. По поводу зависимостей от других узлов - не знаю, не исследовал как в таком случае работает опрос.

Вот здесь это немного обсуждается. И там есть мой комментарий в т.ч. и по поводу триггеров.

[swelf]

http://www.zabbix.com/wiki/howto/con..._notifications

вот тут об ескалации

Reason 2: give Zabbix enough time to evaluate trigger dependencies

никто чтоли по челдовечески не составляет зависимости?

[zalex_ua]

http://www.zabbix.com/wiki/howto/con..._notifications
вот тут об ескалации

Во первых, это не официальная документация, а вики страница, автором и редактором которой является некий Signum, я думаю вот это он.
Можете попробовать обратиться к нему.

Во вторых, попробуйте увеличить шаг эскалации до 3-4 минут ради теста, может быть где то не хватает "десятка" секунд? И чтобы понять что есть и другие (неявные) влияющие факторы, смотрите мою записку ниже.

никто чтоли по челдовечески не составляет зависимости?

пытаемся, до сих пор пытаемся ...

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

Писалось где то на версии 1.8.1 приблизительно. Кое что могло устареть. Кое-где могут быть ошибки (в т.ч. грамматические или стилистические притенении по которым я не принимаю ибо это мой личный черновик). Я хотел было это оформить красиво и опубликовать, но сейчас понимаю что уже не имею на это времени.

Как говорится используйте на свой страх и риск, но если кто найдет ошибку в моем понимании работы заббикс сервера - выслушаю с огромным удовольствием.

Поехали:
Сначала сервер получает сообщение и заносит его во внутреннюю кеш в оперативной памяти на не более чем 5 секунд (буфер скидывается в БД каждых 5 секунд).
В момент когда событие попадает в БД сразу же производится вычисление триггера, который содержит этот элемент данных.
После вычисления триггера и успешной (FAIL) проверки зависимостей он переходит из состояния 0 в состояние 1 Делается обновление его свойств value=1,lastchange=1278847098
В истории триггеров сработку видно не времени его вычисления а времени штамп времени отправки события (заданный агентом) на сервер которое вызывает этот триггер.
Сразу же потом идет проверка (вычисление следующего свободного eventid в пуле из 256 событий зарезервированных сервером) свободного eventid для таблицы events и в таблицу events записывается событие.

Потом идет простая проверка по ряду условий, по которым действия над событием не выполняются вообще. Это последовательности событий,которые по логике не есть информативными и о них вообще сообщать не нужно. Это
/* skip actions in next cases:
* (1) -any- / UNKNOWN (-any-/-any-/UNKNOWN)
* (2) FALSE / FALSE (FALSE/UNKNOWN/FALSE)
* (3) UNKNOWN/ FALSE (UNKNOWN/UNKNOWN/FALSE)
* if event->trigger_type is not TRIGGER_TYPE_MULTIPLE_TRUE:
* (4) TRUE / TRUE (TRUE/UNKNOWN/TRUE)
Здесь уже точно произошли легкие изменения. Смотрите трекер.

Если это фильтр успешно пройден, тогда сразу включается обработка действий actions. Делается выборка всех активных Действий и методом перебора проверяется каждое по Условиям не подходит ли Действие каким либо образом для недавно созданного события. Отрицательные результаты отбрасываются (Conditions do not match our event. Do not execute operations).
Найдя совпадение по условию (Conditions match our event. Execute operations) производится начало Эскалации.

Удаляются шаги эскалаций (с некоторыми статусами) из таблицы escalations для сработавшего триггера, потом обновляются шаги з некоторыми другими статусами и только затем добавляется первый шаг новой эскалации. Это делается для всех Действий, в т.ч тех у которых не включены эскалации потому что все проходит через таблицу эскалаций.
Заканчивается обработка Действий.
Что то проверяется в таблице services по данному триггеру (ИТ-услуги). У нас нет услуг вообще поэтому наверное ничего и не меняется.
Заканчивается обработка события.
Заканчивается обновление триггера.

Далее выполняется обновление тенденций (по отношению к евентлогу это не актуально).
Так как через каждых 3 секунды производится выполнение эскалаций, то вот через секунду начинает процесс выполнения нашего Действия - вычитываются все эскалации из таблицы escalations. Для найденной эскалации запрашивается куча сопутствующих данных из разных таблиц.
Начинается вычисление всех макросов для темы сообщения. End substitute_macros(result:CLONE DEBUG it2: PROBLEM | Test log)
Потом тоже самое но для тела письма.
потом если в комментариях триггера были выражения такие же как в формуле триггера - то они также вычисляются (это так просто к слову так как было замечено).

Проверяются права на узел и на триггер соответственно для пользователя которому планируется передать сообщение. Если все успешно то двигаемся далее.
Потом идет проверка метода сообщения и разрешенного времени - если успешно то переходим к выполнению этой операций (посылки сообщения). Выполняется получение последнего alerts, вычисление ИД для следующего.Выполняется вставка в таблицу alerts новой записи.
Завершение выполнения операций.
Завершение выполнения эскалаций.
Тут обновляется эскалация по разному в зависимости от того стоит ли птицы сообщения восстановления.
Завершение обработки эскалаций.

0 ESCALATION_STATUS_ACTIVE,
4 ESCALATION_STATUS_SUPERSEDED_ACTIVE,
5 ESCALATION_STATUS_SUPERSEDED_RECOVERY,
1 ESCALATION_STATUS_RECOVERY,

/* Alert statuses */
0 ALERT_STATUS_NOT_SENT = 0,
1 ALERT_STATUS_SENT,
2 ALERT_STATUS_FAILED

/* Escalation statuses */
0 ESCALATION_STATUS_ACTIVE = 0,
1 ESCALATION_STATUS_RECOVERY,
2 ESCALATION_STATUS_SLEEP,
3 ESCALATION_STATUS_COMPLETED, /* only in server code, never in DB */
4 ESCALATION_STATUS_SUPERSEDED_ACTIVE,
5 ESCALATION_STATUS_SUPERSEDED_RECOVERY



Каждых 30 секунд на сервере (значение задается параметром SenderFrequency в файле конфигурации сервера и здесь нет привязки к начале минуты) делается выборка (where a.status=0 and a.mediatypeid=mt.mediatypeid and a.alerttype=0 ) из таблицы alerts и если что нибудь обнаруживается то запускается процедура execute_action, которая и выполняет непосредственную отсылку письма.
Отсчет каждых 30 секунд начинается со старта сервера, а не с начала минуты.


Функция триггера nodata() вычисляется каждых 30 секунд точно в начале минуты и на 30-ой секунде. Поэтому если у вас данные пришли например на 5 секунде минуты (время по заббикс серверу) тогда функция {Хост:eventlog[Test].nodata(30)} даст положительный результат аж через 55 секунд, то есть в конце этой минуты, так как при просчете на 30 секунде она еще будет видеть ваше событие, пришедшее на пятой секунде и будет давать отрицательный результат.

Конц записки.