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

Клиентам даём выделенные линии в домах по ADSL. Домов по городу 20 штук.
В каждом доме сервак, на нём каждый клиент - это vlan.

Для снятия статистики с vlan решил юзать Netflow v5 информацию. На каждом сервере запускаю Netflow сенсор, указываю с каких vlan брать данные. Потоки Netflow со всех серверов идут в один коллектор на главном сервере который стоит на Collocation.

Коллектор принимает данные (полные, нефильтрованные и неагрегированные), и складывает их в файлы текстового формата вида:

time_begin:time_end:src_ip:dst_ip:src_port:dst_port:sensor_server

sensor_server, это IP сервера, с которого был принят Netflow поток.

Храню всю эту текстовую инфу в такой иерархии папок:

+ billing
   - Server.Lenina
     - 2007
       - 01
         - 01
           > lenina-20070101-0000-0100.stat
           > lenina-20070101-0100-0200.stat
           > lenina-20070101-0200-0300.stat
         - 02
         - 03
       - 02
       - 03
   - Server.Gorkovo
   - Server.Krasnoarmejskaja
   - Server.Moskovskaja
   - Server.Pushkina

Для удобства статистика разбита по домам,годам,месяцам,числам. В папках за определённое число лежат файлы статистики за часы этого дня, т.е. "0000-0100" с 00:00 до 01:00.

Храню первоначальную статистику в файлах, потому как такие объёмы в базе хранить уж очень накладно по ресурсам.

Статистика старше трёх месяцев архивируется в tar.gz, бэкапиться на отдельные SCSI винт, и удаляется из иерархии папок за ненадобностью.

Далее по окончанию очередного часа времени запускается скрипт, который парсит файлы за прошедщий час.

Он:

1) делает фильтрацию, чтобы не учитывать лишние icmp пакеты, обращения клиентов к локальным сервисам (вообщем всё то, что не тарифицируется - не учитывается)

2) далее по сделанной ранее фильтрацим делается агрегация данных по определённой политике агрегации (за 15 мин скажем)

3) получившиеся на выходе данные льются в базу данных MySQL.

В MySQL табличка нехитрая, просто грамотно расставлены индексы для ускорения выборок.

Далее всё это дело выводиться через веб клиенту (ну и нам в конторе соответственно) всевозможными способами.

Если клиент хочет инфу более чем за 3 месяца тому назад, он просит об этом службу поддержки. Она в свою очередь через веб-скрипт выбирает из tar.gz нужные архивы, распаковывает их и кладёт в темповскую таблицу в MySQL (не в основную). Всё это делается через веб, без лазанья ssh'ом по роутерам - так сказать исключается человеческий фактор.

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

Деньги считаются по тарифам, тоже сформированным в MySQL.

------

Соответственно у меня у самого вопросы:

1) Не хочеться сенсором выгребать все данные под чистую, пересылать их коллектору, а только потом на главном серваке их фильтровать. Соответственно, какой сенсор поддерживает определённые правила фильтрации пакетов чтобы не экспортить такие большие потоки?

2) Корректно ли разработана у меня система работы с устаревшими данными статистики? Я дал планку в 3 месяца, чтобы не загромаждать MySQL таблицу уже фактически устаревшими сведениями. Возможно у Вас на уме есть более привлекательный способ бэкапа старой инфы или  более корректного выбора её из архивов?

3) Что применять для парсинга текстовых файлов? Сейчас это сделано на С++ с применением pthread, т.к. главный сервер содержит 4 Xeon. По сути парсинг голового текста это как раз та задача во всём процессе сбора статистики, которую можно бы и оптимизировать и выиграть во времени. Может есть смысл хранить не в текстовых файлах, а скажем в db файлах и применять Berkeley Database формат для хеширования и более скорого доступа к фрагментам файла по хэшу?

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

Просто прошу Вас оценить идею и дать свои замечания или пожелания по сути.

• Биллинг на Netflow,v.i.t, 21:46 , 24-Май-07
  • Биллинг на Netflow,pavel_simple, 08:42 , 25-Май-07
    • Биллинг на Netflow,Den, 10:53 , 26-Май-07

3)... Может есть смысл хранить не в текстовых файлах, а скажем в db файлах и применять Berkeley Database формат для хеширования и более скорого доступа к фрагментам файла по хэшу?

в бинарном формате(родной формат Flow без  лишних полей)  с фиксированной длиной записи

посмотри ipcad

>посмотри ipcad
а как реализован метод деления трафика на траф зоны (c помощью sql, c/c++, perl или другим софтом) и какой алгоритм используется.

Сам использую flow-tools, деления по траф зонам делаю спомощью flow-tag, flow-nfilter, для которого правила формируются динамически. В базу (postgres) лью уже агрегированный траф по портам (users ports aggregate into port 32000) - так уменьшается количество записей в базе. Потом агрегирую по сесиям (10 минут интервал).

Все писано на perl