Доброго времени суток!Пишу биллинговую систему, столкнулся со следующей проблемой:
как вести ip-статистику? Если пихать в базу информацию о каждом пакете -
требуется немеренно дискового пространства.В нешем городе несколько провайдеров - один не предастовляет
(и наверное не ведет) детальной ip-статистики, только помещает в базу
сумму входящих и исходящих байт за каждые сутки;
другой ведет детальную ip-статистику за месяц и суммирует за этот месяц
количество байт для каждой уникальной пары src_ip - dst_ip.У всех них биллинговые системы сертифицированы.
Может есть какие-от стандарты или рекомендации относительно того,
насколько подробной должна быть ip-статистика?Как это должны делать серьезные провайдеры?
>Как это должны делать серьезные провайдеры?
серьезные провайдеры дают канал и качай, сколько сможешь.
писать статистику по каждому пакету у серьезного провайдера не справится ни одна база. слишком много данных.
пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.
Думается, что серьезные провайдеры ведут детальную статистику.
А в дальнейшем статистика аргрегатируется по вышеуказанным парам.
А для хранения может быть базы постоянно дампятся и за месяц файл растет заново, ну или вроде этого.
И по запросу от клиента уже формаруются необходимые объемы.
Снимая статистику по netflow с маршрутизаторов, данных получается на порядок больше.
И верятно все это крутится не сереьзных машинах с немеренными массивами.
>пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.и как оно у вас сейчас, если не серкет?
У нас сейчас все примитивно просто.
Все валится в текстовой файл с маршрутизатора, а в начале месяца он обрабатывается на windows спецаильно написанной программой.
Да не спорю топорно и неудобно, как обычно дефицит средств, машина для сбора P100.
Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то считал если раскидывать в базу то не хватит хранить годовую статистику в одном файле.
Максимальный размер файла 4Г.
Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до 300-400М в месяц, плюс если увеличить количество клиентов полная креза.
Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база.Другого пути нет, как снимать и в базу класть, мне видится.
>У нас сейчас все примитивно просто.
>Все валится в текстовой файл с маршрутизатора, а в начале месяца он
>обрабатывается на windows спецаильно написанной программой.
>Да не спорю топорно и неудобно, как обычно дефицит средств, машина для
>сбора P100.
>Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то
>считал если раскидывать в базу то не хватит хранить годовую статистику
>в одном файле.
>Максимальный размер файла 4Г.
>Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до
>300-400М в месяц, плюс если увеличить количество клиентов полная креза.
>Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база.
>
>Другого пути нет, как снимать и в базу класть, мне видится.Т.е. если при средней нагрузке в 100 клиентов я хочу отвести под
базу до 10 Гб и хранить статистику за год - остается только сразу
агрегировать по парам ip-адресов за учетный период при снимании с
маршрутизатора (как оно сейчас и есть).
Что-то все очень сложно, смотря какой лог парсить...
Сейчас распарсиваю лог, который за день (около 40 клиентов) метров на 10 наирается, парситя php скриптом и сколадывается в мускуль, была раньше другая версия тоже в мускуль и без демпов детально уже полтора года накапливается и ничего так, работает...
Такчка 300 целка
У меня такой же трабл был, надо сказать, что и на данный момент всё ещё не так гладко, однако факт - работает. Делал следующим образом:
1. Коллектор трафика на серваке собирает данные проходящие через интерфейсы или непосредственно с маршрутеров.
2. Один раз в час (через каждый час) всё это скидывается в файло скриптом, прописанном в Cron'е присваивая файлам названия по времени и дате.
3. Виндовая машина каждый час забирает с сервака данное файло, удаляет старое, разбирает лог, запихивает во временную базу (MYSQL).
4. Разгребает базу по IP-адресам, добавляя данные в отчётную таблицу (где пишется только IP-адрес, начало сессии, конец, сумма байт (исх,вх) и прочее), формирует необходимые статистические данные и файлы.
5. В конце дня (в 0ч. 00мин.) сохраняет эту временную базу с именем (чило дня + число месяца + год) и создаёт новую временную.И так каждый день - в итоге, если что-то надо вытащить и старых баз - прога на виндовой машине шарит по всем сохранённым ранее базам на предмет требуемого IP-адреса и формирует необходимый отчёт. В принципе удобно. Обычно статистика необходима в конце месяца и тогда прога лопатит цельный день для того, чтобы сформировать то, что необходимо - это единственное неудобство.
ЗЫ: ну и машина виндовая должна быть под это дело отведена соответствующая
>4. Разгребает базу по IP-адресам, добавляя данные в отчётную таблицу (где пишется
>только IP-адрес, начало сессии, конец, сумма байт (исх,вх) и прочее),Но ведь понятие сессии применимо не ко всем протоколам, что могут
работать поверх ip.
Понял, наверное имеются в виду диалапные сессии.
>У нас сейчас все примитивно просто.
>Все валится в текстовой файл с маршрутизатора, а в начале месяца он
>обрабатывается на windows спецаильно написанной программой.
>Да не спорю топорно и неудобно, как обычно дефицит средств, машина для
>сбора P100.
>Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то
>считал если раскидывать в базу то не хватит хранить годовую статистику
>в одном файле.
>Максимальный размер файла 4Г.
>Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до
>300-400М в месяц, плюс если увеличить количество клиентов полная креза.
>Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база.
>
>Другого пути нет, как снимать и в базу класть, мне видится.Решал эту проблемму тоже через текстовый файл. Система FreeBSD 5.0
У меня при количестве клиентов ~ 40, месячный файл статистики в зжатом виде не превышает 100 кбайт.
Статистика снимается по Cron каждые 20 минут в нагруженное время и каждые 2 часа в ночное. Счетчик с ipfw.
Сначала обрабатывал в Excel - муторно. Сейчас написал скрипт - получилось
удобно. Все делаю на маршрутизаторе.
Если кому интересно могу скинуть скрипт который парсит файл, складывает все в базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог ulog-acctd
Интересно.
Романтик и какой у тебя размер файла за год?
v3625 посмотри максимальный размер файла для FreeBSD какой.
>v3625 посмотри максимальный размер файла для FreeBSD какой.Для FFS максимальный размер файла равен ~1 Г блоков
(4 Тб при размере блока 4 Кб).Для UFS - не знаю, но наверно не меньше
>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в
>базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог
>ulog-acctdмне интересно alisherk@uzpak.uz
>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в
>базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог
>ulog-acctd
и мне интересно bogatyrjov[dog]bk.ru
Парсить лог конечно можно, а если система должна работать практически в режиме реал-тайм? Кончились деньги на счету клиента - "уёбн зи битте". Согласен. За 5 минут клиент много не накачает (Если он сидит на модемном подключении. А если на ethernet?), но мне бухгалтерия предъявляет претензии за 1-2 мегабайта перебора. Я смог их убедить, что это зависит не от меня. Но вопрос остаётся: с какой частотой нужно снимать данные со счётчиков? Как правильно подобрать оптимальное время сканирования, что бы не перегрузить систему и не дать юзверю нахаляву накачать >3Мб?
Ну как то с задачей надо определиться что надо, универсальных систем нет.
А если канал будет 10М с какой частотой вы будете снимать статистику что бы лишние 3Мб клиент не скачал?
Я так понял, что в реалтайме считать невозможно, т.к. данные
по сети идут быстрее, чем могут добавляться в СУБД, да еще нужно
проверять всех юзеров на предмет необходимости отключения.Нужно подбирать такую периодичность, чтобы не остаться в убытке.
С реал тайм обычно делают pppoe pptp с радиусом и базами.
ХОтя есть на основе ipf
Наверное ты прав все зависит от скорости реакции
Долго не мог писать...
Да согласен, что не очень хорошо давать перебирать траффик, можно конечно снизить съем до минуты, но перебор все равно будет, деваться здесь некуда...
Я думал передавать парсеру попакетно, но опять таки при большой нагрузке и маленьком мту, пакетов будет много и парсер просто захлебывается, причем захлебывается прямо пропорционально нагрузке.
Поэтому деваться некуда, перебор так перебор (для меня приемлимо), зато получается очень даже неплохо...
Файлик маленький(за год не знаю), работает все очень быстрои четко...
Статистика снялась, деньги вычлись, если ноль то отключает(если в онлайне), если нет, то просто не даст потом подключаться...
Раньше я считал на основе лога iptables, но:
1) При использовании syslog терялись пакеты (при высоких нагрузках).
2) Как то раз качал фильм и тут увидел, что файл за несколько минут разросся до нескольких сотен метров.Ulog-acctd собирает данные по связке src-dst и скидыает результат в указанный период (я ставлю каждые 30 секукнд).
Мылы желающих попробовать я записал, буду дома, вышлю с инструкцией, но сразу говорю, что необходим php+apache+mysql, причем php желательно последний, так как в клиентской части я использую глобальные переменные так как умеет только 4.3.3 вроде бы :)... Но пропарсить файл вы сможете и с любым другим не очень старым... apache собственно тоже нужен только для вывода красивостей...
>Долго не мог писать...
>Да согласен, что не очень хорошо давать перебирать траффик, можно конечно снизить
>съем до минуты, но перебор все равно будет, деваться здесь некуда...
>
>Я думал передавать парсеру попакетно, но опять таки при большой нагрузке и
>маленьком мту, пакетов будет много и парсер просто захлебывается, причем захлебывается
>прямо пропорционально нагрузке.
>Поэтому деваться некуда, перебор так перебор (для меня приемлимо), зато получается очень
>даже неплохо...
>Файлик маленький(за год не знаю), работает все очень быстрои четко...
>Статистика снялась, деньги вычлись, если ноль то отключает(если в онлайне), если нет,
>то просто не даст потом подключаться...
>Раньше я считал на основе лога iptables, но:
>1) При использовании syslog терялись пакеты (при высоких нагрузках).
>2) Как то раз качал фильм и тут увидел, что файл за
>несколько минут разросся до нескольких сотен метров.
>
>Ulog-acctd собирает данные по связке src-dst и скидыает результат в указанный период
>(я ставлю каждые 30 секукнд).
>Мылы желающих попробовать я записал, буду дома, вышлю с инструкцией, но сразу
>говорю, что необходим php+apache+mysql, причем php желательно последний, так как в
>клиентской части я использую глобальные переменные так как умеет только 4.3.3
>вроде бы :)... Но пропарсить файл вы сможете и с любым
>другим не очень старым... apache собственно тоже нужен только для вывода
>красивостей...Если можно и мне скиньте скрипт mishvin@mail.ru Спасибо
Провайдеры мы не серъёзные, но 400 живых клиентов есть. С киски скидывается по нетфлов на машину в фаил. В среднем 300М за спокойный день. Фаил парсится в реальном времени, скидывает всё в базу, по таблице на день, и считает общую за день. В принципе по 0,5Гб за месяц выходит в MySQL-e
Во правильно или в день новый файл (таблица)Какой коллектор используешь Владимир, скрипт, что бы парсить не поделишься?
Какое расхождение с провайдером?
Так как с провайдером у нас часовая разница то в среднем за месяц, если не было великих сбоев, расхождений почти нет.
Скрипт является собственностью компании и разглашению не подлежит. Этому есть причина - он переписывается и готовится к сертификации %)
Методы сбора статистики достаточно простые: есть отдельный блок програм работающий только с нетфлов и своей отдельной базой. Есть основная база которая из базы нефлов извлекает изменения (уже суммированные и без всяких адресов и портов) и считает деньги. Всё работает раздельно-паралельно с задержкой 5-10 минут. В последующем можно разнести на разные тачки или поставить вообще в другом месте. Такая вот она у нас разнесенная получается.
>Методы сбора статистики достаточно простые: есть отдельный блок програм работающий только с
>нетфлов и своей отдельной базой. Есть основная база которая из базы
>нефлов извлекает изменения (уже суммированные и без всяких адресов и портов)Сколько хранится статистика в базе нетфлов и насколько она детальна,
агрегируются ли в ней данные о трафике по каким-нибудь параметрам?
Если можно, приведи определения таблиц.Что есть netflow? Чем отличается от cisco ip accounting?
NetFlow пишет кроме меток времени, адресов источника и назначения, количество пакетов, количество отктетов, порт источника, порт назначения, интерфейс входящий, исходящий инетрфейс, следующий хоп, и немного служебной информации.
Если интересно вот таблица
sun# cat /home/leo/raws.sql
CREATE DATABASE IF NOT EXISTS netflow;
USE netflow;
CREATE TABLE IF NOT EXISTS raw (
unix_secs int unsigned,
unix_nsecs int unsigned,
dflows int unsigned,
dpkts int unsigned,
doctets int unsigned,
first int unsigned,
last int unsigned,
engine_type smallint unsigned,
engine_id smallint unsigned,
sysuptime smallint unsigned,
exaddr varchar(15),
srcaddr varchar(15),
dstaddr varchar(15),
nexthop varchar(15),
input smallint unsigned,
output smallint unsigned,
srcport varchar(12),
dstport varchar(12),
prot smallint unsigned,
tos smallint unsigned,
tcp_flags smallint unsigned,
src_mask smallint unsigned,
dst_mask smallint unsigned,
src_as smallint unsigned,
dst_as smallint unsigned,
starttime int unsigned,
endtime int unsigned,
in_encaps smallint unsigned,
out_encaps smallint unsigned,
peer_nexthop varchar(15),
router_src varchar(15),
marked_tos smallint unsigned,
extra_pkts int unsigned,
src_tag smallint unsigned,
dst_tag smallint unsigned
)TYPE=MyISAM COMMENT='netflowtable for flow-tools';
sun#
А что это за метки времени такие (уж не период ли, за который
суммируется размер пакетов с одинаковыми парами "источник-получатель")?
Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad
на PC, он их может выдавать?Существует ли что-нибудь под юникс, изображающее netflow?
Агрегатирование тут нет, агрегатирование настраивается отдельно, сейчас тоно на скажу, то ли на машрутизаторе то ли на коллекторе.
Маршрутизатор с периодчиностью по udp посылает информацию на коллектор, это инфомрмация исключительно за период. Неагргегатированная без специальных настроек.
Под юникс подобно NetFlow ничего не скажу.
Подобно ip accounting есть. Но тут снимаемой информации меньше чем при netflow но достаточно для подсчета трафика.
Для сведения: при снятии ip accounting и netflow на маршрутизаторе суммарная информация отличается. Этим можете поинтересоваться на соседнем форуме может объяснят почему.
>Под юникс подобно NetFlow ничего не скажу.
Для FreeBSD ng_netflow есть>Для сведения: при снятии ip accounting и netflow на маршрутизаторе суммарная информация
>отличается. Этим можете поинтересоваться на соседнем форуме может объяснят почему.Причина проста, ip account снимает статистику на выходе из киски после аксес листов, нетфлов считает на входе до попадание в аксес лист. Дальше думаю догадаетесь откуда разница.
снимает она так, но расхождения не факт что только отсюда отсюда.
даже при отсутствии акл расхождения есть
У вас на всех интерфейсах включен аккаунтинг? Даже на lo0 и null0 ?
>А что это за метки времени такие (уж не период ли, за
>который
>суммируется размер пакетов с одинаковыми парами "источник-получатель")?
>Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad
>на PC, он их может выдавать?
>
>Существует ли что-нибудь под юникс, изображающее netflow?
Статистика за месяц хранится в одной таблице. Размер одного месяца статистики ~0.5Gb. Соответственно сколько у вас есть Gb разделите на эту цифру, или умножте на нужное вам время хранения и получите нужные Вам цифры. Нам достаточно 3-х месячной давности.
Агрегация происходит по клиентским адресам и заносится в агрегированную таблицу которая и синхронизируется с основной базой. Детальная статистика хранится полная и не агрегированная.
У меня складывается детальный трафик каждого юзера в скуль.
Юзеров порядка 350 человек.
Никаких проблем.
Да база детального трафа весит много, но все таки складывает и все ок.
Считаю trafd, затем с попмошью скиптяги все пихаю в скуль.
>У меня складывается детальный трафик каждого юзера в скуль.
>Юзеров порядка 350 человек.
>Никаких проблем.
>Да база детального трафа весит много, но все таки складывает и все
>ок.
>Считаю trafd, затем с попмошью скиптяги все пихаю в скуль.trafd может выдавать статистику попакетно? По-моему не может.
Как-то я все равно еще, честно сказать, не вполне врубаюсь (хотя
прогресс определенно имеет место быть :)
Хотелось бы все-таки добраться до сути а также внести ясность по поводу
агрегирования и детализации.trafd и ipcad, IMHO, могут выдавать только статистику, агрегированную по
ip-адресам за период времени, через который мы с них снимаем.
А агрегированная статистика уже не вполне детальна. Т.е. получается что
абсолютно детальную статистику невозможно вести с использованием
trafd или ip accounting.Да и дисковое пространство требуется вообще
нереальное: информация о пакете занимает минимум 32 байта, за час у
1 юзера может спокойно проходить 10000 пакетов (даже больше,
но возьмем такую цифру для расчета); получается 300 Мб в час для 1 юзера.
А если объемы информации огромны и юзеров очень много - таких дисковых
массивов вообще в природе не существует.
Пример ip accounting21.21.1.5 213.180.193.30 305 65199
За определенный промежуток времени вы получете определенное количество строк и они не агрегатированы.
>Пример ip accounting
>
>21.21.1.5 213.180.193.30 305 65199
>
>За определенный промежуток времени вы получете определенное количество строк и они не
>агрегатированы.Как раз-таки они агрегированы. По ip-адресам источника и приёмника.
Эта запись значит что за период времени с адреса 21.21.1.5 на адрес 213.180.193.30 прошло 305 пакетов общей длиной в 65199 байт.
если так то это для меня открытие, хочешь сказать что если я в течении минуты буду иметь соедниеннеи, потом его разорву и через две минуты установлю соединение с той же машиной, то запись будет одна?
Если за это время небыла выдана команда "clear ip accounting" то да.
cisco (или эмулирующая её программа ipcad) агрегирует данные по ip адресу источника и проиёмника. А была разорвана сессия, или продолжалась она без перерыва им сугубо фиолетово. Она получила пакет, проанализировала ip источника и ip приёмника и добавила его длину в соответствующую ячейку, инкрементировав при этом счётчик пакетов для этой пары.
Сейчас ipcad умеет
# Enable or disable capturing UDP and TCP port numbers.
#
# capture-ports {enable|disable} ;
Source Destination Packets Bytes SrcPort DstPort
192.168.0.6 192.168.2.22 3 120 3333 1757
192.168.2.22 192.168.0.6 3 144 1757 3333
192.168.0.6 192.168.2.22 3 120 3333 1756
192.168.2.22 192.168.0.6 3 144 1756 3333
Так что агрегирование происходит только при совпадении src и dst портов (TCP UDP)
>Так что агрегирование происходит только при совпадении src и dst портов (TCP UDP)Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по портам и такой режим - отход от совместимости с оборудованием CISCO, по поводу которого мы с автором ipcad'а не далее как сегодня ломали копья. Так что...
Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к FTP, отключился - одна запись, подключился снова к FTP, снова отключился - вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном случае, в логах мы получим две сессии объединённых в одну запись.
Хех я имел ввиду по ip accounting CISCO , при снятии нет информации о портах поэтому по портам не может агрегироваться.
А вот по парам адрес источника - адрес назначения не знаю.
Харлан что скажешь?
ИМХО, на этот вопрос я ответил (см выше) и больше мне добавить нечего.
>Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по
>портам и такой режим - отход от совместимости с оборудованием CISCO,
>по поводу которого мы с автором ipcad'а не далее как сегодня
>ломали копья. Так что...
Ну так автор об этом честно предупреждает, причем в самом конфиге
# Enabling this will BREAK Cisco output format compatibility
# and may slow down processing traffic.>Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к
>FTP, отключился - одна запись, подключился снова к FTP, снова отключился
>- вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни
>ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном
>случае, в логах мы получим две сессии объединённых в одну запись.
>
Почаще статистику можно снимать, хотя зависит от загрузки
У меня на обслуживании имеентся одно Интернет-кафе средней загруженности. Считаю трафик с каждой из 14 машин в зале + трафик IP-телефонии + суммарный трафик на интерфейсе смотрящем в мир. По каждой группе счетчиков отдельно считается только входящий и исходящий трафик. Использую IPFilter, данные со счетчиков снимаю каждые <b>10 секунд</b>, все ненулевые значения пишутся в PostgrSQL базу. С середины мая прошлого года база выросла всего до 850 МБ. Так вот.Андрей.
>писать статистику по каждому пакету у серьезного провайдера не справится ни одна
>база. слишком много данных.
>пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.
>Oracle справляется лехко...
у нас.. в г. Владивостоке, по кол-ву трафиика по данным РТК наш город входил в 10ку.. самый крупный провайдер Дальсвязь обсчитывает всех своих выделенщиков Oraclom с цисок и все вроде бы отлично, правда иногда падает, но не чаще чем раз в два месяца и данные не теряются...
В связи с отходом на сессию сделал пока так: с определенной
периодичностью (раз в 15 мин. например) статистика снимается
с коллектора и помещается в pgsql базу, при этом сразу же агрегируется
за месяц по ip-адресам; с этой же периодичностью юзеры проверяются на
предмет необходимости отключения, для чего генерируются правила фаервола.
Дальше совершанствовать буду постепенно в дальнейшем (если другую
работу за это время не найду :)Всех благодарю за ответы (хотя может быть еще кто-нибудь выскажется),
не знаю что бы делал без лучшего в мире форума :)В ближайшие 3 недели писать сюда, вероятнее всего, не буду.
Счастливо.
Мог бы скриптик для агрегатирования оставить .
>Мог бы скриптик для агрегатирования оставить .Высылаю почтой, но он работает тормознуто слегка :)
Сейчас только его быстренько слабал.
>Доброго времени суток!
>
>Пишу биллинговую систему, столкнулся со следующей проблемой:
>как вести ip-статистику? Если пихать в базу информацию о каждом пакете -
>Как это должны делать серьезные провайдеры?
"серьезные провайдеры" (по опыту общения с ТТК и РТК) никогда не собирают детальную статистику - им это не нужно, есть порт включения вот за весь объем и плати - это работа с UpStream провайдером.
Если-же абонентам раздавать, то тут всякие хитрости и извращения начинаются - потери, повторы пакетов, несоответствие отправленного объема к полученному... IMHO тема бесконечная.
Как вариант низкоуровнего получения и минимальной аггрегации статистики трафика предлагаю свой вариант: http://sourceforge.net/projects/iptrafd/
Проект пока еще сырой, но основлое делать умеет - собирает трафик, по запросу складывает в кучу и если надо блокирует пакеты. Добавлять правила в firewall для этого - фи (по опыту работы с /19 сеткой с несколькими сотнями клиентов)
P.S. Offtopic: ищу единомышленников для продолжения написания проекта.
Доброго времени суток!почитал обсуждение.... интересно....
но самое интересное: а время, потраченное клиентом сидящем на модеме для получения повторных пакетов при потере в канале тоже надо учитывать?
>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>повторных пакетов при потере в канале тоже надо учитывать?
LOL :-)P.S. Я шутку понял :)
P.P.S. Я вообще-то про выделенциков, если что.
>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>>повторных пакетов при потере в канале тоже надо учитывать?
>LOL :-)
>
>P.S. Я шутку понял :)
>P.P.S. Я вообще-то про выделенциков, если что.а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? :) в чём разница? и те и другие юзают IP трафик...
>>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>>>повторных пакетов при потере в канале тоже надо учитывать?
>>LOL :-)
>>
>>P.S. Я шутку понял :)
>>P.P.S. Я вообще-то про выделенциков, если что.
>
>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков?
>:) в чём разница? и те и другие юзают IP трафик...
>
Потому что для выделенщиков актуален потребляемый трафик, а для даилапщиков время занятости порта.
>>>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>>>>повторных пакетов при потере в канале тоже надо учитывать?
>>>LOL :-)
>>>
>>>P.S. Я шутку понял :)
>>>P.P.S. Я вообще-то про выделенциков, если что.
>>
>>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков?
>>:) в чём разница? и те и другие юзают IP трафик...
>>
>Потому что для выделенщиков актуален потребляемый трафик, а для даилапщиков время занятости
>порта.и что? получается время потраченное на модеме для того что бы получить повторный пакет оплачивает клиент а на выделенке пакетики повторные (или якобы не нужный клиенту трафик) не учитываются? но передача ведь прошла в сторону клиента...
или к примеру трафик, который якобы клиенту не нужен, его не считаем? Думаю это не правильно... включился в инет, получаешь трафик, оплати его... и не надо выдумывать что скаченный файл в 1 метр должен дать трафика в 1 метр ровно :)
С чего ты взял что при выделенке клиент не оплачивает повторные пакеты . еще как оплачивает.
не факт что всеь трафик попадает в ipfw и обсчёт по ipfw будет правильным.
кстате это уже сто раз обсуждалось... :)
провайдеру, между прочим, абсолютно всё равно какой из трафика нужен клиенту а какой нет, провайдер считает стколько трафика потребил клиент (т.е. прошло в клиента)... при чём тут детализация? детализацию может делать клиент на своём интерфейсе если ему надо знать кто из его "сетян" куда ходил по http или ещё по чему :)
Говоришь детализация не нужна провайдеру.
А если у клиента скажем вирус и он просит провайдера определить что за трафик имеет клиент, провайдер должен быть готов дать ответ как по протоколу так и по портам.
>Говоришь детализация не нужна провайдеру.
>А если у клиента скажем вирус и он просит провайдера определить что
>за трафик имеет клиент, провайдер должен быть готов дать ответ как
>по протоколу так и по портам.с чего бы это провайдер должен был быть обязан это делать?
клиент обязан сам следить за вирусятниками у себя в сети.....
>Говоришь детализация не нужна провайдеру.
>А если у клиента скажем вирус и он просит провайдера определить что
>за трафик имеет клиент, провайдер должен быть готов дать ответ как
>по протоколу так и по портам.это называется "переложим с больной головы на здоровую" :)
если клиент по ЛЮБЫМ причинам накачал больше трафика, провайдер тут абсолютно не при чём... (не берём в расчёт совершенно элементарные вещи, которые провайдер настроит правильно)
Провайдер конечно не обязан, это можно назвать качеством услуги.
Хотя это и можно расценивать как техническую поддержку.
А если возникают спорные моменты с клиентом.
А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег.
>Провайдер конечно не обязан, это можно назвать качеством услуги.
>Хотя это и можно расценивать как техническую поддержку.
>А если возникают спорные моменты с клиентом.
>А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег.
>ну если клиент считает, что его провайдер накалывает, пусть докажет... :)
причём тут даже в суд не надо ходить... нормальному провайдеру достаточно показать лог, в котором клиенту чего-то не нравится... провайдер примет меры со своей стороны, в этом я уверен на все 100%
я вот только вот чего не пойму.... смысл разводить такие темы?
если у провайдера 10 клиентов с локалкоми по 10 компов, он может конечно в качестве "улучшения услуги" сделать любую статистику по протоколам, портам и чёрту лисому.... но требовать этого от провайдера и судить насколько он серъёзен - мне кажется в корне не верно... :)
мне как клиенту самому интересно что происходит на моём внешнем интерфейсе и я тут сам себе провайдер :) для того что бы выяснить что там творится не нужен ни биллинг ни крутые счётчики..... всё достаточно просто...
>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков?
>:) в чём разница? и те и другие юзают IP трафик...
IMHO для диалапщиков трафик должна снимать железка, которая этих самых диалапщиков и обслуживает. Как ни странно, лидером здесь пока является Cisco, но это тема другой конференции.
Если для диалапа вполне реально по деньгам поставить Циску, то даже для районной сети втыкать Циски будет дорого, если конечно это не элитная сеть между домами НР (не Hewlett-Packard :) ).
Весь мой опыт админства подсказывает, что снимать статистику нужно как можно ближе к клиенту (чтобы расхождений было немного), соответственно для дилапщиков пусть считает циска и отдает в биллинг, для выделенщиков пусть роутер считает - лучше всего ближайщий к клиенту.
А как ты собираешься снимать IP статистику с порта, расскажи.
>А как ты собираешься снимать IP статистику с порта, расскажи.
Имелся ввиду порт железки, к которой подключен маршрутизатор downstream провайдера, Т.е. порт маршрутизатора или свича.
я это понял, вот и спрашиваю как снятьс него IP статистику
Мы у себя делаем проще :)
для снятия статистики используем ipacctd или ng_ipacct(немножко поправленные для эффективного агрегирования). Раз в N минут накопленные данные передаются утилите, которая конвертирует эти данные в netflow v5.
В процессе конвертации заполняются поля src_as и dst_as. За каждым клиентом закреплён уникальный идентификатор, который и вставляется в эти поля. После чего данные отправляются на коллектор.
Какие преимущества - очень удобно потом анализировать полученные данные, нет жёсткой привязки к IP адресам клиента. Возможность раздельно учитывать локальный/точки обмена/паритетный трафик. Так-же возможно получить детализацию трафика.
При 200Gb месячного трафика получается порядка 700Mb netflow данных.
Статистика хранится год(как минимум). Варианты с SQL не подошли ввиду их ресурсоёмкости.
>При 200Gb месячного трафика получается порядка 700Mb netflow данных.
>Статистика хранится год(как минимум). Варианты с SQL не подошли ввиду их ресурсоёмкости.
Как максимум - 3 года (срок исковой давности :) )
>я это понял, вот и спрашиваю как снятьс него IP статистику
Если это Cisco-железка, то по SNMP. Google тысячи ссылок даст.
Пользователь платит за ip статистику, а что показывает SNMP
Изобретаю свой велосипед -- десятки имеющихся биллингов по разным причинам не покатили :(Вырисовываются следующие моменты:
1. Нужно вести полные логи -- "разбор полетов", точные счета в конце месяца, архив, вирусы и т.п..
1.1. Самая простая, полная и открытая форма -- текстовые логи. Собирает net-acct, детализация по парам IP и портов, пакеты и байты, UNIXTIME, протокол тоже. Каждые 5 минут сброс в файл (ramdisk -- потери от reset-a за 5 минут на максимальной скорости 256кбит нас устраивают).
1.2. Каждые 15 минут (3 сброса) готовый лог обрезается и gzip-ается на винт под именем MMDDHHMM.gz по cron-у простым скриптом, sync в конце. Лег на винт -- больше не трогается по записи НИКОГДА. Дабы не потерять от сбоя при модификации. Между этими периодами раздел даже отмонтирован;)
1.3. Вся эта ерунда живет на слабеньком, но надежном роутере, LEAF Bering,486DX4-100/24, HD 200_метров_ -- там логов уже за полгода, и еще есть место. Каждые N (минут, часов, у меня -- 1 сутки) биллинговый процесс (с другой тачки автоматом по ssh) тянет пачку логов с винта на более крутую тачку -- это быстро. В месяц при ~10-15Gb трафика с мусором набегает до 150 метров лога, что в кусочных *.gz меньше на ПОРЯДОК. Можно залить на CD-R ;)
1.4. Легкие скрипты (пока win.cmd) вкупе с простой и компактной (300kb), но ОЧЧЧЕНЬ шустрой СУБД SQLite (IMHO идеально подходит для биллинга, http://www.sqlite.org) сливают поток из gz-логов в базу (естественно, за месяц файлик до 150 метров). По базе еще несколько sql-скриптов формируют итоговые суммы и отчеты по вкусу. На Athlon-1GHz это минут 5-7, так что каждые 15 минут можно выкладывать даже очень точную статистику.
1.5. Новый месяц -- новый каталог сжатых логов. БД все равно формируется быстро, на лету. Хотя можно и добавлять записи, но пока и так хватает.
1.6. При желании можно утоптать 15-минутные gz-логи и слиянием, и реляционно -- но тогда труднее искать вдруг заинтересовавший период. Короткие текстовые файлы с внятным именем не требуют софта для быстрого поиска и расшифровки.2. Нужны также агрегатированные счетчики (просто число байт или сумма денег -- показать юзерам в онлайне, отключить некредитоспособных).
2.1. Этим может заниматься скрипт оперативной обработки по оперативным же счетчикам на фаервольных правилах (пока не сделал). Конечно, они врут. Конечно, легко слетают при настройках и сбоях. Но это лишь индикаторы -- в течение тех же 15 минут можно обсчитать месяц и вернуть точность.
2.2. Можно также ПРИ УПАКОВКЕ 15-минутных логов держать мааааленькую итоговую табличку на роутере (тогда там нужен sqlite и опять же доступ к полной базе для восстановления после сбоя -- пока не сделано).
2.3. Если нужно считать именно деньги, да по куче тарифных планов, то все сложнее. Но таки подъемно (на более быстром роутере, конечно).3. Отключение юзеров online. Надо делать быстро, а то на выделенке легко можно стать банкротом -- и обанкротить заодно любимого провайдера;(
3.1. Да, скорости велики, и часто проверять баланс невозможно. НО! Кто мешает ЗАРАНЕЕ спрогнозировать, что в следующий 5~15 минутный период Вася Пупкин рискует исчерпать лимит? Сразу модифицируем его шейпер и подрезаем полосу, чтобы Васе ее хватило аккурат выжрать остатки трафика/денег до следующего сброса лога. Думаю, юзер не обидится, это достаточно точно и гуманно.
3.2. Опять же правила фаервола. Отрубить юзера полностью -- нет почтовых уведомлений, доступа к статистике, сложности с правилами, платить за мусор на его IP... Проще сильно-сильно ограничить шейпером -- а услуга-то еще оказывается, так что плати долги;) Но это еще предстоит проверить.4. Мысли вслух. У нас раздача трафика по радио 802.11b. Искали устройства с RADIUS-ом, и подешевле, и еще много вариантов -- напрасно. Складывается впечатление, что буржуи давно уже собственно трафик не считают, у них даже в RADIUSных HotSpot-ах сплошь повременка :( Как на мобильниках... Так что биллинг придется изобретать и прикручивать родной, домашний.
5. Подскажите, ALL, нормально ли net-acct собирает статистику? Я взял его из-за размера и возраста, а также наличия кучи модификаций. Сертифицированные биллинги юзают nacctd в качестве внешнего коллектора -- тоже немаловажно. Однако провайдерская циска завышает трафик немного. По опыту -- добавляю к суммарной статистике net-acct по 14 байт на каждый IP-пакет, тогда расхождения менее процента. Циска считает Ethernet-пакеты вместе с заголовками?
>Доброго времени суток!
>
>Пишу биллинговую систему, столкнулся со следующей проблемой:
>как вести ip-статистику? Если пихать в базу информацию о каждом пакете -
>
>требуется немеренно дискового пространства.
>
>В нешем городе несколько провайдеров - один не предастовляет
>(и наверное не ведет) детальной ip-статистики, только помещает в базу
>сумму входящих и исходящих байт за каждые сутки;
>другой ведет детальную ip-статистику за месяц и суммирует за этот месяц
>количество байт для каждой уникальной пары src_ip - dst_ip.
>
>У всех них биллинговые системы сертифицированы.
>Может есть какие-от стандарты или рекомендации относительно того,
>насколько подробной должна быть ip-статистика?
>
>Как это должны делать серьезные провайдеры?
Ну серьёзные провайдеры для этого используют Oracle. Тем более я не совсемпонял какую именно информацию нужно собирать? И нужне ли информация о каждом пакете? Если нужно посчитать трафик, то почему не использовть ipfw, iptables для этого? Через крон пишется скрипт, который кладёт счётчики в базу и обнуляет их, потом определёнными запросами за конретный пеиод всё вычисляется..