1. Нужна ли коллектору NetFlow v5 возможность делать детализацию клиентского трафика?

[user_anonymous]

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

[m_medved]

Поясните глупому.. каким образом сам коллектор NetFlow относится к детальной статистике конкретного абонента? Разве не биллинг/его обвески этим занимаются?

[user_anonymous]

Поясните глупому.. каким образом сам коллектор NetFlow относится к детальной статистике конкретного абонента? Разве не биллинг/его обвески этим занимаются?

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

[m_medved]

Всё равно не понятно. Если физически совмещать — так некоторые и файлопомойки на роутере с почтой и биллингом там же делают — всё зависит от задач и их объёмов.

Абоненту деталка в реал-тайме нахрен не нужна — ведь обычно она смотрится уже после возникновения вопросов «куда ушло бабло»/«что пожрало мой канал». При этом абонент взаимодействует с сервером статистики, поэтому логичнее всё-таки держать деталку на его (сервера) сторедже.

«Разливать» (да и и привести егов в человекопонятный текстовый вид) по файлам уже классифицированый поток деталки нехитрая программа на Цэ может со скоростью не менее 10 МБ/с.

Т.е. на мой взгляд, «при определенных условиях» — да, но именно «изготовление» потока.

[raven428]

flow-report всё хорошо умеет делать, но не в рилтайме и хорошо жрёт цпу. поэтому у нас детализация трафика стоит 50р за час детализации, чтобы у абонента не было желания страдать фигнёй.

[kostich]

Ребят, не надо боятся расходов по памяти. Мною делалось это на уровне парсинга неагрегированного сырого нетфлоу выплюхиваемого из коллектора. Делали под нетрамет и там еще свои заморочки были по поводу открытых/закрытых сессий... в итоге мы могли при учете даже обсчитывать тцп сессию на момент её закрытия. Следующую версию той разработки мы собираемся воплотить чуть иначе т.к. опыт по работе с большой напругой имеем. Само собой там будет сенсор ддос-ов и прочей активности, но касаемо учета будет так - бинарное флоу засасывается в обработчик по крону, обработчик лезет в базу и выгребает из неё правила учета на каком-то своем внутреннем языке, далее по всем этим правилам производится обработка флоу и результат добавляется или инкреминтируеся к записям в базе в соответствии с расчетным периодом. Гибкие правила учета нужны для маркетоидов, которые хотят продавать клиенту трафик от офиса до своего ДЦ по одной цене, ix-овый трафик по третьей, транзит по четвертой, локальный по пятой и т.д.... прошлый раз мы програмили это очень жестко и достаточно примитивно - маски можно было добавлять в учет, а можно было из него исключать (по всем полям netflow)... под все правила в памяти создаётся каунтер/ы и дале к нему плюсуется или вычитается в соответствии с учетными масками конкретного учетного объека. Производительность такого решения запрограмленного на сишнике достаточно высока. При большом количестве флоу и правил можно делать отложенный учет, т.е. учет той самой детализухи (smtp, ftp/ftp-data, http in, http out)... т.е. еще тогда мы даже отдавали клиенту сколько трафа нажрало входящее smtp и сколько трафа нажрало исходящее, ну и с такой схемой любой каприз дальше.

 

Память расчитывается очень просто - на один учетный объект максимум 4 байта... если всё правильно сделать на низком уровне, то лям учетных объектов (с кучей правил/масок/сигнатур по каждому) можно открутить по каждой записи из гигантского среза нетфлоу менее чем за 5 минут (не совсем линейно, но это более чем реально на не шибко дорогом железе)... какие-то куски на ассемблере все еще актуальны на самом деле... ну а там уже если не хватает, то можно увеличивать учетный период, использовать отложенную обработку по мене нужным правилам и т.д.... на линейной обработке мы по какому-то избыточному количеству масок обрабатывали более 50к флоу в секунду, а памяти там какие-то копейки жрало... при этом файл с флоу тупо mmap-ом цепляли.

 

ps. и потихонечку тут кумекаем уже под девятое флоу.. но нам в первую очередь интересен сенсор хреноактивности и нульраут в нужный пир, в нужное комунити, снятие анонса префикса по пирам и т.д... ну т.е. те самые базовые ништяки которые повышают доступность сети в момент когда внутри неё кого-то фачат трафом превышающим свободную полосу или что бы на бёрстовых линках не руками экономию наводить.

Изменено 17 ноября, 2008 пользователем kostich

[user_anonymous]

2 kostich - спасибо за интересный пост. Судя по всему, наваяли вы там что-то очень серьезное, у меня все гораздо скромнее, так как я хотел сделать только простую и неприхотливую систему учета.

На данный момент я заморозил работу по своей программе, степень ее готвности я бы оценил процентов на 70 - 75. Реализован поклиентский обсчет входящего и исходящего трафика на лету и генерация поклиентской детализации. Детализаиця генерируется отдельно на каждого клиента и раскладывается по каталогам (путь формируется на основе времени и адреса сети клиента), ничего парсить не надо.

Не реализованы операции добавления/удаления/модификации клиентских записей, тоесть чтобы добавить нового клиента прийдется останавливать коллектор. Также не реализовано реалтаймовое снятие статистики (эти вопросы взаимосвязанны, все что нужно - это обрабатывать еще один сокет) и определение факта пропуска пакетов в последовательности NetFlow (я вообще не уверен, что это нужно).

К сожалению, не проведено тестирование под нагрузкой ( негде :( ), но по субъективным ощущениям потребеление ресурсов CPU очень маленькое.

 

flow-report всё хорошо умеет делать, но не в рилтайме и хорошо жрёт цпу. поэтому у нас детализация трафика стоит 50р за час детализации, чтобы у абонента не было желания страдать фигнёй.

Да, я знаю о проблемах разбора логов flow-tools. В моей программе детализация вообще практически ничего не жрет. Самая ресурсоемкая опреация в высокоприоритетной части - это очистка массива указателей в случае обсчета больших сетей (класса А). В низкоприоритетной - это дисковый ввод-вывод.

Дерево каталогов с детализацией, формируемое программой, в принципе можно просто выставить в область видимости http - сервера (это правда будет не очень красивое решение, так как права доступа настраивать замучаешься). Я же планировал доступ абонента к детальной статистике через CGI-программу (она еще не написано, но сложного в ней ничего нету).

 

Насчет использования более современных версий NetFlow я тоже задумывался, ибо IPv6 не за горами, но это - дело будущего.

Изменено 24 ноября, 2008 пользователем user_anonymous

[zoro]

делали примерно как вы хотите.... т.е. кучу дир,дерево было таким.... год/меяц/день/ID_user... разбросс статистики по дирам с именем-ID пользователя, такая разбросска вызывает сильную фрагментацию дискового пространства, и в последующем даже шустрый SAS масив начинал тормозить итд итп.... легче было сделать так... льется все практически не прерывно в 1 файло(1файл-одна сутка ;) ), находящийся на отдельном "разделе"-реально преднозначенном именно для этого, потом раз в определенное время копия файла валилась на сервер детальной статистики где и делались всякие тело движения...

 

 

[user_anonymous]

делали примерно как вы хотите.... т.е. кучу дир,дерево было таким.... год/меяц/день/ID_user... разбросс статистики по дирам с именем-ID пользователя, такая разбросска вызывает сильную фрагментацию дискового пространства, и в последующем даже шустрый SAS масив начинал тормозить итд итп.... легче было сделать так... льется все практически не прерывно в 1 файло(1файл-одна сутка ;) ), находящийся на отдельном "разделе"-реально преднозначенном именно для этого, потом раз в определенное время копия файла валилась на сервер детальной статистики где и делались всякие тело движения...

Спасибо за ответ. Действительно, подходы у нас схожие. Хотел спросить у вас - а зачем делать так много файлов и каталогов? У меня дерево каталогов для детализаци выстроено несколько по-другому, благодаря чему, ИМХО, фрагментация будет гораздо меньше. У меня путь строится на основе адреса сети клиента, а по дате (год+месяц) формируется имя файла. Тоесть для клиентской сети 192.168.1.10/32 путь к файлу детализации за октябрь выглядит так:

detail/192/168/1/10/2008-10--192.168.1.10.txt

А в сам файл детализации пишется время дампа и количество входящего и исходящего трафика на этот момент, так что если Васи Пупкину захочется узнать, когда именно было скачено 10 гигов творчества немецких кинематографистов :) - надо будет лишь внимательно просмотреть файл, и это будет ясно с точностью до периода дампа (600 секунд по умолчанию).

[zoro]

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

после полной легализации пришлось перейти на биллинг, с дури выбрали UTM, теперь полностью жалеем... ищем альтернативу...

[Bushi]

Чтобы поднять производительность и улучшить функциональность, а так же избавиться от middleware и скриптовых обвязок написал собственный коллектор. Коллектор напрямую работает с базой данной (через интерфейс ODBC для независимости от типа базы данных), получая оттуда список сетевых устройств, абонентов и тарифных планов (с ip правилами). Потоки агрегируются "на лету" и в базу записываются уже обработанная агрегированная информация о трафике. А потоки записываются в обычные бинарные файлы (сжатые gzip) и попадают в архив. Идентификаторы интерфейсов хранятся в файлах независимо от их snmp-индексов. В таком режиме подсчета трафика "на лету" требуется очень немного ресурсов.

 

Детализацию можно запросить из архива в режиме офлайн, но для этого уже требуются существенная процессорная мощность. В режиме онлайн детализация не требуется.

 

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

 

Коллектор имеет следующие особенности:

 

* использование ODBC интерфейса для доступа к базам данных SQL (MySQL, PostgreSQL, Oracle)

* отсутствие привязки к SNMP ID интерфейсов маршрутизатора

* генератор отчетов

* возможность работы с более чем одним маршрутизатором

* счетчики траффика, работающие в реальном времени на базе IP фильтров

* интегрированный сервер авторизации и аккаунтинга Radius для коммутируемых соединений

* поддержка протокола EAP-MD5 для авторизации соединений на портах Ethernet по протоколу 802.1x

* интегрированный сервер DHCP с поддержкой Option 82 и запросов DHCP Leasequery для ADSL коммутаторов и станций DOCSIS

* интеграция Radius и DHCP для поддержки авторизации 802.1x (EAP-MD5)

* динамическое обновление имен DNS абонентских хостов

* учет трафика абонентов с использованием гибких тарифов (с правилами на базе IP фильтров) для постоянных и коммутируемых соединений

* xранение данных о трафике в сжатых (zlib) бинарных файлах

* мониторинг маршрутизаторов и Netflow коллектора

* интерфейс командной строки

* управление по протоколу XML-RPC

* многопоточность

* высокая производительность и нетребовательность к ресурсам

* минимизация нагрузки на базу данных

* небольшой размер