Итем в имени прототипа триггера или двойной snmpindex

[Lurker]

Zabbix 6.2
Я дискаверю OID-a, получаю SNMPINDEX вида X.Y.
Предобработкой изменяю его на X.
Опрашиваю OID-b.X.

Вопрос:
Как создать триггер с именем {OID-b.X.}?

Попытки решения:
Дискаверить OID-b. В этом случае получается лишние триггеры. т.к. мне не все OID-b нужны. Теоретически этот вариант рабочий, но колличество триггеров и опрашиваемых итемов вырастет раз в 20, мне это не нравится и нужно как -то добавить в триггер условие: Существует ли итем с ключом name.{snmpindex}.* где * любое число
Дискавер вида variable-a, OID-a, variable-v, OID-b Не работает т.к. для OID-b нужен другой snmpindex, а он похоже берётся только от OID-a.
Запихнуть в выражение триггера OID-b, а затем вытащить его в имя через {ITEM.VALUE}-работает нестабильно. Я так понимаю проблемы возникают когда триггер создаётся до того, как опросится OID-b

Что могло бы сработать, но я не знаю как к этому подступиться:
1)Можно ли сделать задержку на создание триггеров?Zabbix 6.2
Я дискаверю OID-a, получаю SNMPINDEX вида X.Y.
Предобработкой изменяю его на X.
Опрашиваю OID-b.X.

Вопрос:
Как создать триггер с именем {OID-b.X.}?

Попытки решения:
Дискаверить OID-b. В этом случае получается лишние триггеры. т.к. мне не все OID-b нужны. Теоретически этот вариант рабочий, но колличество триггеров и опрашиваемых итемов вырастет раз в 20, мне это не нравится и нужно как -то добавить в триггер условие: Существует ли итем с ключом name.{snmpindex}.* где * любое число
Дискавер вида variable-a, OID-a, variable-v, OID-b Не работает т.к. для OID-b нужен другой snmpindex, а он похоже берётся только от OID-a.
Запихнуть в выражение триггера OID-b, а затем вытащить его в имя через {ITEM.VALUE}-работает нестабильно. Я так понимаю проблемы возникают когда триггер создаётся до того, как опросится OID-b

Что могло бы сработать, но я не знаю как к этому подступиться:
1)Можно ли сделать задержку на создание триггеров?

[Alex_UUU]

перечитал несколько раз. ТО понял то нет.
Триггеры относятся к элементам данных. и привязаны к одному дискаверингу.
Как вариант - действительно излишние данные

[Lurker]

Попробую тогда объяснить на примере. Ситуация несколько отличается от первого поста т.к. я сделал без предобработки, это работает лучше.
discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6]
Далее создаю итемы, обратите внимание, что OID другой
1.3.6.1.2.1.31.1.1.1.1.{{#SNMPINDEX}.regsub("^\d*" , \0)}
Далее мне нужно создать триггер, в имени которого будет значение этого итема. Функцию last() использовать нельзя, она там не поддерживается. Логичным будет изменить дискавер типа
discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6, {INTNAME}, 1.3.6.1.2.1.31.1.1.1.1]
Но это не работает. Как я понимаю дискавер работает по принципу(я не нашёл другого объяснения почему конструкция выше не работает):
SNMPWALK 1.3.6.1.4.1.9.9.23.1.2.1.1.6
Foreach snmpindex
snmpget 1.3.6.1.2.1.31.1.1.1.1
И вот тут проблема, т.к. snmpindex надо обрезать от вида X.Y до вида X. В OID итема я это могу сделать, а вот в дискавере я не знаю как.

[Alex_UUU]

Хм, в 6 версии появился прототип дискаверинга? Круто.
Что такое дискаверинг? Это обычный элемент данных, на основании которого можно создать другие ЭД, триггеры и т.д.
Условие дискаверинга - получение некой таблицы: имя_макроса=значение_макроса
И на основании этого все остальное создается.
У дискаверинга есть предобработка, которая может изменить полученные значения.
Т.е. я всегда могу сделать так:
Получаю:
имя_макроса=значение_макроса
MKRS_1=1
MKRS_2=2
MKRS_3=4

Предобраюботкой можно поменять что угодно (там же джава есть) и получить MKRS_3=3.
На основании этих данных делаем прототипы элементов:
Имя {#имя_макроса) ключ {#имя_макроса)[{#значение_макроса}]
И создастся 3 элемента.
Также можно создать триггеры.
В триггер можно засунуть другой ЭД или другой прототип.
Но чтобы в прототипе триггере использовать значения ЭД из прототипа - не встречал, кроме как агрегированных функций, т.е. сделат триггер, в котором
MKRS_1[1]+MKRS_2[2] Вроде бы нельзя, т.к. триггеры четко привязаны к ЭД.
Но всегда есть возможность сделать дополнительный ЭД типа "вычисляемый", в котором жестко указать MKRS_1[1]+MKRS_2[2] и повесить триггер на него. Вычисляемые (по крайней мере в 5 версии) не проверяют правильность имени ЭД в формуле.

Также есть всегда возможность переложить сложные сценарии на свой скрипт.

[Lurker]

Хм, в 6 версии появился прототип дискаверинга? Круто.

какой ещё прототип дискаверинга?

Условие дискаверинга - получение некой таблицы: имя_макроса=значение_макроса

Не совсем. Дискавер получает НЕСКОЛЬКО таблиц. 1 это частный случай.
discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6, {INTNAME}, 1.3.6.1.2.1.31.1.1.1.1]
Т.е. тут должно создаться 2 таблицы как я понимаю. Но у меня 2я не создаётся т.к. для второй таблицы SNMPINDEX должен быть другой.

Предобраюботкой можно поменять что угодно (там же джава есть) и получить MKRS_3=3.

Даже, если предобработкой можно поменять snmpindex для дискавера (а не для итемов которые он создаёт) это сломает мне первую таблицу Neighbor.

В триггер можно засунуть другой ЭД или другой прототип.

ЭД=итем?
В выражение триггера можно. А в имени нельзя, там только максросы.

Я попробую переформулировать проблему, чтобы обяснить почему я не могу всё что мне надо получить своим скриптом.
Я не могу ОДНИМ дискавером получить все нужные мне данные(даже без учёта того, что им понадобится обработка)
Т.к. мне нужно опросить
OIDa.X.Y
и OIDb.X
Вот если бы было
OIDa.X
и OIDb.X
То проблемы бы небыло, дискавер отработался бы для двух веток и всё было ок.
Если же я получаю данные не через дискавер, а через прототипы элементов данных, то я не могу их использовать в имени триггера.
P.S.в OIDa.X.Y для каждого X есть только один Y. Поэтому по количеству элементов эти ветки совпадают.

[Alex_UUU]

Не совсем. Дискавер получает НЕСКОЛЬКО таблиц. 1 это частный случай.
.

Чкго? Или мы говорим о разном дискаверинге - автообнаружении? 15. Обнаружение (zabbix.com)

Проблдема в вопросе в том, что ты выдаешь что-то свое специфическое, касательно какого-то SNMP.
discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6, {INTNAME}, 1.3.6.1.2.1.31.1.1.1.1]
Где должно создаться 2 таблицы? Это ЭД (элемент данных, итем)? ПРототип?
Значит дискаверинг отработал и выдал тебе кучу {#NEIGHBOR}, {INTNAME}- макрос системы, но его нет в документации: 1 Поддерживаемые макросы (zabbix.com)

[Lurker]

Значит дискаверинг отработал и выдал тебе кучу {#NEIGHBOR}, {INTNAME}

В том, то и проблема, что он НЕ выдаёт {#INTNAME} Т.к для него окончание OID будет другого формата относительно 1.3.6.1.4.1.9.9.23.1.2.1.1.6

Где должно создаться 2 таблицы? Это ЭД (элемент данных, итем)? ПРототип?

Это дискавер. С точки зрения пользователя это 2 макроса. А вот внутри заббикса я так понимаю это 2 таблицы.

[Lurker]

Чкго? Или мы говорим о разном дискаверинге - автообнаружении? 15. Обнаружение (zabbix.com)

1)Ваша ссылка не открывается. Но да мы говорм о разном, т.к. мануала дискавера SNMP на русском нет.
https://www.zabbix.com/documentation...ples/snmp_oids
2)но да, таблица одна создаётся. собственно это и причина того, что {#INTNAME} пустые т.к. для них SNMPindex должен быть другого формата. а по SNMPINDEX? обнаруженных для {#NEIGHBOR} там ничего нет.

[Alex_UUU]

Ссылка на Дискаверинг (автообнаружение) выше.
ПОйдем другим путем:
какие значения выдает автообнаружение? (там есть кнопочка тест, и можнео получить как сырые значения, так и уже предобработанные).

Написано после получени предыдущего сообщения.
Я не работаю с SNMP, нео из документации видно, что на вход внутреннему скрипту дискаверинга подается перечень пар, таких как имя_макроса и что-то, называемое OID. При этом количество таких пар не ограничено.
Что делает заббикс: он обращается по конкретному OIDу, получает данные и это будет столбец с имя_макроса1, по второму имя_макроса2 и т.д. .
На основании этого можно строить прототипы ЭД или тригеров.
Если дискаверинг не возвращает столбец (json etc) по какомй то макросу, смею сделать предположение, что конечное устройство его не отдает. ПРичин может быть множество, от доступов до ошибки в названиии
Да, при этом заббикс сам добавляет свой макрос: {#SNMPINDEX}

[Kos]

Пока все тут не переругались, я бы хотел вернуться на несколько реплик назад.

Далее мне нужно создать триггер, в имени которого будет значение этого итема.

Если данный айтем упоминается в условии триггера, то в имени триггера на его значение можно сослаться с помощью макроса {ITEM.VALUE<N>} (где <N> - необязательный номер, в каком порядке этот элемент данных в условии триггера упомянут).

изменить дискавер типа
discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6, {INTNAME}, 1.3.6.1.2.1.31.1.1.1.1]
Но это не работает.

Так работать не будет по двум причинам.
Во-первых, должны использоваться LLD-макросы, а {INTNAME} - не LLD (в начале имени макроса отсутствует римвол решётки).
Во-вторых, использование в LLD нескольких таблиц предназначено для случаев, когда эти таблицы имеют совпадающие индексы (они будут подставлены в качестве LLD-макроса {#SNMPINDEX}). В вашем же случае, насколько я понял с ваших слов, индексы у этих таблиц отличаются: для одной из них они имеют вид ".X", а для другой - вид ".X.Y".

[Lurker]

Если данный айтем упоминается в условии триггера, то в имени триггера на его значение можно сослаться с помощью макроса {ITEM.VALUE<N>} (где <N> - необязательный номер, в каком порядке этот элемент данных в условии триггера упомянут).

Сослаться можно, но работает это криво т.к. триггер может создасться до того, как опросится итем. В этом случае триггер не переименуется.

Во-вторых, использование в LLD нескольких таблиц предназначено для случаев, когда эти таблицы имеют совпадающие индексы (они будут подставлены в качестве LLD-макроса {#SNMPINDEX}). В вашем же случае, насколько я понял с ваших слов, индексы у этих таблиц отличаются: для одной из них они имеют вид ".X", а для другой - вид ".X.Y".

Так я с самого начала про это пишу. Да, проблема именно в этом. Всё остальное следствие из этой проблемы. Но пути решения я не вижу.
ну и ещё я уточню, что X в .X.Y равен X в .X И для каждого X сущствует только 1 Y. Так что я бы сказал что индекс равен, но вот формат его отличается. Поэтому в OID итема я могу его поправить регекспом, А вот в дискавере нет .

[Lurker]

Ссылка на Дискаверинг (автообнаружение) выше.
ПОйдем другим путем:
какие значения выдает автообнаружение? (там есть кнопочка тест, и можнео получить как сырые значения, так и уже предобработанные).

Написано после получени предыдущего сообщения.
Что делает заббикс: он обращается по конкретному OIDу, получает данные и это будет столбец с имя_макроса1, по второму имя_макроса2 и т.д. .
На основании этого можно строить прототипы ЭД или тригеров.
Если дискаверинг не возвращает столбец (json etc) по какомй то макросу, смею сделать предположение, что конечное устройство его не отдает. ПРичин может быть множество, от доступов до ошибки в названиии
Да, при этом заббикс сам добавляет свой макрос: {#SNMPINDEX}

Только она не на тот дискавер и не работает. Пишет Пожалуйста, воспользуйтесь боковым меню для доступа к содержимому раздела Обнаружение.
[{"{#SNMPINDEX}":"436207616.9371649","{#NEIGHBOR}": "MOS-CORE"} Ну и далее подобные записи. {#INTNAME} Нет.

Я не работаю с SNMP, нео из документации видно, что на вход внутреннему скрипту дискаверинга подается перечень пар, таких как имя_макроса и что-то, называемое OID. При этом количество таких пар не ограничено.

1)не OID, SNMPINDEX Это конец OID. На понятный вам язык начало OID Говорит нам что мы опрашиваем (например загрузка ЦП) а конец указывает на номер ЦП.
О чём умалчивается в документации, что SNMPINDEX генерируется ТОЛЬКО для первого макроса. для последующих макросов берётся значение, сгенерированное для первого макроса. В подавляющем большинстве случаев это работает.
Условно говоря вы опросили
OIDa.snmpindex, получили загрузку цп.
OIDb.snmpindex получили энергопотребление цп. Но это не сработает если значение энергопотребления будет хранится по адресу OIDb.snmpindex.randomvalue т.к. по сути snmpindex будет snmpindex.randomvalue

[Alex_UUU]

Условно говоря вы опросили
OIDa.snmpindex, получили загрузку цп.
OIDb.snmpindex получили энергопотребление цп. Но это не сработает если значение энергопотребления будет хранится по адресу OIDb.snmpindex.randomvalue т.к. по сути snmpindex будет snmpindex.randomvalue

Прикольное оборудование:
Сервер1.Процессор1.Температура1.ТемператураПроцесс ора2
Сервер1.Процессор1.Температура2.ТемператураПроцесс ора1

[Kos]

Сослаться можно, но работает это криво т.к. триггер может создасться до того, как опросится итем. В этом случае триггер не переименуется.

Не совсем понял вашу мысль.
Триггер в любом случае создаётся раньше, чем опросится элемент данных. Создание триггера (как и элемента данных) происходит при отрабатывании правила низкоуровневого обнаружения (LLD), после этого созданный элемент данных (айтем) начинает опрашиваться, а созданный триггер - контролировать полученные значения. При выполнении условий триггера создаётся событие "триггер перешёл в состояние ПРОБЛЕМА" и генерируется собственно проблема, имя которой наследуется от триггера.

Вот пример триггеров, созданных LLD-правилом (правда, без участия SNMP). В условиях триггера используется два элемента данных, а в имени триггера - тот самый макрос {ITEM.VALUE}, который ссылается на значение первого из этих элементов данных. При срабатывании триггера порождается проблема, в имени которой вместо этого макроса будет конкретное значение (на момент срабатывания триггера).

ну и ещё я уточню, что X в .X.Y равен X в .X И для каждого X сущствует только 1 Y. Так что я бы сказал что индекс равен, но вот формат его отличается. Поэтому в OID итема я могу его поправить регекспом, А вот в дискавере нет .

Как вариант: если для создания прототипа триггера вам всё же требуется предобработанный индекс (например, от имеющегося индекса в формате "X.Y" откусывать только часть "X"), то это можно сделать с помощью предобаботки на уровне правила LLD. Если интересует этот вариант, то могу найти ссылку на пример реализации.

[Kos]

Если интересует этот вариант, то могу найти ссылку на пример реализации.

Собственно, вот он, этот пример (ссылка).
Если вы таки покажете пример того, что возвращается вашим правилом дискаверинга

discovery[{#NEIGHBOR}, 1.3.6.1.4.1.9.9.23.1.2.1.1.6]

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