Изменение элементов данных и триггеров созданные из прототипа

[EvGn]

Есть ситуация, где нужно поправить "важность" триггера или править элемент данных созданные из прототипа, но поля не активны и не могу изменить необходимые параметры. Как это исправить или есть какое-то другое или обходное решение?

[Kos]

Грубый workaround: делать disable объекту (элементу данных или триггеру), который был создан правилами LLD, и вместо них руками создавать свои.
При этом несколько теряется смысл в LLD, но увы... :-(

[Victor Vislobokov]

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

[Kos]

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

В этой ситуации как раз хорошо подходят макросы с контекстом.

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

[Victor Vislobokov]

В этой ситуации как раз хорошо подходят макросы с контекстом.

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

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

[EvGn]

Почему просто не дать редактировать порожденный триггер или элемент данных?!
Риторический вопрос

[Victor Vislobokov]

Почему просто не дать редактировать порожденный триггер или элемент данных?!
Риторический вопрос

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

[EvGn]

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

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

[Victor Vislobokov]

Триггеры и элементы данных создаются из заданных вами прототипов. Согласно частоте автообнаружения, если даже давать их исправить, они будут пересозданы снова из тех же прототипов.
Так что единственный способ - это склонировать имеющийся созданный из прототипа триггер и развлекаться уже с ним как угодно, а сам созданный триггер деактивировать. Это моё IMHO, в меру моего понимания того как это работает в Zabbix.

[EvGn]

Триггеры и элементы данных создаются из заданных вами прототипов. Согласно частоте автообнаружения, если даже давать их исправить, они будут пересозданы снова из тех же прототипов.
Так что единственный способ - это склонировать имеющийся созданный из прототипа триггер и развлекаться уже с ним как угодно, а сам созданный триггер деактивировать. Это моё IMHO, в меру моего понимания того как это работает в Zabbix.

Это каждом узле клонировать необходимые элементы данных и триггеры?????

[Semiadmin]

Может, вам попробовать создать несколько LLD с разными прототипами айтемов и/или триггеров и разными фильтрами, чтобы они работали с различными наборами сервисов. Для запуска на одном хосте нескольких LLD c одинаковым ключем применяется параметр Alias в конфиге агента.

[EvGn]

Может, вам попробовать создать несколько LLD с разными прототипами айтемов и/или триггеров и разными фильтрами, чтобы они работали с различными наборами сервисов. Для запуска на одном хосте нескольких LLD c одинаковым ключем применяется параметр Alias в конфиге агента.

сомневаюсь, что службы можно lld обнаруживать

[EvGn]

сомневаюсь, что службы можно lld обнаруживать

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

[Semiadmin]

Для windows хостов это стандартный функционал. А так, про сервисы я написал просто потому, что они в беседе упоминались, сказанное к любым объектам LLD относится.

[Victor Vislobokov]

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

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