The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Биллинг на Netflow"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Биллинг на Netflow"  
Сообщение от Constantine A. Yarovoy email on 24-Май-07, 19:02 
Публика, подскажите по концепции биллинга. Текста накропал достаточно, но есть вопросы по концепции, которая была сделана и пока ещё не залита на продакшн сервер.
-------

Клиентам даём выделенные линии в домах по 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 формат для хеширования и более скорого доступа к фрагментам файла по хэшу?

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Биллинг на Netflow"  
Сообщение от v.i.t (??) on 24-Май-07, 21:46 
3)... Может есть смысл хранить не в текстовых файлах, а скажем в db файлах и применять Berkeley Database формат для хеширования и более скорого доступа к фрагментам файла по хэшу?

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Биллинг на Netflow"  
Сообщение от pavel_simple (ok) on 25-Май-07, 08:42 
посмотри ipcad
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Биллинг на Netflow"  
Сообщение от Den (??) on 26-Май-07, 10:53 
>посмотри ipcad
а как реализован метод деления трафика на траф зоны (c помощью sql, c/c++, perl или другим софтом) и какой алгоритм используется.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру