Я повторю вопрос — может вам просто найти более квалифицированных специалистов по системам мониторинга?
Специалисты по мониторингу у нас хорошие, но заббикс они почему то не очень любят, возможно не тянет нагрузку в 5к устройств и по 10 тестов на каждом, но при случае я обязательно у них уточню) Развертывать и сопровождать заббикс только для SAN коммутаторов, ну не знаю, по трудозатратам думаю это не проще.
У нас заббикс прекрасно отлавливает ошибки на брокейдах, а вы упорно продолжаете убеждать читателей, что ваш скрипт на много лучше любой системы мониторинга и в частности заббиска
Я не никого не убеждаю я просто уверен в том, что заббикс хуже, это прекрасная система, я хотел рассказать, что есть другой способ, у него есть как плюсы так и минусы.
что же за такие бестолковые системы
Вполне толковые системы, но одна не умеет автоматом дискаверить новые порты, а вторая бывает запаздывает с оповещением.
В скриптовом методе есть еще преимущества, например можно настроить сверку залогиненных устройств по WWN, проверку системного таймера, проверку целостности фабрики, отслеживать появление новых WWN, и много еще чего хорошего. Как сделать это на заббиксе я не знаю(
Кстати если есть контакты людей, которые могут написать подобную вещь за обеденный перерыв (45 мин) и не хотят очень много денег, поделитесь пожалуйста.
Остальные 3 системы — лицензионное ПО купленное за деньги, причем не малые. Скрипт можете называть как угодно, иногда чем проще тем лучше. Один скрипт конечно не система, но десяток подобных скриптов позволяет автоматизировать много полезных задач. Zabbix нам в этом не помог, но мы на него не в обиде и удачно пользуем для других целей. По предыдущему опыту внедрения систем управления blade серверами, могу сказать одно: тот функционал, который был нам нужен, за пару дней мы написали на коленке сами еще 5 лет назад, у вендора он появился только год назад, и то за деньги.
Коммутаторы мониторятся одновременно 3-мя системами, каждая выполняет свои роли: одна мониторит линки и жизненно важные показатели свичей, вторая собирает полные метрики фабрик, но плохо умеет предупреждать о возможной аварии, третья как раз описана в данной статье, уже внедряется четвертая, которая должна заменить все остальные, но надежна невелика.
В теории да, а на практике даже ручной дискаверинг не всегда отрабатывал корректно. Можно было углубиться в допиливание имеющийся системы, но непонятно сколько времени на это бы ушло + интереснее было решить проблему подойдя с другой стороны.
Процессор, вентилятор или блок питания, присутствует в конфигурации свича изначально. И если даже блок питания воткнули потом, все равно будет ветка состояния всех вентиляторов, БП, CPU и тд. и если в этой ветке видим красный флаг, то что-то не в порядке. При использовании vSAN, при первичном дискаверинге устройства, порты находящиесы в другом vSAN не будут найдены и появятся только при повторном дискаверинге или прописыванию ветки вручную.
Хороший вопрос, иногда проходит, иногда приходиться пересоздавать устройство, но это не принципиально, главное что все равно приходиться подкручивать мониторинг, при изменении конфигурации vSAN. Если таких изменений много, то это дополнительные трудозатраты и увеличение влияния человеческого фактора. А при жестком правиле составления имени свича, можно вообще ничего не менять в мониторинге, все появится само)
Добавил имя в ДНС, и он уже на мониторинге.
А если понадобится мониторить процессор, память или температуру — накидаете ещё пару костылей?
Для мониторинга показателей жизнедеятельности самого свича (ping, cpu, fan, ps, и тд.) как раз лучше использовать zabbix или подобное. Здесь все просто, добавил устройство, и забыл.
В комментариях через один упоминание про zabbix, а есть ли живые примеры реализации на zabbix или zabbix подобных системах, мониторинга crc ошибок, и уровня затухания сигнала на sfp модулях?
Если Brocade меняет MIBы на ходу, это камень в их огород. С таким же успехом может смениться и CLI, который вы в своих скриптах эксплуатируете.
Если вы обратите внимание ссылка то для каждой версии FOS свой MIB, и в этом нет ничего плохого, т.к. появляются новые опции и нужно как то продавать BNA)
С формулировкой «костыль» не согласен, система сама в себе, на FOS начиная с 6-ой версии вывод параится корректно, вся настройка и сопровождение заключается в добавлении новой строки в список свичей, никакого дискаверинга при добавлении нового порта в продуктивный vSAN — не требуется.
Zabbix Nagios и Cacti системы ориентированные на работу с SNMP и Syslog, если сеть хранения данных не большая, то они подойдут, но если в сети сотни коммутаторов этот метод не будет оптимальным т.к. в мониторинге нужно описывать каждый порт, и если он не был в нужном vSAN изначально, то автоматически он не отдискавериться
Я не никого не убеждаю
я просто уверенв том, что заббикс хуже, это прекрасная система, я хотел рассказать, что есть другой способ, у него есть как плюсы так и минусы.Вполне толковые системы, но одна не умеет автоматом дискаверить новые порты, а вторая бывает запаздывает с оповещением.
В скриптовом методе есть еще преимущества, например можно настроить сверку залогиненных устройств по WWN, проверку системного таймера, проверку целостности фабрики, отслеживать появление новых WWN, и много еще чего хорошего. Как сделать это на заббиксе я не знаю(
Кстати если есть контакты людей, которые могут написать подобную вещь за обеденный перерыв (45 мин)
и не хотят очень много денег, поделитесь пожалуйста.Добавил имя в ДНС, и он уже на мониторинге.
Для мониторинга показателей жизнедеятельности самого свича (ping, cpu, fan, ps, и тд.) как раз лучше использовать zabbix или подобное. Здесь все просто, добавил устройство, и забыл.
Если вы обратите внимание ссылка то для каждой версии FOS свой MIB, и в этом нет ничего плохого, т.к. появляются новые опции и нужно как то продавать BNA)
С формулировкой «костыль» не согласен, система сама в себе, на FOS начиная с 6-ой версии вывод параится корректно, вся настройка и сопровождение заключается в добавлении новой строки в список свичей, никакого дискаверинга при добавлении нового порта в продуктивный vSAN — не требуется.