atshellnick Опубликовано 17 сентября, 2014 · Жалоба Добрый день! Кто знает, подскажите пожалуйста практику измерения качества доступа в интернет. Нужен некий системный подход + решение, позволяющее выборчно отслеживать качество доступа в сеть Интернет с узлов сети оператора на заранее выбранные цели. Понятно, что интернет это best effort и выбранные цели могут давать не гарантированные показатели во времени. Но все же такой подход способен дать данные для некоторых выводов. Первое что приходит в голову, это взять openwrt установить его на SOHO роутер, а сам роутер разместить на узле. Но тут встает вопрос выбора/поиска ПО и параметров за хочется наблюдать. Среди таких параметров, на которые можно оперется, думаются такие - время отклика на HTTP запрос от крупных серверов, скачивание файла с паблик FTP, возможно еще ICMP echo. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 17 сентября, 2014 · Жалоба Но все же такой подход способен дать данные для некоторых выводов. Маловероятно, подобные выводы с развитием CDN и прочих гуглокэшей стали слишком геозависимы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 17 сентября, 2014 · Жалоба А что мерить? Сеть оператора или интернет всё же? Разные вещи и по-разному решаются. Да и смысла мерить локалку от клиента до вашего оборудования? Если вы не знаете что у вас что-то где-то плохо - значит вам и не надо, ваш конкурент знает лучше. Если же измерять интернет, то ... То никак. Все показатели типа smoke ping / rtt / drop они сильно косвенные. Главный показатель (особенно для конечного потребителя) - субъективные ощущения. Так что берешь инет от Х магистралов, проверяешь на каждом на p2p-линке как оно "сёрфится", находишь идеал, пытаешься сделать так же. И в итоге конечно забиваешь, потому что в 90% случаев оно плохо уже за твоим бордером, и это не исправимо. Дальше оптимизма добавлять? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 17 сентября, 2014 · Жалоба Мы мониторим ошибки на портах, собираем логи со свитчей, смотрим загруженность на аплинковых портах, жалобы клиентов самое действенное средство, хотя и бывает такое, что абонент молчит о своих проблемах. Бывает сами находим проблемный порт, сами звоним абоненту и интересуемся, если ли у него проблемы. Ну далее работа монтажного участка по выявлению и устранению проблемы, даже если абонент всем доволен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 сентября, 2014 · Жалоба Мы мониторим ошибки на портах, собираем логи со свитчей, смотрим загруженность на аплинковых портах, жалобы клиентов самое действенное средство, хотя и бывает такое, что абонент молчит о своих проблемах. Бывает сами находим проблемный порт, сами звоним абоненту и интересуемся, если ли у него проблемы. Ну далее работа монтажного участка по выявлению и устранению проблемы, даже если абонент всем доволен. это всё не особо относится к топику. как я понял, речь идёт о мониторинге внешних ресурсов. в самом деле, вовсе не тривиальная задача и для этого, вообще говоря, желательно иметь подключения от конкурентов с другими аплинками Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 17 сентября, 2014 (изменено) · Жалоба Мы мониторим ошибки на портах, собираем логи со свитчей, смотрим загруженность на аплинковых портах, жалобы клиентов самое действенное средство, хотя и бывает такое, что абонент молчит о своих проблемах. Бывает сами находим проблемный порт, сами звоним абоненту и интересуемся, если ли у него проблемы. Ну далее работа монтажного участка по выявлению и устранению проблемы, даже если абонент всем доволен. это всё не особо относится к топику. как я понял, речь идёт о мониторинге внешних ресурсов. в самом деле, вовсе не тривиальная задача и для этого, вообще говоря, желательно иметь подключения от конкурентов с другими аплинками Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть. Изменено 17 сентября, 2014 пользователем Antares Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 17 сентября, 2014 · Жалоба Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть. А при том что ответ на вопрос "пачиму у меня саед ццц.порно.кг лагаед" лежит в большинстве случаев то за пределами конечного оператора. Если порты не в полке, цпу на роутерах/брасах (если они софтовые) не в полке, то исправлять и нечего. "Последнюю милю" еще надо уметь сделать плохо (речь об архитектуре а не о плохо обжатом кабеле). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 17 сентября, 2014 · Жалоба Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть. А при том что ответ на вопрос "пачиму у меня саед ццц.порно.кг лагаед" лежит в большинстве случаев то за пределами конечного оператора. Если порты не в полке, цпу на роутерах/брасах (если они софтовые) не в полке, то исправлять и нечего. "Последнюю милю" еще надо уметь сделать плохо (речь об архитектуре а не о плохо обжатом кабеле). Ну тогда надо дождаться ТС и узнать, что он имел ввиду Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
atshellnick Опубликовано 18 сентября, 2014 · Жалоба Цель не мониторинг внешних ресурсов (хотя как смотреть на это дело). Цель смотреть за тем как они видны со своей сети для обнаружения проблем у себя и у других. Речь как раз о вспомогательных данных, на которые можно ориентироваться. Например если пользователь сообщил - у меня лагает. Мы говорим - ОК, начинаем разбираться - смотрим текущие данные телеметрии свичей/роутеров/брасов - ошибки на портах, графы загрузки аплинков/процессоров/памяти/таблиц трансляций и прочих интересных моментов. Но ничего не находим, далее смотрим на то как видел "интернет" наш сенсор-резидент с узла до заявки пользователя и после заявки пользователя - пытаемся понять как коррелирует. Думаю полезно при поиске проблем ранее не известных, либо исскуственно созданных своими кривыми/шаловливыми руками. Набрав за пару месяцев данные наблюдения за внешними целями можно уже делать некие выводы о том, как ведут себя внешние цели. Если например у 6-7 целей расположенных на разных материках были одинаковые отколнения от средней условной нормы, то можно уже что-то предполагать. Кроме этого, иногда народ жалуется на конкретные ресурсы. Также, есть возможность разместить такие сенсоры у "дружественных" сетей и сопоставлять свои данные с ними. Идеи были такие (не берусь отстаивать плюсы и минусы): 1. Заббикс агент. 2. Найти что-то что анализирует нетфлоу и выборочно копать данные оттуда. 3. D-ITG PS: интересно также оценить стабильность внешних ресурсов и их видимость со своей сети при своих аплинках (вообщем из своей деревни). Примерные цели. 1. Ближайший Google Cache у апстрима. 2. CDN Akamai 3. Yandex 4. Mail.ru 5. VK.COM 6. Одноклассники 7. Транзитные задержки между узлами связи: Москва, Германия, Голладния, Лондон, Нью-Йорк и т.д. Ну а я понял как раз наоброт, какой смысл мониторить внешние ресурсы? Да и у нормальных провайдеров как правило не менее двух аплинков, при условии что они есть. А при том что ответ на вопрос "пачиму у меня саед ццц.порно.кг лагаед" лежит в большинстве случаев то за пределами конечного оператора. Если порты не в полке, цпу на роутерах/брасах (если они софтовые) не в полке, то исправлять и нечего. "Последнюю милю" еще надо уметь сделать плохо (речь об архитектуре а не о плохо обжатом кабеле). Ну тогда надо дождаться ТС и узнать, что он имел ввиду Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 18 сентября, 2014 · Жалоба Например если пользователь сообщил - у меня лагает. Мы говорим - ОК, начинаем разбираться - смотрим текущие данные телеметрии свичей/роутеров/брасов - ошибки на портах, графы загрузки аплинков/процессоров/памяти/таблиц трансляций и прочих интересных моментов. Но ничего не находим, далее смотрим на то как видел "интернет" наш сенсор-резидент с узла до заявки пользователя и после заявки пользователя - пытаемся понять как коррелирует. Думаю полезно при поиске проблем ранее не известных, либо исскуственно созданных своими кривыми/шаловливыми руками. Это конечно круто, борьба за юзера уже не на шутку. Но как показывает практика, в 99% случаев заяв "лаги" в саппорт, это торренты/вирьё, вобщем проблема на стороне абона, оставшийся процент делят м/у собой рвачество волокон/падение магистралов сверху и косяки с коннектором/плинтом на доступе, в пропорции 9 к 1. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 18 сентября, 2014 · Жалоба У вас процесс траблшутинга в корне не верный. Вам надо не ПО изобретать, а разобраться в том как должен работать ISP (особенно саппорт). В процессе познания вы и придете к простому выводу, что ваша идея "не нужна", ибо большая часть проблем находится за пределами вашей зоны ответственности. Знать rtt между чужими узлами это вообще из разряда фетишизма, уж простите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alex_001 Опубликовано 22 сентября, 2014 · Жалоба http://qosient.com/argus/ - метрики этим можно снимать , но все равно по ним обработку делать. Умеет все основные - rtt,jitter , потери , разные метрики по протоколам tcp ..e.t.c. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 22 сентября, 2014 · Жалоба Я у себя сделал MRTG с ping-ом на основные направления google, youtube, vk, mail, yandex, танки, ну и тд по ним сразу видно какой канал начал тупить, далее пинок магистралов, и ответ у нас упали линки. Без пинка могут провисеть и сутки Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
atshellnick Опубликовано 22 сентября, 2014 · Жалоба Да мне больше не для фетишизма а для исследований и проверок. За argus - спасибо - попробую! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MiB Опубликовано 22 сентября, 2014 · Жалоба RIPE ATLAS по моему именно то что описано в первоначальнорй задаче. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 22 сентября, 2014 · Жалоба RIPE ATLAS по моему именно то что описано в первоначальнорй задаче. Лучше бы они оставили роут-сервера. По ним сразу видны косяки магистралов, пытающихся "оптимизировать" свой траффик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
atshellnick Опубликовано 30 сентября, 2014 · Жалоба RIPE ATLAS по моему именно то что описано в первоначальнорй задаче. культурно! зарегался и попросил себе такой сенсор. посмотрим насколько жизненно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
