[Haus3918]

 

 

 

Carbon NetMon - это система мониторинга сети и поиска неисправностей с элементами DPI. Для анализа сети используется поданное зеркало трафика на сервер. Зеркало проходит предварительную фильтрацию с помощью специального алгоритма, что позволяет анализировать большие объёмы трафика и при этом избегать ложных срабатываний.

 

На текущий момент среди основных функций присутствуют:

Мониторинг сегментов сети

Статистика активности собирается по отдельным хостам и объединяется в подсети (/24). Если у большинства хостов в сети пропал трафик - она считается неисправной.

Обнаружение аномальных всплесков трафика

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

Анализ качества сервиса, предоставляемого абонентам

Система анализирует трафик всех абонентов или заданного сегмента сети, выявляя проблемы с качеством сервиса. Анализируются такие параметры как доля TCP-ретрансмиссий и полный RTT по всем сессиям у абонента. RTT делится на полный, на то что происходит на абонентской стороне, что происходит на стороне сервисов, к которым обращается абонент.

Анализ потребления канала абонентами

Позволяет выявить кто именно потребляет канал и в каком соотношении. Анализ потребления канала абонентами выводит информацию о числе пакетов и объёмах входящего и исходящего трафика. Если абонентов в анализируемой сети много - данные можно автоматически сгруппировать по подсетям. Из промежуточных результатов можно вызвать дальнейший анализ трафика по выбранной подсети или абоненту и таким образом добраться до источника проблемы с каналом.

Сетевая диагностика абонента

Дает возможность максимально глубоко разобраться в проблемах абонента, выявленного с помощью инструмента "Обнаружение абонентов с плохим качеством сервиса".

 

QOE

 

Собираются и анализируются показатели ретрансмиссий и RTT для сети и хоста.

Оповещения

Информирование по email и смс о инцидентах на сети.

 

Для ознакомления доступен бесплатный демо период на 30 дней. Ознакомится с Carbon NetMon можно  на нашем сайте.

Более подробная информация по продукту размещена в документации.

 

 

[moob82]

По ссылке смотреть демо 502 ошибка https://demo-netmon.carbonsoft.ru/

[Haus3918]

13 часов назад, moob82 сказал:

По ссылке смотреть демо 502 ошибка https://demo-netmon.carbonsoft.ru/

Добрый день, moob82.

02.09.20 проводились плановые технические работы, в связи с этим демо стенд был временно недоступен. Приносим свои извинения за доставленные неудобства.

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

[AlexPan]

Что то не получается ознакомиться! Не работает!

[RN3DCX]

сначала были плановые работы, теперь внеплановые...

[Antares]

В 27.08.2020 в 16:14, Haus3918 сказал:

Мониторинг сегментов сети

Статистика активности собирается по отдельным хостам и объединяется в подсети (/24). Если у большинства хостов в сети пропал трафик - она считается неисправной.

А нафига так то??

[Haus3918]

2 часа назад, AlexPan сказал:

Что то не получается ознакомиться! Не работает!

К сожалению действительно временно не доступна, в связи с внутренними работами по улучшению стабильности.  В течение часа все будет исправлено и доступно.

 

 

2 минуты назад, Antares сказал:

А нафига так то??

Для чего контролировать пропажу трафика у сегмента сети или группировать подсети?

[Antares]

2 минуты назад, Haus3918 сказал:

К сожалению действительно временно не доступна, в связи с внутренними работами по улучшению стабильности.  В течение часа все будет исправлено и доступно.

 

 

Для чего контролировать пропажу трафика у сегмента сети или группировать подсети?

Нафига объединять?

 

Хосты могут находиться в разных сегментах

[AlexPan]

2 часа назад, RN3DCX сказал:

сначала были плановые работы, теперь внеплановые...

А можно ценник озвучить?

И варианты тестирования.

[Haus3918]

Только что, AlexPan сказал:

А можно ценник озвучить?

И варианты тестирования.

Все ценны открыты, ознакомиться можно на сайте https://www.carbonsoft.ru/products/netmon/

 

Тестирование доступно без ограничения функционала бесплатно в течение 30 дней.

 

 

13 минут назад, Antares сказал:

Нафига объединять?

 

Хосты могут находиться в разных сегментах

Безусловно вы правы. Хосты могут находится в разных сегментах и при базовой группировке по /24 это может быть не удобно.

/24 был выбран как универсальный вариант. В дальнейшем будет возможность опционально задавать подсети для группировки.

[AlexPan]

На чем работает этот софт? Надо наверное ставить отдельный сервер. Сколько чего надо для мониторинга ~30-40Гбайт?

 Это получается надо 8x10G портов? Трафик оптическим сплитером дублировать? Какие требования к железу?

 

Какой сервак посоветуете с множеством портов?

[AlexPan]

Честно говоря тут вот подумал, а ведь по сути всего то собираются ретрансмиты и по ним строится статистика ошибок. Ну еще собирается статистика на проходящие от ip адресов пакеты. И ради этого городить сервак, куда задублировать весь трафик... Надо ли?

Сейчас все более распространенным является маршрутизатор Juniper MX. Старый и надежный трактор. Так вот там есть механизмы гибкого мироринга пакетов на внешний сервер даже через gre туннель. При этом, все пакеты можно обрезать до уровня заголовков. так что трафик на анализатор упадет на порядок. 

 

https://habr.com/ru/post/336978/

 

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

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

Для статистики по проходящим пакетам интересно посмотреть график по трафику на времени.

Что то более сложное я у вас не заметил, да собственно вы и не DPI предлагаете...

[Saab95]

Эта система работает на карбон редуктор, у кого он стоит могут посмотреть. По сути бесполезная ерунда, толку от этого мониторинга и статистики никакой.

 

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

[Haus3918]

16 часов назад, AlexPan сказал:

Честно говоря тут вот подумал, а ведь по сути всего то собираются ретрансмиты и по ним строится статистика ошибок. Ну еще собирается статистика на проходящие от ip адресов пакеты. И ради этого городить сервак, куда задублировать весь трафик... Надо ли?

Сейчас все более распространенным является маршрутизатор Juniper MX. Старый и надежный трактор. Так вот там есть механизмы гибкого мироринга пакетов на внешний сервер даже через gre туннель. При этом, все пакеты можно обрезать до уровня заголовков. так что трафик на анализатор упадет на порядок. 

 

https://habr.com/ru/post/336978/

 

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

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

Для статистики по проходящим пакетам интересно посмотреть график по трафику на времени.

Что то более сложное я у вас не заметил, да собственно вы и не DPI предлагаете...

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

Насчет алертов системы мониторинга - конечно сидеть и следить за монитором так себе удовольствие, что и логично. Системы алертит при пропаже трафика или всплесках сетевой активности, в дальнейшем мы введем возможность создания собственных триггеров, что позволит избежать описанной вами ситуации с ежедневным мониторингом от инженера.
Так же " накапливать инфу для последующего анализка", этот момент уже реализован в модуле QoE (качество сервиса), буквально сегодня мы перевыложили iso в котором доступен данных функционал.

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

[Haus3918]

14 часов назад, Saab95 сказал:

Эта система работает на карбон редуктор, у кого он стоит могут посмотреть. По сути бесполезная ерунда, толку от этого мониторинга и статистики никакой.

 

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

 

1. Отчасти Вы правы - система действительно изначально развивалась из под Carbon Reductor. Но на данный момент в редукторе есть только часть функционала из NetMon.  Carbon Reductor будет содержать lite вариант NetMon, но весь дальнейший функционал уже будет добавляться только в Netmon, чтобы не воздействовать на основные задачи Carbon Reductor - фильтрацию.

2. Подскажите пожалуйста, является ли предоставляемое качество услуг абонентам для вас важным? Понимает ли сам абонент, что потери в эфире дома из-за плохого wifi или зашумленной среды это локальная беда, а не вина провайдера?
Смысл контролировать RTT и ретрансмиты для определения качества сервиса и вытекающая отсюда - лояльность, маркетинг, продажи. 
Абонентов с такими симптомами, можно передать отделу продаж, который свяжется с абонентом, спросит о том, как у него дела, скажет что "мы вот обнаружили что у вас плохо работает Интернет, предположительно, из-за вашего маршрутизатора». Если маршрутизатор наш - давайте вышлем к вам нашего инженера разобраться в чём дело, а если ваш - мы можем предложить неделю бесплатно попробовать наш маршрутизатор, а потом купить его или взять в аренду, если качество связи ощутимо улучшится".
 

[Saab95]

В 07.09.2020 в 13:05, Haus3918 сказал:

Смысл контролировать RTT и ретрансмиты для определения качества сервиса и вытекающая отсюда - лояльность, маркетинг, продажи. 

Это все важно, но:

 

1. Трафик зеркалиться на СОРМ.

2. Трафик зеркалиться на Карбон редуктор.

3. Надо трафик зеркалить еще на один сервер, который надо купить, и еще ежемесячную аренду за софт платить - это сколько абонентов должны уйти, что бы окупилось?

 

Еще ранее я говорил что в тупиковом направлении идет разработка этой системы мониторинга, то, что она смотрит и ловит, это задача для ДПИ, то есть лучше развивать карбон редуктор, добавляя в него разные функции, и что бы там же была связь с карбон биллингом, и они вместе договаривались и подсвечивали или выставляли какой-то статус у абонента как проблемный или что-то похожее. Сейчас же предлагается работать сразу в 3-х программах (системах) одновременно, которые ну никак не связаны.

[Haus3918]

16 часов назад, Saab95 сказал:

Это все важно, но:

 

1. Трафик зеркалиться на СОРМ.

2. Трафик зеркалиться на Карбон редуктор.

3. Надо трафик зеркалить еще на один сервер, который надо купить, и еще ежемесячную аренду за софт платить - это сколько абонентов должны уйти, что бы окупилось?

 

Еще ранее я говорил что в тупиковом направлении идет разработка этой системы мониторинга, то, что она смотрит и ловит, это задача для ДПИ, то есть лучше развивать карбон редуктор, добавляя в него разные функции, и что бы там же была связь с карбон биллингом, и они вместе договаривались и подсвечивали или выставляли какой-то статус у абонента как проблемный или что-то похожее. Сейчас же предлагается работать сразу в 3-х программах (системах) одновременно, которые ну никак не связаны.

1. По поводу mirror сессий - да не каждое оборудование позволяет поддерживать необходимое количество и при интеграции систем которым это необходимо возникают свои сложности, но это все решаемо при необходимости.
В частности по продуктам DPI и системы мониторинга, тут не стоит вопрос по дополнительной стоимости - так как NetMon для клиентов DPI предоставляется бесплатно. При этом установить NetMon можно и на VM и не придется покупать дополнительно сервер. (естественно при наличии свободных мощностей)
2. Насчет вашего видения развития продуктов как единого целого, в общем не могу не согласиться, что это будет очень удобно и эффективно.

В целом мы к этому и идем. В DPI есть интеграция с Биллингом в виде "системы контроля доступа абонентов", в NetMon так же добавляется интеграция с базой абонентов Биллинга. В тоже время в DPI есть часть функционала NetMon, что позволяет контролировать активность абонентов и качество сервиса из единого web-интерфейса.

В связи с этим у нас есть в планах реализовать по настоящему удобный, полезный и  эффективный инструмент, но для этого требуется время и ресурсы. 

 

[moob82]

В 11.09.2020 в 10:19, Haus3918 сказал:

1. По поводу mirror сессий - да не каждое оборудование позволяет поддерживать необходимое количество и при интеграции систем которым это необходимо возникают свои сложности, но это все решаемо при необходимости.
В частности по продуктам DPI и системы мониторинга, тут не стоит вопрос по дополнительной стоимости - так как NetMon для клиентов DPI предоставляется бесплатно. При этом установить NetMon можно и на VM и не придется покупать дополнительно сервер. (естественно при наличии свободных мощностей)
2. Насчет вашего видения развития продуктов как единого целого, в общем не могу не согласиться, что это будет очень удобно и эффективно.

В целом мы к этому и идем. В DPI есть интеграция с Биллингом в виде "системы контроля доступа абонентов", в NetMon так же добавляется интеграция с базой абонентов Биллинга. В тоже время в DPI есть часть функционала NetMon, что позволяет контролировать активность абонентов и качество сервиса из единого web-интерфейса.

В связи с этим у нас есть в планах реализовать по настоящему удобный, полезный и  эффективный инструмент, но для этого требуется время и ресурсы. 

 

Сейчас все к этому стремятся. У операторов от 10 до 20 программ, в которых приходится работать. Зачастую часть функционала дублируется. Под каждый надо держать сервер или VM . В каждую надо зайти. Сходу могу написать на память : 1С. US, Биллинг, Zabbix, Dude, CRM для монтажей самописная, почта, чат вастап, чат телеграмм , программа для схем PONа. Это я еще не все вспомнил. Знаю, что есть провайдеры которые пишут под себя ERP для объединения всего сия .

[Saab95]

В 11.09.2020 в 08:19, Haus3918 сказал:

При этом установить NetMon можно и на VM и не придется покупать дополнительно сервер. (естественно при наличии свободных мощностей)

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

 

В 11.09.2020 в 08:19, Haus3918 сказал:

В связи с этим у нас есть в планах реализовать по настоящему удобный, полезный и  эффективный инструмент, но для этого требуется время и ресурсы. 

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

[VolanD666]

В 15.09.2020 в 12:25, moob82 сказал:

Сейчас все к этому стремятся. У операторов от 10 до 20 программ, в которых приходится работать. Зачастую часть функционала дублируется. Под каждый надо держать сервер или VM . В каждую надо зайти. Сходу могу написать на память : 1С. US, Биллинг, Zabbix, Dude, CRM для монтажей самописная, почта, чат вастап, чат телеграмм , программа для схем PONа. Это я еще не все вспомнил. Знаю, что есть провайдеры которые пишут под себя ERP для объединения всего сия .

Все верно вы говорите. Каждый производитель пытается запилить свою систему контроля/мониторинга с блэкджеком. И получается, что открыто 100500 окон. На мой взгляд, нужно стремиться строить подобные системы с использованием стандартных средств. Например SNMP, ну или если система прям совсем сложная, то можно сделать какой-то API или модуль для NMS типа zabbix и т.п.

[vop]

24 minutes ago, VolanD666 said:

то можно сделать какой-то API

 

Как показывает опыт последних лет 20... НИЗЯЯЯЯ.

 

:)

 

С унификацией API в телеком софте вообще как-то не очень весело.

[VolanD666]

1 час назад, vop сказал:

 

Как показывает опыт последних лет 20... НИЗЯЯЯЯ.

 

:)

 

С унификацией API в телеком софте вообще как-то не очень весело.

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

[vop]

2 hours ago, VolanD666 said:

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

 

Представьте, что нет унификации, например, SMTP... :) А хотя бы какой-нибудь протокол.... Ну тогда каждый раз надо "пилить скрипт". Как там? "Пилите, Шура! Пилите!" :)