Ошибка "No Such Object available on this agent at this OID"

[registr76]

Версия Zabbix 6.2.6

Здравствуйте.

Делаю шаблон для мониторинга клиентов WiFi сети оборудования Mikrotik.
В зависимости от версии прошивки некоторые OID могут отсутствовать.
При создании правила обнаружения получаю значения двух OID для макросов {#SNMPVALUE} и {#RADIONAME}.

#SNMPVALUE - содержит значение мак-адреса интерфейса клиента
#RADIONAME - содержит имя клиента, если указано в настройках

Запрос выглядит так:

SNMP OID

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1,{#RADIO NAME},1.3.6.1.4.1.14988.1.1.1.2.1.20]

В инструкции ZABBIX для низкоуровневого обнаружения SNMP сказано:

Если обнаруженный объект не имеет указанный OID, тогда по этому объекту соответствующий макрос пропускается. Например, если у нас есть следующие данные...

http://www.zabbix.com/documentation/...very/snmp_oids

В опрашиваемом оборудовании OID 1.3.6.1.4.1.14988.1.1.1.2.1.20 (RADIONAME) отсутствует и по логике этот макрос должен быть пропущен.
Однако я получаю ошибку No Such Object available on this agent at this OID

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

[Kos]

В инструкции ZABBIX для низкоуровневого обнаружения SNMP сказано:

http://www.zabbix.com/documentation/...very/snmp_oids

В опрашиваемом оборудовании OID 1.3.6.1.4.1.14988.1.1.1.2.1.20 (RADIONAME) отсутствует и по логике этот макрос должен быть пропущен.
Однако я получаю ошибку No Such Object available on this agent at this OID

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

Я так понял, что в инструкции имеется в виду ситуация, когда опрашиваемые таблицы имеют различную размерность или, в общем случае, несовпадение индексов (как в приведённом там примере: в таблице ifDescr есть индексы 1, 2 и 4, а в таблице ifAlias - 1, 2, 3 и 5). Тогда соответствующий макрос будет отсутствовать в итоговом JSON-е для несуществующего индекса.
Но OID-ы для самих таблиц должны существовать (возможно, возвращая пустые таблицы, но не ошибки).

А в вашем случае вообще не срабатывает правило LLD? При попытке сделать тест соответствующей кнопкой - не возвращается JSON, а приходит ошибка?

[registr76]

Я так понял, что в инструкции имеется в виду ситуация, когда опрашиваемые таблицы имеют различную размерность или, в общем случае, несовпадение индексов (как в приведённом там примере: в таблице ifDescr есть индексы 1, 2 и 4, а в таблице ifAlias - 1, 2, 3 и 5). Тогда соответствующий макрос будет отсутствовать в итоговом JSON-е для несуществующего индекса.
Но OID-ы для самих таблиц должны существовать (возможно, возвращая пустые таблицы, но не ошибки).

А в вашем случае вообще не срабатывает правило LLD? При попытке сделать тест соответствующей кнопкой - не возвращается JSON, а приходит ошибка?

Здравствуйте.

Да правило LLD не срабатывает и при тестировании сразу выдаёт ошибку.

Возможно ли задать значение по умолчанию для макроса, которое, будет подставляться если OID не обнаружен?

И еще глупый вопрос. Как вообще посмотреть JSON, который, возвращает zabbix после запроса?

[Kos]

Да правило LLD не срабатывает и при тестировании сразу выдаёт ошибку.
[...]
Как вообще посмотреть JSON, который, возвращает zabbix после запроса?

Кнопкой "Test" в настройках правила обнаружения.
Только, если у вас сразу выдаёт ошибку, то вы увидите не сгенерированный JSON, а сообщение об ошибке.

Возможно ли задать значение по умолчанию для макроса, которое, будет подставляться если OID не обнаружен?

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

Возможно, получится выкрутиться через использование singleton-ов (ссылка) следующим образом:

• через отдельное правило LLD проверять наличие второй таблицы (которая может быть, а может отсутствовать);
• в зависимости от результата проверки генерировать тот или иной singleton: либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1,{#RADIONAME},1.3.6.1.4.1.14988.1.1.1.2.1.20]

(если вторая таблица есть), либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1]

(если её нет). В любом случае, должен сгенерироваться обычный элемент данных, где в качестве ключа прописано "discovery[...]" и возвращается корректный JSON.

• уже существующее правило LLD модифицировать таким образом, чтобы оно использовало зависимый элемент данных, где основным является тот, который был сгенерировал этим singleton-ом.

[registr76]

Идея прекрасная.

К сожалению информации по LLD Singleton крайне мало. Кроме нескольких постов на форуме, презентации Виталия Журавлёва и ссылке на документацию, что вы дали выше, ничего не нашел. Еще Singleton встречается нескольких шаблонах. Но там в основном не SNMP, а где SNMP там запрашивают значение существующего OID и на его базе генерируют SIngleton.

Понятно одно.
Чтобы создать зависимый элемент обнаружения, нужно изначально создать обычный элемент данных. Если он (обычный элемент данных) существует, можно в зависимом правиле обнаружения, или элементе данных, генерировать тот или иной Singleton. Потом его (Singleton) подставить в правило обнаружения, которое, будет собирать данные.

Если всё так, то возникает проблема. OID составной 1.3.6.1.4.1.14988.1.1.1.2.1.20.{#SNMPINDEX}. {#SNMPINDEX} всегда разный. Например OID может выглядеть вот так 1.3.6.1.4.1.14988.1.1.1.2.1.20.72.143.90.101.22.14 0.1 . Если запрашивать только первую часть 1.3.6.1.4.1.14988.1.1.1.2.1.20, от элемент данных всегда выдаёт ошибку. То есть просто проверить существует таблица 1.3.6.1.4.1.14988.1.1.1.2.1.20.{#SNMPINDEX} или нет не получится. Только через правило обнаружения. А как добавить прототипы данных из одного правила обнаружения в качестве основного элемента данных в зависимое правило обнаружения понять не могу.

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

[Kos]

• уже существующее правило LLD модифицировать таким образом, чтобы оно использовало зависимый элемент данных, где основным является тот, который был сгенерировал этим singleton-ом.

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

(добавлено)
Это ограничение, вроде, можно обойти при помощи промежуточного элемента данных с типом "вычисляемый".
Получается немного громоздко, но должно работать.
Если интересно, то чуть позже опишу подробнее, что у меня получилось. Конечный результат - это элемент данных с типом данных "Текст", который будет содержать значение JSON-а, получаемого опросом либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1,{#RADIONAME},1.3.6.1.4.1.14988.1.1.1.2.1.20]

либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1]

в зависимости от того, поддерживается ли таблица 1.3.6.1.4.1.14988.1.1.1.2.1.20 на конкретном устройстве или нет. И этот элемент данных можно дальше использовать в качестве мастер-айтема для правила обнаружения конкретных клиентов. И уже в этом правиле обнаружения дальше корректно обрабатывать наличие либо отсутствие LLD-макроса {#RADIONAME}.

[registr76]

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

Конечно интересно!

Я пришел к аналогичным результатам.
Правда через костыль. Получил версию РоутерОС в качестве элемента данных.
Создал зависимый то неё элемент данных и сформировал правильное значение для {#SINGLETON}.
Далее создал зависимое правило обнаружения. Но пока не понятно как всё это тестировать.
Сейчас разбираюсь. Напишу по результатам.

// The script processes the value of the VALUE variable. The value is equal to the ROUTEROS version.
// We use a slice of the value of the VALUE variable up to the fourth digit. We bring to the digital value.
// If the version is higher than 6.46 we request the RADIONAME OID value.

return JSON.stringify(parseFloat(value.slice(0,4)) >= 6.46 ?
[{'{#SINGLETON}': 'discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1,{#RADIONAME},1.3.6.1.4.1.14988.1.1.1.2.1.20]'}] :
[{'{#SINGLETON}': 'discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1]'}]);

[Kos]

О, интересная мысль: можно же сразу отдавать в виде LLD-макроса то значение, которое надо подставить в поле OID. Я извращался через LLD override, получалось громоздко (но работало). Одна голова хорошо, а две лучше!
Я сегодня уже не успею, опишу свои изыскания попозже.

[Kos]

опишу свои изыскания попозже

В общем, у меня получилось так (пытаюсь приложить скриншоты).

Шаг 1.
Создаём обыкновенный элемент данных (т.е. не прототип):

Тип: SNMP agent
Ключ: mikrotik.radioname-check
Тип информации: текст
SNMP OID: discovery[{#SNMPVALUE},1.3.6.1.4.1.23.2.28.2.14.1.2.10]

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

Ключевой момент здесь - предобработка. Если таблица по такому OID-у присутствует, то всё ОК: её можно будет в дальнейшем проверять, а сейчас нам вернётся хоть что-то, какой-то валидный JSON (даже если в данный момент клиентов нет и эта таблица пустая - вернётся JSON в виде пустого массива).
Если же такой таблицы нет, то вернётся ошибка и элемент данных попытается перейти в неподдерживаемое состояние. Мы эту ситуацию отлавливаем с помощью первого шага предобработки: если элемент данных в неподдерживаемом состоянии, то заменяем его пустой строкой (или любой другой фигнёй, которая не является валидным JSON-ом).
Вторым шагом предобработки является короткий код на JavaScript, который проверяет валидность JSON-а на входе и, в зависимости от этого, генерирует тот или иной JSON на выходе.
JSON на выходе предназначен для LLD, он всегда содержит массив из одного элемента, содержащий объект с двумя полями:

• {#SINGLETON} - пустое значение
• {#OID} - та строка, которую нужно будет подставить в поле "OID": либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1]

либо

discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1,{#RADIONAME},1.3.6.1.4.1.14988.1.1.1.2.1.20]

Код JavaScript:

var present = '';
try {
  //transform source string into JSON object
  value = JSON.parse(value);
  //if parse was successful, it is a valid JSON; otherwise the exception will be thrown
  present = ',{#RADIONAME},1.3.6.1.4.1.14988.1.1.1.2.1.20';
}
catch (error){ ; }
return '[{"{#SINGLETON}": "", "{#OID}": "discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1' + present + ']"}]';​

Скриншот 1:

Скриншот 2:

Шаг 2.
Создаём правило низкоуровневого обнаружения:

Тип: Зависимый
Ключ: mikrotik.radioname-check.discovery
Основной элемент данных: выбранный па шаге 1

Теоретически, можно было бы весь первый шаг запихнуть сюда, но проблема в том, что для правил LLD в предобработке нет возможности добавить шаг "проверка на неподдерживаемое значение", поэтому приходится извращаться так.
Скриншот 3:

[Kos]

Шаг 3.
В созданное на предыдущем шаге правило LLD добавляем прототип-синглтон, который всегда будет создавать один элемент данных с ключом "mikrotik.radionames[]":

Тип: SNMP агент
Ключ: mikrotik.radionames[{#SINGLETON}]
Тип информации: Текст
SNMP OID: {#OID}

Этот элемент данных будет использоваться для второго правила обнаружения, которое будет создавать из прототипов нужные элементы данных и триггеры для конкретных клиентов.
Он будет содержать JSON, поэтому тип данных для него - текст, а история - короткая, но ненулевая (например, 1 день).
Скриншот 4:

Шаг 4.
Создаём ещё один обычный (т.е. не прототип) элемент данных. Он нужен исключительно для того, чтобы обойти сразу два ограничения:

• в настройках правила LLD нельзя использовать вычисляемый тип;
• если в настройках правила LLD использовать зависимый тип, то он может ссылаться только на какой-то уже существующий элемент данных (а не такой, который лишь будет создан при помощи нашего синглтона).

Итак, делаем:

Тип: Вычисляемый
Ключ: mikrotik.radioname-check.get
Тип информации: Текст
Формула: last(//mikrotik.radionames[])
Интервал: такой же, как у прототипа из шага 3

Этот элемент данных служит лишь для того, чтобы на него можно было сослаться во втором правиле LLD как на основной элемент данных (master); поэтому его история нам не нужна (хотя для отладки, опять же, можно её поставить, допустим, 1 день).
Изначально (до того, как отработало первое правило дискаверинга и созданный им элемент данных получил своё первое значение) этот элемент данных будет в неподдерживаемом состоянии - это нормально.
Скриншот 5:

Шаг 5.
Создаём, наконец, наше правило LLD для клиентов:

Тип: Зависимый
Ключ: mikrotik.radio-clients.discovery
Основной элемент данных: созданный на шаге 4

Скриншот 6:

Ну, дальше уже настраиваем прототипы и прочее по вкусу.

[registr76]

Огромное спасибо!

Вернулся из командировки.
Завтра попробую настроить шаблон по вашей инструкции.

[registr76]

Сделал шаблон по вашей инструкции.

Для его корректной работы нужно обновить zabbix до последней версии. На версии 6.2.6, на втором шаге не работал. Ругался на JSON объект. Обновил до 6.2.9 и всё заработало.

Еще раз огромное спасибо за подробные примеры.
Пока делал и тестировал многому научился. )

PS.
Готовый шаблон закрепил в этом сообщении.
Возможно кому-нибудь пригодится.

[sadman]

Раз в гугле эта тема выпадает по запросу "zabbix SINGLETONE", то поделюсь тут своим простецким способом манипуляции с синглтоном.

Задача: сделать общий шаблон для SMNPv2 устройств, часть моделей которых имеет поддерево с расширенной статистикой, а часть не имеет. При подключении шаблона к любой модели требуется избежать перехода метрик, связанных с расширенной статистикой, в состояние "Не поддерживается".

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

Основная проблема - определение в рамках выполнения правила низкоуровневого обнаружения наличия соответствующего поддерева SNMP. Для этого берем произвольный коротенький фрагмент этого дерева. Существование в нём перечисления индексов или чего-то подобного не принципиально. Главное - чтобы выполнялось discovery[].

В MIB-браузере находим что-нибудь подходящее:



Правило обнаружения сконфигурируем так:



Добавим к нему препроцессинга со маленьким скриптом:

return JSON.stringify(value === '[]' ? [] : [{'{#SINGLETON}': 'extended'}]);

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



Готово!