глобальная корреляция создает большое количество проблем

[lawdt]

Настраиваю глобальную корреляцию для подавления событий об превышении места на одинаковых массивах на разных ESXi.
получается, у меня десять хостов ESXI, по десять одинаковых массивов на каждом. Так отработал дискаверинг, все отлично.
Добавляю в теги на триггере по превышению места на массиве тег с именем массива. создаю правило глобальной корреляции, которое закрывает все новые события по массиву на основании тега с именем массива.
Теперь все супер, выводятся только проблемы по каждому массиву, но только на одном из хостов. Ничего лишнего.
Но , зайдя в историю проблем, я ужаснулся!!!
каждый раз, как срабатывает триггер, создается проблема, потом отрабатывает глобальная корреляция, закрывает проблему. Даже для моих 10 массивов на 10 хостах при снятии айтема 1 раз в 1 минутe создается (я посчитал) 144000 проблем в сутки!!! это же ужас какойто. Так и должно быть ? через три месяца БД распухнет до 13 миллионов записей. Хаузкипинг придется снизить до пары суток. И это нормально ?
или я что-то не понимаю насчет глобальной корреляции. В других системах корреляция подавляет возникновение аварий, а не закрывает уже созданные. Заббиксоиды, объясните пожалуйста.

[Kos]

Подозреваю, что то, что Вам надо - это, скорее, зависимости, нежели корреляция.

[who_care]

Я "выкрутился" из подобной ситуации с помощью аггрегированных проверок сделав триггер на минимальное значение эл. данных в группе, но это не очень хорошее решение, в том плане, что если в какой-то группе элементов данных сработает триггер, не видно будет для какого хоста он сработал =\

[lawdt]

Подозреваю, что то, что Вам надо - это, скорее, зависимости, нежели корреляция.

зависимости планировалось использовать для трех уровней срабатывания, для одного стораджа например 70, 80 и 95 % с разными уровнями критичностей.
Но! касаемо топика, зависимостями тут не выкрутишься, поскольку как вы себе представляете определить межхостовые зависимости на уровне правила дискаверинга в шаблоне ?
конечно, можно выбрать один хост главным, и на него приклеить все зависимости, но это такой махровый кастом будет, что лучше сразу застрелиться.

Я "выкрутился" из подобной ситуации с помощью аггрегированных проверок сделав триггер на минимальное значение эл. данных в группе, но это не очень хорошее решение, в том плане, что если в какой-то группе элементов данных сработает триггер, не видно будет для какого хоста он сработал =\

да, это вариант, однако в моем варианте со стандартными шаблонами vmware внутри айтемов используются макросы, которые плохо агрегируются. В принципе важность хоста на котором сработал триггер не важна, поскольку все хранилища подключены к каждому хосту. Сейчас колдую чтобы агрегированный айтем собирал все айтемы в пределах группы, но из-за того что в ключе есть макросы, они раскрываются и ключ оказывается совсем не такой как нужно, в итоге пока агрегация не работает. Может подскажете, как в агрегированных проверках заставить макросы не раскрываться, а быть plain text ?

Вот о чем я говорю, функция агрегации
grpmin["Hypervisors","vmware.hv.datastore.size[{$URL},{HOST.HOST},cluster53_disk16_vplex,free]",last]
макросы раскрываются, в итоге функция ищет айтемы с ключами типа "vmware.hv.datastore.size["https://192.168.1.1/sdk","someuud",cluster53_disk16_vplex,free]"
естесственно ничего не находит, поскольку в искомых ключах макросы не раскрыты.

[Semiadmin]

Вот о чем я говорю, функция агрегации
grpmin["Hypervisors","vmware.hv.datastore.size[{$URL},{HOST.HOST},cluster53_disk16_vplex,free]",last]
макросы раскрываются, в итоге функция ищет айтемы с ключами типа "vmware.hv.datastore.size["https://192.168.1.1/sdk","someuud",cluster53_disk16_vplex,free]"
естесственно ничего не находит, поскольку в искомых ключах макросы не раскрыты.

В качестве страшного костыля - сделать calculated item с формулой last("vmware.hv.datastore.size[{$URL},{HOST.HOST},cluster53_disk16_vplex,free]"), который будет дублировать значение айтема, но его ключ уже не будет содержать макросы. Агрегировать эти calculated items.

[lawdt]

В качестве страшного костыля - сделать calculated item с формулой last("vmware.hv.datastore.size[{$URL},{HOST.HOST},cluster53_disk16_vplex,free]"), который будет дублировать значение айтема, но его ключ уже не будет содержать макросы. Агрегировать эти calculated items.

Эта ужасающая идея работает, проверил. Но вернемся к топику.

[Semiadmin]

Эта ужасающая идея работает, проверил.

Только сейчас сообразил, что идея может быть не столь уж ужасающей, если вместо calculated использовать depended item без препроцессинга.

[Evgeniy]

В других системах корреляция подавляет возникновение аварий, а не закрывает уже созданные.

Мда... Тоже не понимаю, как в таком виде ее можно использовать...

[lawdt]

Только сейчас сообразил, что идея может быть не столь уж ужасающей, если вместо calculated использовать depended item без препроцессинга.

а в чем принципиальная выгода будет ? по мне так шило на мыло.

[Semiadmin]

а в чем принципиальная выгода будет ? по мне так шило на мыло.

В том, что зависимый айтем будет получать значение в тот же самый момент, что и основной. Главная проблема с вычисляемым айтемом - его отставание от основного по времени. А добавить еще один айтем в шаблон - не проблема, тем более что время хранения его истории можно сделать минимальным, 1 час.