BiTel

Можно ли каким-то образом для сбора Netflow использовать сторонний сборщик, сохраняющий в формате flow-tools?
Речь идёт о real-time сборе Netflow с порта и передаче его дальше BGBilling на обработку. Например это могло бы выглядеть так:
1. Сборщик кладёт файлы куда-то в стандартное место (например /usr/local/BGInetAccounting/data/flow/source_N)
2. BGBilling периодически проверяет наличие новых файлов Netflow и обрабатывает их

Клиент: вер. 5.2 сборка 1071 от 19.11.2012 18:23:40
os: Linux; java: Java HotSpot(TM) Server VM, v.1.6.0_26
Сервер: вер. 5.2 сборка 1347 от 19.11.2012 18:15:07
os: Linux; java: Java HotSpot(TM) Server VM, v.1.6.0_26

inet вер. 5.2 сборка 1019 от 19.11.2012 19:59:03

Сейчас можно положить и вручную обработать. Но сессии не появятся . Пересоздание сессии будет в 6.1. Можно будет глобальным скриптом добавлять задания на обработку. А скрипт запускать в планировщике.

+1 к запросу.

У нас сейчас сторонний сборщик работает для IPN, затем конвертируем в нужный формат и подсовываем коллектору.
Поскольку переход на Inet будет постепенным, хотелось бы, чтобы одни и те же логи можно было использовать в 2 модулях. Скажем, сделать симлинк на директорию с логами для каждого источника: source_<inet_mid> -> source_<ipn_mid>.
Да вот только так не выходит - именование субдиректорий и файлов различное. Это печально.

Это ещё более печально.


А по какой логике будут создаваться сессии?
Скажем, у клиента есть radius-сессии за это время, а чуть позже мы загружаем netflow - трафик привяжется к существующим уже сессиям или будут созданы новые?

А критично-ли, если id сессий будут пересекаться в разных месяцах?
Мне вот потребовалось за предыдущий месяц добавить клиента и насчитать ему трафик. Создал новый тип сервиса и тип устройства, само устройство.
Подложил ему в папку source_<id> данные от flow-tools.
Создал сессии (просто insert'ом в inet_session_log_1_201304), а id продолжил от максимального.
В итоге получились сессии с одинаковыми id в апреле и мае.
Переобсчитал логи. Вроде ошибок не было, трафик и наработка посчитались.

Уже сделали это в 6.1. Если сессии уже есть, то трафик можно просто переобработкой привязать к существующим сессиям - это можно и сейчас уже сделать.А в 6.1 Пересоздание сессий сделали для автосесии, которые стартуют по наличию трафика (типа инициации - по трафику) . Их просто пересоздают с 00:00 по 23:59:59 если в этот день пришел хоть один байт. Это сделано в первую очередь на случай аварий , когда трафик потерян, сессий нет , но есть какая-то копия собранная во flow-tools , тогда подсовывают этот трафик и переобрабатывают . Все существующие сессии при этом грохаются. Пересоздание сесстий для сессий стратующих по сигналу ( по radius ) , по Radius-логам не делали . да и нужно ли ?

Вопрос возник: могу ли я повесить на один rootDeviceId два аккаунтинг-сервера?
Скажем, один обрабатывает radius-протокол, а другой - только netflow собирает?
Не хочу все яйца в одну корзину класть - рестартовать коллектор лишний раз не хочется.

Должно работать. Но полноценно такой вариант еще не пробовали/не тестировали.

Я думаю, тут вопрос распадается на 2:
- сервисы (и устройства?) не пересекаются
- сервисы пересекаются (сессии есть и по радиусу, и netflow)

1. Если сессии не пересекаются - точно должно работать.
2. Если сессии пересекаются, т.е. одна сессия (по сигналу) работает и по RADIUS и по Netflow на разных Accounting - тут надо потестить, в т.ч. переход дня, стоп сессии, изменение опций в тарифе, перезагрузку одного из Accounting.

Ок.
Настроил flow в том же аккаунтинг-сервере, трафик пошел, файлы пишутся, но сессия для сервиса не создаётся.
Может быть проблема в том, что у сервиса не заданы ip-адреса? Есть только интерфейс, ifindex указан прямо в номере порта. В модуле IPN по тому же интерфейсу трафик есть.

Если по всему интерфейсу и нет желания указывать в сервисе 0.0.0.0-255.255.255.255, то нужно в типе сервиса галочку поставить "весь интерфейс".

И правда! Заработало, спасибо!