Comments 7
Посмотрите AnyEvent::SNMP — я использую его.
AnyEvent конечно замечательная штука, я сейчас ловлю SNMP-трапы с помощью этой либы. Но когда я писал этот скрипт, мои познания в перл были на уровне «никакой», и AnyEvent для меня был, что-то вроде тригонометрии для первоклассника. А сейчас уже смысла не вижу переписывать, и так все устраивает. И да, в моем случае даже не нужно ничего доустанавливать, библиотека идет в комплекте с net-snmp.
Спасибо за статью, очень интересно. В свое время нашел github.com/mteg/braa Насколько хтонично, настолько и интересная реализация, просто ураган.
Спасибо за статью. Я мониторю "Кактусом", мои самописные скрипты на bash и это жесть, когда начинаются задержки и подтормаживания - в сетке около 100 железок, некоторые не бьются по mib-ам и потому для них всё исключительно самописное и значит тормозное (процессор Carl в промышленных кондиционерах выдаёт свои параметра в виде 3х производных таблиц, расстановка значений в которых зависит от фантазии программмстов конкретной железки - у меня 3 разных кондея и у каждого всё по своему и большая удача, если есть таблица соответствия значения и номера ячейки не говоря уже о трапах/алармах). Попробую ваш скрипт себе прикрутить - надеюсь будет поменьше тормозов и подвисов, чем в стандартном snmpwalk ....
Вообще, SNMP.pm фактически использует тот же программный код, что и snmpwalk. Тут снижение времени опросов достигается как раз на большом количестве устройств за счет использования &SNMP::MainLoop. С MIB отдельная история, практически все базы от вендоров приходится исправлять. Сейчас как раз пишу статью про MIB браузер, постараюсь привести несколько примеров.
Скорость сбора данных по snmp зависит не столько от того, кто запрашивает и как на нем это реализовано, сколько от отвечающего девайса. Упомянутый вами Observium на моем опыте за 10 секунд снимает с каталиста-шеститонника порядка тысячи OID-ов, а со свитчей доступа намного более дебильных производителей типа господи прости д-линка, с каждого может мучаться с десятью цифрами до минуты в зависимости от настроения коммутатора. А код ваш быстро работает, потому что, вот же положила, сам автор написал использует асинхронные вызовы и, таким образом, не ожидает ответа с той стороны для совершения следующей итерации. Все бы хорошо, но есть далеко ненулевая вероятность, что таким образом данные вы соберёте не все.
Тут не совсем с Вами соглашусь. Понятно, что многое зависит от самого оборудования, не так давно разбирался с техподдержкой одного вендора как раз по поводу фризов при опросе LLDP таблиц. Из-за того, что один из индексов они отдавали в HEX вместо STRING обработка увеличивалась на 2-6 секунд. Но…
На том же Perl я сравнивал две реализации работы с snmp, тот же SNMP.pm и Net::SNMP. Первая однозначно выигрывала по скорости. Потом многое зависит того используются ли запросы типа snmptable или getnext, при правильно сформированном запросе можно получить заметный прирост в производительности. Как ни странно, многое зависит от того, пользуетесь ли вы текстовыми идентификаторами или цифровыми OID, вернее как реализовано преобразование. Если NMS перегружена MIB, а как правило в дефолтных инсталляциях так и есть, скорость так же падает.
На том же Perl я сравнивал две реализации работы с snmp, тот же SNMP.pm и Net::SNMP. Первая однозначно выигрывала по скорости. Потом многое зависит того используются ли запросы типа snmptable или getnext, при правильно сформированном запросе можно получить заметный прирост в производительности. Как ни странно, многое зависит от того, пользуетесь ли вы текстовыми идентификаторами или цифровыми OID, вернее как реализовано преобразование. Если NMS перегружена MIB, а как правило в дефолтных инсталляциях так и есть, скорость так же падает.
Sign up to leave a comment.
Быстрый SNMP опрос сетевых устройств