Ошибка при обработке OID

[Steal]

Дорогие форумчане, поделитесь опытом. Пытаюсь настроить мониторинг ИБП марки Eaton. Есть OID 1.3.6.1.4.1.534.1.7.2.1 из MIB XUPS и аналог этого OID 1.3.6.1.2.1.33.1.6.2.1. Через snmpwalk Zabbix 6.0 выдаёт ответ, представленный на рисунке. И вот в чём проблема - я хочу получить данныt только из 1.3.6.1.2.1.33.1.6.2.1.2 (upsAlarmDescr). Но элемент данных с этим OID выдаёт ошибку, хотя через snmpwalk данный OID 1.3.6.1.2.1.33.1.6.2.1.2 (upsAlarmDescr) откликается. В чём может быть проблема? Почему через snmpwalk OID 1.3.6.1.2.1.33.1.6.2.1.2 (upsAlarmDescr) откликается, а прописав его в элемент данных - выдаёт ошибку

[Hamardaban]

Потому, что zabbix "использует" snmpget а не snmpwalk .
Т.е. не бежит по дереву мибов а запрашивает конкретное значение.
укажите в элементе .1.3.6.1.2.1.33.1.6.2.1.2.0

[Steal]

Потому, что zabbix "использует" snmpget а не snmpwalk .
Т.е. не бежит по дереву мибов а запрашивает конкретное значение.
укажите в элементе .1.3.6.1.2.1.33.1.6.2.1.2.0

Это я понимаю. Я указал конкретный OID 1.3.6.1.2.1.33.1.6.2.1.2 (пробовал и с 0 на конце и без). Но не работает. Так же изменял тип получаемых данных ( ставил Текст и Лог). Результат тот же. snmpwalk через консоль выдаёт нужную информацию. Но если я пишу это же в элемент данных - ошибка.

[Hamardaban]

Выполните snmpwalk с параметрами -Ona для 1.3.6.1.2.1.33.1.6.2.1.2
а также snmpget для 1.3.6.1.2.1.33.1.6.2.1.2
и покажите результаты.
Также проверьте правильность указания параметров snmp для интерфейса - всё правильно?
Утилитами запрашиваете с того-же сервера который обслуживает данный узел сети?
может дело не в бобине?

[Kos]

Насколько видно из вашего же скриншота, реальный OID оканчивается на ".464".

[Steal]

Выполните snmpwalk с параметрами -Ona для 1.3.6.1.2.1.33.1.6.2.1.2
а также snmpget для 1.3.6.1.2.1.33.1.6.2.1.2
и покажите результаты.
Также проверьте правильность указания параметров snmp для интерфейса - всё правильно?
Утилитами запрашиваете с того-же сервера который обслуживает данный узел сети?
может дело не в бобине?

Параметры проверил. Всё верно. Остальные параметры опрашиваются без проблем. SNMP работает. Заметил одну особенность. Когда ошибка пропадает, то пропадает и сам OID 1.3.6.1.2.1.33.1.6.2.1.2. Т.е. OID 1.3.6.1.2.1.33.1.6 показывает только один параметр. И вторая вещь, после исчезновения ошибки и её повторного появления - изменилось окончание OID с 464 на 556.

[Steal]

Насколько видно из вашего же скриншота, реальный OID оканчивается на ".464".

При указании полного OID - zabbix вообще его не находит. И окончание динамическое. При закрытии проблемы и её повторном появлении OID заканчиванся на .560, потом .556 и т.п.

[Kos]

При указании полного OID - zabbix вообще его не находит. И окончание динамическое. При закрытии проблемы и её повторном появлении OID заканчиванся на .560, потом .556 и т.п.

Тогда сложнее, но, теоретически, так тоже можно извратиться:

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

Только для меня всё равно польза такого решения остаётся довольно сомнительной: ведь, если я правильно понимаю, в качестве результата вы в данном случае вы получите OID, характеризующий проблему; для его расшифровки необходим MIB-файл и, видимо, какие-то дальнейшие преобразования в более читабельный вид.

[Hamardaban]

По практике работы с SNMP: вопросы информирования о возникновении "алармов" на оборудовании нужно решать через SNMP trap....
Да - у этого метода есть куча недостатков (например оборудование может в принципе не поддерживать трепы) но основное преимущество в скорости и адресности реакции.
А может имеет смысл опрашивать upsAlarmsPresent (1.3.6.1.2.1.33.1.6.1) ? и от этого "плясать"?

[Steal]

По практике работы с SNMP: вопросы информирования о возникновении "алармов" на оборудовании нужно решать через SNMP trap....
Да - у этого метода есть куча недостатков (например оборудование может в принципе не поддерживать трепы) но основное преимущество в скорости и адресности реакции.
А может имеет смысл опрашивать upsAlarmsPresent (1.3.6.1.2.1.33.1.6.1) ? и от этого "плясать"?

А что это даст? И вопрос как из него забрать нужную инфу?

[Hamardaban]

Получить инфу SNMP запросом. Насколько понимаю значением будет количество активных проблем. Если больше 0 - аларм.


Априори мыж не знаем ваших задач - гадаемс. С динамическими индексами уже разобрались.

[Steal]

Получить инфу SNMP запросом. Насколько понимаю значением будет количество активных проблем. Если больше 0 - аларм.


Априори мыж не знаем ваших задач - гадаемс. С динамическими индексами уже разобрались.

Такой триггер давно есть. Вот только доступа у персонала к оборудованию нет. Получится, что проблема есть, но какая неизвестно)

[Hamardaban]

А с трэпами пробовали работать?

[Steal]

А с трэпами пробовали работать?

Сегодня буду пробовать. Пока не уверен, что ИБП поддерживает отправку Traps

[Hamardaban]

какая модель ибп?

[Steal]

Eaton 9PX 3000i