Множественная проблема только если изме&

[MetrS]

Всем привет!

Можно ли сделать повторное срабатывание триггера, если элемент данных отдает "a b c" в первый раз, а в последующие меняет свое значение и отдает "a b c d" или "a b".

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

Версия Zabbix Server 3.2

[Kos]

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

Вы ничего не написали про Ваш элемент данных и про исходную формулу триггера, а также о том, когда бы Вы хотели этот триггер закрывать.

Это данные, которые собираются с какой-то периодичностью, либо это некий лог, куда новые записи могут попасть в непредсказуемые моменты времени (в том числе несколько раз подряд)?
Нужно (и можно) ли закрывать триггер перед "повторным срабатыванием"?

С "галочкой" "множественные проблемы", которую приходится выставлять при мониторинге нерегулярных событий (вроде записей в логи), есть, извините за тавтологию, свои проблемы при использовании в формуле триггера временнЫх функций (вроде nodata()).

[MetrS]

Вы ничего не написали про Ваш элемент данных и про исходную формулу триггера, а также о том, когда бы Вы хотели этот триггер закрывать.

Это данные, которые собираются с какой-то периодичностью, либо это некий лог, куда новые записи могут попасть в непредсказуемые моменты времени (в том числе несколько раз подряд)?
Нужно (и можно) ли закрывать триггер перед "повторным срабатыванием"?

С "галочкой" "множественные проблемы", которую приходится выставлять при мониторинге нерегулярных событий (вроде записей в логи), есть, извините за тавтологию, свои проблемы при использовании в формуле триггера временнЫх функций (вроде nodata()).

Элемент данных текст, получает массив данных в результате вывода скрипта:

asterisk -rx 'sip show peers' | grep -E "UNKNOWN|UNREACHABLE" | awk '{print $1}' | awk -F'/' '{print $1}'| awk '$1~/(^[0-9]{4}$)/ {print $1}'

вывод например, такой: 1001 1002 1003
Это телефоны в состояниях UNKNOWN|UNREACHABLE

Если добавляется один еще телефон, который кто-то отключил или пропала сеть, то будет: 1001 1002 1003 1004
Вот я хотел бы узнать что 1004 пропал еще...

Триггер:
{Asterisk сheck:whoisunknown.count(#2,"",ne)}=2

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

История данных: http://prntscr.com/fmk8u5

[Semiadmin]

Напрашивается вывод, что триггеров должно быть 2. Первый - тот, что у вас, говорит о наличии проблемы. Второй -
{Asterisk сheck:whoisunknown.count(#2,"",ne)}=2 and {Asterisk сheck:whoisunknown.diff}=1
о том, что эта проблема стала выглядеть несколько иначе.

[Kos]

Полностью поддерживаю коллегу Semiadmin: тут одним триггером не обойтись.
У нас примерно так и сделано: один триггер просто "висит", пока есть проблема (сигнализируя о ней на веб-консоли), а другой триггер служит для отсылки оповещений по условию "пришла новая строка, которая непуста и отличается от предыдущей" и закрывается по тайм-ауту, который меньше интервала получения данных. На обоих триггерах галка "множественные события" НЕ стоит.
Формула второго триггера получается примерно такая:

{Host:Item.strlen()}>0 and {Host:Item.diff()}>0 and {Host:Item.nodata(30)}=0

Правда, при этом на тот же триггер нельзя навешивать уведомление об окончании проблемы. Если оно нужно, то об этом должен сигнализировать именно первый триггер (когда закроется). В этом случае, действительно, уведомление о первоначальной проблеме тоже должен отсылать первый триггер, а второй уже должен сигнализировать только об изменениях (как указано в примере из предыдущего сообщения, в нём нужно проверять, что и последнее, и предпоследнее значения непусты).

[MetrS]

Напрашивается вывод, что триггеров должно быть 2. Первый - тот, что у вас, говорит о наличии проблемы. Второй -
{asterisk сheck:whoisunknown.count(#2,"",ne)}=2 and {asterisk сheck:whoisunknown.diff}=1
о том, что эта проблема стала выглядеть несколько иначе.

Спасибо, это то что нужно.

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

[MetrS]

Полностью поддерживаю коллегу semiadmin: тут одним триггером не обойтись.
У нас примерно так и сделано: один триггер просто "висит", пока есть проблема (сигнализируя о ней на веб-консоли), а другой триггер служит для отсылки оповещений по условию "пришла новая строка, которая непуста и отличается от предыдущей" и закрывается по тайм-ауту, который меньше интервала получения данных. На обоих триггерах галка "множественные события" НЕ стоит.
Формула второго триггера получается примерно такая:

{host:item.strlen()}>0 and {host:item.diff()}>0 and {host:item.nodata(30)}=0

Правда, при этом на тот же триггер нельзя навешивать уведомление об окончании проблемы. Если оно нужно, то об этом должен сигнализировать именно первый триггер (когда закроется). В этом случае, действительно, уведомление о первоначальной проблеме тоже должен отсылать первый триггер, а второй уже должен сигнализировать только об изменениях (как указано в примере из предыдущего сообщения, в нём нужно проверять, что и последнее, и предпоследнее значения непусты).

Можно ли по-тихому восстановить триггер второй сразу после сработки, без генерации уведомления?

[Semiadmin]

Можно ли по-тихому восстановить триггер второй сразу после сработки, без генерации уведомления?

Боюсь, что только старым способом - сделать для этого триггера отдельное действие без генерации recovery message.

[Kos]

Можно ли по-тихому восстановить триггер второй сразу после сработки, без генерации уведомления?

О чём и речь.
Второй триггер не должен слать уведомлений о восстановлении, только о проблеме.

Если сообщения о восстановлении нужны, то:
* сообщения о начале проблемы и восстановлении должен слать первый триггер (должно быть настроено своё действие для него);
* сообщения о продолжении проблемы ("состояние изменилось, но проблема всё ещё есть") должен слать второй триггер (и на него настроено своё отдельное действие, без отсылки уведомлений о восстановлении).

[MetrS]

Боюсь, что только старым способом - сделать для этого триггера отдельное действие без генерации recovery message.

Можно пример, я запутался?

[MetrS]

О чём и речь.
Второй триггер не должен слать уведомлений о восстановлении, только о проблеме.

Если сообщения о восстановлении нужны, то:
* сообщения о начале проблемы и восстановлении должен слать первый триггер (должно быть настроено своё действие для него);
* сообщения о продолжении проблемы ("состояние изменилось, но проблема всё ещё есть") должен слать второй триггер (и на него настроено своё отдельное действие, без отсылки уведомлений о восстановлении).

Если он не восстанавливается, то висит постоянно в Событиях.

[Semiadmin]

В 3.2 в настройках триггера можно установить "OK event generation" в None, но это работает не так, как интуитивно ожидается - предотвращает не отправку recovery mesage, а восстановление триггера. Поэтому этой опцией пользоваться здесь не нужно, а делать так, как делали всегда - создавать отдельное действие без генерации recovery message.

[MetrS]

В 3.2 в настройках триггера можно установить "ok event generation" в none, но это работает не так, как интуитивно ожидается - предотвращает не отправку recovery mesage, а восстановление триггера. Поэтому этой опцией пользоваться здесь не нужно, а делать так, как делали всегда - создавать отдельное действие без генерации recovery message.

А, понял. Надо в действиях создать отдельный пункт по данному триггеру.

[MetrS]

Спасибо большое, коллеги!