Cloud.ru вместе с «Нейтрино Технолоджис» и Netwell проверил, как Neutrino Foresight работает в распределенной инфраструктуре из трех независимых контуров. Для рынка вывод практический: NetFlow-аналитику можно собирать локально на каждой площадке, не отправляя сырые потоки в центральный ЦОД, а общую картину смотреть через единый интерфейс.
Для российских ИТ-команд это не демонстрация ради демонстрации. Речь о схеме, которая помогает снизить нагрузку на каналы связи, сохранить историю сетевых событий и не жертвовать обзором всей инфраструктуры.
Проект проверили на инфраструктуре, близкой к рабочей
О проекте 29 июля 2026 года сообщил CNews. По данным издания, речь шла не о лабораторном стенде: заказчику требовалось раздельно собирать NetFlow-статистику в каждом контуре, хранить длительную историю сетевых взаимодействий и не раздувать межплощадочный трафик.
Отдельным требованием стала совместимость с Astra Linux. Для российских заказчиков это уже не факультативная опция, а частый пункт в закупках и проектах по импортозамещению.
Как устроили сбор и сводную аналитику
Neutrino Foresight анализирует сетевой трафик и принимает данные в форматах NetFlow, sFlow и IPFIX с маршрутизаторов, коммутаторов и межсетевых экранов нового поколения. Система убирает дубликаты, дополняет потоки контекстом и сохраняет данные для последующего разбора.
На практике это дает понятные для эксплуатации и ИБ ответы: кто с кем взаимодействовал, куда уходил трафик, где появились аномалии, когда началась атака или деградация сервиса и что происходило до инцидента.
В каждом из трех контуров развернули отдельный экземпляр системы: коллектор, модуль обогащения, хранилище и пользовательский интерфейс. Затем между хранилищами настроили связность и кластерную работу. В результате платформа может работать как с локальной площадкой, так и с несколькими контурами сразу, если нужен сводный отчет.
Для пользователя это выглядит как единое окно аналитики: отчеты, виджеты и панели доступны из одного интерфейса, хотя сами данные остаются распределенными.
Технические доработки и требования заказчика
Cloud.ru отдельно отметил эксплуатационную часть проекта. Руководитель департамента эксплуатации и поддержки Дмитрий Максимов сказал, что компании было важно проверить решение в конфигурации, близкой к боевой: с несколькими контурами, единым интерфейсом, низкой нагрузкой на сеть и длительным хранением данных.
Со стороны Netwell BDM Александр Грачев сделал акцент на том, как вендор адаптировал продукт под реальную задачу заказчика. Для инфраструктурных проектов это обычно важнее красивого списка функций в презентации.
Среди прикладных деталей: совместимость с Astra Linux подтверждена, а все три коллектора развернули в виде виртуальных машин с невысокими требованиями к ресурсам. Кроме того, в проект добавили массовую загрузку групп и подсетей, чтобы упростить аналитику трафика между VLAN, региональными сегментами и другими логическими зонами.
Значение для рынка
Для российских провайдеров, крупных ИТ-служб и команд ИБ здесь важна сама архитектурная модель: данные остаются локально, а общая аналитика собирается поверх локальных хранилищ. Это снижает требования к межплощадочным каналам, упрощает масштабирование и лучше ложится на курс импортозамещения. Если схема покажет себя в реальной эксплуатации, у рынка появится еще один рабочий пример того, как строить распределенный сетевой мониторинг без лишней централизации.
Следующий шаг уже обозначен: стороны обсуждают интеграцию с Jira по API, чтобы автоматически передавать сведения о сетевых аномалиях в контур задач и инцидентов.