[Robot_NagNews]

Материал:

Любой инженер стремится автоматизировать повторяющиеся действия, стремится свести на минимум количество работы, которую нужно сделать вручную.

 

Полный текст

[s.lobanov]

В самом деле, основная проблема создать такую универсальную(во всех смыслах этого слова) систему в том, что она не нужна производителям оборудования по экономическим соображениям, никто не будет рыть себе яму, делая своё оборудование(или решение в комплексе) легко заменимым решениями других производителей. А с описываемой универсальной системой так оно и будет. Развивая мысль дальше, можно понять, что такая система может быть создана либо сторонними разработчиками(не имеющих явных предпочтений перед каким-либо вендором) или же в операторе. По поводу сторонних разработчиков, им не будет оказана поддержка со стороны многих вендоров, а на сегодняшний день(поскольку необходимых стандратов, формализующих логи и аварийные сообщения, нет) без поддержки вендоров такое ПО создать, фактически, невозможно.

 

Раз уж в статье все примеры относятся к оборудованию Huawei, то рассмотрим их продукт - U2000. В принципе, с помощью этого ПО очень много чего автоматизируется(и даже, частично, траблшутинг за счёт функционала корелляции событий). Но этот продукт по своей сути vendor-lock, как и другие аналогичные продукты от вендоров. А найти оператора без зоопарка(по крайней мере в РФ) совсем нетривиальная задача.

 

Моё мнение - необходимые стандарты и протоколы созданы не будут(потому что они невыгодны производителям, а у операторов не хватит желания и квалификации их написать в виде стандартов, которые можно отдать программистам на реализацию) и как мне кажется наиболее реалистичная возможность создания универсальной системы обслуживания сети это развёртывания NMS-ов от вендоров и разработка стороннего продукта, которое будет использовать API этих NMS для агрегации данных с них, но тут довольно быстро можно упереться в возможности этих API, обычно они существуют для интеграции с системами биллинга/тех.учёта оператора, а не для полного перекачивания данных из них/в них.

[SmalleR]

Речь в материале идет о создании системы искусственного интеллекта.

Но это задача не вендора, а оператора. И вендор дает оператору механизмы для реализации.

 

Автор, дерзайте!

[zi_rus]

Прочитал, прям удивляет как сильно это похоже на NOC (http://nocproject.org), а именно его Fault management модуль. Фактически там и делается то, что все сообщения стандартизуются, с помощью regexp из syslog message или snmp trap выдергиваются ключевые параметры и подставляются в стандартное сообщение которое не зависит от вендора, а дальше идет работа с этим сообщением, по важным поднимаются алармы, рассылаются уведомления и прочее, с помощью правил можно прописать какие-то зависимости между событиями. если в системе чего-то нет, она не знает или не умеет, очень просто добавить от собственное правило

[s.lobanov]

Речь в материале идет о создании системы искусственного интеллекта.

Но это задача не вендора, а оператора. И вендор дает оператору механизмы для реализации.

 

Как раз речь о том, что механизмов недостаточно. А то что есть - syslog и snmp trap совершенно не стандартизировано(кроме самых тривиальных случаев типа IF-MIB::linkDown).

[s.lobanov]

Прочитал, прям удивляет как сильно это похоже на NOC (http://nocproject.org), а именно его Fault management модуль. Фактически там и делается то, что все сообщения стандартизуются, с помощью regexp из syslog message или snmp trap выдергиваются ключевые параметры и подставляются в стандартное сообщение которое не зависит от вендора

 

Формально, nocproject не имеет право включать проприетарные мибы того же Huawei, для этого нужно подписать NDA(что выглядет смешно, т.к. nocproject свободно распространяемый). По поводу syslog, они(сообщения) вообще зависят от версии ПО. Т.е. требуется непрерывная работа по допиливанию regexp-ов, а если бы была поддержка от вендора, тогда бы это очень сильно упростилось. При том, если какого-то regexp-а нет, то либо авария не будет замечена или же отобразится авария, но без нормального описания и дежурная смена не поймёт что это такое.

Nocproject это конкурент проприетарных NMS (в датаком линейке уж точно, в access(dslam,gpon) и транспорте(dwdm и прочее) вряд ли), а вендоры не хочет кормить конкурента и уменьшать свои продажи.

[zi_rus]

ну да, есть такая проблема, сообщения меняются, но этим грешат обычно китайские недовендоры вроде хуавея, например с циской надо буквально несколько правил под одно событие для разных моделей и за три года я не заметил чтобы что-то перестало работать.

а поддержка вендора это такая штука, они stp реализовать нормально не могут, так что в одном кольце не рекомендуют держать разных вендоров, так что проблемы все равно будут

[adnull]

Специалисты отдела мониторинга узнают о проблемах и её причине раньше, чем очухается первый пользователь.

Ха, у меня в 50% случаев пользователь на проблему реагирует быстрее nagios-а.

[eucariot]

В самом деле, основная проблема создать такую универсальную(во всех смыслах этого слова) систему в том, что она не нужна производителям оборудования по экономическим соображениям, никто не будет рыть себе яму, делая своё оборудование(или решение в комплексе) легко заменимым решениями других производителей.

С этим сложно спорить. Так и есть в данный момент. Но вряд ли кто-то думает, что ситуация всегда будет оставаться такой. Через 50 лет всё будет иначе именно автоматизация, исключения человека из поиска проблем и настройки - один из векторов развития. Почему не начать говорить об этом сейчас?

 

а на сегодняшний день(поскольку необходимых стандратов, формализующих логи и аварийные сообщения, нет) без поддержки вендоров такое ПО создать, фактически, невозможно

Именно. Нужно стандартизировать. И начинать с простого - логов и трапов. Кто из вендоров не реализует - тот лузер и в отстающих. Когда-то и MPLS был только у избранных. Да, объём работы гигантский - это не просто реализовать один протокол - это для всех протоколов предусмотреть все сообщения, все ситуации.

 

Пока готовил статью, тоже понял, что U2000 - это движение в сторону автоматизацию (взять хотя бы даже автоматическое создание трейлов), но это всё также бесконечно далеко от того, что необходимо, что удобно. Для меня U2000 - это как iTunes - всё непонятно, нелогично и тормозит.

Но мысль-то правильная - хотя бы в пределах одного вендора добиться полной гармонии - а пока только корреляция аварий.

[eucariot]

Прочитал, прям удивляет как сильно это похоже на NOC (http://nocproject.org), а именно его Fault management модуль. Фактически там и делается то, что все сообщения стандартизуются, с помощью regexp из syslog message или snmp trap выдергиваются ключевые параметры и подставляются в стандартное сообщение которое не зависит от вендора, а дальше идет работа с этим сообщением, по важным поднимаются алармы, рассылаются уведомления и прочее, с помощью правил можно прописать какие-то зависимости между событиями. если в системе чего-то нет, она не знает или не умеет, очень просто добавить от собственное правило

 

Действительно. Судя по скриншотам и описанию, довольно интересный проект, не знал о его существовании, но, как вы и сами сказали - проблемы с разными производителями и даже разными версиями. Очень инертно, пока нет поддержки со стороны вендоров. Ну и опять же ограниченный функционал, реализующий только небольшую часть того, что я описал, чего бы хотелось.

[s.lobanov]

Почему не начать говорить об этом сейчас?

 

Что нужно сейчас и так понятно. Самое сложное это допиливание железа под такую систему, но это не нужно сегодняшним вендорам.

Единственная надежда на открытое железо, т.е. чипы с открытой документацией, с открытым SDK, это позволит добавить весь необходимый функционал силами сообщества или новыми компаниями, модель бизнеса которых будет иная(с меньшими прибылями, но это уже другой вопрос). Вспомнить историю с CPE-шкой Linksys WRT54G, после того как были опубликованы исходники, вышло куча всяких прошивок, со всевозможным функционалом(у кого на что фантазии хватило), каждый стал иметь возможность реализовать то, что ему хотется.

[zi_rus]

Действительно. Судя по скриншотам и описанию, довольно интересный проект, не знал о его существовании, но, как вы и сами сказали - проблемы с разными производителями и даже разными версиями. Очень инертно, пока нет поддержки со стороны вендоров. Ну и опять же ограниченный функционал, реализующий только небольшую часть того, что я описал, чего бы хотелось.

на самом деле там заложена очень хорошая база, но нужны руки чтобы все вот такие хотелки реализовать, а пока я вижу только что народ удивляется когда упоминаю этот проект, хотя на этом форуме есть тема длиною в несколько лет полностью об этом проекте

[Mikler]

Почему не начать говорить об этом сейчас?

 

Что нужно сейчас и так понятно. Самое сложное это допиливание железа под такую систему, но это не нужно сегодняшним вендорам.

Единственная надежда на открытое железо, т.е. чипы с открытой документацией, с открытым SDK, это позволит добавить весь необходимый функционал силами сообщества или новыми компаниями, модель бизнеса которых будет иная(с меньшими прибылями, но это уже другой вопрос). Вспомнить историю с CPE-шкой Linksys WRT54G, после того как были опубликованы исходники, вышло куча всяких прошивок, со всевозможным функционалом(у кого на что фантазии хватило), каждый стал иметь возможность реализовать то, что ему хотеться.

Хорошая шутка. Как правило основные вендоры сидят тихо и документы под NDA и очень большие деньги на входящий платеж. Новейшие технологии и знания публичными не будут.

[s.lobanov]

Как правило основные вендоры сидят тихо и документы под NDA и очень большие деньги на входящий платеж.

 

Да, щас оно так и есть. И если ничего не изменится в отношении ASIC-ов для оборудования коммутации/маршрутизации, то и дальше можно лишь рассуждать на тему "как хорошо было бы добавить такие-то фичи в оборудование и соответсвующий функционал в NMS" или продолжать есть кактус и запиливить сотни тысяч регэкспов и разнообразных событийных обработчиков в nocproject или собственное ПО аналогичной направленности

[zi_rus]

лично я не вижу почему что-то должно измениться

если подумать, то если кто и заинтересован в подобных вещах, то это операторы, которые как раз тут и сидят, это не надо ни вендорам, ни комьюнити. первым по понятным причинам, вторым просто это не нужно (всякие кастомный прошивки для рутеров вспомните, никто про такое даже не заморачивался, а это первое с чего должно все начаться). а теперь вопрос, кто здесь готов оплатить подобную разработку

[SmalleR]

а теперь вопрос, кто здесь готов оплатить подобную разработку

Нобелевский комитет.

[zi_rus]

ну вот и порешили, это никому оказывается не надо, было бы надо то заплатили

[eucariot]

лично я не вижу почему что-то должно измениться

если подумать, то если кто и заинтересован в подобных вещах, то это операторы, которые как раз тут и сидят, это не надо ни вендорам, ни комьюнити. первым по понятным причинам, вторым просто это не нужно (всякие кастомный прошивки для рутеров вспомните, никто про такое даже не заморачивался, а это первое с чего должно все начаться). а теперь вопрос, кто здесь готов оплатить подобную разработку

 

Развитие телекома не ограничивается увеличением скоростей и добавлением новых свистелок в старые протоколы. Во времена ARPANET некоторые бы тоже недоумевали, зачем нужны VLAN'ы, а потом кто-то не ждал MPLS. Но всё это стало сейчас открытым и широкоиспользуемым.

Сети 5G, которые разрабатываются сейчас, уже направлены не на простое увеличение скорости, а на бОльшую гибкость. У каждого вендора (наверное, у каждого) есть своя NMS, допиленная до той или иной степени автоматизации. Мешает выйти одной из таких NMS в свет - отсутствие каких-либо стандартов.

 

Человеческий ресурс - очень дорогой. Причём не только по оплате, но и по последствиям ошибок.

Я уверен, что в будущем так или иначе технологии будут двигаться в сторону уменьшения необходимости человека в обслуживании и настройке.

 

И начать надо с малого - того, что не так сильно скажется на доходах вендоров - стандартизации логов.

 

а теперь вопрос, кто здесь готов оплатить подобную разработку

 

И это говорит участник открытого, бесплатного проекта NOC :)

 

Хотя вопрос в том, что исходить это должно, конечно, не от нескольких инженеров, а от организаций по стандартизации.

[s.lobanov]

И это говорит участник открытого, бесплатного проекта NOC :)

 

Вы просто не очень в курсе как вносятся коммиты в открытые проекты. Большинство участников запиливают то, что нужно им, правят те баги, которые потенциально интересны им.

Конечно, есть и другие участники, те кто зарабатывают на коммерческом саппорте или добавляют фичи за деньги по ТЗ заказчика, в их интересах всестороннее развитие проекта, но всё же по большей части получается не что-то универсальное, а набор фич, которые требуются участникам проекта(или коммерческим потребителям).

 

И начать надо с малого - того, что не так сильно скажется на доходах вендоров - стандартизации логов.

Если это сделать(стандартизировать snmp traps или syslog), то можно будет выкинуть тот же U2000 из многих мест(где он используется как мониторинг), не внедрять его в новых проектах. Huawei-ю это надо? Особенно учитывая то, что каждая фича лицензируется и стоит кучу денег

По своему опыту могу сказать, что автоматизировать конфигурирование не сложно(сделать шабоны кусков конфигураций CLI/snmp/netconf не очень долго), а вот полноценный мониторинг это невероятно сложная задача(учесть специфику кучу разного железа)

 

По поводу всяческих организаций по стандратизации. Возьмём в пример GPON. Есть такая штука http://www.fsan.org/members/ . Реально оборудование между собой несовместимо(за исключением единичных случаев, которые лишь подтвеждают правило), причины несовместимости чисто экономического характера.

Так что стандратизация она условная. Взять самые обычные протоколы, например radius, dhcp, snmp. Поля стандратны, их все соблюдают, но всё самое интересное хранится в vendor-specific(радиус-аттрибуты, dhcp-опции, snmp enteprise.vendor).

С логами будет тоже самое, придумают формат, всё будет красиво, но опять вендоры всё засунут в vendor-specific поля и будет как с snmp-трапами

[zi_rus]

И это говорит участник открытого, бесплатного проекта NOC :)

я обычный пользователь, которому интересно развитие данного проекта, хотя и от меня там кое-что есть

весь этот проект напоминает одну шутку "есть мнение что наши футболисты, играют в футбол после работы"

 

стандартизация вещь хорошая, только силой ее не насадить, надо чтобы вендоры сами захотели

тут вспомнили снмп, почему все вендоры ушли в vendor-specific ветку, большинство вполне поддерживают и стандартные МИБы, ну там SysName, SysDescr, всякие линк статус, МТУ и тд. почему всякие радиус или dhcp сидят в вендор специфике, я конечно не знаю, но полагаю что стандартных тупо нет, ну а если их нет то что жаловаться. как бы то ни было, но чтобы сдвинуть дело с мертвой точки надо что-то делать, я вот помогаю проекту который помогает решать мои проблемы на приемлимом для меня уровне, если вам мой способ не подходит, то пишите RFC, обсуждайте, корректируйте, внедряйте, может быть это заставит вендоров присмотреться к инициативе, а "надо/не надо", этим делу не поможешь

[s.lobanov]

тут вспомнили снмп, почему все вендоры ушли в vendor-specific ветку, большинство вполне поддерживают и стандартные МИБы, ну там SysName, SysDescr, всякие линк статус, МТУ и тд.

 

Речь шла про трапы, а не про get/set, "стандартных" трапов ооочень мало. Для чтения/управления стандратные есть, но их тоже не хватает

[eucariot]

можно будет выкинуть тот же U2000 из многих мест

 

Разумеется. И дело в том, что, если стандарт будет разработан, и его начнут придерживаться крупные игроки, то те, кто не реализовал, потеряют рынок.

Приведу пример - системы DPI. Если вендор создаст проприетарную замену Gx, Gy интерфейса и протоколу Diameter, пользователям придётся вместе c Back End'ом и Front End'ом покупать ещё и PCRF и OCS именно данной фирмы. Да, заказчик будет вынужден делать это. Но если другие вендоры стандартов придерживаются, то, скорее всего, их оборудование и предпочтут.

 

Но выгода DPI гораздо более очевидна, чем выгода автоматического тарблшутинга.

 

И, может быть, этот тот случай, когда можно начать с интерпрайза, который крайне редко, по-моему, покупает системы управления в комплекте с оборудованием.

 

Автоматическая настройка - именно полностью автоматическая, а не написание скриптов и подгонка их под разные синтаксисы - задача вовсе нетривиальная. Я говорю о том, что мы подсовываем Системе Контроля файлик с LLD, а она проходит по всей сети и через специальный протокол (может, и SNMP) прогружает сгенерированную конфигурацию на все устройства. При этом она может отследить неконсистентность настроек. Это как минимум.

 

Если говорить о vendor-specific, то, да, ему всегда будет место. Но известные и необходимые вещи должны быть реализованы, иначе возвращаемся к первому абзацу.

[eucariot]

Речь шла про трапы, а не про get/set, "стандартных" трапов ооочень мало. Для чтения/управления стандратные есть, но их тоже не хватает

Ну а что, если cisco, juniper и dlink встретятся и решат вдруг использовать одинаковый набор трапов и set/get? В течение года причешут все свои коды для соответствия новому стандарту. Через 3 года закончат новую Систему Контроля, которая будет обладать грандиозным функционалом и начнут её продавать, как киллер фичу.

А ещё через два года откроют, как cisco открыла EIGRP? Тем самым они вырвутся вперёд с одной стороны и дадут возможность сделать шаг в будущее и другим с другой стороны?

 

P.S я понимаю, что сценарий фантастический и, может быть, довольно наивный.

Изменено 28 октября, 2013 пользователем eucariot

[zi_rus]

Речь шла про трапы, а не про get/set, "стандартных" трапов ооочень мало. Для чтения/управления стандратные есть, но их тоже не хватает

ну это тоже самое, вот их нету, вендор в этом совершенно не виноват что те кто делали стандарт не додумались больше прописать, так например даже проще, не надо изобретать велосипед, создать просто rfc с описанием расширенных стандартных трапов. кто знает процедуру? надо двинуть такую идею, народ должен поддержать если оно действительно нужно, а не больная фантазия отдельных личностей. к идее модно и драфт rfc приложить, так оно лучше, будет от чего плясать, что удалить, что добавить

[eucariot]

надо двинуть такую идею, народ должен поддержать если оно действительно нужно, а не больная фантазия отдельных личностей.

Я среди личностей с больной фантазией, Dank. Пока ничего не читал про RFC и draft, ничего об этом не знаю, но мысль об этом грею. Если что, я участвую.