BiTel

Всем доброе время.
Подскажите пожалуйста как можно пересчитать наработку у абонентов. Суть вот в чем.
Стоит система ваша, обсчет велся по нетфлоу, сменили оборудование у себя и забыли про то что нам нужен этот поток, в таком состоянии отработали дней 5, пока добрый пользователь не сказал что сидит на халяву, ну и кинулись, у нас нечего не считается. полазили по базе удивили таблицу log_session в ней нашли строчки о принятых и переданных данных, зародилась мысль что если у нас отсутствует данные нетфлоу, можно посчитать радиус, в настройках радиуса изменили вариант сбора данных, изменили коллекторы на radin и radout, стали считаться без потока, но если мы делаем обсчет этих дней то все равно в наработке у пользователя как было 0 за сесию так и остается.

п.с. Вот такая ситуация, Так как это серые пользователи, исход не важен, получиться так получиться, нет так нет, но хотелось бы.

netflow еще куда-то шел? например на flow-capture? если да - подсуньте его логи ipn коллектору и пересчитайте в dialup сессии

Нет, netflow шел только на коллектор.

чей? только dialup? в ipn ничего не слали? если нет - выкашивайте из конфига модуля все что касается netflow (netflow.service.link.x), в конфиге наса пишите

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

если у Вас железка слала с сервисами ... хотя ХЗ почему не пересчиталось

Вот что было:
поток шел нал IPNNetflowCollector. (ну чтобы пользователю статистику получать)
nas.port_time.default.*=1
nas.port_traffic.default.*=4:collector;5:collector

Вот что сделали и то что сейчас:
netflow.receive.from=192.168.201.2
nas.port_time.default.*=1
nas.port_traffic.default.*=4:RADIN;5:RADOUT
month.break=1
#для DialUP - режим работы
#1 - режим UPDATE - пересчет во время прохождения UPDATE пакетов
#2 - режим CHECKER - пересчет по таймеру, UPDATE пакеты используются для получения
#информации о трафике
dialup.workmode=1
nas.inspector.class=bitel.billing.server.processor.PoDNASConnectionInspector
nas.inspector.pod.port=1700
nas.inspector.pod.attributes=User-Name;Framed-IP-Address;Acct-Session-Id
#интервал между посылками на проверку либо сброс соедиенения
nas.inspector.sleep_time=60
#максимальное число попыток сброса соединения
nas.inspector.kill.max_messages=5
#разрешение активировать все типы карточек на этом NASе
card.activate.service=0
#поддержка CallBack (1-включите)
callback.support=0
#Для автозакрытия соединений "висящих" более часа
drop.sleep.timeout=3600
ipn.module.id=6
ipn.source.id=1
netflow.log.path=D:/BGIPNNetflowCollector/null/


и что самое интересное, в таблице log_session меняли значение стоимости session_cost на любой(просто чтобы проверить), при этом поля input_octets и output_octets имели значения отличные от 0 и потом при переобсчете он опять возвращался в ноль (.

алилуйа! у Вас есть файлики со всеми нужными данными


на момент перерасчета - возвращайте взад COLLECTOR


это точные данные? с ними детализация высылается? с чего Вы взяли что на винде такие слеши?
может все же туда надо написать

или даже

в IPNNetflowCollector как-раз и вся беда что там нет не чего, нету файлов за это время, а как получилось что их там нет увы уже не скажу, то ли мы то ли лыжи.
По поводу слэшей все работает, достаточно давно и очень не плохо, по сравнению с Айдеко, БГ выдерживает такие фокусы ))

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

фак! бум ждать разработчиков ... может они чего толкового посоветуют

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

Большие всегда хранят первичный NetFlow поток. Вам нужно просто вставить данные по трафикам в таблицу session_detail_<mid>_yyyyMM из log_session_<mid>_yyyyMM.
Как-то так:


Вопрос не отлажен. Допилите сами. Очень рекомендую сделать бакап таблицы session_detail : .