Re: SNMP - best practices?
On 04/12/11 19:27, Max Kosmach wrote: Ну вот у меня в не очень большой сети сейчас по SNMP идет: спасибо, именно это и хотелось услышать - мониторинг состояния принтеров - мониторинг оборудования (температура, загрузка CPU, загрузка портов) - мониторинг UPS (напряжение в сети, загрузка, статус) какими средствами ведётся мониторинг? - мониторинг серверов можно подробнее? что, как и зачем мониторится? - мониторинг VPN-шлюзов (статус, к-во соединений, загрузка и т.д.) имеются в виду железки от cisco и подобные? - сбор трапов от железок и VPN-шлюзов (пока без обработки) а что там интересного? - построение L2 карты сети - получение данных по соответствию портов коммутаторов, MAC-адресов и IP-адресов netdisco? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da599fc.3030...@yandex.ru
Re: SNMP - best practices?
13.04.2011 16:41, Ed пишет: On 04/12/11 19:27, Max Kosmach wrote: Ну вот у меня в не очень большой сети сейчас по SNMP идет: спасибо, именно это и хотелось услышать - мониторинг состояния принтеров - мониторинг оборудования (температура, загрузка CPU, загрузка портов) - мониторинг UPS (напряжение в сети, загрузка, статус) какими средствами ведётся мониторинг? мониторинг - nagios со штатными и своими плагинами картинки загрузки - сейчас collectd по большей части - мониторинг серверов можно подробнее? что, как и зачем мониторится? у меня мониторится статус нужных мне сервисов (пример - насколько криво отработал Symantec LiveUpdate Administrator сегодня) Можно мониторить всякие общие вещи типа свободного места и тд, но мне пока лень присматривать активно за тем, что просто работает - мониторинг VPN-шлюзов (статус, к-во соединений, загрузка и т.д.) имеются в виду железки от cisco и подобные? Нет, собственные интересное мне они умеют сообшать из командной строки, соотвественно дальше парсер для nagios и collectd - сбор трапов от железок и VPN-шлюзов (пока без обработки) а что там интересного? Коммутаторы - изменение конфигов, появление MAC на портах и т.д. VPN - ошибки создания IPSEC SA и т.д. Как я уже писал - это пока только укладывается в файл без обработки - построение L2 карты сети - получение данных по соответствию портов коммутаторов, MAC-адресов и IP-адресов netdisco? угумс с небольшим к-вом локальных костылей (получение ARP таблицы с pix, который не умеет SNMP, модификации для получения данных маршрутизаторов под Windows и Solaris и т.д.) и собранный из cvs, хотя вот прямо сейчас оно почти ничем не отличается от дистрибутивного. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da59fca.7060...@tcen.ru
Re: SNMP - best practices?
12.04.2011 2:13, Ed пишет: On 04/11/11 09:39, Max Kosmach wrote: 11.04.2011 1:03, Ed пишет: Сеть растёт, постепенно в ней накапливается всё больше устройств с поддержкой SNMP (свитчи, принтеры, ...). И думается мне - не просто так производители эту поддержку добавляли, может наверное SNMP приносить пользу админу. Главный вопрос, как и всегда, в том, что именно хочет админ :) Можно статистику собрать - collectd,cricket, rrd*, etc. статистика - имеется в виду в первую очередь скорость на портах? я так понимаю кратковременные всплески на ней будут не видны. collectd собирает статистику раз в 10 сек при умолчательных настройках. хотя все зависит от понятия кратковременные конечно хотя статистику с принтеров наверное интересно было бы собрать... как раз с принтеров интересно собирать не по snmp - чтобы была привязка к пользователям и т.д. Можно мониторить - nagios/icinga, snmptrapd, etc. а что именно можно мониторить? Можно захотеть чего-нибудь странного. PS: смотрел netdisco. вроде бы задумки неплохие, но впечатление осталось не очень. А что именно не очень? В своей области (сбор данных по L2/L3 устройствам, поддерживающим CDP/CDP-MIB и/или LLDP/LLDP-MIB, построение карты сети на L2, сбор IP и MAC адресов с привязкой к портам оборудования и т.д.) - вполне себе работает и неплохо. для dlink 2108 он не смог ничего считать - ни порты, ни vlan'ы (кривые MIB?) присылайте snmpwalk -v 1 -c public ваш-ip и snmpwalk -v 1 -c public ваш-ip enterprises.171 (если я правильно помню dlink) ну или сами гляньте. Если оно там в принципе есть (хотя мое общение с Dlink наводит на мысль, что железки данного производителя обычно весьма так себе и там запросто может ничего и не быть), то можно будет и глянуть почему оно не видится SNMP::Info для AT-8024 он смог получить только список mac-адресов. Аналогично По обоим пунктам - если оно в принципе есть в MIB, то добавить поддержку в SNMP::Info - дело 5 минут даже для человека, который perl видел только в страшных снах :) поставил на linux-роутер SNMP-агент - не использует arp-кеш (хотя по snmpwalk я его вижу); Что значит не использует arp-кеш? у меня с net-snmp все получает. А вместе с lldpd - tot b CDP/LLDP для autodiscovery хотелось бы VLAN'ы видеть именно как VLAN'ы, а не как отдельные интерфейсы (ну это скорее всего в SNMP-агенту). дело вкуса. Я не вижу принципиальных различий именно на роутере построение сети на мой взгляд могло бы быть более продвинутое - на основе собранной по SNMP информации можно было бы определять линки между устройствами, не поддерживающими LLDP (по мак-адресам). Готовы дописать?:) В принципе там оставлен костыль в виде внешнего файла топологии, который учитывается при построении графа. мне кажется должны существовать более продвинутые программы такого плана. Коммерческие виденные были мягко говоря тоже не без странностей. из открытых реализаций мне эту проще всего допиливать под мои нужды. Но могу подсказать несколько альтернатив не из дистрибутива: nedi, netdot, NAV. Кроме того был еще аналог netdisco на python в зачаточном состоянии, но я что-то не могу пока найти в памяти ссылку. Возможно это был wiremaps от автора lldpd. PS. для netdisco также есть всякие сторонние дополнения типа https://github.com/ollyg/Net-Appliance-Frontpanel/wiki и других, но большая часть заброшена - видать никому не нужно, хватает и базового функционала. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da3ef9f.7020...@tcen.ru
Re: SNMP - best practices?
On 04/12/11 10:22, Max Kosmach wrote: хотя статистику с принтеров наверное интересно было бы собрать... как раз с принтеров интересно собирать не по snmp - чтобы была привязка к пользователям и т.д. я как раз начал с вопроса зачем производители добавлюят поддержку SNMP?. применительно к тем же принтерам - ? поставил на linux-роутер SNMP-агент - не использует arp-кеш (хотя по snmpwalk я его вижу); Что значит не использует arp-кеш? у меня с net-snmp все получает. а у меня - нет (в результате соответствия mac-ip в программе нет) А вместе с lldpd - tot b CDP/LLDP для autodiscovery это работает, да. построение сети на мой взгляд могло бы быть более продвинутое - на основе собранной по SNMP информации можно было бы определять линки между устройствами, не поддерживающими LLDP (по мак-адресам). Готовы дописать?:) ну честно говоря мне не очень понравилась программа - начиная от процедуры установки deb-пакета и заканчивая веб-интерфейсрм. но если это лучше из опенсорного - то почему бы и не дописать ;) PS: и всё-таки на свой основной вопрос для решения каких задач можно (стоит) использовать SNMP в корпоративной сети я не получил ответа. вспомогательное средство при сборе информации о сети (в системах a-la netdisco) - понятно. счётчики байт на портах - понятно (хотя особой практической ценности не вижу). и всё? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da44d58.6080...@yandex.ru
Re: SNMP - best practices?
12.04.2011 17:02, Ed пишет: On 04/12/11 10:22, Max Kosmach wrote: хотя статистику с принтеров наверное интересно было бы собрать... как раз с принтеров интересно собирать не по snmp - чтобы была привязка к пользователям и т.д. я как раз начал с вопроса зачем производители добавлюят поддержку SNMP?. применительно к тем же принтерам - ? ну у них полно параметров которые можно мониторить у меня например - уровень чернил в картриджах и тд поставил на linux-роутер SNMP-агент - не использует arp-кеш (хотя по snmpwalk я его вижу); Что значит не использует arp-кеш? у меня с net-snmp все получает. а у меня - нет (в результате соответствия mac-ip в программе нет) хм, а что говорит snmpwalk -v 1 -c public localhost ipNetToMediaIfIndex snmpwalk -v 1 -c public localhost ipNetToMediaPhysAddress snmpwalk -v 1 -c public localhost ipNetToMediaNetAddress построение сети на мой взгляд могло бы быть более продвинутое - на основе собранной по SNMP информации можно было бы определять линки между устройствами, не поддерживающими LLDP (по мак-адресам). Готовы дописать?:) ну честно говоря мне не очень понравилась программа - начиная от процедуры установки deb-пакета и заканчивая веб-интерфейсрм. ну про эту часть не знаю - стоит самодельный deb с тех пор, пока ее еще не запаковали в Debian c ytrjnjhsvb [frfvb/ но если это лучше из опенсорного - то почему бы и не дописать ;) Может и не лучшее - если найдете интереснее, дайте знать PS: и всё-таки на свой основной вопрос для решения каких задач можно (стоит) использовать SNMP в корпоративной сети я не получил ответа. вспомогательное средство при сборе информации о сети (в системах a-la netdisco) - понятно. счётчики байт на портах - понятно (хотя особой практической ценности не вижу). и всё? Ну вот у меня в не очень большой сети сейчас по SNMP идет: - мониторинг состояния принтеров - мониторинг оборудования (температура, загрузка CPU, загрузка портов) - мониторинг UPS (напряжение в сети, загрузка, статус) - мониторинг серверов - мониторинг VPN-шлюзов (статус, к-во соединений, загрузка и т.д.) - сбор трапов от железок и VPN-шлюзов (пока без обработки) - построение L2 карты сети - получение данных по соответствию портов коммутаторов, MAC-адресов и IP-адресов Это то, что вспомнилось -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da46f59.7080...@tcen.ru
Re: SNMP - best practices?
12.04.2011 19:27, Max Kosmach пишет: ну у них полно параметров которые можно мониторить у меня например - уровень чернил в картриджах и тд А нет ли тут такого геморроя, что некоторые умеют так, некоторые сяк, а некоторые вообще не умеют? Или тут практиковался индивидуальный подход к настройке (и часть оборудования, соответственно, вообще не мониторится)? Или это решалось на стадии закупки оборудования? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da47111.40...@gmail.com
Re: SNMP - best practices?
12.04.2011 19:34, Dmitry Samsonov пишет: 12.04.2011 19:27, Max Kosmach пишет: ну у них полно параметров которые можно мониторить у меня например - уровень чернил в картриджах и тд А нет ли тут такого геморроя, что некоторые умеют так, некоторые сяк, а некоторые вообще не умеют? Или тут практиковался индивидуальный подход к настройке (и часть оборудования, соответственно, вообще не мониторится)? По-разному. В части сетевого оборудования - етсь общие варианты и частные. SNMP::Info как раз и помогает спрятать частности за общим интерфейсом. В части принтеров - разброд и шатании, но обычно есть mib-файлы вендора. Спасает то, что пока почти все мониторящееся - HP-шное, за исключением сетевого оборудования. Так что особых проблем нет. Или это решалось на стадии закупки оборудования? Оборудование,по крайней мере принтеры, выбирается все же по совсем другим критериям. По крайней мере у нас. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da4b50f.2060...@tcen.ru
Re: SNMP - best practices?
On 04/11/11 09:39, Max Kosmach wrote: 11.04.2011 1:03, Ed пишет: Сеть растёт, постепенно в ней накапливается всё больше устройств с поддержкой SNMP (свитчи, принтеры, ...). И думается мне - не просто так производители эту поддержку добавляли, может наверное SNMP приносить пользу админу. Главный вопрос, как и всегда, в том, что именно хочет админ :) Можно статистику собрать - collectd,cricket, rrd*, etc. статистика - имеется в виду в первую очередь скорость на портах? я так понимаю кратковременные всплески на ней будут не видны. хотя статистику с принтеров наверное интересно было бы собрать... Можно мониторить - nagios/icinga, snmptrapd, etc. а что именно можно мониторить? Можно захотеть чего-нибудь странного. PS: смотрел netdisco. вроде бы задумки неплохие, но впечатление осталось не очень. А что именно не очень? В своей области (сбор данных по L2/L3 устройствам, поддерживающим CDP/CDP-MIB и/или LLDP/LLDP-MIB, построение карты сети на L2, сбор IP и MAC адресов с привязкой к портам оборудования и т.д.) - вполне себе работает и неплохо. для dlink 2108 он не смог ничего считать - ни порты, ни vlan'ы (кривые MIB?) для AT-8024 он смог получить только список mac-адресов. поставил на linux-роутер SNMP-агент - не использует arp-кеш (хотя по snmpwalk я его вижу); хотелось бы VLAN'ы видеть именно как VLAN'ы, а не как отдельные интерфейсы (ну это скорее всего в SNMP-агенту). построение сети на мой взгляд могло бы быть более продвинутое - на основе собранной по SNMP информации можно было бы определять линки между устройствами, не поддерживающими LLDP (по мак-адресам). мне кажется должны существовать более продвинутые программы такого плана. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da37cff.3080...@yandex.ru
SNMP - best practices?
Сеть растёт, постепенно в ней накапливается всё больше устройств с поддержкой SNMP (свитчи, принтеры, ...). И думается мне - не просто так производители эту поддержку добавляли, может наверное SNMP приносить пользу админу. Прошу более опытных товарищей поделиться опытом в этой области. PS: смотрел netdisco. вроде бы задумки неплохие, но впечатление осталось не очень. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da21b16.70...@yandex.ru
Re: SNMP - best practices?
11.04.2011 1:03, Ed пишет: Сеть растёт, постепенно в ней накапливается всё больше устройств с поддержкой SNMP (свитчи, принтеры, ...). И думается мне - не просто так производители эту поддержку добавляли, может наверное SNMP приносить пользу админу. Главный вопрос, как и всегда, в том, что именно хочет админ :) Можно статистику собрать - collectd,cricket, rrd*, etc. Можно мониторить - nagios/icinga, snmptrapd, etc. Можно захотеть чего-нибудь странного. PS: смотрел netdisco. вроде бы задумки неплохие, но впечатление осталось не очень. А что именно не очень? В своей области (сбор данных по L2/L3 устройствам, поддерживающим CDP/CDP-MIB и/или LLDP/LLDP-MIB, построение карты сети на L2, сбор IP и MAC адресов с привязкой к портам оборудования и т.д.) - вполне себе работает и неплохо. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da29419.50...@tcen.ru
