[atshellnick]

Добрый день!

 

Кто знает, подскажите пожалуйста практику измерения качества доступа в интернет. Нужен некий системный подход + решение, позволяющее выборчно отслеживать качество доступа в сеть Интернет с узлов сети оператора на заранее выбранные цели. Понятно, что интернет это best effort и выбранные цели могут давать не гарантированные показатели во времени. Но все же такой подход способен дать данные для некоторых выводов.

 

Первое что приходит в голову, это взять openwrt установить его на SOHO роутер, а сам роутер разместить на узле. Но тут встает вопрос выбора/поиска ПО и параметров за хочется наблюдать. Среди таких параметров, на которые можно оперется, думаются такие - время отклика на HTTP запрос от крупных серверов, скачивание файла с паблик FTP, возможно еще ICMP echo.

[pppoetest]

Но все же такой подход способен дать данные для некоторых выводов.

Маловероятно, подобные выводы с развитием CDN и прочих гуглокэшей стали слишком геозависимы.

[DVM-Avgoor]

А что мерить? Сеть оператора или интернет всё же? Разные вещи и по-разному решаются. Да и смысла мерить локалку от клиента до вашего оборудования? Если вы не знаете что у вас что-то где-то плохо - значит вам и не надо, ваш конкурент знает лучше. Если же измерять интернет, то ... То никак. Все показатели типа smoke ping / rtt / drop они сильно косвенные. Главный показатель (особенно для конечного потребителя) - субъективные ощущения. Так что берешь инет от Х магистралов, проверяешь на каждом на p2p-линке как оно "сёрфится", находишь идеал, пытаешься сделать так же. И в итоге конечно забиваешь, потому что в 90% случаев оно плохо уже за твоим бордером, и это не исправимо. Дальше оптимизма добавлять? :)

[Antares]

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

[s.lobanov]

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

 

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

[Antares]

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

 

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

Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть.

Edited September 17, 2014 by Antares

[DVM-Avgoor]

Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть.

 

 

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

[Antares]

Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть.

 

 

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

Ну тогда надо дождаться ТС и узнать, что он имел ввиду

[atshellnick]

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

 

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

 

Набрав за пару месяцев данные наблюдения за внешними целями можно уже делать некие выводы о том, как ведут себя внешние цели. Если например у 6-7 целей расположенных на разных материках были одинаковые отколнения от средней условной нормы, то можно уже что-то предполагать. Кроме этого, иногда народ жалуется на конкретные ресурсы. Также, есть возможность разместить такие сенсоры у "дружественных" сетей и сопоставлять свои данные с ними.

 

Идеи были такие (не берусь отстаивать плюсы и минусы):

 

1. Заббикс агент.

2. Найти что-то что анализирует нетфлоу и выборочно копать данные оттуда.

3. D-ITG

 

 

PS:

 

интересно также оценить стабильность внешних ресурсов и их видимость со своей сети при своих аплинках (вообщем из своей деревни).

 

Примерные цели.

 

1. Ближайший Google Cache у апстрима.

2. CDN Akamai

3. Yandex

4. Mail.ru

5. VK.COM

6. Одноклассники

7. Транзитные задержки между узлами связи: Москва, Германия, Голладния, Лондон, Нью-Йорк и т.д.

 

 

 

 

 

 

 

 

Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть.

 

 

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

Ну тогда надо дождаться ТС и узнать, что он имел ввиду

[pppoetest]

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

Это конечно круто, борьба за юзера уже не на шутку. Но как показывает практика, в 99% случаев заяв "лаги" в саппорт, это торренты/вирьё, вобщем проблема на стороне абона, оставшийся процент делят м/у собой рвачество волокон/падение магистралов сверху и косяки с коннектором/плинтом на доступе, в пропорции 9 к 1.

[DVM-Avgoor]

У вас процесс траблшутинга в корне не верный. Вам надо не ПО изобретать, а разобраться в том как должен работать ISP (особенно саппорт).

В процессе познания вы и придете к простому выводу, что ваша идея "не нужна", ибо большая часть проблем находится за пределами вашей зоны ответственности.

Знать rtt между чужими узлами это вообще из разряда фетишизма, уж простите.

[alex_001]

http://qosient.com/argus/ - метрики этим можно снимать , но все равно по ним обработку делать. Умеет все основные - rtt,jitter , потери , разные метрики по протоколам tcp ..e.t.c.

[SiXeD]

Я у себя сделал MRTG с ping-ом на основные направления google, youtube, vk, mail, yandex, танки, ну и тд

по ним сразу видно какой канал начал тупить, далее пинок магистралов, и ответ у нас упали линки.

 

Без пинка могут провисеть и сутки

[atshellnick]

Да мне больше не для фетишизма а для исследований и проверок.

 

За argus - спасибо - попробую!

[MiB]

RIPE ATLAS по моему именно то что описано в первоначальнорй задаче.

[vlad11]

RIPE ATLAS по моему именно то что описано в первоначальнорй задаче.

 

Лучше бы они оставили роут-сервера.

По ним сразу видны косяки магистралов, пытающихся "оптимизировать" свой траффик.

[atshellnick]

RIPE ATLAS по моему именно то что описано в первоначальнорй задаче.

 

 

культурно! зарегался и попросил себе такой сенсор. посмотрим насколько жизненно.