| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия |
| dpi:qoe_analytics:cases:network_health:full_netflow_analytics [2025/10/31 11:49] – elena.krasnobryzh | dpi:qoe_analytics:cases:network_health:full_netflow_analytics [2025/12/11 10:39] (текущий) – elena.krasnobryzh |
|---|
| <note important>[[dpi:dpi_options:opt_statistics:statistics_ipfix|DPI выгружает информацию о всех сессиях клиентов в формате IPFIX (NetFlow v10)]].</note> | <note important>[[dpi:dpi_options:opt_statistics:statistics_ipfix|DPI выгружает информацию о всех сессиях клиентов в формате IPFIX (NetFlow v10)]].</note> |
| |
| DPI выгружает [[dpi:qoe_analytics:qoe_gui:reports:paramdescript|информацию о задержках]] между клиентом и DPI и между DPI и хостом во время установления TCP соединения - [[https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D1%83%D0%B3%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0|RTT]]. | Самая простая и изученная метрика DPI по проверке качества связи - [[https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D1%83%D0%B3%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0|RTT]]. DPI позволяет измерить RTT и поделить его по направлениям (к абоненту и от абонента) и уточнить по протоколам и устройствам при необходимости. Большая задержка в течение продолжительного времени "от абонента" скорее всего говорит о том, что абонент испытывает сложности с доступом к онлайновым сервисам — играм, видео, коммуникации. Как правило, задержка возникает из-за WiFi-сети абонента, но может говорить и о перегрузке узлов сети. |
| В статистике фиксируется задержка в рамках каждого протокола с привязкой к UserAgent (берется из ClickStream), что дает возможность отследить работу конкретного устройства.\\ | |
| Необходимые действия для поиска: | Действия: |
| - перейти в раздел QoE Аналитика - > Абоненты - > Нетфлоу | - Перейти в раздел QoE Аналитика → Абоненты → Нетфлоу\\ {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_1.png?nolink&400|}} |
| - создать фильтр, где | - Создать фильтр, где: |
| * предлагается ограничить поиск по протоколу http/https, чтобы отсеять возможные особенности других протоколов при установке TCP соединения | * предлагается ограничить поиск по протоколу http/https, чтобы отсеять возможные особенности других протоколов при установке TCP соединения |
| * указать среднюю скорость, чтобы делать выборку из абонентов, активно пользующихся интернет | * указать среднюю скорость, чтобы делать выборку из абонентов, активно пользующихся интернет |
| * указать нижний порог RTT от клиента | * указать нижний порог RTT от клиента |
| {{ :dpi:qoe_analytics:cases:network_health:full_netflow_analytics:фильтр_rtt.png?600 |}} | |
| Интерпретация полученной статистики: {{ :dpi:qoe_analytics:cases:network_health:full_netflow_analytics:результат_rtt.png?600 |}} | {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_3.png?nolink&700|}} |
| * Фильтр вывел 25 потенциальных клиентов, у которых могут быть проблемы с доступом. | |
| * Подробнее с задержками по времени, которые у них фиксируются, можно ознакомиться в окне **"Детали"**. | Рекомендуется работать с абонентами из выгрузки, у которых среднее (а еще лучше медианное) RTT больше 100 за 24 часа. Для этого можно: |
| * Используя рупор, можно перенести их в __[[dpi:dpi_components:dpiui:user_guide:ssg_control_section:ad_campaign_management|маркетинговую кампанию]] и провести уведомление или опрос через браузер по удовлетворенности услугами__. | - Выгружать данные ежедневно в свою базу данных через API или напрямую из Click House QoE, уже в ней накладывать фильтры. |
| * Возможна выгрузка отчета в удобном формате. | - Сделать триггер в графическом интерфейсе с заданными параметрами. |
| | |
| | При обработке важно учесть следующие факторы: |
| | - Стоит проверить географическое распределение "проблемной" выгрузки. "Кучность" как правило появляется из-за перегрузок сети или старого коммутатора, проблему можно устранить на стороне оператора. Бывает, что "плохой" район подключен по устаревшей технологии (DSL или радиодоступ), тогда плохой RTT уже "не баг, а фича". |
| | - Абонент может не испытывать дискомфорт из-за задержки (и прямо говорит об этом если его спросить по телефону), например в случаях: |
| | * работают устройства IoT, может быть слабый сигнал у них |
| | * работает на устаревшем оборудовании и не ждет чудес |
| | * не пользуется онлайновыми сервисами |
| | - Проблемы в Wi-Fi сети могут возникать по причинам: |
| | * зашумленный Wi-Fi диапазон 2.4 в многоквартирном доме |
| | * слабый роутер |
| | * сложная топология или большие размеры квартиры/дома |
| | - Иногда невозможно определить хост, куда обращался абонент с высоким RTT\\ {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_4.png?nolink&1100|}}\\ Такое может быть по трем причинам: |
| | * обращение по IP |
| | * не http протокол |
| | * не указан SNI |
| | - В дополнение к RTT можно использовать метрику % ретрансмитов при поиске проблемных абонентов. Если продолжительное время (>30 минут) наблюдается существенное превышение фонового значения по ретрансмитам (обычно 4-5%), это признак деградации услуги у абонента. Использовать ретрансмиты без RTT не рекомендуется, велика вероятность ложного срабатывания. |
| | |
| | {{:dpi:qoe_analytics:cases:queries_from_database:problematic_subscribers_5.png?nolink&1100|}} |
| | |
| | Пример запроса в базу:\\ |
| | {{ :dpi:qoe_analytics:cases:queries_from_database:subs_bad_rtt_sample.sh |Скачать скрипт}} |
| | |
| | Параметры в скрипте:\\ |
| | ''format="CSV"'' - формат вывода. По умолчанию CSV. Возможные форматы: https://clickhouse.com/docs/en/interfaces/formats/\\ |
| | ''periodSecs=24*3600'' - период в секундах. По умолчанию 24 часа\\ |
| | ''rttMore=100'' - значение RTT. По умолчанию 100 |
