LLD trigger tag

[astrix89]

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

Можно конечно клонировать нужный триггер и отключить оригинальный, но это как-то не очень на мой взгляд.

[MaksimsE]

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

Можно конечно клонировать нужный триггер и отключить оригинальный, но это как-то не очень на мой взгляд.

Разве при смене тега в правиле lld и обходе самого lld еще раз тег не меняется?

[astrix89]

Разве при смене тега в правиле lld и обходе самого lld еще раз тег не меняется?

Нельзя менять тег, или его значение в триггере, если он создан через lld. В этом проблема. На данный момент интересует только стандартный веб интерфейс.

Конкретный пример. На порту растут ошибки. Мы не можем дозвонится до абонента, либо его все устраивает, выключать триггер не вариант, так как там в дальнейшем может быть другой абонент и про это можно забыть. Чтобы эти события не забивали дашборд основной, можно сделать фильтр по тегам, туда будут попадать только события, с определенной меткой, и по ним дальше работать.

[sperr0w]

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

[sperr0w]

Сейчас обсуждаем еще один вариант.
Обновлять тэг триггера через SQL запрос: update trigger_tag set value = '...' where TRIGGERID = '...'
Решение обновлять напрямую через SQL не самое лучшее, но другого способа изменить тэг для части триггеров, созданных разведкой мы пока не нашли.

Еще один вариант - ставить в разведке для сервера фильтр, чтобы она отрабатывала только для тех файловых систем, для которых мы хотим изменить тэг и обновлять тэг в прототипе триггера. В этом случае разведка перестанет работать на все триггеры и обновит только их часть. Но такой вариант очень сложно поддерживать.

У кого - нибудь есть еще идеи?

[mykolaq]

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

[sperr0w]

Допустим, мы впишем в теге прототипа триггера макрос. Но мы не получим гибкости. Во всех разведанных по данному прототипу метриках будет стоят один и тот же макрос. Таким способом не получится отделить часть метрик.

[Sinot]

Простите за некромантию, но проблема все еще актуальна. =(

Единственный способ, который я нашел - добавить в LLD правила Замещения (Overrides). В моем случае необходимо для выбранных ФС добавлять к триггерам дополнительные теги.
Однако и тут не без проблем. Эти правила так же не доступны для редактирования если принадлежат шаблону.

[Kos]

Можно попробовать использовать в качестве значения тега макрос с контекстом. В этом случае значение по умолчанию (например, пустую строку) можно задать в виде макроса без контекста на уровне шаблона, а затем там, где это нужно, на уровне хоста определить для конкретного элемента значение в виде макроса с контекстом.
Недостаток: для уже сработавших триггеров это никак не поможет, т.к. теги проблем генерируются на момент генерации события "проблема".