Отчеты NetFlow/sFlow для филиалов: кто «съел» интернет

Что значит «кто съел интернет» в филиале

Типичная картина: в филиале жалуются, что «все тормозит», но канал не падает. В мониторинге видно, что линк то 60%, то 90%, иногда есть потери, иногда нет. Почта, ERP и видеозвонки работают рывками, а пользователи уверены, что «интернет пропал».

Проблема в том, что пинг и утилизация интерфейса отвечают только на вопрос «есть ли симптом». Пинг показывает задержку и потери до одной точки, а график интерфейса - общий объем. Но они не объясняют, кто именно создал нагрузку, какое приложение ее создало и куда ушли мегабиты.

Когда спрашивают «кто съел интернет», обычно нужно быстро разложить ситуацию по четырем осям: кто (устройство, пользователь, подсеть), что (приложение, порт, протокол), когда (точное окно, всплески, повторяемость), сколько и куда (объем, скорость, направление, внешний адрес или внутренний сервер). Именно для этого и нужны отчеты NetFlow/sFlow: они показывают не только «сколько», но и «кем и чем».

Простой пример: канал в филиал 50 Мбит/с, и каждый день в 10:00 начинаются жалобы. По интерфейсу - просто пик. А по потокам выясняется, что один ПК гонит большие загрузки в облачное хранилище, и из-за этого страдают голос и доступ к корпоративным системам.

В первые 30 минут инцидента обычно важны такие вопросы:

• Что стало топ-1 по трафику прямо сейчас и за последние 15 минут?
• Какие приложения выросли сильнее всего по сравнению со «вчера в это время»?
• Это один «топ-говорун» или много мелких источников?
• Трафик наружу или внутрь (к ЦОД, в интернет, в облака)?
• Какие сервисы важны для бизнеса и насколько они деградировали?

Если вы можете ответить на них быстро и одинаково понятно для ИТ и руководства, значит вы действительно находите «кто съел интернет», а не просто наблюдаете графики.

NetFlow vs sFlow: что вы получаете на выходе

Отчеты NetFlow/sFlow отвечают на практичный вопрос: какие устройства и какие «разговоры» в сети заняли канал. Это не «прослушка» содержимого, а учет того, кто с кем общался, сколько данных передал и когда.

NetFlow работает с «потоками». Поток можно представить как запись о соединении: источник, назначение, порты, протокол, объем, время. Такие записи удобно агрегировать в отчеты: топ по трафику, по направлениям, по приложениям (если они определяются), по филиалам.

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

Почему разница важна:

• Потоки проще агрегировать и сравнивать по времени (до/после, час пик, рабочие часы).
• Пакетная выборка быстрее и легче для оборудования, но иногда «прячет» редкие события.
• И там, и там вы видите метаданные (кто, куда, сколько), но не видите содержимое.

Экспортировать данные обычно могут разные устройства на периметре и в ядре филиала. На практике источники чаще всего такие: маршрутизатор (видит весь выход в WAN), межсетевой экран (видит политики и часто пользователей), коммутатор (видит то, что проходит через него, особенно полезно в больших офисах).

Отдельная тема - «имена приложений» уровня L7 (например, Teams, YouTube, облачные диски). Одних flow-данных иногда мало: современный трафик часто шифруется, а порты давно перестали «говорить правду». Чтобы в отчетах появились понятные названия, нужен источник классификации:

• DPI или App-ID на межсетевом экране
• NBAR или похожие механизмы на маршрутизаторе
• логи прокси/secure web gateway
• сопоставление по DNS и SNI (работает не всегда)

Простой пример: филиал жалуется на «медленный интернет». Flow покажет, что 60% канала уходит на один IP внутри филиала и несколько внешних хостов. А чтобы понять, это обновления, видеосервисы или резервное копирование, чаще всего нужен L7 на FW или прокси.

Какие данные собирать, чтобы отчеты были полезными

Чтобы отчеты NetFlow/sFlow реально отвечали на вопрос «кто съел интернет», важно собрать не «все подряд», а минимальный, но полный набор данных. Иначе вы увидите красивые графики, но не сможете назвать конкретное приложение, пользователя или направление.

Начните с базовой цепочки: устройство-экспортер (маршрутизатор, L3-коммутатор, пограничный фаервол), коллектор (куда стекаются потоки), хранилище (на сколько дней держите историю) и панель отчетов. Если нет истории хотя бы 7-14 дней, вы не поймете, это разовый всплеск или новая норма.

Критичные поля лучше проверить сразу, до пилота. Без них «виновник» часто остается анонимным:

• src/dst IP (кто и куда)
• src/dst port и протокол (что за тип трафика)
• bytes/packets (сколько именно)
• time (время начала и конца потока)
• interface и direction (вход/выход, какой линк)

Дальше решает точность. sFlow обычно идет с sampling, NetFlow часто точнее, но и тяжелее для оборудования. Практичный подход - начать с sampling 1:512 или 1:1024, проверить, не теряются ли короткие, но важные потоки (например, DNS), и только потом повышать точность. Таймауты потоков тоже важны: слишком короткие раздробят картину, слишком длинные спрячут пики.

Разделение по филиалам продумайте заранее. Проще всего привязать трафик к конкретному WAN-интерфейсу филиала. Если сеть сложнее, помогут теги по VRF, понятный адресный план и единые имена интерфейсов, чтобы отчеты не смешивали филиалы.

И наконец, договоритесь о «норме» для каждого филиала. Зафиксируйте базу по типовым дням (будни, конец месяца) и согласуйте пороги:

• средняя загрузка канала и пики
• топ-5 приложений по трафику
• доля «небизнес» трафика
• допустимый рост (например, +20% к базе)

Тогда, когда филиал внезапно «упадет» по скорости, вы сравните с базой и быстро увидите отклонение, а не будете спорить, «так всегда было» или нет.

Быстрые отчеты, которые находят виновника за 10 минут

Когда в филиале «все тормозит», важно не гадать, а быстро сузить круг: кто, куда и в какой момент занял канал. Ниже - набор отчетов NetFlow/sFlow, который обычно дает ответ за один проход.

5 отчетов, которые проверяют первыми

Начните с фиксированного окна времени (например, последние 30-60 минут) и при необходимости сдвигайте его к моменту, когда пользователи начали жаловаться.

• Top talkers по объему и по скорости (Mbps): покажет устройства, которые «съели» больше всего, и тех, кто держал самую высокую скорость. Часто это разные хосты.
• Top applications (приложения или порты) с долей канала: помогает понять, это рабочая нагрузка (CRM, обновления), или что-то лишнее (стриминг, торренты, облачные загрузки).
• Top conversations (пары клиент-сервер): сразу видно, кто именно общался с каким сервером и где «льется» трафик. Полезно, когда одно устройство говорит с одним внешним адресом и забивает линию.
• Тренд утилизации по времени: график загрузки канала по минутам покажет, когда началась деградация. Это помогает связать всплеск с событием (бэкап, обновления, выгрузка отчетов).
• Inbound vs outbound: отвечает на вопрос «качали или отдавали». Если outbound высокий, ищите загрузки в облако, резервные копии, отправку видео, удаленные рабочие столы.

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

Быстрая проверка «это локально или системно»

Если у вас несколько филиалов, добавьте разрез «филиал-канал»: сравните долю утилизации и топ-приложения по каждому каналу. Так видно, проблема в одном офисе (локальный «виновник») или это общий сценарий (например, централизованные обновления пошли одновременно).

Мини-сценарий: тренд показывает пик в 10:15, inbound вырос в 3 раза. В Top applications лидирует HTTPS, а в Top conversations один ПК активно качает с одного внешнего адреса. Дальше остается подтвердить, что это было (обновление, загрузка архива, видеопоток) и принять меру: перенести на ночь, ограничить скорость, добавить исключение или поменять политику.

Главная идея простая: один отчет редко дает ответ. Два-три отчета из этого набора почти всегда сходятся в одну понятную причину.

Шаблон дашборда для ИТ (оперативный)

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

Верхняя шапка: «что горит прямо сейчас»

Вверху держите статус каналов по филиалам в формате зелено-желто-красно. Рядом покажите 3-5 свежих инцидентов по влиянию: где есть потери, задержка или утилизация близко к пределу.

В шапке обычно достаточно:

• Утилизация вход/выход по каждому филиалу и тренд за последний час.
• Потери и задержка (если есть измерение) и отметка «в норме/плохо».
• Топ филиалов по риску: «канал забит», «скачок новых назначений», «рост real-time».
• Быстрые фильтры: филиал, период, направление (в интернет/из интернета/межфилиальный).

Основные блоки: «кто и чем забивает»

Дальше идут два быстрых среза: топ устройств и топ приложений. Держите три окна времени: последние 15 минут, 1 час и 24 часа, чтобы отличать разовый всплеск от привычной нагрузки.

Добавьте таблицу conversations (разговоров) с сортировкой по битрейту и объему. В фильтрах оставьте минимум: филиал, источник/назначение, порт или приложение, направление. Важно показывать не только «топ по объему», но и «топ по текущей скорости», иначе ночные бэкапы будут выглядеть виновниками днем.

Если у вас включены QoS-классы, покажите долю real-time трафика (голос, ВКС) и отдельно - что вытесняет его сейчас. Это помогает быстро решить, что резать нельзя, а что можно ограничить.

Блок «аномалии» держите коротким, чтобы он действительно работал:

• резкие всплески относительно базовой линии (например, +200% за 10 минут)
• новые внешние назначения (раньше не встречались в филиале)
• новые сервисы/порты или внезапная смена приложения
• долгие «тяжелые» разговоры (высокая скорость больше N минут)
• несоответствие расписанию (например, бэкап пошел в рабочее время)

Короткий пример: филиал стал красным, а в топе за 15 минут появляется один ПК и приложение «облачное хранилище». В conversations видно один внешний адрес и устойчивые 80-90% канала. Действие: временно ограничить класс best effort, перенести синхронизацию по расписанию и проверить, не появился ли новый агент или политика обновлений.

Шаблон дашборда для руководства (управленческий)

Руководству нужен дашборд, который отвечает на три вопроса: где есть риск остановки работы, сколько это длится и что выгоднее сделать дальше. Технические детали (порты, ACL, очереди) лучше оставить ИТ-команде, а здесь показывать понятные метрики и причины.

Блок 1. Состояние связи по филиалам (KPI)

Сделайте таблицу или тепловую карту по всем филиалам за неделю и месяц. Для каждого филиала достаточно 2-3 индикаторов: доступность, качество (потери/задержка как оценка) и число инцидентов. Важно показывать не разовые пики, а устойчивые проблемы: например, филиал был в красной зоне 4 дня из 7.

Блок 2. Загрузка канала и время "на пределе"

Один график по каждому проблемному филиалу: средняя загрузка и 95-й перцентиль, плюс счетчик часов, когда канал был выше заранее заданного порога (например, 85-90%). Это переводит разговор из «иногда тормозит» в «12 часов в неделю работаем на грани».

Блок 3. Структура трафика по категориям (не по портам)

Покажите доли: бизнес-приложения, инфраструктура (обновления, бэкапы) и «прочее» (видео, соцсети, неизвестное). Этот срез часто делают на основе классификации в отчетах NetFlow/sFlow, чтобы руководству было понятно, куда уходит полоса и что можно ограничить без вреда для работы.

Блок 4. Топ причин ухудшений и последствия

Выведите топ-3 причин за период с коротким пояснением. Обычно это перегруз в часы пик, фоновые обновления или резервное копирование в рабочее время. Рядом полезно показать эффект: сколько часов деградации, сколько филиалов затронуто и какие бизнес-процессы страдают (кассы, медсистемы, ERP).

Ниже удобно добавить «блок решений» как понятный выбор:

• изменить политику (перенести обновления/бэкапы на ночь, ограничить «прочее»)
• увеличить канал (если бизнес-трафик стабильно упирается в потолок)
• оптимизировать приложение (если один сервис создает всплески)
• настроить контроль (цели на следующий месяц: меньше часов «на пределе», меньше инцидентов)

Пример: филиал в пиковые часы 9:00-12:00 регулярно превышает 90%, при этом доля бизнес-приложений всего 35%, а остальное - обновления и «прочее». Решение для руководства выглядит просто: сначала перенос обновлений и ограничение категорий, и только если KPI не улучшатся, обсуждать расширение канала.

Пошаговый разбор: как найти источник перегруза

Когда в филиале «все тормозит», важно попасть в конкретные 10-20 минут, когда пользователи жаловались. Тогда отчеты NetFlow/sFlow дают ответ быстро и без догадок.

Сначала выберите нужный филиал (или конкретный WAN-канал) и узкий период. Лучше всего взять время из обращений в сервис-деск, сообщений в чате или логов приложений: например, «вторник 10:40-11:05». Дальше откройте график утилизации канала и отметьте окно деградации: рост до 90-100%, всплески или ровную «полку».

Затем работайте только внутри этого окна:

• откройте Top talkers (источники и получатели) и Top applications (приложения) за выбранные минуты
• сравните лидеров по трафику и по количеству соединений: один «толстый» поток и тысячи мелких создают разные проблемы
• проверьте, не совпал ли пик с резервным копированием, обновлениями, синхронизациями, видеонаблюдением или видеозвонками
• отфильтруйте результаты по интерфейсу и направлению, чтобы понять, где узкое место: inbound или outbound

Когда нашли подозрительный источник или приложение, провалитесь в детали разговоров (Top conversations). Там обычно становится ясно «кто с кем», в какие сети, на какие порты, и это легитимная нагрузка или нет. Пример: один ПК бухгалтера «льет» десятки гигабайт в облачное хранилище по 443, а рядом идет поток из сервера обновлений на все рабочие места.

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

Финальный шаг - зафиксировать вывод в тикете и согласовать действие. Обычно выбирают одно из двух:

• изменить приоритеты (QoS) или перенести задачу на ночь (резервные копии, обновления)
• ограничить или заблокировать конкретный трафик, если он не нужен бизнесу

Частые ошибки и ловушки в отчетах NetFlow/sFlow

Самая частая проблема не в том, что «нет данных», а в том, что данные собраны так, что по ним нельзя быстро ответить: кто именно занял канал и почему это стало проблемой. Тогда отчеты NetFlow/sFlow превращаются в красивые графики без действий.

Первая ловушка - слишком крупный sampling и слишком короткое хранение. При агрессивной выборке вы увидите только «крупные» потоки, а мелкие, но постоянные (обновления, синхронизации, облачные агенты) будут теряться. Если хранить детальные данные всего 1-2 дня, вы не сможете сравнить «сегодня» с «обычно», и повторяющиеся сбои останутся без объяснения.

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

Третья ловушка - смотреть только на Mbps. Для голоса и ВКС важны потери, задержка и джиттер. Реальный кейс: канал загружен всего на 60%, но пользователи жалуются на «роботизированный» звук. Причина может быть в очередях QoS или потере пакетов на последней миле, а по одному графику Mbps это не видно.

Еще две типичные ошибки: отсутствие базовой линии и отсутствие понятной классификации приложений. Без «нормы» любой всплеск кажется инцидентом. А когда все сводится к портам и IP, даже верный «виновник» плохо читается бизнесом.

Проверьте настройки, чтобы отчеты не вводили в заблуждение:

• sampling и период агрегации подходят вашей задаче (видны короткие пики)
• хранение позволяет сравнивать хотя бы 2-4 недели
• есть теги филиала, канала и конкретного интерфейса
• помимо скорости видны потери и задержка для критичных сервисов
• приложения подписаны понятными категориями, а не только IP:port

Короткий чеклист: готов ли ваш мониторинг отвечать за 5 минут

Если в филиале «пропал интернет», времени на долгие расследования нет. Хороший мониторинг должен за несколько кликов показать: где узкое место, когда началось, кто и что забило канал.

Проверьте, можете ли вы сделать базовую диагностику без ручной выгрузки и «танцев» с фильтрами:

• Для каждого филиала есть два быстрых вида: «топ за последние 15 минут» (для инцидента) и «топ за 24 часа» (для понимания привычной нагрузки).
• Один простой фильтр выделяет нужный канал (интерфейс) и направление: входящий или исходящий трафик. Если для этого нужно 5 условий, вы потеряете время именно тогда, когда оно важно.
• Есть список «топ разговоров» (кто с кем) с возможностью сразу провалиться в детализацию по конкретному времени, а не только «среднее за час».
• На графике видно момент ухудшения и момент восстановления: по времени до минут, а не «где-то сегодня утром».

Отдельно оцените, насколько мониторинг говорит на языке бизнеса, а не только IP и портов:

• Приложения показаны понятными категориями: почта, ВКС, ERP/CRM, обновления, облачные хранилища.
• Есть сохраненный «отчет на 1 страницу» для руководства: что случилось, какой филиал, сколько длилось, какой тип трафика был причиной, какие действия выполнены.

Если по любому пункту ответ «скорее нет», улучшение обычно несложное: добавить готовые представления, закрепить фильтры по интерфейсам, настроить категории приложений и стандартизировать управленческий шаблон. Тогда через 5 минут у вас будет не «кажется, кто-то качает», а конкретный ответ с временем и фактами.

Пример из практики: один филиал, один виновник, понятный вывод

Утро, обычный рабочий день. Филиал жалуется, что ERP «подвисает», а в видеосовещаниях рвется звук. По ощущениям у пользователей «интернет умер», но по пингу до провайдера все выглядит терпимо. Нужен ответ не «плохо работает», а кто и чем забил канал.

Смотрим отчеты NetFlow/sFlow по филиалу и сразу сужаем окно: в 10:05 начался резкий рост исходящего трафика, к 10:40 он вернулся к норме. На графике загрузки WAN видно, что забит именно outbound, поэтому интерактивные приложения (ERP, ВКС) страдают первыми.

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

Чтобы не гадать, фиксируем вывод простым набором фактов, который понятен и ИТ, и бизнесу:

• интервал перегруза: 10:05-10:40
• направление: исходящий трафик
• источник: один ПК в офисе
• характер: длительные сессии на внешний адрес
• эффект: просадки ERP и ВКС в те же минуты

Решение оказалось приземленным: на этом ПК запускали выгрузку архивов в облако «как удобно», то есть днем. Задачу перенесли на ночь, для этого класса трафика поставили ограничение, а на будущие повторы настроили алерт по правилу «если один хост держит больше X% исходящего канала дольше N минут».

Через неделю в управленческом отчете для руководства стало видно главное: количество «часов перегруза» в рабочее время резко снизилось, а жалобы по ERP и ВКС прекратились.

Следующие шаги: как внедрить и закрепить процесс

Внедрение за 2-4 недели

Начните с договоренностей. Если не зафиксировать, какие филиалы и каналы важнее, вы получите много графиков, но мало ответов. Составьте короткий список приоритетов: ключевые филиалы (по выручке или количеству сотрудников), основные каналы (MPLS, VPN, интернет) и бизнес-приложения, которые нельзя «ронять» (например, 1С, CRM, видеосвязь).

Дальше определите обязательный минимум отчетов. Обычно достаточно двух наборов: оперативный для ИТ (что происходит сейчас и кто создает пик) и управленческий для руководства (что мешает бизнесу, где нужны изменения или бюджет). Важно, чтобы логика этих отчетов была одинаковой во всех филиалах, иначе сравнивать будет невозможно.

Чтобы процесс работал ежедневно, оформите его как короткий план:

• зафиксировать приоритеты: филиалы, каналы, приложения, критичные часы (например, 09:00-12:00)
• утвердить 5-7 обязательных метрик и отчетов для ИТ и для руководства, и кто их получает
• настроить пороги и уведомления: всплеск трафика, новые назначения (new destinations), аномальный рост «unknown» приложений
• подготовить регламент действий: кто смотрит алерты, какие действия разрешены (связаться с филиалом, ограничить класс трафика, открыть тикет провайдеру)
• ввести ритм: ежедневный быстрый просмотр (5 минут) и еженедельный разбор причин и изменений

Закрепление как привычки

Полезная практика: раз в неделю выбирайте один «шумный» филиал и делайте короткий вывод в 3 строки: что было, кто генерировал, что изменили. Через месяц у вас появится база типовых причин (обновления, резервные копии, камеры, торренты, облачные синхронизации) и понятные правила.

Если параллельно нужна инфраструктура под коллектор, хранение и отчетность, это часто упирается в надежные серверы и нормальную интеграцию в действующую сеть. В таких задачах может помочь GSE.kz (gse.kz) как системный интегратор: например, поставить серверы под сбор и хранение данных (в том числе из линейки S200 Series) и поддержать решение в эксплуатации.