[Forst]

Всем бАльшое здрасте!

Пишу небольшой билинг. Собирает статистику по NetFlow.

Вобщем с напарником возникли разногласия.

Как хранить детальную статистику.

 

Вобщем моя идея вот такая:

В течении дня коллектор будет всё собирать в текстовые файлы.

Раз в несколько минут сохранять.

Паралельно общие данные будет заносить в БД (для оперативного доступа к ним).

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

Раз в неделю/месяц(в начале) бинарники(за прошлый месяц/неделю) будут архивироваться.

Вобщем человеку через веб будет доступна только общая статистика.

Если надо детально то по запросу, будет предоставляться распечатка из архивов.

 

У напарника идея проще: пихать всё в БД.

 

Чегось посоветуете?

[EvilShadow]

Все пихать в базу? Интересно, долго она протянет при таком подходе и какова будет скорость работы через Ндцать дней? :)

[Kuzin Andrey]

Вы разрабатываете Open Source или в закрытом виде ?!

У меня достаточно большой опыт создания биллинга для собственного пользования (уже более 3 лет). Хотел с нуля написать улучшенную версию распеределенной биллинговой системы и выложить в опенсорс, даже для этого домен имеется http://www.openbilling.ru , но сил не хватает одному такую систему создать. Если хотите, присоединяйтесь...

 

А теперь по вопросу... В своем биллинге я обрабатываю пакеты через libipq и заголовок каждого пакета записываю в файл. Помоему (стал забывать) каждая запись занимает 24 байта (заголовок и дата/время), таким образом записывается информация обо всех пакетах. При трафике в 300 гиг всего файлы занимают около 15 гиг, в сжатом виде около 3-4 гигов (для современных хардов это копейки у меня 100 гигов занимает информация за полгода, вполне достаточно если вдруг спорные вопросы возникнут).

Думаю для NetFlow также можно записывать в бинарном виде все приходящие посылки. А обрабатывать и считать надо в realtime. Смысла пихать это все в базу данных нет никакого. Надо считать сразу, потому что это процесс достаточно трудоемкий, и раз в сутки его делать достаточно накладно, можно уменьшить отклик системы и потерю новых данных.

Изменено 28 сентября, 2006 пользователем Kuzin Andrey

[nikitich87]

пихать всё в отдельную базу и через день\неделю\месяц\год выгребать все в файл-архив с очисткой БД.

[hcube]

Вообще говоря, современные БД очень быстро считают с включенными индексами. Конкретно у меня приемлемая скорость работы достигалась при агрегации по IP пользователя, IP сайта и подневной сборке статистики - т.е. за день можно для конкретного IP посмотреть статистику посещений по обьему. На базе порядка 2000 адресов выборку делало за единицы секунд. Вероятно будет вполне нормально пахать и при почасовой сборке. А детальную - кто, куда, с кем, вплоть до пакетов - можно кидать в файл.

Изменено 28 сентября, 2006 пользователем hcube

[balamutang]

flow-tools рулят. читайте маны и будет вам щастье.

 

flow-capture складывает в бинарники раз в пять минут. по еще тепленькому бинарнику обсчитывать трафик и посчитанный складывать в SQL-базу: "дата, юзер, послал, принял". бинарники хранишь полгода для детализации (вдруг чо :)). по SQL-базе считаешь траф и отдаешь юзверям статистику. фсе

 

пихать все в БД - глупо. у вас трафик с БД будет больше чем тот который считаете по нетфлоу.

[Microsoft]

Это смотря какая база. Если стоит какой-нибудь SQL сервер - все будет нормально. Все по-моему забыли, что на то и БД, чтобы хранить большие объемы данных.

Добавление записи всего одним запросом:

"INSERT INTO STATISTIC VALUES(.......)"

Какой тут трафик с БД? Когда делаешь INSERT - никаких выборок не делается, а просто добавляется запись и все. Нагрузка на машину с БД минимальная.

Пишите в базу и все будет работать нормально. Да и вообще сам запрос на добавление можете слать на другую машину по UDP, там получать и пихать в базу, только буфер приема сокета сделать побольше, чтобы при активном трафике не дропались пакеты.

[balamutang]

Это смотря какая база. Если стоит какой-нибудь SQL сервер - все будет нормально. Все по-моему забыли, что на то и БД, чтобы хранить большие объемы данных.

Добавление записи всего одним запросом:

"INSERT INTO STATISTIC VALUES(.......)"

Какой тут трафик с БД? Когда делаешь INSERT - никаких выборок не делается, а просто добавляется запись и все. Нагрузка на машину с БД минимальная.

Пишите в базу и все будет работать нормально. Да и вообще сам запрос на добавление можете слать на другую машину по UDP, там получать и пихать в базу, только буфер приема сокета сделать побольше, чтобы при активном трафике не дропались пакеты.

поищи по форуму - я уже делал выкладки. вкратце смысл в том что пакет инфы, которую описывает нетфлоу по размеру может быть меньше чем пакет с запросом INSERT отправленный к БД, особенно всякие UDP пакеты (DNS запросы, игры через интернет, синхронизация времени и тд)

[Microsoft]

Никто не мешает взять нужные поля из NetFlow-пакета и отправить их в бинарном виде на машину с БД. ИМХО это намного проще и удобней предложенной схемы с бинарными файлами, архивами, БД и т. д. Это получится не биллинг а куча костылей, где каждый костыль - слабое звено. То файлик пропал, то битый то еще чего...

 

flow-capture складывает в бинарники раз в пять минут. по еще тепленькому бинарнику обсчитывать трафик и посчитанный складывать в SQL-базу:

Тоже можно проделать с временными таблицами в БД.

[Forst]

Вы разрабатываете Open Source или в закрытом виде ?!

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

Пока что опен, но у партнёра сильное желание усё сертифицировать.

Отлов трафика это привелегия считалки какой-нить (Циски, на худой конец компа с ипкадом.)

Поэтому всё через netflow работает.

 

пихать всё в отдельную базу и через день\неделю\месяц\год выгребать все в файл-архив с очисткой БД.

О таком раскладе я чё-то даже неподумал... Неплохая идея.

 

flow-tools рулят. читайте маны и будет вам щастье.

 

flow-capture складывает в бинарники раз в пять минут. по еще тепленькому бинарнику обсчитывать трафик и посчитанный складывать в SQL-базу: "дата, юзер, послал, принял". бинарники хранишь полгода для детализации (вдруг чо :)). по SQL-базе считаешь траф и отдаешь юзверям статистику. фсе

У меня сейчас уже гатов аналог flow-capture, тока с нескалькми отличиями:

1: Весит 10илобайт. Против 3Мб flow-capture.

2: Я знаю как он работает, ибо мною писан.

3: Таймер запуска внешней программы с параметров в виде пути к толькочто созданнму файлу работает не как flow-tools (где указывают скока раз в сутки запускать, а более понятней, до крона далеко, но всё же лучше.)

4: Я могу слёгкостью дописать модуль, чтобы энта штука ложила всё не в файлы, а в БД.

5: Из минусов: он ложит всё в текстовые файлы несжимая. (Ну не такой уж и минус)

 

 

Это смотря какая база. Если стоит какой-нибудь SQL сервер - все будет нормально. Все по-моему забыли, что на то и БД, чтобы хранить большие объемы данных.

Добавление записи всего одним запросом:

"INSERT INTO STATISTIC VALUES(.......)"

INSERT это конечно легко.

Но опять никакой агрегации трафика.

Или это нафиг не надо, ложить всё как идёт на коллектор, а затем архивировать?

 

 

 

Вроде всё написал...

[Microsoft]

Но опять никакой агрегации трафика.

Или это нафиг не надо, ложить всё как идёт на коллектор, а затем архивировать?

Цитата

flow-capture складывает в бинарники раз в пять минут. по еще тепленькому бинарнику обсчитывать трафик и посчитанный складывать в SQL-базу:

Тоже можно проделать с временными таблицами в БД.

[Forst]

Но опять никакой агрегации трафика.

Или это нафиг не надо, ложить всё как идёт на коллектор, а затем архивировать?

Цитата

flow-capture складывает в бинарники раз в пять минут. по еще тепленькому бинарнику обсчитывать трафик и посчитанный складывать в SQL-базу:

Тоже можно проделать с временными таблицами в БД.

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

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

Объясните плз.

И вообще какую СУБД лучше использовать.

Я например очень привык к MySQL.

[Kuzmich]

ИМХО - в СУБД самого биллинга нужно пихать уже трафик, агрегированный по зонам. Для начислений ведь нужно знать не конкретные IP-адреса удаленных сайтов, а только к какой зоне этот трафик относится (интернет, внутренние сервисы и т.д.).

 

Если жу нужен подробный отчет - пусть юзер его отдельно заказывает, и делать отчет обычным flow-print с фильтрами или грепами.

 

Пишу небольшой билинг. Собирает статистику по NetFlow.

Если делаете биллинг не только для себя, а еще и для продажи - лучше не привязывайтесь сразу гвоздями к netflow, а сделайте его более универсальным. Кому-то больше по сердцу придется netramet, кому-то radius-accounting, а кто-то вообще будет парсить логи сквида.

 

Лучше разработать универсальный формат передачи данных о оказанных услугах в биллинговую систему, нпример:

 

Дата/Время записи об услуге | Источник записи (например, маршрутизатор) | Класс услуги (трафик, скачаный файл, кофе в постель) | единица измерения | количество | доп. информация

[Microsoft]

Потери не возникнет, если у временное таблицы будет одно постоянное название?

Не обязательно разные таблицы. Ведь сервер БД управляет обращениями к данным и их записью.

Пример:

1. Выгребаешь все записи с датой/временем до 15:00:00;

2. Агрегируешь, пихаешь агрегированные данные в основную таблицу;

3. Удаляешь все записи с датой/временем до 15:00:00 из временной таблицы.

Можно при агрегации например помечать для удаления обработанные и потом тупо их удалить. Вариантов много.

[Microsoft]

Да, еще: неплохо все это завернуть в транзакцию - это еще одно приимущество перед файликами...

[Forst]

Пишу небольшой билинг. Собирает статистику по NetFlow.

Если делаете биллинг не только для себя, а еще и для продажи - лучше не привязывайтесь сразу гвоздями к netflow, а сделайте его более универсальным. Кому-то больше по сердцу придется netramet, кому-то radius-accounting, а кто-то вообще будет парсить логи сквида.

 

Лучше разработать универсальный формат передачи данных о оказанных услугах в биллинговую систему, нпример:

 

Дата/Время записи об услуге | Источник записи (например, маршрутизатор) | Класс услуги (трафик, скачаный файл, кофе в постель) | единица измерения | количество | доп. информация

Нет сертифицированных железок, которые бы давали сквид-логи :-)

Зато есть железки которые дают нетФлоу и которые сертифицированы.

Получить сертификат на билинг легче если трафик получаешь с сертифицированного источника а не с какого-нить неизвестного.

 

P.S. Продавать пока несобираюсь ибо нечего продавать.

Изменено 29 сентября, 2006 пользователем Forst

[GateKeeper]

PostgreSQL:

myyear := extract(YEAR from mytime);

mymonth := extract(MONTH from mytime);

monthtable := 'traf_' || myyear || '_' || mymonth;

if not exists(select * from pg_catalog.pg_tables where tablename=monthtable) then

execute 'create table ' || monthtable || '(

"gettime" timestamptz NOT NULL,

"url" varchar NOT NULL,

"user" varchar NOT NULL,

"urlstatus" varchar NOT NULL,

"size" int8 NOT NULL

) WITHOUT OIDS';

execute 'CREATE INDEX ' || monthtable || '_uidx ON ' || monthtable || ' USING btree ("user")';

end if;

---------

 

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

 

Естественно, поля и их описание для временной таблицы - Ваши. Здесь только пример.

[balamutang]

Тоже можно проделать с временными таблицами в БД.

да ептваю.... простой пример: при синхронизации NTP пересылается 4 байта. при этом в MySQL от нетфлоу коллектора пойдет минимум 40-80 байт - в 10-20 раз больше. абсолютно аналогично будет с DNS запросами и гамесами типа контры... на TCP сессиях конечно трафик от коллектора к БД поменьше будет.

 

Но!..... кто знает что день грядущий нам готовит? мож придумают СуперСкайп какой-нить, звонилка, качалка и операционка в одном флаконе, а бегать все будет по UDP... :) и вам никаких 64-процессорных серверов не хватит, чтоб Мускуль это все переварил и не поперхнулся :)

[balamutang]

У меня сейчас уже гатов аналог flow-capture, тока с нескалькми отличиями:

1: Весит 10илобайт. Против 3Мб flow-capture.

2: Я знаю как он работает, ибо мною писан.

3: Таймер запуска внешней программы с параметров в виде пути к толькочто созданнму файлу работает не как flow-tools (где указывают скока раз в сутки запускать, а более понятней, до крона далеко, но всё же лучше.)

4: Я могу слёгкостью дописать модуль, чтобы энта штука ложила всё не в файлы, а в БД.

5: Из минусов: он ложит всё в текстовые файлы несжимая. (Ну не такой уж и минус)

1) и чо ты будешь делать с освободившимися 2.9 мб? :)

2) в манах все есть

3) про таймер не понятно... формат имени файла у flow-capture очень простой: ft-v05.2006-09-15.081001+0300 -

"ft-v05" - flow-tools netflow version 5 :)

"2006-09-15"-дата

"081001" - время

"+0300"-часовой пояс

можно кроном и запускать все...

а во flow-capture задается период в минутах, через который он закрывает старый файл и начинает новый. и разгребает он не только 5й нетфлоу, но и остальные понимает.

4)блин... да есть такое гавно во flow-tools, только не пользует его никто, потому что глупо нетфлоу в базу ложить.

5)без каментов. и чем это потом парсить? скриптами на перле чтоли? гы.

[Forst]

Усё разобрался!

Щас всё красиво выглядит.

Сделал как Microsoft сказал.

Щас всё симпотично выглядит!

 

Вот тока определится какую СУБД пользовать MySQL PgSQL иль чё другое.?????

[deep_admin]

Все отлично живет в mysql для несокльких терабайт трафика в месяц и при заборе как нетфлоу так и ip-accounting на нескольких тысячах юзеров. Просто используйте много временных таблиц, главное чтоб процессы записи и выборки из таблиц не пересекались по времени. Трафик с коллекторов можно ложить сразу в БД с частотой даже раз в минуту, там же аггрегировать и любому полю, раз в час/сутки/месяц можно суммировать. При правильных индексах все будет очень быстро выбираться.

Кстати очень рекомендую максимально разнести задачи биллинга на модули, например модуль аггрегации трафика не должен проводить операции с деньгами, ну и тд.

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

[jab]

Все отлично живет в mysql для несокльких терабайт трафика в месяц

Как насчет нескольких сотен терабайт в месяц ? :-)

[balamutang]

Все отлично живет в mysql для несокльких терабайт трафика в месяц

Как насчет нескольких сотен терабайт в месяц ? :-)

терабайты разные бывают. если это терабайты с серваков с фильмами - это одно, а если это терабайты с игровых это другое. либо одна ТСП-сессия на 700мб либо семь миллионов :)

[deep_admin]

Все отлично живет в mysql для несокльких терабайт трафика в месяц

Как насчет нескольких сотен терабайт в месяц ? :-)

терабайты разные бывают. если это терабайты с серваков с фильмами - это одно, а если это терабайты с игровых это другое. либо одна ТСП-сессия на 700мб либо семь миллионов :)

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

Чем чаще снимаются данные с коллекторов, тем меньше надо ресурсов для их тарификации, достаточно умно организовать очередь из временных таблиц (если например трафик за минуту неуспеваем за следующую минуту посчитать), тем более что предварительную аггрегацию делает сам netflow, вот например в том же ipcad'е:

 

netflow timeout active 30; # Timeout when flow is active, in minutes

netflow timeout inactive 15; # Flow inactivity timeout, in seconds

 

Более того когда у вас 7 миллионов TCP-сессий :) можно поставить N-тачек которые будут делать предбиллинг, а потом уже это сливать на сервер тарификации, к тому же еще на этапе предбиллинга можно отлавливать флуды, сканы и тд

[jab]

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

Для тех кто предлагал хранить неаггрегированные значения netflow в mysql - разница есть. :-)

 

Это при том, что если тенденция по анлимитам сохранится - биллинг с тарификацией траффика нафик

никому не нужен будет через пару лет. Все сведется к банальным SNMP counters.