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

2.

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

3.

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

Применения системы aVistar

наблюдаемость (obsevability) трафика передачи данных поверх стека Ethernet/IP;
качественные характеристики каналов связи для понимания реального SLA;
качественные характеристики сервисов для улучшения пользовательского опыта;
«учетные» данные по трафику для понимания загруженности каналов, устройств и отдельных направлений — необходимо для сетевого планирования;
поиск аномалий, в том числе для обогащения данных систем SIEM/SOAR;
инструментарий для исследования нештатных ситуаций в реальном времени или в прошлом.

Максимальный акцент

на использование визуализации больших данных и гибких средствах фильтрации данных о трафике для представления их на дашбордах в различных срезах.

Идеология: идея швейцарского ножа

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

Для кого предназначена система

Департаменты контроля и обеспечения качества сетевых услуг.
Инфраструктурные подразделения.
Команды SRE.
Для подразделений, отвечающих за кибербезопасность. Подробнее.

Тренды и базовые линии

На экране «Тренды и KPIs» отображаются тренды для каналов связи и сервисов с возможностью отслеживания порогов. Этот инструмент позволяет быстро увидеть и оценить долгосрочные и краткосрочные тренды состояния объектов под мониторингом на диапазоне времени от 15 минут до 1 года.

Достигается визуализация возможных деградаций.
Создается возможность планирования развития каналов связи и сервисов (capacity).

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

Исследовательский подход

Инструменты

Используются инструменты для ручного исследования проблем:

1. Фильтры данных – в зависимости от виджета используйте инструменты фильтрации данных для поиска нужной информации. Типовые варианты фильтрации:

по IP-адресам и подсетям;
по логическим портам;
по протоколам;
по именам пользовательских сервисов
по MAC-адресам;
по VLAN;
по ключевому слову в доменных именах и URL;
по типу транспортного протокола или версии IP;
по количественным и временным характеристикам трафика;
поиск с комбинированием разных фильтров;
… другие врианты

2. Сортировка данных в таблицах — последовательное нажатие на заголовок колонки меняет вариант ранжирования или возвращает выдачу данных в дефолтное состояние. Пример сортировок: по длительности сессий, по объёму полезной нагрузки и т.д.

3. Контекстные подсказки на виджетах — просто наведите курсор на элемент диаграммы для получения дополнительной информации в виде всплывающих подсказок (тултипов) при наведении курсора.

4. Представления трафика по разным срезам на виджетах системы, которые позволяют увидеть:

ТОПы генераторов трафика по объёму, сессиям или пакетам;
активность серверов, сервисов и эндпоинтов;
связи между эндпоинтами в любой интервал времени;
классификацию трафика;
загрузку как всего канала, так и отдельных сервисов;
содержимое DNS-запросов и SNI-записей из сертификатов;
потери пакетов как внутри канала под мониторингом, так и между любыми эндпоинтами в любой момент времени;
TCP-флаги любых сессий в любой момент времени;
временные параметры любых сессий: задержка на сервере, задержка на канале RTT;
трансграничный трафик;
… многое другое

Пример: как быстро увидеть связи между конечными точками трафика

ЦЕЛЬ: надо быстро увидеть, как ходит трафик в канале под мониторингом и детализировать информацию по нему и сервисам:

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

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

Инструменты решения в aVistar:

Отображение трафика по типам транспорта, версии IP
Возможность фильтрации по MAC/IP/VLAN/Протоколам/Подсетям
Встроенная машина времени для ретроспективного анализа
Возможность детализации данных (drill-down анализ)

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

Внутренние хосты по трафику (top talkers)

Топ хостов по трафику со связями, географическими данными и количеством трафика — Топ хостов по трафику со связями, географическими данными, количеством трафика и обнаруженными доменными именами

Top Talkers в Авистар — Топ хостов по сессиям со связями и привязкой к Geo-IP

aVisatr - Топ внешних хостов по трафику — Топ внешних хостов по трафику. При наведении курсора появляется тултип с дополнительной информацией.

Дальнейшие шаги

Drill-down анализ: практически каждый виджет в системе aVistar имеет возможность последующей детализации по клику мышкой.
Экспортировать данные: Данные с виджета также можно легко экспортировать в различные форматы для последующей вставки в отчеты или внешние системы BI-аналитики.
Проанализировать исторические данные.
Присвоить имена информационным потокам для дальнейшего отображения на дашбордах: просто и удобно

Общее время на решение задачи в системе aVistar - 1 минута

Пример: найти данные по отдельной сессии

ЦЕЛЬ: найти сессию по интересующим нас параметрам и посмотреть её детализацию.

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

Фильтры могут быть самые разные, вот некоторые из них:

IPs, ports, VLAN, ToS, QoS, MACs, Domain Names, транспортный протокол, версия IP, версия TLS, время начала и завершения сессии.
Данные по трафику в направлении клиент-> сервер и сервер -> клиент (размер payload, количество пакетов, общий объём данных, переотправлено пакетов/байт, потери пакетов, фрагментировано пакетов, перепутано пакетов/байт).
Флаги TCP.
Время круговой задержки (RTT).
Время отклика приложения (ART).
Содержимое служебных данных http: куки, методы, коды отклика, url, и т.д.

Далее выполняется вертикальный анализ (drill-down) по выбранной сессии, одним кликом, для получения более детальной информации:

Пример окна детализации сессии HTTP

Общее время поиска сессий в системе aVistar - не более 2-х минут

Пример: карта решения для медленного сервиса в aVistar

Вариант использования aVistar — исследовательский режим

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

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

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

Первостепенной задачей поиска причин деградации является необходимость быстрого понимания на чьей стороне возникла проблема:

сервер
сеть
устройство пользователя.

На рисунке показан примерный алгоритм определения сегмента, в котором возникают неисправности, при жалобе пользователя на «медленный сервис».

Каждый блок на диаграмме – это обращение к определенному виджету на дашборде системы, который представляет нужный срез данных с возможностью дополнительной фильтрации данных. Дополнительная навигация по временной шкале Таймлайна позволяет увидеть тренды по тем же данным: «как было» и «как сейчас».

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

Пример: находим медленные DNS серверы

Скорость отклика подсистемы DNS (Domain Name System) напрямую влияет на общее восприятие пользователями работы сетевых сервисов. Давайте посмотрим как можно выявить проблему средствами системы aVistar на конкретном примере.

Постановка задачи. Ряд клиентов из локальной сети 192.168.1.0/24 жалуется на медленное открытие внешних ресурсов. Проблема носит несистемный, «плавающий» характер.

Решение. В этом случае потребуется комплексный подход к выявлению причин деградации пользовательского опыта (QoE). Начать необходимо с проверки работы базовых сервисов внешних транзакций клиента, в частности проверки работы DNS.

Шаг 1. Используя виджет «Хосты по отклику» с дополнительной фильтрацией по протоколу DNS можно наглядно увидеть список самых медленных сервисов DNS, с указанием максимального отклика за выбранный интервал наблюдения.

Шаг 2. Drill-down. Кликаем по медленному серверу DNS (77.88.8.8) для выявления клиентов, которые подверглись негативному влиянию этого DNS-сервера.

Шаг 3. Разбор ситуации. В новом окне построена таблица, в которой каждая строка — это отдельная сессий между выбранным DNS-сервером и клиентами. По умолчанию результаты ранжированы по времени отклика. Из результатов можно сделать выводы, что:

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

Шаг 4. Локализация проблемы. Если пролистать результаты дальше, то можно увидеть, что отклик DNS сервера 77.88.8.8 для других хостов находился в рамках приемлемых значений (не более 20 миллисекунд). Это означает, что с высокой степенью вероятности проблемы была связана с локальной перегрузкой на хосте 192.168.1.147

Общее время решения задачи в системе aVistar - 3 минуты

Дальнейшие шаги

Экспортировать полученные данные для вставки в отчет или Excel.
Получить детализацию по каждой отдельной сессии из таблицы сессий.
Посмотреть исторические данные по взаимодействию пары 77.88.8.8 <—> 192.168.1.147 через протокол DNS.
Поставить на постоянный мониторинг время задержки отклика DNS для пары эндпоинтов 77.88.8.8 <—> 192.168.1.147, чтобы убедиться, что проблема не носит постоянный характер.
Посмотреть смежные параметры, которые могут дать дополнительную картину о состоянии сервисов DNS (как завершались сессии, количество ретрансмитов и т.д.)
Перейти к рассмотрению других параметров, которые могут внести вклад в деградацию QoE для пользователя 192.168.1.147.

Задержки в канале: определяем на чьей стороне проблема

Задача: посмотреть распределение задержек (latency, delays, RTT) во времени внутри канала связи под мониторингом и разобраться с чем связаны задержки: с работой сети передачи данных или с работой прикладных серверов.

Решение. Система имеет несколько способов поиска или мониторинга медленных приложений. Для серверов мы строим топ медленных серверов и простым вертикальным анализом наглядно видим, на каких клиентов из нашей сети они оказывали негативное влияние.

Информация разбивается на два ключевых параметра:

Задержка — что соответствует круговой задержке на сети (RTT Round-trip Time)
Отклик — что соответствует задержке на стороне серверной части (ART — Application Response Time)

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

Дальнейшие шаги

Детализировать информацию, сузив поиск только для конкретных протоколов или эндпоинтов.
Поставить на постоянный мониторинг задержки внутри канала (ART и/или RTT).
Посмотреть данные по задержкам внутри канала в историческом срезе с помощью виджета статистики.

Общее время решения задачи в системе aVistar - 1 минута

Смотрим потери пакетов для целевых сервисов

Задача: В корпоративной сети имеются почтовые сервисы. Абоненты жалуются на проблемы «доступности» этих сервисов. Необходимо определить, что вызывает проблемы.

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

Одними из ключевых метрик качества, на которые надо обратить внимание в любом случае, являются:

потери пакетов;
фрагментирование пакетов;
переотправка пакетов.

В системе aVistar есть ряд виджетов, которые покажут распределение этих метрик во времени.

Дополнительные шаги

Можно:

Отфильтровать эти данные для пары p2p, или многовекторной передачи данных p2mp.
Выбрать конкретные IP или сервисы.
Выбрать нужный интервал времени в прошлом, или в реальном времени.
Поставить эти метрики на мониторинг (прокативный подход)

Разбираем жалобы клиентов на качество web-сервиса

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

Решение проблемы

Используя инструменты системы, пользователь может быстро сузить поиск и локализовать проблему. Сперва смотрим сессии пользователей, от которых поступила жалоба. Для этого:

На экране «Просмотр сессий» отфильтруем сессии с IP адресов этих пользователей за выбранные период времени с четом протокола SMB. Определяем пул SMB-серверов, который был задействован в информационном обмене.

Поскольку SMB-протокол работает поверх TCP, обращаем пристальное внимание на параметры отфильтрованных сессий по флагам TCP. Флаги выводятся в отдельную колонку таблицы, что делает процесс анализа предельно простым. Обращаем внимание на сессии с флагами SYN-RST, SYN-FIN, SYN-ACK-RST, только SYN и особенно CWR (Congestion Window Reduced). Перечисленных сессий должно быть мало от общего количества сессий.

Общее время решения задачи в системе aVistar - 10 минут

Разбираемся как загружено целевое устройство

ЦЕЛЬ: разобраться как загружено конечное сетевое устройство (сервер, хост, принтер, устройство IoT, и т.д.) и как оно взаимодействует с сетью

Для решения этой задачи в системе предусмотрен простой визуальный инструмент, а последовательность действий выглядит так:

Открываем специальный экран внутри системы
Вводим ip адрес интересующего нас устройства
Смотрим результаты на отдельном виджете «Статистика по пользователю».

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

Дальнейшие шаги

При необходимости меняем на виджете KPI (на примере выбран «Общий трафик» устройства), чтобы увидеть активность устройства по другим параметрам.

Общее время решения задачи в системе aVistar - 2 минуты

Сравнительный анализ сессий

ЦЕЛЬ: поиск анализ причин возникновения проблемных сессий, которые оказывают влияние на пользовательский опыт.

Решение

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

Суть: сравнить проблемные сессии с аналогичными «здоровыми» сессиями по разным векторам и/или временным интервалам.

Это позволит локализовать проблему, ответив на вопросы:

Проблема только для конкретной p2p-сессии, или на сети есть сессии с аналогичным стеком технологий и без проблем?
Проблема существует для определенного направления (подсети)? Тогда проблема находится на коммутатор, который собирает проблемные направления.
Проблема существует для всех направлений? Если проблема возникает только по одному вектору p2p, то причина находится на стороне клиента и работе последнего фута.

Далее

Сравнить важные дополнительные детали:

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

Общее время решения задачи в системе aVistar - 3 - 15 минут