Отслеживание хоста с динамическим адресом (без DNS)

[Bag]

Подскажите пожалуйста: возможно ли наблюдать за хостом (целевым) по протоколу SNMP agent, у которого динамически меняется адрес интерфейса без использования DNS, порт остаётся неизменным.
Network Discovery показал себя слишком медлительным из-за большого пула возможных адресов.
Текущий адрес этого хоста (целевого) я получаю из данных другого хоста (статического).

Использовал для этого LLD.
Хост создаёт, шаблон сбора данных на целевом хосте отрабатывает "на ура". При смене адреса взятого от "статического хоста" создаёт новый хост, и опять всё красиво работает. Потерянный хост со временем убивает.
НО! При этом теряется вся история данных, а это неприемлемо. Как бы таки динамически менять интерфейс уже существующего целевого хоста???
Возможно я недоиспользовал все возможности LLD. Пока я в тупике.

Если возможно, то как?

[Kos]

На "статический" хост, с которого забираете текущий IP целевого хоста, навесить триггер, срабатывающий при изменении полученного значения.
На триггер навесить действие - запуск скрипта на сервере Zabbix, передавая срипту в качестве параметра последнее полученное значение (т.е. текущий IP целевого хоста).
Наконец, самое сложное (хотя и не так уж, на самом деле) - написать сам скрипт, который, используя Zabbix API, у заранее известного хоста в свойствах его SNMP-интерфейса меняет адрес на то значение, которое передано в качестве параметра.

[PavelZ]

Трудно.
Может active proxy проще поставить куда-то рядом?

[Bag]

Active proxy ставить пока (как и DNS) нет возможности.

[Kos]

На "статический" хост, с которого забираете текущий IP целевого хоста, навесить триггер, срабатывающий при изменении полученного значения.
На триггер навесить действие - запуск скрипта на сервере Zabbix, передавая срипту в качестве параметра последнее полученное значение (т.е. текущий IP целевого хоста).
Наконец, самое сложное (хотя и не так уж, на самом деле) - написать сам скрипт, который, используя Zabbix API, у заранее известного хоста в свойствах его SNMP-интерфейса меняет адрес на то значение, которое передано в качестве параметра.

[Bag]

Спасибо. Очень интересная мысль.
С API ещё не работал, не изучал. Пока нет прав на его использование, и не известно дадут ли.
А без API нельзя никак? Если Вы или ещё кто-нибудь считаете, что без API никак, отпишите своё тут мнение. Эту позицию я буду использовать в качестве аргумента для "права дающих".

[Bag]

На "статический" хост, с которого забираете текущий IP целевого хоста, навесить триггер, срабатывающий при изменении полученного значения.
На триггер навесить действие - запуск скрипта на сервере Zabbix, передавая срипту в качестве параметра последнее полученное значение (т.е. текущий IP целевого хоста).
Наконец, самое сложное (хотя и не так уж, на самом деле) - написать сам скрипт, который, используя Zabbix API, у заранее известного хоста в свойствах его SNMP-интерфейса меняет адрес на то значение, которое передано в качестве параметра.

Спасибо. Очень интересная мысль.
С API ещё не работал, не изучал. Пока нет прав на его использование, и не известно дадут ли.
А без API нельзя никак? Если Вы или ещё кто-нибудь считаете, что без API никак, отпишите своё тут мнение. Эту позицию я буду использовать в качестве аргумента для "права дающих".

[Kos]

Спасибо. Очень интересная мысль.
С API ещё не работал, не изучал. Пока нет прав на его использование, и не известно дадут ли.
А без API нельзя никак? Если Вы или ещё кто-нибудь считаете, что без API никак, отпишите своё тут мнение. Эту позицию я буду использовать в качестве аргумента для "права дающих".

По сути вашего вопроса - вам нужно отслеживать изменение IP-адреса некоего хоста и соответственно менять этот адрес в свойствах хоста в Zabbix-е.
Насколько я понимаю, первая часть (отслеживание изменения IP-адреса) у вас уже решена, осталось решить вторую.
Чтобы поменять с свойствах хоста IP-адрес его интерфейса, в любом случае нужны права чтения/записи на этот хост. А дальше уже возможны варианты - либо редактировать каждый раз вручную (например, отправляя по электронной почте уведомление тому администратору, который может это сделать), либо как-то автоматизировать. Эффективнее, конечно, второй вариант; собственно, для этого и предназначены Zabbix API.

От себя я бы добавил пару замечаний про использование API:

• удобно (именно для использования API в скриптах) тому пользователю, от имени которого будут обращения в Zabbix, сгенерировать отдельный постоянный токен, тогда не нужно будет в скрипте делать логин/логаут, а при простых запросах (вроде вашего) скрипт сводится к одному обращению (которое можно сделать, например, с помощью утилиты curl, см. примеры тут);
• документацию по API лучше смотреть на английском языке, этот раздел переводится в последнюю очередь;
• если имеете понятие о языке Python, то довольно удобно с Zabbix API работать при помощи официальной библиотеки для Python (ссылка).

[Bag]

Благодарю за столь обстоятельный ответ.
А можно в личку?
Обещаю любые вопросы тщательно обдумывать и формулировать. И спрашивать только в случае тупика.
А то я в предложенном Вами алгоритме пока как "слепой котенок" - знаю только направление.

[Kos]

А можно в личку?
Обещаю любые вопросы тщательно обдумывать и формулировать. И спрашивать только в случае тупика.
А то я в предложенном Вами алгоритме пока как "слепой котенок" - знаю только направление.

Можно; правда, не обещаю, что отвечу сразу же.
Но лучше спрашивать здесь же, на форуме: а) это может оказаться интересным не только вам, но и другим посетителям форума; б) ответить по делу смогу не только я, но и другие опытные пользователи.
При задавании вопроса не забывать указывать, о какой версии Zabbix идёт речь (от этого могут зависеть его возможности, расположение меню в веб-интерфейсе и дальнейшие рекомендации).

Ещё добавлю, что для данной задачи в качестве скрипта можно использовать веб-хук (код на JavaScript, встроенный в сервер Zabbix) - как минимум для версий Zabbix с 6.0 по 7.0 можно за основу взять примеры из моих комментариев к этой статье (ссылка), подогнав под себя нужный API. Начиная с 7.0, можно (а с 7.2 - нужно) чуть модифицировать эти скрипты, чтобы передавать токен аутентификации не в теле JSON'а, а в заголовке HTTP-запроса (как описано здесь).

[PavelZ]

Эту позицию я буду использовать в качестве аргумента для "права дающих".

Еще вам потребуется надежный компьютер и доступ к компьютеру чтобы эти скрипты запускать.
И любой ваш код мониторинга написанный за 15 минут означает, что следующие лет 10 в него будут глядеть разные люди и часами пытаться его понять и исправить.

В общем, подумайте хорошо.

[Bag]

Необходимую аргументацию привёл.
Жду предоставления соотв. прав.

[Bag]

Можно; правда, не обещаю, что отвечу сразу же.
Но лучше спрашивать здесь же, на форуме: а) это может оказаться интересным не только вам, но и другим посетителям форума; б) ответить по делу смогу не только я, но и другие опытные пользователи.
При задавании вопроса не забывать указывать, о какой версии Zabbix идёт речь (от этого могут зависеть его возможности, расположение меню в веб-интерфейсе и дальнейшие рекомендации).

Ещё добавлю, что для данной задачи в качестве скрипта можно использовать веб-хук (код на JavaScript, встроенный в сервер Zabbix) - как минимум для версий Zabbix с 6.0 по 7.0 можно за основу взять примеры из моих комментариев к этой статье (ссылка), подогнав под себя нужный API. Начиная с 7.0, можно (а с 7.2 - нужно) чуть модифицировать эти скрипты, чтобы передавать токен аутентификации не в теле JSON'а, а в заголовке HTTP-запроса (как описано здесь).

Доброго времени суток!
Начал разработку проблемы. Понял, что возможно нужен другой подход. Дело в том, что таких целевых хостов более 332 (два целевых получают адрес от своего статического).
В предложенном Вами варианте необходимо создавать 166 шт. Trigger Actions.
Как быть в таком массовом случае?
И правильно ли передавать скрипту значение через Trigger Tag?
Как возможно отлаживать скрипт (проверять передаётся ли ему нужное значение, как он отрабатывает...) ?
Пока много вопросов... Если не трудно, сообщите своё мнение пожалуйста.

[Kos]

таких целевых хостов более 332 (два целевых получают адрес от своего статического).
В предложенном Вами варианте необходимо создавать 166 шт. Trigger Actions.
Как быть в таком массовом случае?
И правильно ли передавать скрипту значение через Trigger Tag?
Как возможно отлаживать скрипт (проверять передаётся ли ему нужное значение, как он отрабатывает...) ?
Пока много вопросов... Если не трудно, сообщите своё мнение пожалуйста.

Trigger Action может быть один, настроенный, например, на использование тега, которым помечен триггер.
А значением тега может являться, например, последнее значение элемента данных из триггерного выражения, взятое при помощи макроса {ITEM.VALUE}.
Только скрипту нужно ещё, кроме этого, передавать ссылку на тот хост (или даже на интерфейс хоста), который нужно редактировать. Но его тоже можно держать в каком-нибудь теге, которым помечать либо сам триггер, либо элемент данных, который в нём используется.

При задавании вопроса не забывать указывать, о какой версии Zabbix идёт речь

Увы, используемая вами версия Zabbix нам до сих пор неизвестна

Да, как минимум системный макрос {EVENT.TAGS.<имя_тега>} поддерживается, начиная с версии Zabbix 4.4.2, и доступен в оповещениях и командах на триггерные события.

Например, при отладке вебхуков полезно использовать встроенную функцию Zabbix.log() и смотреть на её вывод в логе сервера.

[Bag]

Trigger Action может быть один, настроенный, например, на использование тега, которым помечен триггер.
А значением тега может являться, например, последнее значение элемента данных из триггерного выражения, взятое при помощи макроса {ITEM.VALUE}.
Только скрипту нужно ещё, кроме этого, передавать ссылку на тот хост (или даже на интерфейс хоста), который нужно редактировать. Но его тоже можно держать в каком-нибудь теге, которым помечать либо сам триггер, либо элемент данных, который в нём используется.

Увы, используемая вами версия Zabbix нам до сих пор неизвестна

Да, как минимум системный макрос {EVENT.TAGS.<имя_тега>} поддерживается, начиная с версии Zabbix 4.4.2, и доступен в оповещениях и командах на триггерные события.

Например, при отладке вебхуков полезно использовать встроенную функцию Zabbix.log() и смотреть на её вывод в логе сервера.

Прошу прощение за то, что сразу не указал версию Zabbix.
Вчера версия была обновлена с 6.2.8. на 7.0.8
Счас пытаюсь понять то, что изменилось в худшую сторону. Напр.: Trigger Tag перестал применяться после сработки триггера, судя по отображению самой проблемы, и в шапке самого хоста Тэга Триггера не появляется. А он необходим в этой задаче! Тег я формировал по предложенной позднее Вами методике с использованием {ITEM.VALUE}.

Ссылку на целевой хост передавать скорее всего не придётся т.к. имена целевых хостов детерминированы и определяются от имени статического хоста (а скрипт будет отрабатываться Trigger Action статического хоста, применённому к шаблону для массовости) путём замены концевой части имени, начиная с определённой последовательности, на характерную константу.

Вопрос "Как отлаживать отработку скрипта" остаётся пока для меня мучительно открытым т.к в Zabbix.log() не появляются сообщения отработки скрипта. Скорее всего недостаточный уровень Verbose логирования. Как хотябы увидеть возвращаемое скриптом значение?
Хотя виджет Action Log показывает, что скрипт усиленно отрабатывается (счас скрипт: return value).

[Kos]

С версией понятно, спасибо. Мы тоже используем 7.0.
Про имена хостов тоже понятно, это несколько упрощает задачу. Имя исходного хоста можно брать, например, из системного макроса {HOST.HOST}, а дальше уже в скрипте заменять нужную часть. Правда, для использования в API нужен идентификатор хоста, но это будет просто дополнительное обращение к API, чтобы по имени хоста узнать его ID.
Про отладку: при использовании в Zabbix.log() уровня логирования 3 и меньше в лог сервера эти записи должны попадать. При использовании уровня 4 - уже только если для сервера включен повышенный уровень логирования. Прежде чем что-то возвращать - логируйте, и должны увидеть в логах.

Счас пытаюсь понять то, что изменилось в худшую сторону. Напр.: Trigger Tag перестал применяться после сработки триггера, судя по отображению самой проблемы, и в шапке самого хоста Тэга Триггера не появляется. А он необходим в этой задаче!

Честно говоря, этого фрагмента не понял. Распишите подробнее, пожалуйста, что подразумевается под применением "Trigger Tag после сработки триггера" и где именно оно перестало работать.