Различия

Показаны различия между двумя версиями страницы.

--- dpi:qoe:use_cases:monetization:full_netflow_analytics:start [2024/01/26 13:35] – elena.krasnobryzh
+++ dpi:qoe:use_cases:monetization:full_netflow_analytics:start [2024/04/25 08:26] (текущий) – удалено elena.krasnobryzh
@@ Строка 1: / Строка 1: @@
-{{indexmenu_n>1}}
-====== Аналитика Full NetFlow ======
-<note important>[[dpi:dpi_options:opt_statistics:statistics_ipfix:start|DPI выгружает информацию о всех сессия клиентов в формате IPFIX (NetFlow v10)]].</note>
-===== 1. Поиск ухудшения качества доступа к интернет =====
-DPI выгружает [[dpi:qoe:paramdescript:start|информацию о задержках между клиентом и 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]].
-В статистике фиксируется задержка в рамках каждого протокола с привязкой к UserAgent (берется из ClickStream), что дает возможность отследить работу конкретного устройства.\\
-Необходимые действия для поиска:
-  - перейти в раздел QoE Аналитика - > Абоненты - > Нетфлоу
-  - создать фильтр, где
-  * предлагается ограничить поиск по протоколу http/https, чтобы отсеять возможные особенности других протоколов при установке TCP соединения
-  * указать среднюю скорость, чтобы делать выборку из абонентов, активно пользующихся интернет
-  * указать нижний порог RTT от клиента
-{{ dpi:qoe:use_cases:фильтр_rtt.png?direct&600 |}}
-Интерпретация полученной статистики: {{ dpi:qoe:use_cases:результат_rtt.png?direct&600 |}}
-  * Фильтр вывел 25 потенциальных клиентов, у которых могут быть проблемы с доступом.
-  * Подробнее с задержками по времени, которые у них фиксируются, можно ознакомиться в окне **"Детали"**.
-  * Используя рупор, можно перенести их в __[[dpi:dpi_components:dpiui:user_guide:ssg_control_section:ad_campaign_management:start|маркетинговую кампанию и провести уведомление или опрос через браузер по удовлетворенности услугами]]__.
-  * Возможна выгрузка отчета в удобном формате.
-===== 2. Сервис "Мониторинг аплинков" =====
-==== Термины и определения ====
-**Аплинк (Uplink, восходящая линия)** — это канал связи от оператора к вышестоящему и/или магистральному оператору, откуда оператор берет интернет. \\
-**[[dpi:qoe:use_cases:monetization:full_netflow_analytics:start#описание_rtt|RTT]] (Round-Trip Time, время приема-передачи)** — это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен. Это время задержки, следовательно, состоит из времени передачи сигнала между двумя точками.
-==== Назначение ====
-Сервис "Мониторинг аплинков" позволяет без специальных экспертных знаний онлайн выявлять проблемы с доступностью сервиса у пользователей, которые могут возникнуть из-за канала между провайдером и интернет-ресурсом:
-  * Проблемы или загруженность вышестоящего оператора (аплинка).
-  * Медленная работа или недоступность самого сервиса.
-==== Начало работы ====
-Перед началом работы необходимо включить возможность сбора статистики.
-Для этого нажать на иконку ☰ в левом верхнем углу экрана и
-  - Выбрать в открывшемся меню пункт //Администратор//
-  - Выбрать пункт //Конфигурация QoE Stor//
-  - //QoE Stor//
-  - //Настройки сервиса сбора статистики UPLINK LOAD RATE//
-  - В пункте //Сбор статистики UPLINK LOAD RATE// выбрать //Включено//
-После выполненных действий нажать кнопку //Сохранить// в верхней части экрана.\\
-{{dpi:qoe:use_cases:uplink_settings.png?nolink&1100 |}}
-==== Внешний вид ====
-Сервис располагается в //QoE аналитика → QoE дашборд.//
-Чтобы добраться до виджета для мониторинга аплинков, в боковой панели с виджетами необходимо выбрать //Нетфлоу → Панели → Мониторинг аплинков// и перетащить виджет на дашборд.
-На боковой панели можно настроить (1) и удалить (2) каждый виджет. \\
-{{dpi:qoe:use_cases:widget_panel.png?nolink&300|}} \\
-В окне настройки виджета (1) можно изменить имя виджета на английском и русском языках (3) и его видимость (4). \\
-{{dpi:qoe:use_cases:widget_setup_1.png?nolink&300|}} \\
-В верхней части экрана можно выбрать, за какой период будет отображаться трафик (5), выбрать источник данных (6). \\
-{{dpi:qoe:use_cases:widget_setup_2.png?nolink&600|}} \\
-Для каждого протокола в его плитке отображается:
-  * **Наименование** протокола (7)
-  * **Объем** трафика на выбранный период (8)
-  * **Медиана** по RTT к абоненту, ms (9)
-  * **Дельта** трафика, % (10). Это разница между трафиком за выбранный период времени и трафиком из статистики, который обычно бывает за аналогичный период в тот же день недели
-  * Общая **оценка** здоровья сервиса (11):
-  - 0-3 балла — хорошо, кривая зеленого цвета
-  - 4-7 баллов — удовлетворительно, кривая желтого цвета
-  - 8-10 баллов — плохо, кривая красного цвета
-  * **Кривая** изменения оценки здоровья протокола (12). Кривая показывает, сколько раз менялась оценка протокола на выбранный период времени и не было ли плохих оценок. \\ {{dpi:qoe:use_cases:widget_estimate.png?nolink&350|}}
-==== Настройка протоколов в виджете ====
-При наведении на виджет в его верхнем правом углу появится значок ☰. Нажав на него, можно перейти в настройки, либо удалить виджет.
-{{dpi:qoe:use_cases:widget_protocols_setup.png?nolink&200|}}
-При нажатии на пункт //Настройки// откроется форма настройки. Здесь представлен список протоколов (1), их количество — от 1 до 10. Чтобы отображать больше 10 протоколов, можно добавить на дашборд несколько виджетов. Например, можно сделать несколько тематических виджетов — на мессенджеры и соцсети, стримы и прочее, в каждом до 10 протоколов.
-Добавлять (2) или удалять (3) можно все протоколы, которые есть в стандартном словаре. Для каждого протокола можно настроить оценки по дельте объема трафика (4) (в зависимости от того, насколько трафик изменится, будет добавлено от 0 до 2 баллов) и по показателю RTT (5). Данный показатель более важный, поэтому настройка более гибкая для сервисов, которые могут быть очень чувствительны к изменению этого показателя.
-Также для каждого из протоколов можно задать категорию важности (6), которая будет добавлять от 0 до 2 баллов к итоговой оценке в случае, если сумма по оценкам трафика и медиане будет больше нуля. Ресурсы имеют разную "чувствительность". Важно не допускать даже небольших проблем с чувствительными ресурсами. Каждому ресурсу пользователем присваивается категория важности:
-  * Категория 1 — очень популярный сервис, крайне чувствительный к качеству и разрывам связи.
-  * Категория 2 — нишевый, но известный сервис, требовательный к качеству.
-  * Категория 3 — сервис только начинает набирать популярность, но сам не может гарантировать качества контента или контент не критически важный.
-Рекомендованные значения влияния дельты объема трафика на оценку протокола (в %) и показателей RTT определяются разработчиком и передаются оператору, который далее настраивает их исходя из особенностей своей сети.
-{{dpi:qoe:use_cases:widget_setup_form.png?nolink&400|}}
-==== Что делать в случае проблемы ====
-В случае своевременного выявления и локализации проблем провайдер может решить их:
-  * Переключением на другой аплинк.
-  * Приоритизацией трафика (применением "аварийных" политик).
-  * Инициированием обращения к аплинку о проблемах.
-<note tip>Если решение невозможно (проблемы у сервиса или аплинк невозможно поменять), техническая поддержка провайдера сможет экономить время на выявлении проблем и своевременно информировать пользователей.</note>
-==== Описание RTT ====
-Время приема-передачи (англ. round-trip time, RTT) — это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен. Это время задержки, следовательно, состоит из времени передачи сигнала между двумя точками в пределах одного flow.\\
-За flow в DPI принимается вся сетевая активность в рамках source/destination socket (source IP:port /destination IP:port). \\
-Так как весь flow между клиентом и сервером проходит через DPI, подсчет RTT на DPI производится для двух направлений:
-  - От клиента до DPI (обозначение в GUI **от абонента**)
-  - От сервера до DPI (обозначение в GUI **к абоненту**)
-Регистрация каждого нового flow на DPI производится не по сообщению SYN от инициатора TCP соединения, а при получении ответа SYN/ACK, поэтому подсчет RTT производится исходя из разницы передачи и приема последующих сообщений:
-Клиент может являться сервером, а сервер - клиентом, в зависимости от того, кто инициализирует TCP соединение ( TCP SYN ). Соответственно, логика подсчета RTT тогда тоже меняется, и подсчет ведется наоборот.
-!!! Важно понимать, что RTT считается только для session-oriented ( TCP ) соединений. Для UDP подсчет RTT не производится.
-=== RTT от абонента до DPI ===
-{{ :dpi:dpi_components:dpiui:rtt_from.jpg?nolink&1000 |}}
-=== RTT к абоненту - от сервера до DPI (в случае если завершение было инициировано со стороны клиента) ===
-{{ :dpi:dpi_components:dpiui:rtt_to.jpg?nolink&1000 |}}
-=== RTT к абоненту - от сервера до DPI (в случае если завершение было инициировано со стороны сервера) ===
-{{ :rtt_from_fyn.jpg?nolink&1000 |}}
-== Особенности протокола TCP и расчет RTT ==
-В виду особенностей протокола TCP, возможно множество различных ситуаций, влияющих на подсчет RTT для конкретного flow.
-=== RTT от клиента до DPI для некоторых flow равен нулю ===
-{{ :dpi:dpi_components:dpiui:rtt_no_ack.jpg?nolink&1000 |}}
-В случае, если DPI не получил ACK от клиента на отправленный SYN/ACK.
-Подобная ситуация может случиться по нескольким причинам, например, клиент разорвал соединение физически, либо прислал RST.
-Во всех подобных ситуация, DPI проставит значение “0” в RTT от клиента до DPI для данного flow.
-=== RTT для некоторых flow принимают очень большие значения (десятки секунд) ===
-{{ :dpi:dpi_components:dpiui:rtt_zero.jpg?nolink&1000 |}}
-Например, такая ситуация может возникнуть в случае TCP HALF CLOSED CONNECTION (наполовину закрытый TCP), когда один из участников соединения прекращает передачу данных, однако все еще может получать данные от удаленной стороны. В таком случае, передающая сторона может послать FYN/ACK только после завершения передачи данных, в следствии чего, значение RTT значительно возрастет.
-===== 3. Сервис "Мониторинг киберугроз" =====
-<note>Статья в блоге: [[https://vasexperts.ru/blog/telekom/treker-kiberugroz-reshenie-ot-kaspersky-i-vas-experts/|Трекер киберугроз — решение от Лаборатории Касперского и VAS Experts]]\\ \\ Вебинар по теме: {{youtube>vU-yEuidtNc?}}</note>
-<note>Видео с демонстрацией интерфейса:\\ {{youtube>ewEF37z_9Ts?}}</note>
-С версии **2.30.4** в GUI СКАТ появилась возможность детектировать абонентов с киберугрозами. VAS Experts делает это в сотрудничестве с Лабораторией Касперского, которая обладает базой опасных ресурсов и огромным опытом в данной сфере.
-В разделе QoE Аналитика -> QoE дашборд появился виджет "Монитор киберугроз", на котором видно, сколько абонентов в течение выбранного периода времени посещали фишинговые сайты; вирусы на компьютерах каких абонентов проявляли какую-то активность в сети; какие абоненты являются участниками ботнета.
-Виджет состоит из четырех ячеек с цифрами:
-  - "Зараженные абоненты" — общее количество абонентов с потенциальными угрозами разных видов. **У одного абонента может быть несколько угроз, поэтому данное число может быть меньше суммы трех последующих.**
-  - "Абоненты с ботнет трафиком" — абоненты-участники ботнет. У таких абонентов **точно** есть вредоносное ПО, которое посещает командные центры ботнета.
-  - "Абоненты с вредоносным трафиком" — абоненты, которые посетили сайты с угрозами безопасности. Абонент мог посетить такой сайт самостоятельно либо мог вирус сходить. Такие абоненты необязательно что-то заражены вредоносным ПО, но есть угроза.
-  - "Абоненты с фишинговым трафиком" — абоненты, которые посетили фишинговые сайты. Абонент мог оставить на таких сайтах данные от своих банковских карт.
-Важно иметь в виду, что цифры отражают проблемные запросы, которые СКАТ увидел в трафике абонентов за заданное время. Если расширить фильтр по времени, туда попадут больше абонентов. За неделю их может быть до 40-50% от базы.
-Виджет можно добавить на экран со вкладки "Виджеты" -> Нетфлоу -> Панели -> "Монитор киберугроз".\\
-После добавления можно нажать на любую из ячеек виджета и попасть на соответствующий список абонентов. Этих абонентов можно предупредить об опасности, продать им антивирус или еще каким-то образом помочь, либо отследить их поведение — посмотреть, будут ли они обращаться в техническую поддержку с проблемами.
-{{ :dpi:qoe:use_cases:monetization:cyberthreat_monitor.png?nolink&1200 |}}
-<note tip>Для подключения данной функциональности нужно обратиться с заявкой в службу технической поддержки. В вашу QoE будет установлена база Лаборатории Касперского, после этого можно будет пользоваться виджетом.</note>