форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"как правильно вести ip-статистику?"
Сообщение от v3625 on 12-Янв-04, 11:31  (MSK)
Доброго времени суток! Пишу биллинговую систему, столкнулся со следующей проблемой: как вести ip-статистику? Если пихать в базу информацию о каждом пакете - требуется немеренно дискового пространства. В нешем городе несколько провайдеров - один не предастовляет (и наверное не ведет) детальной ip-статистики, только помещает в базу сумму входящих и исходящих байт за каждые сутки; другой ведет детальную ip-статистику за месяц и суммирует за этот месяц количество байт для каждой уникальной пары src_ip - dst_ip. У всех них биллинговые системы сертифицированы. Может есть какие-от стандарты или рекомендации относительно того, насколько подробной должна быть ip-статистика? Как это должны делать серьезные провайдеры?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "как правильно вести ip-статистику?"
Сообщение от Nikolaev_D on 12-Янв-04, 12:10  (MSK)
>Как это должны делать серьезные провайдеры? серьезные провайдеры дают канал и качай, сколько сможешь.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "как правильно вести ip-статистику?"
Сообщение от Nickolay on 12-Янв-04, 12:32  (MSK)
писать статистику по каждому пакету у серьезного провайдера не справится ни одна база. слишком много данных. пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 12-Янв-04, 12:41  (MSK)
	Думается, что серьезные провайдеры ведут детальную статистику. А в дальнейшем статистика аргрегатируется по вышеуказанным парам. А для хранения может быть базы постоянно дампятся и за месяц файл растет заново, ну или вроде этого. И по запросу от клиента уже формаруются необходимые объемы. Снимая статистику по netflow с маршрутизаторов, данных получается на порядок больше. И верятно все это крутится не сереьзных машинах с немеренными массивами.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 12-Янв-04, 15:26  (MSK)
	>пробовали мы такое заделать на mysql. он не справлялся с обработкой данных. и как оно у вас сейчас, если не серкет?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 12-Янв-04, 15:39  (MSK)
	У нас сейчас все примитивно просто. Все валится в текстовой файл с маршрутизатора, а в начале месяца он обрабатывается на windows спецаильно написанной программой. Да не спорю топорно и неудобно, как обычно дефицит средств, машина для сбора P100. Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то считал если раскидывать в базу то не хватит хранить годовую статистику в одном файле. Максимальный размер файла 4Г. Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до 300-400М в месяц, плюс если увеличить количество клиентов полная креза. Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база. Другого пути нет, как снимать и в базу класть, мне видится.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 12-Янв-04, 15:52  (MSK)
	>У нас сейчас все примитивно просто. >Все валится в текстовой файл с маршрутизатора, а в начале месяца он >обрабатывается на windows спецаильно написанной программой. >Да не спорю топорно и неудобно, как обычно дефицит средств, машина для >сбора P100. >Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то >считал если раскидывать в базу то не хватит хранить годовую статистику >в одном файле. >Максимальный размер файла 4Г. >Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до >300-400М в месяц, плюс если увеличить количество клиентов полная креза. >Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база. > >Другого пути нет, как снимать и в базу класть, мне видится. Т.е. если при средней нагрузке в 100 клиентов я хочу отвести под базу до 10 Гб и хранить статистику за год - остается только сразу агрегировать по парам ip-адресов за учетный период при снимании с маршрутизатора (как оно сейчас и есть).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "как правильно вести ip-статистику?"
	Сообщение от BRomantik on 12-Янв-04, 18:18  (MSK)
	Что-то все очень сложно, смотря какой лог парсить... Сейчас распарсиваю лог, который за день (около 40 клиентов) метров на 10 наирается, парситя php скриптом и сколадывается в мускуль, была раньше другая версия тоже в мускуль и без демпов детально уже полтора года накапливается и ничего так, работает... Такчка 300 целка
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "как правильно вести ip-статистику?"
	Сообщение от SES on 12-Янв-04, 18:35  (MSK)
	У меня такой же трабл был, надо сказать, что и на данный момент всё ещё не так гладко, однако факт - работает. Делал следующим образом: 1. Коллектор трафика на серваке собирает данные проходящие через интерфейсы или непосредственно с маршрутеров. 2. Один раз в час (через каждый час) всё это скидывается в файло скриптом, прописанном в Cron'е присваивая файлам названия по времени и дате. 3. Виндовая машина каждый час забирает с сервака данное файло, удаляет старое, разбирает лог, запихивает во временную базу (MYSQL). 4. Разгребает базу по IP-адресам, добавляя данные в отчётную таблицу (где пишется только IP-адрес, начало сессии, конец, сумма байт (исх,вх) и прочее), формирует необходимые статистические данные и файлы. 5. В конце дня (в 0ч. 00мин.) сохраняет эту временную базу с именем (чило дня + число месяца + год) и создаёт новую временную. И так каждый день - в итоге, если что-то надо вытащить и старых баз - прога на виндовой машине шарит по всем сохранённым ранее базам на предмет требуемого IP-адреса и формирует необходимый отчёт. В принципе удобно. Обычно статистика необходима в конце месяца и тогда прога лопатит цельный день для того, чтобы сформировать то, что необходимо - это единственное неудобство. ЗЫ: ну и машина виндовая должна быть под это дело отведена соответствующая
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 09:49  (MSK)
	>4. Разгребает базу по IP-адресам, добавляя данные в отчётную таблицу (где пишется >только IP-адрес, начало сессии, конец, сумма байт (исх,вх) и прочее), Но ведь понятие сессии применимо не ко всем протоколам, что могут работать поверх ip.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 10:03  (MSK)
	Понял, наверное имеются в виду диалапные сессии.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "как правильно вести ip-статистику?"
	Сообщение от Aliv on 13-Янв-04, 09:50  (MSK)
	>У нас сейчас все примитивно просто. >Все валится в текстовой файл с маршрутизатора, а в начале месяца он >обрабатывается на windows спецаильно написанной программой. >Да не спорю топорно и неудобно, как обычно дефицит средств, машина для >сбора P100. >Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то >считал если раскидывать в базу то не хватит хранить годовую статистику >в одном файле. >Максимальный размер файла 4Г. >Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до >300-400М в месяц, плюс если увеличить количество клиентов полная креза. >Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база. > >Другого пути нет, как снимать и в базу класть, мне видится. Решал эту проблемму тоже через текстовый файл. Система FreeBSD 5.0 У меня при количестве клиентов ~ 40, месячный файл статистики в зжатом виде не превышает 100 кбайт. Статистика снимается по Cron каждые 20 минут в нагруженное время и каждые 2 часа в ночное. Счетчик с ipfw. Сначала обрабатывал в Excel - муторно. Сейчас написал скрипт - получилось удобно. Все делаю на маршрутизаторе.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "как правильно вести ip-статистику?"
	Сообщение от BRomantik on 13-Янв-04, 10:48  (MSK)
	Если кому интересно могу скинуть скрипт который парсит файл, складывает все в базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог ulog-acctd
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 11:04  (MSK)
	Интересно. mailto:v3625@mail.ru
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 11:18  (MSK)
	Романтик и какой у тебя размер файла за год? v3625 посмотри максимальный размер файла для FreeBSD какой.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	19. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 16:09  (MSK)
	>v3625 посмотри максимальный размер файла для FreeBSD какой. Для FFS максимальный размер файла равен ~1 Г блоков (4 Тб при размере блока 4 Кб). Для UFS - не знаю, но наверно не меньше
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "как правильно вести ip-статистику?"
	Сообщение от Alish on 13-Янв-04, 11:21  (MSK)
	>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в >базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог >ulog-acctd мне интересно alisherk@uzpak.uz
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	28. "как правильно вести ip-статистику?"
	Сообщение от boger on 14-Янв-04, 13:38  (MSK)
	>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в >базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог >ulog-acctd и мне интересно bogatyrjov[dog]bk.ru
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	29. "как правильно вести ip-статистику?"
	Сообщение от harlan on 14-Янв-04, 14:30  (MSK)
	Парсить лог конечно можно, а если система должна работать практически в режиме реал-тайм? Кончились деньги на счету клиента - "уёбн зи битте". Согласен. За 5 минут клиент много не накачает (Если он сидит на модемном подключении. А если на ethernet?), но мне бухгалтерия предъявляет претензии за 1-2 мегабайта перебора. Я смог их убедить, что это зависит не от меня. Но вопрос остаётся: с какой частотой нужно снимать данные со счётчиков? Как правильно подобрать оптимальное время сканирования, что бы не перегрузить систему и не дать юзверю нахаляву накачать >3Мб?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	30. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 14-Янв-04, 14:39  (MSK)
	Ну как то с задачей надо определиться что надо, универсальных систем нет. А если канал будет 10М с какой частотой вы будете снимать статистику что бы лишние 3Мб клиент не скачал?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	31. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 14-Янв-04, 15:17  (MSK)
	Я так понял, что в реалтайме считать невозможно, т.к. данные по сети идут быстрее, чем могут добавляться в СУБД, да еще нужно проверять всех юзеров на предмет необходимости отключения. Нужно подбирать такую периодичность, чтобы не остаться в убытке.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	32. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 14-Янв-04, 15:35  (MSK)
	С реал тайм обычно делают pppoe pptp с радиусом и базами. ХОтя есть на основе ipf Наверное ты прав все зависит от скорости реакции
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	67. "как правильно вести ip-статистику?"
	Сообщение от BRomantik on 20-Янв-04, 13:36  (MSK)
	Долго не мог писать... Да согласен, что не очень хорошо давать перебирать траффик, можно конечно снизить съем до минуты, но перебор все равно будет, деваться здесь некуда... Я думал передавать парсеру попакетно, но опять таки при большой нагрузке и маленьком мту, пакетов будет много и парсер просто захлебывается, причем захлебывается прямо пропорционально нагрузке. Поэтому деваться некуда, перебор так перебор (для меня приемлимо), зато получается очень даже неплохо... Файлик маленький(за год не знаю), работает все очень быстрои четко... Статистика снялась, деньги вычлись, если ноль то отключает(если в онлайне), если нет, то просто не даст потом подключаться... Раньше я считал на основе лога iptables, но: 1) При использовании syslog терялись пакеты (при высоких нагрузках). 2) Как то раз качал фильм и тут увидел, что файл за несколько минут разросся до нескольких сотен метров. Ulog-acctd собирает данные по связке src-dst и скидыает результат в указанный период (я ставлю каждые 30 секукнд). Мылы желающих попробовать я записал, буду дома, вышлю с инструкцией, но сразу говорю, что необходим php+apache+mysql, причем php желательно последний, так как в клиентской части я использую глобальные переменные так как умеет только 4.3.3 вроде бы :)... Но пропарсить файл вы сможете и с любым другим не очень старым... apache собственно тоже нужен только для вывода красивостей...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	69. "как правильно вести ip-статистику?"
	Сообщение от mishvin on 21-Янв-04, 14:32  (MSK)
	>Долго не мог писать... >Да согласен, что не очень хорошо давать перебирать траффик, можно конечно снизить >съем до минуты, но перебор все равно будет, деваться здесь некуда... > >Я думал передавать парсеру попакетно, но опять таки при большой нагрузке и >маленьком мту, пакетов будет много и парсер просто захлебывается, причем захлебывается >прямо пропорционально нагрузке. >Поэтому деваться некуда, перебор так перебор (для меня приемлимо), зато получается очень >даже неплохо... >Файлик маленький(за год не знаю), работает все очень быстрои четко... >Статистика снялась, деньги вычлись, если ноль то отключает(если в онлайне), если нет, >то просто не даст потом подключаться... >Раньше я считал на основе лога iptables, но: >1) При использовании syslog терялись пакеты (при высоких нагрузках). >2) Как то раз качал фильм и тут увидел, что файл за >несколько минут разросся до нескольких сотен метров. > >Ulog-acctd собирает данные по связке src-dst и скидыает результат в указанный период >(я ставлю каждые 30 секукнд). >Мылы желающих попробовать я записал, буду дома, вышлю с инструкцией, но сразу >говорю, что необходим php+apache+mysql, причем php желательно последний, так как в >клиентской части я использую глобальные переменные так как умеет только 4.3.3 >вроде бы :)... Но пропарсить файл вы сможете и с любым >другим не очень старым... apache собственно тоже нужен только для вывода >красивостей... Если можно и мне скиньте скрипт mishvin@mail.ru Спасибо
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "как правильно вести ip-статистику?"
	Сообщение от Vladimir on 13-Янв-04, 13:35  (MSK)
	Провайдеры мы не серъёзные, но 400 живых клиентов есть. С киски скидывается по нетфлов на машину в фаил. В среднем 300М за спокойный день. Фаил парсится в реальном времени, скидывает всё в базу, по таблице на день, и считает общую за день. В принципе по 0,5Гб за месяц выходит в MySQL-e
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 13:38  (MSK)
	Во правильно или в день новый файл (таблица) Какой коллектор используешь Владимир, скрипт, что бы парсить не поделишься? Какое расхождение с провайдером?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "как правильно вести ip-статистику?"
	Сообщение от Vladimir on 13-Янв-04, 13:57  (MSK)
	Так как с провайдером у нас часовая разница то в среднем за месяц, если не было великих сбоев, расхождений почти нет. Скрипт является собственностью компании и разглашению не подлежит. Этому есть причина - он переписывается и готовится к сертификации %) Методы сбора статистики достаточно простые: есть отдельный блок програм работающий только с нетфлов и своей отдельной базой. Есть основная база которая из базы нефлов извлекает изменения (уже суммированные и без всяких адресов и портов) и считает деньги. Всё работает раздельно-паралельно с задержкой 5-10 минут. В последующем можно разнести на разные тачки или поставить вообще в другом месте. Такая вот она у нас разнесенная получается.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	20. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 16:34  (MSK)
	>Методы сбора статистики достаточно простые: есть отдельный блок програм работающий только с >нетфлов и своей отдельной базой. Есть основная база которая из базы >нефлов извлекает изменения (уже суммированные и без всяких адресов и портов) Сколько хранится статистика в базе нетфлов и насколько она детальна, агрегируются ли в ней данные о трафике по каким-нибудь параметрам? Если можно, приведи определения таблиц. Что есть netflow? Чем отличается от cisco ip accounting?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 16:46  (MSK)
	NetFlow пишет кроме меток времени, адресов источника и назначения, количество пакетов, количество отктетов, порт источника, порт назначения, интерфейс входящий, исходящий инетрфейс, следующий хоп, и немного служебной информации.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	22. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 16:50  (MSK)
	Если интересно вот таблица 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#
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	24. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 13-Янв-04, 17:17  (MSK)
	А что это за метки времени такие (уж не период ли, за который суммируется размер пакетов с одинаковыми парами "источник-получатель")? Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad на PC, он их может выдавать? Существует ли что-нибудь под юникс, изображающее netflow?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	25. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 17:29  (MSK)
	Агрегатирование тут нет, агрегатирование настраивается отдельно, сейчас тоно на скажу, то ли на машрутизаторе то ли на коллекторе. Маршрутизатор с периодчиностью по udp посылает информацию на коллектор, это инфомрмация исключительно за период. Неагргегатированная без специальных настроек. Под юникс подобно NetFlow ничего не скажу. Подобно ip accounting есть. Но тут снимаемой информации меньше чем при netflow но достаточно для подсчета трафика. Для сведения: при снятии ip accounting и netflow на маршрутизаторе суммарная информация отличается. Этим можете поинтересоваться на соседнем форуме может объяснят почему.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	26. "как правильно вести ip-статистику?"
	Сообщение от Vladimir on 13-Янв-04, 17:53  (MSK)
	>Под юникс подобно NetFlow ничего не скажу. Для FreeBSD ng_netflow есть >Для сведения: при снятии ip accounting и netflow на маршрутизаторе суммарная информация >отличается. Этим можете поинтересоваться на соседнем форуме может объяснят почему. Причина проста, ip account снимает статистику на выходе из киски после аксес листов, нетфлов считает на входе до попадание в аксес лист. Дальше думаю догадаетесь откуда разница.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	27. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 13-Янв-04, 17:57  (MSK)
	снимает она так, но расхождения не факт что только отсюда отсюда. даже при отсутствии акл расхождения есть
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	41. "как правильно вести ip-статистику?"
	Сообщение от Vladimir on 16-Янв-04, 09:14  (MSK)
	У вас на всех интерфейсах включен аккаунтинг? Даже на lo0 и null0 ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	49. "как правильно вести ip-статистику?"
	Сообщение от Anvar on 16-Янв-04, 16:50  (MSK)
	>А что это за метки времени такие (уж не период ли, за >который >суммируется размер пакетов с одинаковыми парами "источник-получатель")? >Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad >на PC, он их может выдавать? > >Существует ли что-нибудь под юникс, изображающее netflow? Netramet https://www.opennet.ru/base/cisco/netr.txt.html
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	23. "как правильно вести ip-статистику?"
	Сообщение от Vladimir on 13-Янв-04, 17:14  (MSK)
	Статистика за месяц хранится в одной таблице. Размер одного месяца статистики ~0.5Gb. Соответственно сколько у вас есть Gb разделите на эту цифру, или умножте на нужное вам время хранения и получите нужные Вам цифры. Нам достаточно 3-х месячной давности. Агрегация происходит по клиентским адресам и заносится в агрегированную таблицу которая и синхронизируется с основной базой. Детальная статистика хранится полная и не агрегированная.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	33. "как правильно вести ip-статистику?"
	Сообщение от virus_net on 14-Янв-04, 20:53  (MSK)
	У меня складывается детальный трафик каждого юзера в скуль. Юзеров порядка 350 человек. Никаких проблем. Да база детального трафа весит много, но все таки складывает и все ок. Считаю trafd, затем с попмошью скиптяги все пихаю в скуль.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	34. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 15-Янв-04, 10:28  (MSK)
	>У меня складывается детальный трафик каждого юзера в скуль. >Юзеров порядка 350 человек. >Никаких проблем. >Да база детального трафа весит много, но все таки складывает и все >ок. >Считаю trafd, затем с попмошью скиптяги все пихаю в скуль. trafd может выдавать статистику попакетно? По-моему не может. Как-то я все равно еще, честно сказать, не вполне врубаюсь (хотя прогресс определенно имеет место быть :) Хотелось бы все-таки добраться до сути а также внести ясность по поводу агрегирования и детализации. trafd и ipcad, IMHO, могут выдавать только статистику, агрегированную по ip-адресам за период времени, через который мы с них снимаем. А агрегированная статистика уже не вполне детальна. Т.е. получается что абсолютно детальную статистику невозможно вести с использованием trafd или ip accounting. Да и дисковое пространство требуется вообще нереальное: информация о пакете занимает минимум 32 байта, за час у 1 юзера может спокойно проходить 10000 пакетов (даже больше, но возьмем такую цифру для расчета); получается 300 Мб в час для 1 юзера. А если объемы информации огромны и юзеров очень много - таких дисковых массивов вообще в природе не существует.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	35. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 15-Янв-04, 11:23  (MSK)
	Пример ip accounting 21.21.1.5     213.180.193.30                 305               65199 За определенный промежуток времени вы получете определенное количество строк и они не агрегатированы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	36. "как правильно вести ip-статистику?"
	Сообщение от harlan on 15-Янв-04, 11:35  (MSK)
	>Пример ip accounting > >21.21.1.5     213.180.193.30       305  65199 > >За определенный промежуток времени вы получете определенное количество строк и они не >агрегатированы. Как раз-таки они агрегированы. По ip-адресам источника и приёмника. Эта запись значит что за период времени с адреса 21.21.1.5 на адрес 213.180.193.30 прошло 305 пакетов общей длиной в 65199 байт.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	37. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 15-Янв-04, 14:22  (MSK)
	если так то это для меня открытие, хочешь сказать что если я в течении минуты буду иметь соедниеннеи, потом его разорву и через две минуты установлю соединение с той же машиной, то запись будет одна?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	38. "как правильно вести ip-статистику?"
	Сообщение от harlan on 15-Янв-04, 14:29  (MSK)
	Если за это время небыла выдана команда "clear ip accounting" то да. cisco (или эмулирующая её программа ipcad) агрегирует данные по ip адресу источника и проиёмника. А была разорвана сессия, или продолжалась она без перерыва им сугубо фиолетово. Она получила пакет, проанализировала ip источника и ip приёмника и добавила его длину в соответствующую ячейку, инкрементировав при этом счётчик пакетов для этой пары.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	39. "как правильно вести ip-статистику?"
	Сообщение от Rippy on 15-Янв-04, 16:20  (MSK)
	Сейчас 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)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	40. "как правильно вести ip-статистику?"
	Сообщение от harlan on 15-Янв-04, 18:16  (MSK)
	>Так что агрегирование происходит только при совпадении src и dst портов (TCP UDP) Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по портам и такой режим - отход от совместимости с оборудованием CISCO, по поводу которого мы с автором ipcad'а не далее как сегодня ломали копья. Так что... Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к FTP, отключился - одна запись, подключился снова к FTP, снова отключился - вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном случае, в логах мы получим две сессии объединённых в одну запись.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	42. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 16-Янв-04, 09:21  (MSK)
	Хех я имел ввиду по ip accounting CISCO , при снятии нет информации о портах поэтому по портам не может агрегироваться. А вот по парам адрес источника - адрес назначения не знаю. Харлан что скажешь?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	44. "как правильно вести ip-статистику?"
	Сообщение от harlan on 16-Янв-04, 09:37  (MSK)
	ИМХО, на этот вопрос я ответил (см выше) и больше мне добавить нечего.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	43. "как правильно вести ip-статистику?"
	Сообщение от Rippy on 16-Янв-04, 09:33  (MSK)
	>Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по >портам и такой режим - отход от совместимости с оборудованием CISCO, >по поводу которого мы с автором ipcad'а не далее как сегодня >ломали копья. Так что... Ну так автор об этом честно предупреждает, причем в самом конфиге # Enabling this will BREAK Cisco output format compatibility # and may slow down processing traffic. >Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к >FTP, отключился - одна запись, подключился снова к FTP, снова отключился >- вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни >ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном >случае, в логах мы получим две сессии объединённых в одну запись. > Почаще статистику можно снимать, хотя зависит от загрузки
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	45. "как правильно вести ip-статистику?"
	Сообщение от Андрей. on 16-Янв-04, 13:37  (MSK)
	У меня на обслуживании имеентся одно Интернет-кафе средней загруженности. Считаю трафик с каждой из 14 машин в зале + трафик IP-телефонии + суммарный трафик на интерфейсе смотрящем в мир. По каждой группе счетчиков отдельно считается только входящий и исходящий трафик. Использую IPFilter, данные со счетчиков снимаю каждые <b>10 секунд</b>, все ненулевые значения пишутся в PostgrSQL базу. С середины мая прошлого года база выросла всего до 850 МБ. Так вот. Андрей.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	74. "как правильно вести ip-статистику?"
	Сообщение от alx on 29-Янв-04, 05:04  (MSK)
	>писать статистику по каждому пакету у серьезного провайдера не справится ни одна >база. слишком много данных. >пробовали мы такое заделать на mysql. он не справлялся с обработкой данных. > Oracle справляется лехко... у нас.. в г. Владивостоке, по кол-ву трафиика по данным РТК наш город входил в 10ку.. самый крупный провайдер Дальсвязь обсчитывает всех своих выделенщиков Oraclom с цисок и все вроде бы отлично, правда иногда падает, но не чаще чем раз в два месяца и данные не теряются...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

46. "как правильно вести ip-статистику?"
Сообщение от v3625 on 16-Янв-04, 16:39  (MSK)
В связи с отходом на сессию сделал пока так: с определенной периодичностью (раз в 15 мин. например) статистика снимается с коллектора и помещается в pgsql базу, при этом сразу же агрегируется за месяц по ip-адресам; с этой же периодичностью юзеры проверяются на предмет необходимости отключения, для чего генерируются правила фаервола. Дальше совершанствовать буду постепенно в дальнейшем (если другую работу за это время не найду :) Всех благодарю за ответы (хотя может быть еще кто-нибудь выскажется), не знаю что бы делал без лучшего в мире форума :) В ближайшие 3 недели писать сюда, вероятнее всего, не буду. Счастливо.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	47. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 16-Янв-04, 16:41  (MSK)
	Мог бы скриптик для агрегатирования оставить .
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	48. "как правильно вести ip-статистику?"
	Сообщение от v3625 on 16-Янв-04, 16:45  (MSK)
	>Мог бы скриптик для агрегатирования оставить . Высылаю почтой, но он работает тормознуто слегка :) Сейчас только его быстренько слабал.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

50. "как правильно вести ip-статистику?"
Сообщение от LionSoftware on 20-Янв-04, 08:40  (MSK)
>Доброго времени суток! > >Пишу биллинговую систему, столкнулся со следующей проблемой: >как вести ip-статистику? Если пихать в базу информацию о каждом пакете - >Как это должны делать серьезные провайдеры? "серьезные провайдеры" (по опыту общения с ТТК и РТК) никогда не собирают детальную статистику - им это не нужно, есть порт включения вот за весь объем и плати - это работа с UpStream провайдером. Если-же абонентам раздавать, то тут всякие хитрости и извращения начинаются - потери, повторы пакетов, несоответствие отправленного объема к полученному... IMHO тема бесконечная. Как вариант низкоуровнего получения и минимальной аггрегации статистики трафика предлагаю свой вариант: http://sourceforge.net/projects/iptrafd/ Проект пока еще сырой, но основлое делать умеет - собирает трафик, по запросу складывает в кучу и если надо блокирует пакеты. Добавлять правила в firewall для этого - фи (по опыту работы с /19 сеткой с несколькими сотнями клиентов) P.S. Offtopic: ищу единомышленников для продолжения написания проекта.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	51. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 08:43  (MSK)
	Доброго времени суток! почитал обсуждение.... интересно.... но самое интересное: а время, потраченное клиентом сидящем на модеме для получения повторных пакетов при потере в канале тоже надо учитывать?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	52. "как правильно вести ip-статистику?"
	Сообщение от LionSoftware on 20-Янв-04, 08:46  (MSK)
	>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения >повторных пакетов при потере в канале тоже надо учитывать? LOL :-) P.S. Я шутку понял :) P.P.S. Я вообще-то про выделенциков, если что.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	54. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 09:15  (MSK)
	>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения >>повторных пакетов при потере в канале тоже надо учитывать? >LOL :-) > >P.S. Я шутку понял :) >P.P.S. Я вообще-то про выделенциков, если что. а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? :) в чём разница? и те и другие юзают IP трафик...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	55. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 09:21  (MSK)
	>>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения >>>повторных пакетов при потере в канале тоже надо учитывать? >>LOL :-) >> >>P.S. Я шутку понял :) >>P.P.S. Я вообще-то про выделенциков, если что. > >а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? >:) в чём разница? и те и другие юзают IP трафик... > Потому что для выделенщиков актуален потребляемый трафик, а для даилапщиков время занятости порта.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	56. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 09:26  (MSK)
	>>>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения >>>>повторных пакетов при потере в канале тоже надо учитывать? >>>LOL :-) >>> >>>P.S. Я шутку понял :) >>>P.P.S. Я вообще-то про выделенциков, если что. >> >>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? >>:) в чём разница? и те и другие юзают IP трафик... >> >Потому что для выделенщиков актуален потребляемый трафик, а для даилапщиков время занятости >порта. и что? получается время потраченное на модеме для того что бы получить повторный пакет оплачивает клиент а на выделенке пакетики повторные (или якобы не нужный клиенту трафик) не учитываются? но передача ведь прошла в сторону клиента... или к примеру трафик, который якобы клиенту не нужен, его не считаем? Думаю это не правильно... включился в инет, получаешь трафик, оплати его... и не надо выдумывать что скаченный файл в 1 метр должен дать трафика в 1 метр ровно :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	61. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 09:40  (MSK)
	С чего ты взял что при выделенке клиент не оплачивает повторные пакеты . еще как оплачивает.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	59. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 09:29  (MSK)
	не факт что всеь трафик попадает в ipfw и обсчёт по ipfw будет правильным. кстате это уже сто раз обсуждалось... :) провайдеру, между прочим, абсолютно всё равно какой из трафика нужен клиенту а какой нет, провайдер считает стколько трафика потребил клиент (т.е. прошло в клиента)... при чём тут детализация? детализацию может делать клиент на своём интерфейсе если ему надо знать кто из его "сетян" куда ходил по http или ещё по чему :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	62. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 09:43  (MSK)
	Говоришь детализация не нужна провайдеру. А если у клиента скажем вирус и он просит провайдера определить что за трафик имеет клиент, провайдер должен быть готов дать ответ как по протоколу так и по портам.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	63. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 10:04  (MSK)
	>Говоришь детализация не нужна провайдеру. >А если у клиента скажем вирус и он просит провайдера определить что >за трафик имеет клиент, провайдер должен быть готов дать ответ как >по протоколу так и по портам. с чего бы это провайдер должен был быть обязан это делать? клиент обязан сам следить за вирусятниками у себя в сети.....
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	64. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 10:06  (MSK)
	>Говоришь детализация не нужна провайдеру. >А если у клиента скажем вирус и он просит провайдера определить что >за трафик имеет клиент, провайдер должен быть готов дать ответ как >по протоколу так и по портам. это называется "переложим с больной головы на здоровую" :) если клиент по ЛЮБЫМ причинам накачал больше трафика, провайдер тут абсолютно не при чём... (не берём в расчёт совершенно элементарные вещи, которые провайдер настроит правильно)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	65. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 10:11  (MSK)
	Провайдер конечно не обязан, это можно назвать качеством услуги. Хотя это и можно расценивать как техническую поддержку. А если возникают спорные моменты с клиентом. А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	66. "как правильно вести ip-статистику?"
	Сообщение от Grey on 20-Янв-04, 10:28  (MSK)
	>Провайдер конечно не обязан, это можно назвать качеством услуги. >Хотя это и можно расценивать как техническую поддержку. >А если возникают спорные моменты с клиентом. >А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег. > ну если клиент считает, что его провайдер накалывает, пусть докажет... :) причём тут даже в суд не надо ходить... нормальному провайдеру достаточно показать лог, в котором клиенту чего-то не нравится... провайдер примет меры со своей стороны, в этом я уверен на все 100% я вот только вот чего не пойму.... смысл разводить такие темы? если у провайдера 10 клиентов с локалкоми по 10 компов, он может конечно в качестве "улучшения услуги" сделать любую статистику по протоколам, портам и чёрту лисому.... но требовать этого от провайдера и судить насколько он серъёзен - мне кажется в корне не верно... :) мне как клиенту самому интересно что происходит на моём внешнем интерфейсе и я тут сам себе провайдер :) для того что бы выяснить что там творится не нужен ни биллинг ни крутые счётчики..... всё достаточно просто...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	57. "как правильно вести ip-статистику?"
	Сообщение от LionSoftware on 20-Янв-04, 09:26  (MSK)
	>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? >:) в чём разница? и те и другие юзают IP трафик... IMHO для диалапщиков трафик должна снимать железка, которая этих самых диалапщиков и обслуживает. Как ни странно, лидером здесь пока является Cisco, но это тема другой конференции. Если для диалапа вполне реально по деньгам поставить Циску, то даже для районной сети втыкать Циски будет дорого, если конечно это не элитная сеть между домами НР (не Hewlett-Packard :) ). Весь мой опыт админства подсказывает, что снимать статистику нужно как можно ближе к клиенту (чтобы расхождений было немного), соответственно для дилапщиков пусть считает циска и отдает в биллинг, для выделенщиков пусть роутер считает - лучше всего ближайщий к клиенту.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	53. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 08:49  (MSK)
	А как ты собираешься снимать IP статистику с порта, расскажи.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	58. "как правильно вести ip-статистику?"
	Сообщение от LionSoftware on 20-Янв-04, 09:27  (MSK)
	>А как ты собираешься снимать IP статистику с порта, расскажи. Имелся ввиду порт железки, к которой подключен маршрутизатор downstream провайдера, Т.е. порт маршрутизатора или свича.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	60. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 20-Янв-04, 09:37  (MSK)
	я это понял, вот и спрашиваю как снятьс него IP статистику
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	68. "как правильно вести ip-статистику?"
	Сообщение от Sergey Shumov on 20-Янв-04, 13:45  (MSK)
	Мы у себя делаем проще :) для снятия статистики используем ipacctd или ng_ipacct(немножко поправленные для эффективного агрегирования). Раз в N минут накопленные данные передаются утилите, которая конвертирует эти данные в netflow v5. В процессе конвертации заполняются поля src_as и dst_as. За каждым клиентом закреплён уникальный идентификатор, который и вставляется в эти поля. После чего данные отправляются на коллектор. Какие преимущества - очень удобно потом анализировать полученные данные, нет жёсткой привязки к IP адресам клиента. Возможность раздельно учитывать локальный/точки обмена/паритетный трафик. Так-же возможно получить детализацию трафика. При 200Gb месячного трафика получается порядка 700Mb netflow данных. Статистика хранится год(как минимум). Варианты с SQL не подошли ввиду их ресурсоёмкости.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	71. "как правильно вести ip-статистику?"
	Сообщение от LionSoftware on 22-Янв-04, 09:40  (MSK)
	>При 200Gb месячного трафика получается порядка 700Mb netflow данных. >Статистика хранится год(как минимум). Варианты с SQL не подошли ввиду их ресурсоёмкости. Как максимум - 3 года (срок исковой давности :) )
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	70. "как правильно вести ip-статистику?"
	Сообщение от LionSoftware on 22-Янв-04, 09:39  (MSK)
	>я это понял, вот и спрашиваю как снятьс него IP статистику Если это Cisco-железка, то по SNMP. Google тысячи ссылок даст.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	75. "как правильно вести ip-статистику?"
	Сообщение от A Clockwork Orange on 29-Янв-04, 08:57  (MSK)
	Пользователь платит за ip статистику, а что показывает SNMP
		Рекомендовать в FAQ | Cообщить модератору | Наверх

72. "как правильно вести ip-статистику?"
Сообщение от Евгений on 28-Янв-04, 20:20  (MSK)
Изобретаю свой велосипед -- десятки имеющихся биллингов по разным причинам не покатили :( Вырисовываются следующие моменты: 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-пакеты вместе с заголовками?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

73. "как правильно вести ip-статистику?"
Сообщение от NetKnight on 29-Янв-04, 00:40  (MSK)
>Доброго времени суток! > >Пишу биллинговую систему, столкнулся со следующей проблемой: >как вести ip-статистику? Если пихать в базу информацию о каждом пакете - > >требуется немеренно дискового пространства. > >В нешем городе несколько провайдеров - один не предастовляет >(и наверное не ведет) детальной ip-статистики, только помещает в базу >сумму входящих и исходящих байт за каждые сутки; >другой ведет детальную ip-статистику за месяц и суммирует за этот месяц >количество байт для каждой уникальной пары src_ip - dst_ip. > >У всех них биллинговые системы сертифицированы. >Может есть какие-от стандарты или рекомендации относительно того, >насколько подробной должна быть ip-статистика? > >Как это должны делать серьезные провайдеры? Ну серьёзные провайдеры для этого используют Oracle. Тем более я не совсемпонял какую именно информацию нужно собирать? И нужне ли информация о каждом пакете? Если нужно посчитать трафик, то почему не использовть ipfw, iptables для этого? Через крон пишется скрипт, который кладёт счётчики в базу и обнуляет их, потом определёнными запросами за конретный пеиод всё вычисляется..
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.