Публика, подскажите по концепции биллинга. Текста накропал достаточно, но есть вопросы по концепции, которая была сделана и пока ещё не залита на продакшн сервер.
-------Клиентам даём выделенные линии в домах по 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 формат для хеширования и более скорого доступа к фрагментам файла по хэшу?
В этом тексте специально я не указывал особо какие я юзаю утилиты (читай порты, коллекторы, демоны и т.д.), чтобы не было споров на тему что лучше. Подход как видите весьма продуман был, согласитесь.
Просто прошу Вас оценить идею и дать свои замечания или пожелания по сути.