К сожалению, достаточно широко распространен прецедентный подход к построению систем сбора и анализа статистики сетевого трафика, когда тиражируется некоторое демонстрационное, модельное решение, вполне адекватное для небольших сетей, но не масштабируемое для реальных потребностей. Как правило, такие реализации имеют целью продемонстрировать состоятельность определенного технологического подхода, а не обеспечить решение практических вопросов, постоянно возникающих в процессе эксплуатации сети у ее администраторов и технического персонала. Модель-прототип оснащается графическим интерфейсом, и в результате возникает сложная и тяжеловесная система, декларативно предназначенная для чего угодно - для анализа трафика, для подсчета календарных итогов и для представления результатов такого анализа случайному пользователю, обладающая ``богатой'' функциональностью (суммы за неделю; суммы за декаду; суммы за две; за месяц и пр.), однако, имеющая чрезвычайно узкий круг пользователей в силу априорной заданности исходных принятых посылок. Обычно такого рода ``априорно'' построенные системы возникают в отсутствие предварительного анализа потребностей, набора задач и круга пользователей.
Ретроспективный анализ причин такого ограничения применений системы, как правило, сводится к утверждению об объективной невозможности обеспечения требуемой функциональности при использовании априорно выбранного инструментария. Отсюда делается неправильный вывод либо о невозможности реализации требуемой функциональности, либо о необоснованности неудовлетворенной потребности. Значительность ресурсов, затраченных в совокупности на реализацию такой системы, далее зачастую используется в качестве аргумента о нецелесообразности каких-либо переделок, по сути дела замораживая дальнейшее развитие всего направления.
На наш взгляд, соответствующий список приоритетов для сети СО РАН должен базироваться на понимании предназначения самой сети и функций обслуживающих эту сеть подразделений и служб. Так, одной из важных и, без сомнения, необходимых для оперативного управления сетью и для перспективного планирования, являются задачи учета потребления ресурсов сети различными группами пользователей -- как определенными статически (некоторая организация; региональный НЦ как единое целое), так и динамически возникающими субъектами (участники видеоконференции из разных организаций, участники традиционных конференций и/или собраний, использующие лишь традиционный доступ к ресурсам сети как в пределах конкретной организации, так и для группы организаций).
Принимая во внимание высокую ценность используемых в сети ресурсов (в первую очередь ресурсов пропускной способности внешних каналов), необходимо обеспечить возможность как оперативного, так и ретроспективного анализа нерегулярностей в использовании этих ресурсов с достаточной детализацией для выявления злоупотреблений в использовании ресурсов пользователями, группами пользователей, организациями.
Непредсказуемость вопросов, которые могут возникать при анализе аномалий, диктует необходимость наличия многофункционального пользовательского интерфейса для формулировки и выполнения конкретных запросов к системе, а также обеспечения доступа к исходным сырым данным, накопленным за некоторый период времени, для их обработки с помощью выбранных критериев и алгоритмов. Такие алгоритмы было бы нерационально включать в общую систему, разве что за исключением современных средств автоматической классификации аномалий и нерегулярностей потребления сетевых ресурсов.
В предлагаемой к реализации системе предусматривается наличие эффективных автономных средств для анализа и визуализации значительных объемов данных, генерируемых системой мониторинга. Например, при суммарной емкости внешних каналов 
150 Мбит/сек объем ``сырой'' статистики Netflow составляет около 1 Гбайт/час.
Если оперативный анализ экстренных ситуаций в сети квалифицированными сетевыми операторами в рамках современной системы возможен, хотя и непрост (например, эпизод с локализацией червя Slammer в сети ИМ СО РАН в 2004 г.), то их ретроспективный анализ существенно затруднен. То же самое следует отметить в отношении малозаметной, размазанной утечки ресурсов в современных сетях файлового обмена (упоминавшиеся выше P2P-приложения).
Упрощенные подходы к построению систем учета использования ресурсов в сети существенно увеличивают чувствительность реализуемых систем к помехам от сетевых атак и, тем самым, понижают их устойчивость. Так, достаточно распространенное сканирование внешними хостами портов внутренней сети, не говоря уже об атаке типа DDoS (разновидность атаки, приводящей к отказу в обслуживании легитимных пользователей за счет посылки большого числа сфабрикованных, бессмысленных запросов на использование определенного информационного ресурса) может приводить к существенному искажению и к потере статистических данных. Для обеспечения упомянутой выше устойчивости, системы сбора статистики должны разрабатываться с учетом возможности помех от зашумления исходных данных и непосредственных атак на систему. Эта проблема может быть снята путем обеспечения координация действий с системами обеспечения информационной безопасности (в частности, с IDS).
В современных условиях, когда в силу указанных выше обстоятельств, использование сетевых ресурсов не поддается тривиальной классификации по протоколам/номерам портов, зачастую необходимо привлекать дополнительную информацию более высоких уровней модели ВОС, которая может быть доступна либо при взаимодействии с IDS, либо при непосредственном анализе трафика. Наибольшие неприятности в данном случае могут представлять, как уже отмечалось, современные P2P-системы, эффективно использующие различные схемы динамического назначения портов (включая 80, 22, 25 и 53 порты).
Подводя итог краткому обзору распространенных подходов к сбору статистических данных в реальных сетях можно, на наш взгляд, выделить подходы, базирующиеся на поточной архитектуре (netflow и подобные), и подходы, аккумулирующие данные на фиксированных временных интервалах (IP-Accounting, SNMP-мониторинг).
При этом подходы, тяготеющие к поточной архитектуре, принципиально не могут отражать сиюминутную временную динамику трафика, тем самым искажая реальную картину: данные по определенному потоку во-первых, станут доступны только после завершения (естественного или принудительного) этого потока, а, во-вторых, эти данные представляют лишь интегрированные, усредненные по времени ``жизни'' потока результаты.
Подходы другого типа, собирающие данные на фиксированных временных интервалах, могут характеризовать трафик в реальном масштабе времени (с разрешением, определяемым продолжительностью интервала сбора статистики). Однако, в современных сетевых устройствах (коммутаторах, маршрутизаторах) таким образом может быть зафиксирован лишь очень ограниченный набор атрибутов трафика. Полноценный его анализ может быть обеспечен лишь при использовании специализированных сенсоров, что влечет дополнительные материальные затраты и приводит к общему усложнению системы. С другой стороны, такие дополнительные компоненты могут обеспечивать и ценную дополнительную функциональность, например, выступать в качестве IDS.