URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 39233
[ Назад ]

Исходное сообщение
"как правильно вести ip-статистику?"

Отправлено v3625 , 12-Янв-04 11:31 
Доброго времени суток!

Пишу биллинговую систему, столкнулся со следующей проблемой:
как вести ip-статистику? Если пихать в базу информацию о каждом пакете -
требуется немеренно дискового пространства.

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

У всех них биллинговые системы сертифицированы.
Может есть какие-от стандарты или рекомендации относительно того,
насколько подробной должна быть ip-статистика?

Как это должны делать серьезные провайдеры?


Содержание

Сообщения в этом обсуждении
"как правильно вести ip-статистику?"
Отправлено Nikolaev_D , 12-Янв-04 12:10 
>Как это должны делать серьезные провайдеры?


серьезные провайдеры дают канал и качай, сколько сможешь.


"как правильно вести ip-статистику?"
Отправлено Nickolay , 12-Янв-04 12:32 
писать статистику по каждому пакету у серьезного провайдера не справится ни одна база. слишком много данных.
пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.

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

"как правильно вести ip-статистику?"
Отправлено v3625 , 12-Янв-04 15:26 
>пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.

и как оно у вас сейчас, если не серкет?


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

Другого пути нет, как снимать и в базу класть, мне видится.


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

Т.е. если при средней нагрузке в 100 клиентов я хочу отвести под
базу до 10 Гб и хранить статистику за год - остается только сразу
агрегировать по парам ip-адресов за учетный период при снимании с
маршрутизатора (как оно сейчас и есть).


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


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

И так каждый день - в итоге, если что-то надо вытащить и старых баз - прога на виндовой машине шарит по всем сохранённым ранее базам на предмет требуемого IP-адреса и формирует необходимый отчёт. В принципе удобно. Обычно статистика необходима в конце месяца и тогда прога лопатит цельный день для того, чтобы сформировать то, что необходимо - это единственное неудобство.

ЗЫ: ну и машина виндовая должна быть под это дело отведена соответствующая


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

Но ведь понятие сессии применимо не ко всем протоколам, что могут
работать поверх ip.


"как правильно вести ip-статистику?"
Отправлено v3625 , 13-Янв-04 10:03 
Понял, наверное имеются в виду диалапные сессии.


"как правильно вести ip-статистику?"
Отправлено Aliv , 13-Янв-04 09:50 
>У нас сейчас все примитивно просто.
>Все валится в текстовой файл с маршрутизатора, а в начале месяца он
>обрабатывается на windows спецаильно написанной программой.
>Да не спорю топорно и неудобно, как обычно дефицит средств, машина для
>сбора P100.
>Файл за месяц при средней нагрузке 10 клиентов порядка 200М. Как то
>считал если раскидывать в базу то не хватит хранить годовую статистику
>в одном файле.
>Максимальный размер файла 4Г.
>Если какой нибудь вирусняк на денек другой у клиента, файл пухнет до
>300-400М в месяц, плюс если увеличить количество клиентов полная креза.
>Отсюда верятнее всего у крупных провайдеров каждый месяц свой файл-база.
>
>Другого пути нет, как снимать и в базу класть, мне видится.

Решал эту проблемму тоже через текстовый файл. Система FreeBSD 5.0
У меня при количестве клиентов ~ 40, месячный файл статистики в зжатом виде не превышает 100 кбайт.
Статистика снимается по Cron каждые 20 минут в нагруженное время и каждые 2 часа в ночное. Счетчик с ipfw.
Сначала обрабатывал в Excel - муторно. Сейчас написал скрипт - получилось
удобно. Все делаю на маршрутизаторе.



"как правильно вести ip-статистику?"
Отправлено BRomantik , 13-Янв-04 10:48 
Если кому интересно могу скинуть скрипт который парсит файл, складывает все в базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог ulog-acctd

"как правильно вести ip-статистику?"
Отправлено v3625 , 13-Янв-04 11:04 
Интересно.

mailto:v3625@mail.ru


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 13-Янв-04 11:18 
Романтик и какой у тебя размер файла за год?
v3625 посмотри максимальный размер файла для FreeBSD какой.

"как правильно вести ip-статистику?"
Отправлено v3625 , 13-Янв-04 16:09 
>v3625 посмотри максимальный размер файла для FreeBSD какой.

Для FFS максимальный размер файла равен ~1 Г блоков
(4 Тб при размере блока 4 Кб).

Для UFS - не знаю, но наверно не меньше


"как правильно вести ip-статистику?"
Отправлено Alish , 13-Янв-04 11:21 
>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в
>базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог
>ulog-acctd

мне интересно alisherk@uzpak.uz


"как правильно вести ip-статистику?"
Отправлено boger , 14-Янв-04 13:38 
>Если кому интересно могу скинуть скрипт который парсит файл, складывает все в
>базу, генерит лог, и сниает деньги со счета пользователя:) Парсит лог
>ulog-acctd
и мне интересно bogatyrjov[dog]bk.ru

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

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 14-Янв-04 14:39 
Ну как то с задачей надо определиться что надо, универсальных систем нет.
А если канал будет 10М с какой частотой вы будете снимать статистику что бы лишние 3Мб клиент не скачал?

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

Нужно подбирать такую периодичность, чтобы не остаться в убытке.


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

"как правильно вести ip-статистику?"
Отправлено BRomantik , 20-Янв-04 13:36 
Долго не мог писать...
Да согласен, что не очень хорошо давать перебирать траффик, можно конечно снизить съем до минуты, но перебор все равно будет, деваться здесь некуда...
Я думал передавать парсеру попакетно, но опять таки при большой нагрузке и маленьком мту, пакетов будет много и парсер просто захлебывается, причем захлебывается прямо пропорционально нагрузке.
Поэтому деваться некуда, перебор так перебор (для меня приемлимо), зато получается очень даже неплохо...
Файлик маленький(за год не знаю), работает все очень быстрои четко...
Статистика снялась, деньги вычлись, если ноль то отключает(если в онлайне), если нет, то просто не даст потом подключаться...
Раньше я считал на основе лога iptables, но:
1) При использовании syslog терялись пакеты (при высоких нагрузках).
2) Как то раз качал фильм и тут увидел, что файл за несколько минут разросся до нескольких сотен метров.

Ulog-acctd собирает данные по связке src-dst и скидыает результат в указанный период (я ставлю каждые 30 секукнд).
Мылы желающих попробовать я записал, буду дома, вышлю с инструкцией, но сразу говорю, что необходим php+apache+mysql, причем php желательно последний, так как в клиентской части я использую глобальные переменные так как умеет только 4.3.3 вроде бы :)... Но пропарсить файл вы сможете и с любым другим не очень старым... apache собственно тоже нужен только для вывода красивостей...


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

Если можно и мне скиньте скрипт mishvin@mail.ru Спасибо


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

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 13-Янв-04 13:38 
Во правильно или в день новый файл (таблица)

Какой коллектор используешь Владимир, скрипт, что бы парсить не поделишься?

Какое расхождение с провайдером?


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

"как правильно вести ip-статистику?"
Отправлено v3625 , 13-Янв-04 16:34 
>Методы сбора статистики достаточно простые: есть отдельный блок програм работающий только с
>нетфлов и своей отдельной базой. Есть основная база которая из базы
>нефлов извлекает изменения (уже суммированные и без всяких адресов и портов)

Сколько хранится статистика в базе нетфлов и насколько она детальна,
агрегируются ли в ней данные о трафике по каким-нибудь параметрам?
Если можно, приведи определения таблиц.

Что есть netflow? Чем отличается от cisco ip accounting?


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 13-Янв-04 16:46 
NetFlow пишет кроме меток времени, адресов источника и назначения, количество пакетов, количество отктетов, порт источника, порт назначения, интерфейс входящий, исходящий инетрфейс, следующий хоп, и немного служебной информации.

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 13-Янв-04 16:50 
Если интересно вот таблица
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#

"как правильно вести ip-статистику?"
Отправлено v3625 , 13-Янв-04 17:17 
А что это за метки времени такие (уж не период ли, за который
суммируется размер пакетов с одинаковыми парами "источник-получатель")?
Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad
на PC, он их может выдавать?

Существует ли что-нибудь под юникс, изображающее netflow?


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

"как правильно вести ip-статистику?"
Отправлено Vladimir , 13-Янв-04 17:53 
>Под юникс подобно NetFlow ничего не скажу.
Для FreeBSD ng_netflow есть

>Для сведения: при снятии ip accounting и netflow на маршрутизаторе суммарная информация
>отличается. Этим можете поинтересоваться на соседнем форуме может объяснят почему.

Причина проста, ip account снимает статистику на выходе из киски после аксес листов, нетфлов считает на входе до попадание в аксес лист. Дальше думаю догадаетесь откуда разница.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 13-Янв-04 17:57 
снимает она так, но расхождения не факт что только отсюда отсюда.
даже при отсутствии акл расхождения есть

"как правильно вести ip-статистику?"
Отправлено Vladimir , 16-Янв-04 09:14 
У вас на всех интерфейсах включен аккаунтинг? Даже на lo0 и null0 ?

"как правильно вести ip-статистику?"
Отправлено Anvar , 16-Янв-04 16:50 
>А что это за метки времени такие (уж не период ли, за
>который
>суммируется размер пакетов с одинаковыми парами "источник-получатель")?
>Хотелось бы про них что-нибудь услышать. Я снимаю статистику с ipcad
>на PC, он их может выдавать?
>
>Существует ли что-нибудь под юникс, изображающее netflow?


Netramet
http://www.opennet.me/base/cisco/netr.txt.html


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

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

"как правильно вести ip-статистику?"
Отправлено v3625 , 15-Янв-04 10:28 
>У меня складывается детальный трафик каждого юзера в скуль.
>Юзеров порядка 350 человек.
>Никаких проблем.
>Да база детального трафа весит много, но все таки складывает и все
>ок.
>Считаю trafd, затем с попмошью скиптяги все пихаю в скуль.

trafd может выдавать статистику попакетно? По-моему не может.

Как-то я все равно еще, честно сказать, не вполне врубаюсь (хотя
прогресс определенно имеет место быть :)
Хотелось бы все-таки добраться до сути а также внести ясность по поводу
агрегирования и детализации.

trafd и ipcad, IMHO, могут выдавать только статистику, агрегированную по
ip-адресам за период времени, через который мы с них снимаем.
А агрегированная статистика уже не вполне детальна. Т.е. получается что
абсолютно детальную статистику невозможно вести с использованием
trafd или ip accounting.

Да и дисковое пространство требуется вообще
нереальное: информация о пакете занимает минимум 32 байта, за час у
1 юзера может спокойно проходить 10000 пакетов (даже больше,
но возьмем такую цифру для расчета); получается 300 Мб в час для 1 юзера.
А если объемы информации огромны и юзеров очень много - таких дисковых
массивов вообще в природе не существует.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 15-Янв-04 11:23 
Пример ip accounting

21.21.1.5     213.180.193.30                 305               65199

За определенный промежуток времени вы получете определенное количество строк и они не агрегатированы.


"как правильно вести ip-статистику?"
Отправлено harlan , 15-Янв-04 11:35 
>Пример ip accounting
>
>21.21.1.5     213.180.193.30       305  65199
>
>За определенный промежуток времени вы получете определенное количество строк и они не
>агрегатированы.

Как раз-таки они агрегированы. По ip-адресам источника и приёмника.
Эта запись значит что за период времени с адреса 21.21.1.5 на адрес 213.180.193.30 прошло 305 пакетов общей длиной в 65199 байт.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 15-Янв-04 14:22 
если так то это для меня открытие, хочешь сказать что если я в течении минуты буду иметь соедниеннеи, потом его разорву и через две минуты установлю соединение с той же машиной, то запись будет одна?

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


"как правильно вести ip-статистику?"
Отправлено Rippy , 15-Янв-04 16:20 
Сейчас 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)

"как правильно вести ip-статистику?"
Отправлено harlan , 15-Янв-04 18:16 
>Так что агрегирование происходит только при совпадении src и dst портов (TCP UDP)

Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по портам и такой режим - отход от совместимости с оборудованием CISCO, по поводу которого мы с автором ipcad'а не далее как сегодня ломали копья. Так что...
Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к FTP, отключился - одна запись, подключился снова к FTP, снова отключился - вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном случае, в логах мы получим две сессии объединённых в одну запись.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 16-Янв-04 09:21 
Хех я имел ввиду по ip accounting CISCO , при снятии нет информации о портах поэтому по портам не может агрегироваться.
А вот по парам адрес источника - адрес назначения не знаю.
Харлан что скажешь?

"как правильно вести ip-статистику?"
Отправлено harlan , 16-Янв-04 09:37 
ИМХО, на этот вопрос я ответил (см выше) и больше мне добавить нечего.



"как правильно вести ip-статистику?"
Отправлено Rippy , 16-Янв-04 09:33 
>Ага. А вот сиська, ИМХО, до сих пор не умеет агрегировать по
>портам и такой режим - отход от совместимости с оборудованием CISCO,
>по поводу которого мы с автором ipcad'а не далее как сегодня
>ломали копья. Так что...
Ну так автор об этом честно предупреждает, причем в самом конфиге
# Enabling this will BREAK Cisco output format compatibility
# and may slow down processing traffic.

>Кроме того, вопрос был поставлен по поводу временного разделения сессий (подключился к
>FTP, отключился - одна запись, подключился снова к FTP, снова отключился
>- вторая запись, etc.) Так агрегировать данные (ИМХО) ни сиська, ни
>ipcad не умеют. Единственное, если исходящий порт не совпадёт, в противном
>случае, в логах мы получим две сессии объединённых в одну запись.
>
Почаще статистику можно снимать, хотя зависит от загрузки


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

Андрей.


"как правильно вести ip-статистику?"
Отправлено alx , 29-Янв-04 05:04 
>писать статистику по каждому пакету у серьезного провайдера не справится ни одна
>база. слишком много данных.
>пробовали мы такое заделать на mysql. он не справлялся с обработкой данных.
>

Oracle справляется лехко...
у нас.. в г. Владивостоке, по кол-ву трафиика по данным РТК наш город входил в 10ку.. самый крупный провайдер Дальсвязь обсчитывает всех своих выделенщиков Oraclom с цисок и все вроде бы отлично, правда иногда падает, но не чаще чем раз в два месяца и данные не теряются...


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

Всех благодарю за ответы (хотя может быть еще кто-нибудь выскажется),
не знаю что бы делал без лучшего в мире форума :)

В ближайшие 3 недели писать сюда, вероятнее всего, не буду.
Счастливо.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 16-Янв-04 16:41 
Мог бы скриптик для агрегатирования оставить .

"как правильно вести ip-статистику?"
Отправлено v3625 , 16-Янв-04 16:45 
>Мог бы скриптик для агрегатирования оставить .

Высылаю почтой, но он работает тормознуто слегка :)
Сейчас только его быстренько слабал.


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

"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 08:43 
Доброго времени суток!

почитал обсуждение.... интересно....
но самое интересное: а время, потраченное клиентом сидящем на модеме для получения повторных пакетов при потере в канале тоже надо учитывать?


"как правильно вести ip-статистику?"
Отправлено LionSoftware , 20-Янв-04 08:46 
>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>повторных пакетов при потере в канале тоже надо учитывать?
LOL :-)

P.S. Я шутку понял :)
P.P.S. Я вообще-то про выделенциков, если что.


"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 09:15 
>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>>повторных пакетов при потере в канале тоже надо учитывать?
>LOL :-)
>
>P.S. Я шутку понял :)
>P.P.S. Я вообще-то про выделенциков, если что.

а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков? :) в чём разница? и те и другие юзают IP трафик...


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


"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 09:26 
>>>>но самое интересное: а время, потраченное клиентом сидящем на модеме для получения
>>>>повторных пакетов при потере в канале тоже надо учитывать?
>>>LOL :-)
>>>
>>>P.S. Я шутку понял :)
>>>P.P.S. Я вообще-то про выделенциков, если что.
>>
>>а что за дискриминация? :) почему выделенищиков надо обсчитывать иначе чем дайлапщиков?
>>:) в чём разница? и те и другие юзают IP трафик...
>>
>Потому что для выделенщиков актуален потребляемый трафик, а для даилапщиков время занятости
>порта.

и что? получается время потраченное на модеме для того что бы получить повторный пакет оплачивает клиент а на выделенке пакетики повторные (или якобы не нужный клиенту трафик) не учитываются? но передача ведь прошла в сторону клиента...
или к примеру трафик, который якобы клиенту не нужен, его не считаем? Думаю это не правильно... включился в инет, получаешь трафик, оплати его... и не надо выдумывать что скаченный файл в 1 метр должен дать трафика в 1 метр ровно :)


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 20-Янв-04 09:40 
С чего ты взял что при выделенке клиент не оплачивает повторные пакеты . еще как оплачивает.

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

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 20-Янв-04 09:43 
Говоришь детализация не нужна провайдеру.
А если у клиента скажем вирус и он просит провайдера определить что за трафик имеет клиент, провайдер должен быть готов дать ответ как по протоколу так и по портам.

"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 10:04 
>Говоришь детализация не нужна провайдеру.
>А если у клиента скажем вирус и он просит провайдера определить что
>за трафик имеет клиент, провайдер должен быть готов дать ответ как
>по протоколу так и по портам.

с чего бы это провайдер должен был быть обязан это делать?
клиент обязан сам следить за вирусятниками у себя в сети.....


"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 10:06 
>Говоришь детализация не нужна провайдеру.
>А если у клиента скажем вирус и он просит провайдера определить что
>за трафик имеет клиент, провайдер должен быть готов дать ответ как
>по протоколу так и по портам.

это называется "переложим с больной головы на здоровую" :)
если клиент по ЛЮБЫМ причинам накачал больше трафика, провайдер тут абсолютно не при чём... (не берём в расчёт совершенно элементарные вещи, которые провайдер настроит правильно)


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 20-Янв-04 10:11 
Провайдер конечно не обязан, это можно назвать качеством услуги.
Хотя это и можно расценивать как техническую поддержку.
А если возникают спорные моменты с клиентом.
А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег.

"как правильно вести ip-статистику?"
Отправлено Grey , 20-Янв-04 10:28 
>Провайдер конечно не обязан, это можно назвать качеством услуги.
>Хотя это и можно расценивать как техническую поддержку.
>А если возникают спорные моменты с клиентом.
>А правильность и нормальность вещи оспоримые тем более когда касается зарабатывания денег.
>

ну если клиент считает, что его провайдер накалывает, пусть докажет... :)
причём тут даже в суд не надо ходить... нормальному провайдеру достаточно показать лог, в котором клиенту чего-то не нравится... провайдер примет меры со своей стороны, в этом я уверен на все 100%
я вот только вот чего не пойму.... смысл разводить такие темы?
если у провайдера 10 клиентов с локалкоми по 10 компов, он может конечно в качестве "улучшения услуги" сделать любую статистику по протоколам, портам и чёрту лисому.... но требовать этого от провайдера и судить насколько он серъёзен - мне кажется в корне не верно... :)
мне как клиенту самому интересно что происходит на моём внешнем интерфейсе и я тут сам себе провайдер :) для того что бы выяснить что там творится не нужен ни биллинг ни крутые счётчики..... всё достаточно просто...


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

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 20-Янв-04 08:49 
А как ты собираешься снимать IP статистику с порта, расскажи.



"как правильно вести ip-статистику?"
Отправлено LionSoftware , 20-Янв-04 09:27 
>А как ты собираешься снимать IP статистику с порта, расскажи.
Имелся ввиду порт железки, к которой подключен маршрутизатор downstream провайдера, Т.е. порт маршрутизатора или свича.


"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 20-Янв-04 09:37 
я это понял, вот и спрашиваю как снятьс него IP статистику

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



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


"как правильно вести ip-статистику?"
Отправлено LionSoftware , 22-Янв-04 09:39 
>я это понял, вот и спрашиваю как снятьс него IP статистику
Если это Cisco-железка, то по SNMP. Google тысячи ссылок даст.

"как правильно вести ip-статистику?"
Отправлено A Clockwork Orange , 29-Янв-04 08:57 
Пользователь платит за ip статистику, а что показывает SNMP

"как правильно вести ip-статистику?"
Отправлено Евгений , 28-Янв-04 20:20 
Изобретаю свой велосипед -- десятки имеющихся биллингов по разным причинам не покатили :(

Вырисовываются следующие моменты:

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-статистику?"
Отправлено NetKnight , 29-Янв-04 00:40 
>Доброго времени суток!
>
>Пишу биллинговую систему, столкнулся со следующей проблемой:
>как вести ip-статистику? Если пихать в базу информацию о каждом пакете -
>
>требуется немеренно дискового пространства.
>
>В нешем городе несколько провайдеров - один не предастовляет
>(и наверное не ведет) детальной ip-статистики, только помещает в базу
>сумму входящих и исходящих байт за каждые сутки;
>другой ведет детальную ip-статистику за месяц и суммирует за этот месяц
>количество байт для каждой уникальной пары src_ip - dst_ip.
>
>У всех них биллинговые системы сертифицированы.
>Может есть какие-от стандарты или рекомендации относительно того,
>насколько подробной должна быть ip-статистика?
>
>Как это должны делать серьезные провайдеры?


Ну серьёзные провайдеры для этого используют Oracle. Тем более я не совсемпонял какую именно информацию нужно собирать? И нужне ли информация о каждом пакете? Если нужно посчитать трафик, то почему не использовть ipfw, iptables для этого? Через крон пишется скрипт, который кладёт счётчики в базу и обнуляет их, потом определёнными запросами за конретный пеиод всё вычисляется..