Сетевое обнаружение, удаленная команда, м

[blah.blah]

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

[yukra]

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

Есть специальная таблица, однако столбец "Supported in" в нем, кмк, не достаточно формализирован и не понятно искать ли вам в данном случае "Discovery notifications" или "Trigger-based notifications and commands", так что я бы советовал прибегнуть к методу ползучего эмпиризма. Только обратите внимание что документация на русском несколько отличается от английской.

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

Кмк "{DISCOVERY.DEVICE.IPADDRESS} довольно однозначно идентифицирует устройство в сети в определенный момент времени. Если у вас есть прокси, за которыми живут пересекающиеся диапазоны, то это решается добавлением {DISCOVERY.RULE.NAME}. В крайнем случае можно передать {EVENT.ID}, а потом через API по нему вытащить все остальное.

[blah.blah]

столбец "supported in" в нем, кмк, не достаточно формализирован

Это и послужило причиной создания топика.

В крайнем случае можно передать {EVENT.ID}, а потом через api по нему вытащить все остальное.

Интересная идея, спасибо, буду пробовать.
В целом задача в том, чтоб слегка подкрутить настройки хоста по api после его добавления.

[blah.blah]

Наверное, я не понимаю, как это должно работать, но вот так (см. картинку) это не работает.

Если выполнять на "Zabbix сервер", то каким образом тут влияет "Список целей". Когда выполнение на агенте - там понятно, каждой цели через агент передаются команды, которые должны быть исполнены. А в ситуации как на картинке - как оно?

[yukra]

Наверное, я не понимаю, как это должно работать, но вот так (см. картинку) это не работает.

Если выполнять на "Zabbix сервер", то каким образом тут влияет "Список целей". Когда выполнение на агенте - там понятно, каждой цели через агент передаются команды, которые должны быть исполнены. А в ситуации как на картинке - как оно?

Список целей не имеет смысла, если команда выполняется на Zabbix сервере. В этом случае выбор нескольких целей приведет только к тому, что команда выполнится на сервере несколько раз.

https://www.zabbix.com/documentation...tion/operation

[blah.blah]

Точно, недоглядел.

В общем, такая история, что эта конструкция работает нормально:

echo "{EVENT.ID} {DISCOVERY.DEVICE.IPADDRESS} {DISCOVERY.RULE.NAME} {HOST.HOST}" >> /tmp/echo.txt

IP обнаруженного девайса и имя правила прилетают верные, HOST.HOST не передается, а вот EVENT.ID - какой-то хитрый. Ивент генерится, но через API не находится. Думаю, дело в том, что узел уже добавлен. Т.е. для существующих узлов ивент не сохранятеся, хотя ID при этом есть. И ID прирастает.
Upd. 1
И вот, что любопытно, в базе запись с соответствующим ID есть:

+---------+--------+--------+----------+------------+-------+--------------+----+
| eventid | source | object | objectid | clock      | value | acknowledged | ns |
+---------+--------+--------+----------+------------+-------+--------------+----+
| 1578259 |      1 |      2 |      178 | 1516110911 |     0 |            0 |  0 |
| 1578260 |      1 |      1 |       92 | 1516110911 |     0 |            0 |  0 |
+---------+--------+--------+----------+------------+-------+--------------+----+

source - 1 событие создано правилом обнаружения;
object - 1 обнаруженный узел сети;
object - 2 обнаруженный сервис.
Т.е. вероятно сначала возникает ивент об обнаружении SNMP, потом о самом узле уже.
Но API почему-то не возвращает.
Upd.2
А, не, возвращает. Надо явно указывать и source и object, что немного неудобно, т.к. id уже уникален.
Получается, что узнать source и object можно из описания ивента, но для получения этого описания нужны source и object.
Иными словами, если источник события не триггер, то одного id недостаточно.

[yukra]

Точно, недоглядел.

В общем, такая история, что эта конструкция работает нормально:

echo "{EVENT.ID} {DISCOVERY.DEVICE.IPADDRESS} {DISCOVERY.RULE.NAME} {HOST.HOST}" >> /tmp/echo.txt

IP обнаруженного девайса и имя правила прилетают верные, HOST.HOST не передается, а вот EVENT.ID - какой-то хитрый. Ивент генерится, но через API не находится. Думаю, дело в том, что узел уже добавлен. Т.е. для существующих узлов ивент не сохранятеся, хотя ID при этом есть. И ID прирастает.
Upd. 1
И вот, что любопытно, в базе запись с соответствующим ID есть:

+---------+--------+--------+----------+------------+-------+--------------+----+
| eventid | source | object | objectid | clock      | value | acknowledged | ns |
+---------+--------+--------+----------+------------+-------+--------------+----+
| 1578259 |      1 |      2 |      178 | 1516110911 |     0 |            0 |  0 |
| 1578260 |      1 |      1 |       92 | 1516110911 |     0 |            0 |  0 |
+---------+--------+--------+----------+------------+-------+--------------+----+

source - 1 событие создано правилом обнаружения;
object - 1 обнаруженный узел сети;
object - 2 обнаруженный сервис.
Т.е. вероятно сначала возникает ивент об обнаружении SNMP, потом о самом узле уже.
Но API почему-то не возвращает.
Upd.2
А, не, возвращает. Надо явно указывать и source и object, что немного неудобно, т.к. id уже уникален.
Получается, что узнать source и object можно из описания ивента, но для получения этого описания нужны source и object.
Иными словами, если источник события не триггер, то одного id недостаточно.

Я немного глянул на все это, достать из event.id настроящий id хоста (не тот, который в "Мониторинг - обнаружение") не так просто, поэтому я бы лично сделал так:
По факту "Сервис обнаружен" узел суется в группу "обнаруженные", пинается наш скрипт, скрипт выбирает все хосты из группы "обнаруженные", делает нужные вам настройки и удаляет хосты из этой группы.
Я честно говоря не пробовал, но вроде как должно сработать.

[blah.blah]

Кое-что достать все-же можно. Вон на примере выше был objectid 178. Это id обнаруженного сервиса. Если получить данные по нему, то там есть ip, и собственно полученное по SNMP значение.
Конкрено в моем случае, при обнаружении по SNMP добавленный узел будет иметь ip в поле name.
Я набросал черновичок, который мне возвращает объект узла сети по полученному {EVENT.ID}. На этом этапе уже можно переименовывать узлы, менять им community, ну и т.д.
В принципе, можно пропустить один шаг, и сразу опираться на ip - благо {DISCOVERY.DEVICE.IPADDRESS} тоже передается.
Есть и еще один вариант - сделать отдельный шаблон, в котором будет один-единственный элемент данных с типом "внешняя проверка", который и будет запускать скрипт. Вот там уже сразу будет однозначно идентифицирован хост. А скрипт может выполнить необходимые настройки, после чего отсоединить и очистить шаблон.
Сижу думаю, какой вариант изящнее.