Быстрый SNMP опрос сетевых устройств

[tubecleaner]

Посмотрите AnyEvent::SNMP — я использую его.

[Di-Ger]

AnyEvent конечно замечательная штука, я сейчас ловлю SNMP-трапы с помощью этой либы. Но когда я писал этот скрипт, мои познания в перл были на уровне «никакой», и AnyEvent для меня был, что-то вроде тригонометрии для первоклассника. А сейчас уже смысла не вижу переписывать, и так все устраивает. И да, в моем случае даже не нужно ничего доустанавливать, библиотека идет в комплекте с net-snmp.

[openbsod]

Спасибо за статью, очень интересно. В свое время нашел github.com/mteg/braa Насколько хтонично, настолько и интересная реализация, просто ураган.

[FotoHunter]

Спасибо за статью. Я мониторю "Кактусом", мои самописные скрипты на bash и это жесть, когда начинаются задержки и подтормаживания - в сетке около 100 железок, некоторые не бьются по mib-ам и потому для них всё исключительно самописное и значит тормозное (процессор Carl в промышленных кондиционерах выдаёт свои параметра в виде 3х производных таблиц, расстановка значений в которых зависит от фантазии программмстов конкретной железки - у меня 3 разных кондея и у каждого всё по своему и большая удача, если есть таблица соответствия значения и номера ячейки не говоря уже о трапах/алармах). Попробую ваш скрипт себе прикрутить - надеюсь будет поменьше тормозов и подвисов, чем в стандартном snmpwalk ....

[Di-Ger]

Вообще, SNMP.pm фактически использует тот же программный код, что и snmpwalk. Тут снижение времени опросов достигается как раз на большом количестве устройств за счет использования &SNMP::MainLoop. С MIB отдельная история, практически все базы от вендоров приходится исправлять. Сейчас как раз пишу статью про MIB браузер, постараюсь привести несколько примеров.

[Da_Uff]

Скорость сбора данных по snmp зависит не столько от того, кто запрашивает и как на нем это реализовано, сколько от отвечающего девайса. Упомянутый вами Observium на моем опыте за 10 секунд снимает с каталиста-шеститонника порядка тысячи OID-ов, а со свитчей доступа намного более дебильных производителей типа господи прости д-линка, с каждого может мучаться с десятью цифрами до минуты в зависимости от настроения коммутатора. А код ваш быстро работает, потому что, вот же положила, сам автор написал использует асинхронные вызовы и, таким образом, не ожидает ответа с той стороны для совершения следующей итерации. Все бы хорошо, но есть далеко ненулевая вероятность, что таким образом данные вы соберёте не все.

[Di-Ger]

Тут не совсем с Вами соглашусь. Понятно, что многое зависит от самого оборудования, не так давно разбирался с техподдержкой одного вендора как раз по поводу фризов при опросе LLDP таблиц. Из-за того, что один из индексов они отдавали в HEX вместо STRING обработка увеличивалась на 2-6 секунд. Но…
На том же Perl я сравнивал две реализации работы с snmp, тот же SNMP.pm и Net::SNMP. Первая однозначно выигрывала по скорости. Потом многое зависит того используются ли запросы типа snmptable или getnext, при правильно сформированном запросе можно получить заметный прирост в производительности. Как ни странно, многое зависит от того, пользуетесь ли вы текстовыми идентификаторами или цифровыми OID, вернее как реализовано преобразование. Если NMS перегружена MIB, а как правило в дефолтных инсталляциях так и есть, скорость так же падает.