Посчитать траффик

[wel]

Привет Всем
стоит задача посчитать траффик + хранить детализацию для каждого ИП-а с разных роутеров....
Думаю, что лучше всего подходит netflow, тоесть пункт 2-а хранить полную детализацию выполнен...

Теперь как быть с подсчетом траффика?
Надо считать по ипу, и желательно в ДБ лишнюю инфу не гонять...Есть тут примеры - закинуть всю инфу в дб, но Мне такое не подходит....

Прочел о flow-filter и написал:

Код: Выделить всё

# cat mynet.acl
ip access-list standard mynetwork permit 10.200.0.0 0.0.255.255
ip access-list standard mynetwork deny any

Код: Выделить всё

flow-cat /var/db/flows/2009/2009-01/2009-01-12/f* | flow-filter -fmynet.acl -D mynetwork | flow-stat -f8 -S2 
flow-cat /var/db/flows/2009/2009-01/2009-01-12/f* | flow-filter -fmynet.acl -S mynetwork | flow-stat -f9 -S2 

Вроде имею отдельно сумму траффа по хостам отдельно исходящую, и отдельно входящую...
+Я еще и не уверен что правильно
Встал вопрос - как получить статистику которую можно в Дб положить в виде ИП/входящий траф/исходящий траф?

Можно наверное взять:

Код: Выделить всё

# flow-cat /var/db/flows/2009/2009-01/2009-01-12/f* | flow-nfilter -Ficf -f 1.cfg | flow-stat -f 10 -s 2 | grep 10.200.253.253|grep 81.177.141.7 | less
# src IPaddr     dst IPaddr       flows                 octets                packets
10.200.253.253   81.177.141.7     1                     1109                  8
81.177.141.7     10.200.253.253   2                     6833                  10

и суммировать вручную, но Я думаю - это будет долго....

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[paradox]

а что такое Дб ?? )))

зы
екпортируй с нетфлов сразу в БД и там уже простенькими запросами обрабатуй

[ADRE]

может имелось в виду дБ на декаду?

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

[wel]

может имелось в виду дБ на декаду?

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

Дб => Db Database И вообще это в контексте сказано
Эт все гуд, до поры до времени...Я согласен, что можно хоть 100 раз в базу заливать инфу, хоть 300 раз для каждого пользователя пересчитывать, но это все можно делать в одном лишь случае - если подсчет успевает за входящей новой порцией информации...
Но такова жизнь...и в том месте где Я нахожусь каждому уже сейчас дают безлим в 8Мбит, а в будущем(через 4мес) ->40Мбит...
Надо ли говорить, что сейчас у Меня:

Код: Выделить всё

nas1# flow-cat ft-v05.2009-01-13.000000+0200  | flow-print | wc -l
   24303 

За 1 минуту...И это не все пользуются торентами и прочим ...+ ко всему добавится UA-IX 1Гбит...
Посему Я не вижу смысла так издеваться над базой данных - вваливая ненужную инфу и там её суммируя.

[hizel]

filter

Код: Выделить всё

filter-primitive client-address
 type ip-address-mask
 permit a.b.c.d w.x.y.z
 default deny

filter-definition client-in
 match ip-destination-address client-address

filter-definition client-out
 match ip-source-address client-address

Код: Выделить всё

flow-cat nas/2008-12 | flow-nfilter -ffilter -Fclient-in | flow-stat -f8 -S2

входящий трафик


вобще я бы рекомендовал к flow-capture прикрутить тэгирование, по тэгам быстрее выбирается, там же разделять трафик например до UA-IX и внешка

[paradox]

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

а ты не каптурь все записи в одну бд
а используй для каждого месяца к примеру (или каждой недели) свою таблицу
и ненадо думать за СУБД
за нее думает процессор ) - небаись он умный справиться

нетфлов вообще то не для онлан учета
а для суммирования траффика к примеру по суточно
и предоставления подробной статистики

для он лайн учета
используй другие системы

[hizel]

для он лайн учета
используй другие системы

просвети глупого какие такие системы используются?

[paradox]

имеллось ввиду всякие count на счетчиках ipfw и прочие

что бы при привышении лимита deny вставлять

когда траффика несколько пирингов
то лучше разнести пиры на отельные тазики
и вести учет воды на каждом отдельно и там же count или чего то то там считать и блочить


а использовать нетфлов записи для учета запуская их подсчет каждые 5 минут к примеру - несамый лучший вариант

ну либо как саааамый крайний вариант
после експорта статистики с нетфлов в базу
сразу запускать подчет и результаты скидывать в отдельную таблицу
по которой уже и ориентироваться на allow / deny клиенту

думаю все же у всех нормальных провов уже анлимит
и мало кто занимаеться учетом по превышении месячного лимита 100 мегабайт с точностью в байт))))))

[wel]

когда траффика несколько пирингов
то лучше разнести пиры на отельные тазики

+1

и вести учет воды на каждом отдельно и там же count или чего то то там считать и блочить

а использовать нетфлов записи для учета запуская их подсчет каждые 5 минут к примеру - несамый лучший вариант

ну либо как саааамый крайний вариант
после експорта статистики с нетфлов в базу
сразу запускать подчет и результаты скидывать в отдельную таблицу
по которой уже и ориентироваться на allow / deny клиенту

думаю все же у всех нормальных провов уже анлимит
и мало кто занимаеться учетом по превышении месячного лимита 100 мегабайт с точностью в байт))))))

НУ блин есть 1500 чел с безлимитами и 500 с помегабайтами(дается 10Гб халявных и потом помегабайт), которые надо считать с погрешностью 1Кб...Так вот все тягомотина из-за помегобайтщиков+надо знать сколько каждый клиент выкачивает....

[paradox]

НУ блин есть 1500 чел с безлимитами и 500 с помегабайтами

а как они подключены ?
диалап?
выделиные линии?
домовые сети?- если да то там обычно vpn

[wel]

НУ блин есть 1500 чел с безлимитами и 500 с помегабайтами

а как они подключены ?
диалап?
выделиные линии?
домовые сети?- если да то там обычно vpn

Руководство сказало уходить от PPPTP/PPPoE...

[paradox]

на ум приходит такая схема

1 отдельно машинки под mpd для клиентской стороны
2 отдельно машина под биллинг(радиус) помощнее с быстрыми винтами и упсом
3 отдельно машины под пиринги что бы учитывать разные *-IX и нетфлов сбрасывать на биллинг машину
внимание!!!! не все записи а токо общую сумму которая уже посчитата

это при условии что надо считать для каждого юзера скоко какого пиринга он сожрал и килять его в mpd (килять будет радиус+биллинг) котроый и будет вести статистику

думаю на такое колличество клинетов это будет оптимальное решение

[hizel]

ipfw c каунтами строем идут в зад, когда нужно разделить трафик по направлениям
ну и еще аргумент, желательно разделять Authorization\Authentication и Accounting, удобнее и суше

[paradox]

ipfw c каунтами строем идут в зад, когда нужно разделить трафик по направлениям

траффик считаеться уже на пире который разрулен по BGP
тоесть уже на точка идет подсчет

но при таком количестве юзеров конежно да ipfw будет тяжеловато

[ADRE]

а нахера при таком количетсве вообще ipfw считать? мне че-то не понятно... если геморишся с ipfw то и дописывай соответственно скрипты, даже траффик с 1500 машин можно учесть имея слабый проц, но если прикручивать ограничения то нужно чтоб все быстро делалось )

[paradox]

ipfw count в некоторых случаях оптимально
но в даном случае будет оптимально нетфлов
но что бы не загружать сеть и машины
то сразу сортировку и суммиорования производить на месте
а в биллинг отдавать сумму по айпи

[hizel]

какбэ с этого топик и начался, а ты завернул куда то в другу степь!!!1

[paradox]

я предлагал варианты оптимальные для разных конфигураций
а про количество юзеров стало известно с середины топика