Попробуйте. Может я наконец пойму что делаю не так.
Ad Widget
Collapse
Бестолковые корелляции. А может я просто не умею готовить?
Collapse
X
-
-
Тогда давайте разбираться детально. Первый вопрос - у вас интервал обновления данных сколько секунд стоит?Comment
-
Ок. Поэкспериментирую со временем. Но на проде я не могу себе позволить такое количество узлов опрашивать с 30 сек. интервалом.Comment
-
Это не должно влиять. Обратите внимание, длительность событий закрытых корреляцией =0, т.е. закрываться должны сразу же при срабатывании вне зависимости от интервалов опроса. Единственное, проблемы могут возникнуть, если используете nodata в выражении триггера, они насколько я помню пересчитываются каждые 30 секунд вне зависимости от интервалов опроса.Comment
-
-
Тут у меня всплыли более срочные дела, поэтому я отложил на время, но ваша реплика заставила меня вернуться к проблеме и посмотреть свежим взглядом. И вот тогда я прочитал всё с самого начала и понял, почему у вас работает, а у меня нет.
Смотрите. У меня раньше было так в настройках корелляции:
- Тег старого события NODATA, значение: сервер
- Тег нового события NODATA, значение: роутер
Закрывать старые события.
Так работало ровно как я описал. Вернее не работало как мне нужно. И в полном соответствии с моими представлениями.
Т.е. что происходило: Допустим интервал обновления данных 1 минута. В случае отказа роутера:
1. Срабатывает триггер NODATA на сервере и он становится виден. (предположим этот триггер из-за асинхронности проверки сработал раньше).
2. Срабатывает триггер NODATA на роутере и он закрывает первый триггер, но сам остаётся видимым. (причём сработать он может спустя много секунд после первого)
Всё бы здорово, да только через 1 минуту, снова срабатывает триггер п.1 и уже остаётся висеть, ибо новых событий по триггеру в п.2 уже не генерируется.
Уведомления уходят. Всё плохо.
Теперь я сделал так:
- Тег старого события NODATA, значение: роутер
- Тег нового события NODATA, значение: сервер
Закрывать новые события.
Теперь работает тоже в соответствии с моими представлениями, почти так как вы описываете, но есть одна проблема, о чём ниже.
Что происходит теперь.
- Если срабатывает первым триггер для роутера, то вообще всё шоколадно, потому что каждое новое событие срабатывающего триггера на сервере натыкается на корелляцию и автоматически закрывается. Уведомления при этом не уходят. Это логично и никак не зависит от времени проверки элементов данных. Но есть проблема:
- А вот если первым срабатывает триггер для сервера, то при срабатывании триггера для роутера никакая корелляция не срабатывает и триггер сервера остаётся висеть. Это тоже логично, ведь всё согласно условиям: старого события не было!
Можно добавить ещё и ту корелляцию, которую я сделал вначале, чтобы происходило закрытие и этих событий, хотя в данном случае ОДИН РАЗ мы это всё увидим и уведомления получим.
Т.е. теперь надо как-то всё доработать, чтобы первым срабатывал именно триггер роутера, тогда действительно проблем не будет.
Но вот тут-то и загвоздка - на мой взгляд это невозможно нормально сделать.
Единственное, что приходит в голову - условие триггера на роутер должно выполняться в два раза чаще, чем у триггера на сервер! Т.е. например, мы у роутера при потере пакетов в 100% сразу апаем триггер, а у сервера проверяем потерю пакетов два раза. (при тех же интервалах опросов данных).
Если у вас есть какие-то соображения, буду рад их услышать!Comment
-
Я всегда считал это стандартным и , например, у меня все так и сделано, с разным временем срабатывания и зависимостями между триггерами.Но вот тут-то и загвоздка - на мой взгляд это невозможно нормально сделать.
Единственное, что приходит в голову - условие триггера на роутер должно выполняться в два раза чаще, чем у триггера на сервер! Т.е. например, мы у роутера при потере пакетов в 100% сразу апаем триггер, а у сервера проверяем потерю пакетов два раза. (при тех же интервалах опросов данных).Comment
Comment