GFORGX Опубликовано 17 марта, 2011 (изменено) · Жалоба Есть странное желание мониторить трафик по каждому абонентскому порту (не только по магистральным). В своё время использовали mrtg для мониторинга по SNMP нагрузки портов с чуда под названием AlliedTelesis AT9000/28SP (коммутатор неплохой, не в обиду сказано будет), так вот, управление - через пару дней отваливалось стабильно до ребута, к счастью, коммутировать при этом он не переставал. Так вот, кто-нибудь издевался так жестоко над 3528? Изменено 17 марта, 2011 пользователем GFORGX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dnk.nbd Опубликовано 17 марта, 2011 · Жалоба 3828, 3028, 3200 не загибаются. Норм молотят. Думаю 3528 тоже справится. Только с интервалом съема данных не наглейте. А АТ9000 действительно управление отваливается до ребута, а вот молотит норм. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nickuz Опубликовано 17 марта, 2011 · Жалоба Сорри за оффтоп, а MRTG настолько удобен для дальнейшей обработки результатов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dnk.nbd Опубликовано 17 марта, 2011 · Жалоба Нет конечно, я имел ввиду что съем данных по SNMP не нагибает коммутаторы. А уж просмотр, заббикс например. Опять же все от задачи зависит. Если один, два, три коммутатора, то нет смысла городить что-то большее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 17 марта, 2011 · Жалоба Нет конечно, я имел ввиду что съем данных по SNMP не нагибает коммутаторы. А уж просмотр, заббикс например.Опять же все от задачи зависит. Если один, два, три коммутатора, то нет смысла городить что-то большее. Коммутаторов - около 300, а прикрутить планируется к уже и без того пиленному Smokeping (складывание в БД, кружочки с текущим состоянием и audio-тэги в листинге, просмотр логов из Syslog, ещё всякое), сейчас выглядит как-то так: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 17 марта, 2011 · Жалоба Сорри за оффтоп, а MRTG настолько удобен для дальнейшей обработки результатов? Возможно я не умею его готовить, но с rrdtool 300*24 портов на одном экране как-то неудобно смотреть. Появилась ли нормальная альтернатива routers2.cgi ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 17 марта, 2011 · Жалоба Сорри за оффтоп, а MRTG настолько удобен для дальнейшей обработки результатов? Возможно я не умею его готовить, но с rrdtool 300*24 портов на одном экране как-то неудобно смотреть. Появилась ли нормальная альтернатива routers2.cgi ? Зачем? Показывать только 24 порта на страничке одного коммутатора :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 17 марта, 2011 · Жалоба Думаю 3528 тоже справится. Только с интервалом съема данных не наглейте. Дефолтное Debian-овское */5 (минуты) - это нагло? :) Хотя, ясно дело, поставлю больше, с 300 железками оно за 5 минут не успеет обойти всё это. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 марта, 2011 (изменено) · Жалоба Думаю 3528 тоже справится. Только с интервалом съема данных не наглейте.Дефолтное Debian-овское */5 (минуты) - это нагло? :) Хотя, ясно дело, поставлю больше, с 300 железками оно за 5 минут не успеет обойти всё это. А что мешает запустить опрашивалку в N потоков/процессов? Больше 5 минут интервал лучше не делать, уж слишком всё будет усреднённо. Советую потестировать даже с интервалом в 1 минуту. Можно ещё задействовавать snmpbulkget и все порты опросить за 6 запросов(3 запроса на ifHCInOctets и 3 на out). cacti умеет snmpbulkget и многопоточность, советую присмотреться. Для пары-тройки сотен коммутаторов вполне нормальное решение. Изменено 17 марта, 2011 пользователем s.lobanov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
