BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 03 июл 2025, 12:57

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
 Заголовок сообщения: Поток netflow и модуль IPN
СообщениеДобавлено: 25 май 2009, 15:03 
Можно ли не использовать netflow коллектор и в качестве источника забить сразу микротик как источник потока?


Вернуться к началу
  
 
 Заголовок сообщения: Re: Поток netflow и модуль IPN
СообщениеДобавлено: 25 май 2009, 15:52 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
L-ZiX писал(а):
Можно ли не использовать netflow коллектор и в качестве источника забить сразу микротик как источник потока?


источник - микротик . Можно
коллектор - не хотите использовать .. Тогда ето будет длоиг netfow собирать? можете flow-tools использовать


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 25 май 2009, 16:15 
Так всетаки как правильно? Как я понимаю надо в качествет источника указать микротик, с микротика направить поток на коллектор, а тот в свою очередь сам всё будет делать. Верно?


Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: 25 май 2009, 18:08 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
да
исчтоник есть по любому. Это тот, кто шлет логи . У вас это mikrotik .Коллектор нужен чтобы собирать логи , эти логи можно собирать не только нашим коллектором, но и помощью flow-tools .Возможны оба варианта - оба правильные. У нашего коллектора есть недостаток - он медленее работает чем flow-tools и поэтому иногда может не справляться с нагрузкой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 29 май 2009, 11:03 
Не в сети

Зарегистрирован: 06 май 2009, 05:25
Сообщения: 102
Откуда: г. Амурск
Карма: 10
Пробую БГБ (BGBillingServer_4.6_463, BGIPNNetflowCollector_4.6_176, ipn_4.6_175, BGRadiusIPN_4.6_146, npay_4.6_157)

Встал вопрос как обрабатывать NetFlow...
Вариант, который предлагается в мануале не совсем нравится - там или источник NetFlow с БГБ-сервером на одной машине, или NetFlow гонится через сеть. Ни то, ни другое не подходит - первое по вопросам производительности, второе по надежности.
Хотелось (в идеале) вообще по сети NetFlow не гнать, в крайнем случае по интерфейсу lo (127.0.0.1).

Выбрана схема, при которой:
- интервал файлов NetFlow - 5 минут;
- источник NetFlow на роутере (Linux - Debian-lenny (stable));
- приемник на ней-же (flow-tools);
- на сервере БГБ поднят proftpd (DefaultRoot /var/get_flow , заведен бесправный юзер со всеми правами в этом каталоге).

Т.е. бинарные файлы собираются на роутере, по FTP гонятся на сервер БГБ. Для надежной (даже при сбоях) передачи файлов сделаны следущие скрипты:

test_flow - запускается по готовности очередного файла.
Для этого в конфиге /etc/flow-tools/flow-capture.conf строка
-w /var/flow/eth0 -n 275 0/127.0.0.1/555 -R /lib/test_flow/test

Код:
# Files of flow-tools
flow_dir="/var/flow/eth0"
flow_file="$flow_dir/$1"

# Тут проверка трафика средствами flow-tools, grep и gawk - для оперативного вмешательства в iptables ;)
#***************

# Копируем очередной файл во временный каталог
cp $flow_file /var/flow/tmp/

# Запускаем отправку на FTP БГБ-сервер
/lib/test_flow/send_flow


send_flow (использует пакет ncftp):
Код:
#!/bin/sh

ftp_user="****"
ftp_pass="****"

# Для отладки желательно. При желании можно указать report="/dev/null"
report="report"

cd /var/flow/tmp
echo "---------------" >> $report
date >> $report

# Получение md5 файлов. Параметр -V при обработке в режиме демона обязательно!
ncftpget -DD -V -u $ftp_user -p $ftp_pass 10.10.10.2 . *.md5

# теперь проверим наличие и правильность md5 для каждого бинарного файла
for ft in $(ls -C1 ft*1100); do
    echo "Обрабатываем $ft" >> $report
    if [ -r $ft.md5 ]; then
   echo "Для файла $ft есть $ft.md5" >> $report
   md5_r=$( md5sum -c --status "$ft.md5")
   echo "Результат проверки: $md5_r" >> $report
   if [ "$md5_r" = "" ]; then
       echo "Файл $ft - правильный, удален" >> $report
       # Тут можно и удалить ft - бинарный файл
       rm $ft
   else
       echo "Файл $ft - ошибка md5 !!!!!!!!!" >> $report
   fi
    else
   echo "Для $ft нет $ft.md5" >> $report
    fi
done

# Удалим md5
rm *.md5

# Отправка всех накопившихся ft*
ncftpput -V -u $ftp_user -p $ftp_pass 10.10.10.2 . ft*1100


На сервере БГБ, по крону каждую минуту запускается скрипт check_flow (использует пакет gawk для вычленения YYYY, MM, DD, HH из имени файла):
Код:
#!/bin/sh

dir_get="/var/get_flow"
dir_flow="/var/flow/source_4"

cd $dir_get

# Если в работе - выход
if [ -f "$dir_get/all.par" ]; then
    exit
fi

# Запишем контрольные суммы
for ft in $(ls -C1 ft*1100); do
    echo "$ft"
    md5sum -b $ft > $ft.md5
done
chmod 666 *.md5

# Сделаем список файлов
ls -C1 ft*1100 > all.list

# Теперь переделаем его в список параметров для копирования и запуска сбора логов
cat all.list | gawk -F'[.-]' '{ print $0 " " $3 " " $4 " " $5 " " substr($6, 1, 2) }' > all.par

# Ну и для каждой строки...
while read -r LINE; do
    /lib/proc_flow/copy_load $LINE
done < all.par

rm all.par
rm all.lis


copy_load:
Код:
#!/bin/sh

get_dir="/var/get_flow"
send_dir="/var/flow/source_4"

ft=$1
YYYY=$2
MM=$3
DD=$4
HH=$5

# Проверим наличие каталогов, сделаем если надо
if [ ! -d "$send_dir" ]; then
    mkdir $send_dir
    #echo "Create $send_dir"
fi

if [ ! -d "$send_dir/$YYYY" ]; then
    mkdir "$send_dir/$YYYY"
    #echo "Create $send_dir/$YYYY"
fi

if [ ! -d "$send_dir/$YYYY/$YYYY-$MM" ]; then
    mkdir "$send_dir/$YYYY/$YYYY-$MM"
    #echo "Create $send_dir/$YYYY/$YYYY-$MM"
fi

if [ ! -d "$send_dir/$YYYY/$YYYY-$MM/$YYYY-$MM-$DD" ]; then
    mkdir "$send_dir/$YYYY/$YYYY-$MM/$YYYY-$MM-$DD"
    #echo "Create $send_dir/$YYYY/$YYYY-$MM/$YYYY-$MM-$DD"
fi

# Копирую файл куда надо, если удачно - удаляю
cp $get_dir/$ft $send_dir/$YYYY/$YYYY-$MM/$YYYY-$MM-$DD/$ft && rm $get_dir/$ft

# Запуск обработки в БГБ-коллекторе
/lib/bg_nf_ipn_c/netflow.sh isload 4 $YYYY-$MM-$DD-$HH


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

ЗЫ. В линуксе не силен и БГБ только изучаю, просьба сильно не ругать... Но может кому идея пригодится... Отправка на FTP с подтверждением ;)

ЗЫЫ. flow-tools складывает файлы:
{указанный в конфиге каталог}/YYYY/YYYY-MM/YYYY-MM-DD/ft-v50.YYYY-MM-DD.hhmmss+1100 - в конце часовой пояс.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 29 май 2009, 16:37 
Не в сети
Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93
Вы бы в WiKi сей шедевр выложили..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 01:36 
Не в сети

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
вариант поставить коллектор IPN там же где собирает трафик flow_capture не подошел ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 07:01 
Не в сети

Зарегистрирован: 06 май 2009, 05:25
Сообщения: 102
Откуда: г. Амурск
Карма: 10
И записывать в базу на другой машине?
В том-то и цинус получившейся схемы, что не страшны обрывы соединения между роутером и сервером БГБ. Т.е. если связь нарушилась - файлы NetFlow (flow-tools) копятся. Когда будет связь, перекинутся для обработки. И даже если в момент передачи связь оборвется - ничего страшного. Частично переданный файл отправится по новой, ну и оставшиеся отправятся.

Наверное, это паранойя... Но как-то не хочется зависеть от постоянства коннектов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 13:06 
Не в сети

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
ничего страшного нет в обрыве соединения коллектора с базой
в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 13:10 
Не в сети
Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93
Цитата:
в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили

Нет, загрузку там не дать. Только обработку. Загрузки как таковой нет, коллектору же логи подсовывают. А загрузка осталась с тех времен, когда еще с текстовых файлов грузили сначала в БД, потом обрабатывали. В телефонии схема такая и осталась..
Записал в TODO, уберем вообще пункты меню про загрузку логов для IPN.. Путают только.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 13:18 
Не в сети

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
я предлагаю добавить в TODO такую фичу:
при получении задания на обработку, коллектор проверяет в базе предыдущие периоды, и если там есть пропуски то пытается найти файлы за эти периоды
иначе говоря простейший механизм востановления работы после обрыва коннективити с СУБД, иначе получается что все задания на загрузку которые были при отсутсвии соединения с базой приходится ручками давать


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 03 июн 2009, 13:32 
Не в сети
Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93
Хм, подумаем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 04 июн 2009, 06:26 
Не в сети

Зарегистрирован: 06 май 2009, 05:25
Сообщения: 102
Откуда: г. Амурск
Карма: 10
Jimson писал(а):
ничего страшного нет в обрыве соединения коллектора с базой
в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили

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

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

По надежности - если процесс использует связь с другой системой (не обязательно другой ПК, может быть и просто другой процесс), то надежность резко падает. Особенно если такая связь "синхронная".

А данный набор, как раз, обеспечивает "асинхронную" связь. В роли буфера (хранилища заданий) - файловая система. Что обеспечит восстановление (выполнение заданий) даже при перезапуске компьютера.

Даже если коллектор востанавливает соединение с базой - а где он хранит "пропущенные" задания (информацию о незаписанных в базу логах)? В памяти? Перезапуск - и их нет! Значит опять только ручками... Хотелось бы, чтобы "само"...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 04 июн 2009, 08:03 
Не в сети

Зарегистрирован: 06 май 2009, 05:25
Сообщения: 102
Откуда: г. Амурск
Карма: 10
Несколько вопросов разработчикам.

Коллектор на комманду isload (если все нормально) выдает "OK log is marked, process started..".

Что конкретно это обозначает?

Что задание принято "к исполнению"?
Что задание поставлено в очередь обработки?
Что данные корректные и загружены?

Имеется ли очередь заданий? Т.е. корректно подряд давать много?
А если подряд несколько заданий за один интервал времени (один и тотже час), то как это работает? Так все подряд и выполняются?

Дополнительно, пожелания.
- Иметь возможность загружать порции меньше чем за час. В идеале - просто указав файл логов.
- Хотелось бы иметь коды возврата на комманду isload - все хорошо, ошибка в файле, внутренняя ошибка и т.д. (0,1,2...). Это позволит строить какую-то логику. Пойдет даже вывод какого-то кода в стандартный вывод (там его можно подхватить и обработать).
- Иметь возможность "дождаться окончания обработки". Т.е. на выходе (по коду возврата) точно знать успешность выполнения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 04 июн 2009, 14:32 
Не в сети
Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93
Цитата:
Что задание принято "к исполнению"?
Что задание поставлено в очередь обработки?
Что данные корректные и загружены?

Помечено на обработку, задание добавлено в таблицу task_proccess. Т.е. по сути в очередь добавлено.

Цитата:
Имеется ли очередь заданий? Т.е. корректно подряд давать много?
А если подряд несколько заданий за один интервал времени (один и тотже час), то как это работает? Так все подряд и выполняются?

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

Цитата:
Дополнительно, пожелания.
- Иметь возможность загружать порции меньше чем за час. В идеале - просто указав файл логов.
- Хотелось бы иметь коды возврата на комманду isload - все хорошо, ошибка в файле, внутренняя ошибка и т.д. (0,1,2...). Это позволит строить какую-то логику. Пойдет даже вывод какого-то кода в стандартный вывод (там его можно подхватить и обработать).
- Иметь возможность "дождаться окончания обработки". Т.е. на выходе (по коду возврата) точно знать успешность выполнения.

Не получится, файл не проверяется при этом. Просто задание добавляется в очередь.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.048s | 42 Queries | GZIP : On ]