Использование SNMP Trap/Inform сообщений в мониторинге сети

[Wundarshular]

Спасибо за статью, довольно насыщенный текст.
Лично мой опыт использования трапов в мониторинге показал, что иной раз всё таки эффективнее распарсить логи соседнего оборудования. В частности, потому что syslog вроде как у всех одинаковый: либо RFC3164, либо RFC5424, в то время как SNMP допускает издеваться над форматами сообщений как душе угодно.

Не могли бы вы уточнить различия между вашим приёмником трапов и модуля snmptrap в составе net-snmp? Помимо того, что у вас конфигурационный файл выглядит более человекочитаемым.
Те же Zabbix предлагают связку net-snmp + snmptt. И то snmptt только потому что там переформатирование сообщения выполнять комфортнее чем средствами net-snmp.

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

Не могли бы вы привести пример таких приёмников?

Зачастую нужно обязательно указывать engine id

Не зачастую, а всегда - https://www.ietf.org/rfc/rfc2571.txt раздел 3.1.1.1. Протокол рассчитывает на это, чтобы идентифицировать хост-отправитель трап\информ-сообщения.

В качестве подопытного коммутатора выступит Cisco Catalyst IE-3000-8TC.

Это вы, бесспорно, хорошо придумали. У Cisco подробные хорошо стандартизированные MIB. Было бы здорово посмотреть решение вашей задаче на стенде с менее именитым железом. Которое из трапов если поддерживает хоть что-то, то не более чем вот этот раздел -http://oidref.com/1.3.6.1.6.3.1.1.5

Помимо этого вижу, вы завели отдельный элемент данных для приёма сообщений с тестируемого интерфейса. В реальной среде не замучаетесь эту работу выполнять для каждого нового сетевого устройства в системе мониторинга? Discovery в Zabbix, конечно, могуч, но тем не менее.

[OlegPowerC]

Добрый день.

Спасибо за комментарий.

Попробую по порядку ответить на ваши вопросы.

Хочу сразу обратить внимание что свой приемник делал как альтернативу приемникам основанным на Gosnmp/SNMP4J а не Net-SNMP но тем не менее сравнивать будем именно с Net-SNMP.

Итак давайте сразу заметим что при отправке Trap, коммутаторы используют свой локальный Engine-ID, а в конфигурации snmptrapd указывается связка engineid + username + auth/priv параметры.

В случае же Inform, Engine-ID используется удаленной стороны, то есть сервера.

Вот тут описана настройка и разница:

https://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html

И мы видим что в случае трапов, мы можем использовать одинаковые имена с разными параметрами (протоколы, пароли), так как engineid разный.

А в случае с Inform так не получится - engine id один, нашего сервера.

Я же решил отказаться от привязке к engine id в принципе (хотя разумеется добавить это не составит труда), а дать возможность сделать две стадии выборки учетных данных, по username + ip и просто по username (хотя можно еще и по engineid добавить).

Это не является какой то серьезной проблемой, можно просто использовать разные имена но все же.

Есть еще приемники трапов на базе SNMP4J, тот же Apache NiFi в связке с чем либо (Kafka например и далее чтото) Гибко, хорошо но затратно и явно не для простых кейсов.

Про Gosnmp можно даже не говорить - там даже v2c и v3 на одном порту принимать проблема.

Ну и да, не вижу смысла в каком то предварительном обработчике перед тем как записать в файл в моем случае, так как все легко дописывается прямо в приемнике, но в целом можно и отдать куда то еще на пост обработку.

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

По поводу Cisco/не Cisco - могу написать отдельную статью о настройке Trap/Inform v3 на Eltex/Huawei/Maipu - будет полезно?

Спасибо за уделенное внимание!