Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
В любой инфраструктуре должно быть средство централизованного мониторинга, Nagios и Zabbix являются бесплатными и широкоиспользуемыми решениями, которое это в состоянии мониторить…
Zabbix Nagios и Cacti системы ориентированные на работу с SNMP и Syslog, если сеть хранения данных не большая, то они подойдут, но если в сети сотни коммутаторов этот метод не будет оптимальным т.к. в мониторинге нужно описывать каждый порт, и если он не был в нужном vSAN изначально, то автоматически он не отдискавериться
то автоматически он не отдискавериться
Это почему?
Хороший вопрос, иногда проходит, иногда приходиться пересоздавать устройство, но это не принципиально, главное что все равно приходиться подкручивать мониторинг, при изменении конфигурации vSAN. Если таких изменений много, то это дополнительные трудозатраты и увеличение влияния человеческого фактора. А при жестком правиле составления имени свича, можно вообще ничего не менять в мониторинге, все появится само)
Добавил имя в ДНС, и он уже на мониторинге.
Добавил имя в ДНС, и он уже на мониторинге.
Если у вас такая инфраструктура, что одних только SAN коммутаторов — сотни, и вы это мониторите подобными скриптами… Ну жалко мне вас, что ещё сказать. Ну и видимо вам нужны хорошие специалисты по Zabbixу. У нас конечно не сотни коммутаторов, но проблем мы не испытываем никаких.
Коммутаторы мониторятся одновременно 3-мя системами, каждая выполняет свои роли: одна мониторит линки и жизненно важные показатели свичей, вторая собирает полные метрики фабрик, но плохо умеет предупреждать о возможной аварии, третья как раз описана в данной статье, уже внедряется четвертая, которая должна заменить все остальные, но надежна невелика.
При всём уважении, но называть этот наколенный скрипт СИСТЕМОЙ и ставить её в один ряд с полноценными система мониторинга… или остальные 2 системы — аналогичные скрипты?
Очень интересно было бы узнать где вы так инфраструктуру мониторите
Очень интересно было бы узнать где вы так инфраструктуру мониторите
Остальные 3 системы — лицензионное ПО купленное за деньги, причем не малые. Скрипт можете называть как угодно, иногда чем проще тем лучше. Один скрипт конечно не система, но десяток подобных скриптов позволяет автоматизировать много полезных задач. Zabbix нам в этом не помог, но мы на него не в обиде и удачно пользуем для других целей. По предыдущему опыту внедрения систем управления blade серверами, могу сказать одно: тот функционал, который был нам нужен, за пару дней мы написали на коленке сами еще 5 лет назад, у вендора он появился только год назад, и то за деньги.
Остальные 3 системы — лицензионное ПО купленное за деньги
третья как раз описана в данной статье
нет-нет, вы не подумайте что я к словам то придираюсь, я просто пытаюсь понять — что же за такие бестолковые системы, за немалые, как я думаю деньги, не в состоянии покрыть ваши нужды, которые покрываются данным скриптом, накиданном за сколько? за обеденный перерыв? Я повторю вопрос — может вам просто найти более квалифицированных специалистов по системам мониторинга? У нас заббикс прекрасно отлавливает ошибки на брокейдах, а вы упорно продолжаете убеждать читателей, что ваш скрипт на много лучше любой системы мониторинга и в частности заббиска. Где тут ребята из Badoo? Они вас быстро на путь истинный наставят :)))
третья как раз описана в данной статье
нет-нет, вы не подумайте что я к словам то придираюсь, я просто пытаюсь понять — что же за такие бестолковые системы, за немалые, как я думаю деньги, не в состоянии покрыть ваши нужды, которые покрываются данным скриптом, накиданном за сколько? за обеденный перерыв? Я повторю вопрос — может вам просто найти более квалифицированных специалистов по системам мониторинга? У нас заббикс прекрасно отлавливает ошибки на брокейдах, а вы упорно продолжаете убеждать читателей, что ваш скрипт на много лучше любой системы мониторинга и в частности заббиска. Где тут ребята из Badoo? Они вас быстро на путь истинный наставят :)))
Я повторю вопрос — может вам просто найти более квалифицированных специалистов по системам мониторинга?Специалисты по мониторингу у нас хорошие, но заббикс они почему то не очень любят, возможно не тянет нагрузку в 5к устройств и по 10 тестов на каждом, но при случае я обязательно у них уточню) Развертывать и сопровождать заббикс только для SAN коммутаторов, ну не знаю, по трудозатратам думаю это не проще.
У нас заббикс прекрасно отлавливает ошибки на брокейдах, а вы упорно продолжаете убеждать читателей, что ваш скрипт на много лучше любой системы мониторинга и в частности заббискаЯ не никого не убеждаю
что же за такие бестолковые системыВполне толковые системы, но одна не умеет автоматом дискаверить новые порты, а вторая бывает запаздывает с оповещением.
В скриптовом методе есть еще преимущества, например можно настроить сверку залогиненных устройств по WWN, проверку системного таймера, проверку целостности фабрики, отслеживать появление новых WWN, и много еще чего хорошего. Как сделать это на заббиксе я не знаю(
Кстати если есть контакты людей, которые могут написать подобную вещь за обеденный перерыв (45 мин)
В том же cacti данные можно получать через скрипт. Например, в случае, если с snmp надо хитро работать
Вы меня опередили… :)
Я почти ничего не понял, но мне очень понравилось)
Какой-то вы изобрели ужасный колхоз велосипед.
Это что-то странное, есть MIB-ы в которых всё что надо прописано обычно достаточно жёстко. Если Brocade меняет MIBы на ходу, это камень в их огород. С таким же успехом может смениться и CLI, который вы в своих скриптах эксплуатируете.
Правильным способом было бы использовать Zabbix + Low level discovery по SNMP.
Оно и порты само обнаружит, и триггеры необходимые по шаблону создаст и письмо или смску пришлёт когда проблему обнаружит.
А то, что в статье — костыль.
а snmp дерево может значительно меняться как на разных свичах, так и при переходе на новый FOS.
Это что-то странное, есть MIB-ы в которых всё что надо прописано обычно достаточно жёстко. Если Brocade меняет MIBы на ходу, это камень в их огород. С таким же успехом может смениться и CLI, который вы в своих скриптах эксплуатируете.
Правильным способом было бы использовать Zabbix + Low level discovery по SNMP.
Оно и порты само обнаружит, и триггеры необходимые по шаблону создаст и письмо или смску пришлёт когда проблему обнаружит.
А то, что в статье — костыль.
Если Brocade меняет MIBы на ходу, это камень в их огород. С таким же успехом может смениться и CLI, который вы в своих скриптах эксплуатируете.
Если вы обратите внимание ссылка то для каждой версии FOS свой MIB, и в этом нет ничего плохого, т.к. появляются новые опции и нужно как то продавать BNA)
С формулировкой «костыль» не согласен, система сама в себе, на FOS начиная с 6-ой версии вывод параится корректно, вся настройка и сопровождение заключается в добавлении новой строки в список свичей, никакого дискаверинга при добавлении нового порта в продуктивный vSAN — не требуется.
и в этом нет ничего плохого, т.к. появляются новые опции
Дерево OIDов конкретной железки обычно разделено на множество разных MIBов и добавление новых опций приводит к изменению лишь некоторых из них. В любом случае, как я говорил, с CLi может быть так же.
С формулировкой «костыль» не согласен, система сама в себе, на FOS начиная с 6-ой версии вывод параится корректно, вся настройка и сопровождение заключается в добавлении новой строки в список свичей, никакого дискаверинга при добавлении нового порта в продуктивный vSAN — не требуется.
Всё это прекрасно, но ваше решение от этого не становится менее велосипедным или костыльным.
Вместо того, чтобы почитать мануал к Zabbix и реализовать нормальную схему, в которой мониторились бы все необходимые параметры ваших коммутаторов, а не только CRC у SFP, вы написали костыль который делает только одно.
А если понадобится мониторить процессор, память или температуру — накидаете ещё пару костылей?
А если понадобится мониторить процессор, память или температуру — накидаете ещё пару костылей?
Для мониторинга показателей жизнедеятельности самого свича (ping, cpu, fan, ps, и тд.) как раз лучше использовать zabbix или подобное. Здесь все просто, добавил устройство, и забыл.
Чем же ошибки CRC на портах так принципиально отличаются от других параметров?
Процессор, вентилятор или блок питания, присутствует в конфигурации свича изначально. И если даже блок питания воткнули потом, все равно будет ветка состояния всех вентиляторов, БП, CPU и тд. и если в этой ветке видим красный флаг, то что-то не в порядке. При использовании vSAN, при первичном дискаверинге устройства, порты находящиесы в другом vSAN не будут найдены и появятся только при повторном дискаверинге или прописыванию ветки вручную.
В заббиксе обнаружение новых итемов на хостах происходит с некоторой заданной периодичностью, допустим раз в 10 минут. Причём для каждого типа можно указать свою периодичность. Так что не вижу никакой проблемы — все нужные порты обнаружатся автоматически через заданное время.
В комментариях через один упоминание про zabbix, а есть ли живые примеры реализации на zabbix или zabbix подобных системах, мониторинга crc ошибок, и уровня затухания сигнала на sfp модулях?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бесплатный мониторинг CRC ошибок