forum.bitel.ru http://forum.bitel.ru/ |
|
Поток netflow и модуль IPN http://forum.bitel.ru/viewtopic.php?f=7&t=2347 |
Страница 1 из 1 |
Автор: | L-ZiX [ 25 май 2009, 15:03 ] |
Заголовок сообщения: | Поток netflow и модуль IPN |
Можно ли не использовать netflow коллектор и в качестве источника забить сразу микротик как источник потока? |
Автор: | stark [ 25 май 2009, 15:52 ] |
Заголовок сообщения: | Re: Поток netflow и модуль IPN |
L-ZiX писал(а): Можно ли не использовать netflow коллектор и в качестве источника забить сразу микротик как источник потока?
источник - микротик . Можно коллектор - не хотите использовать .. Тогда ето будет длоиг netfow собирать? можете flow-tools использовать |
Автор: | L-ZiX [ 25 май 2009, 16:15 ] |
Заголовок сообщения: | |
Так всетаки как правильно? Как я понимаю надо в качествет источника указать микротик, с микротика направить поток на коллектор, а тот в свою очередь сам всё будет делать. Верно? |
Автор: | stark [ 25 май 2009, 18:08 ] |
Заголовок сообщения: | |
да исчтоник есть по любому. Это тот, кто шлет логи . У вас это mikrotik .Коллектор нужен чтобы собирать логи , эти логи можно собирать не только нашим коллектором, но и помощью flow-tools .Возможны оба варианта - оба правильные. У нашего коллектора есть недостаток - он медленее работает чем flow-tools и поэтому иногда может не справляться с нагрузкой. |
Автор: | Yagoda [ 29 май 2009, 11:03 ] |
Заголовок сообщения: | |
Пробую БГБ (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 ] |
Заголовок сообщения: | |
Вы бы в WiKi сей шедевр выложили.. |
Автор: | Jimson [ 03 июн 2009, 01:36 ] |
Заголовок сообщения: | |
вариант поставить коллектор IPN там же где собирает трафик flow_capture не подошел ? |
Автор: | Yagoda [ 03 июн 2009, 07:01 ] |
Заголовок сообщения: | |
И записывать в базу на другой машине? В том-то и цинус получившейся схемы, что не страшны обрывы соединения между роутером и сервером БГБ. Т.е. если связь нарушилась - файлы NetFlow (flow-tools) копятся. Когда будет связь, перекинутся для обработки. И даже если в момент передачи связь оборвется - ничего страшного. Частично переданный файл отправится по новой, ну и оставшиеся отправятся. Наверное, это паранойя... Но как-то не хочется зависеть от постоянства коннектов. |
Автор: | Jimson [ 03 июн 2009, 13:06 ] |
Заголовок сообщения: | |
ничего страшного нет в обрыве соединения коллектора с базой в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили параноя в первую очередь заставляет минимизировать кол-во узлов в схеме, повышение надежности с помощью пачки скриптов решение не всегда верное ) |
Автор: | Администратор [ 03 июн 2009, 13:10 ] |
Заголовок сообщения: | |
Цитата: в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили
Нет, загрузку там не дать. Только обработку. Загрузки как таковой нет, коллектору же логи подсовывают. А загрузка осталась с тех времен, когда еще с текстовых файлов грузили сначала в БД, потом обрабатывали. В телефонии схема такая и осталась.. Записал в TODO, уберем вообще пункты меню про загрузку логов для IPN.. Путают только. |
Автор: | Jimson [ 03 июн 2009, 13:18 ] |
Заголовок сообщения: | |
я предлагаю добавить в TODO такую фичу: при получении задания на обработку, коллектор проверяет в базе предыдущие периоды, и если там есть пропуски то пытается найти файлы за эти периоды иначе говоря простейший механизм востановления работы после обрыва коннективити с СУБД, иначе получается что все задания на загрузку которые были при отсутсвии соединения с базой приходится ручками давать |
Автор: | Администратор [ 03 июн 2009, 13:32 ] |
Заголовок сообщения: | |
Хм, подумаем. |
Автор: | Yagoda [ 04 июн 2009, 06:26 ] |
Заголовок сообщения: | |
Jimson писал(а): ничего страшного нет в обрыве соединения коллектора с базой
в идеале через АРМ администратора ты всегда можешь дать задание коллектору на загрузку логов, правда у меня через АРМ эта фича не работает, но думаю в 4.6 уже все починили параноя в первую очередь заставляет минимизировать кол-во узлов в схеме, повышение надежности с помощью пачки скриптов решение не всегда верное ) Отчасти согласен, но хотелось бы иметь механизм само-востановления. В коллекторе этого механизма я не вижу. Хорошо, конечно, если будет. Как раз этот "набор скриптов" и добавляет нужный мне функционал. Костыли? Отчасти да. По надежности - если процесс использует связь с другой системой (не обязательно другой ПК, может быть и просто другой процесс), то надежность резко падает. Особенно если такая связь "синхронная". А данный набор, как раз, обеспечивает "асинхронную" связь. В роли буфера (хранилища заданий) - файловая система. Что обеспечит восстановление (выполнение заданий) даже при перезапуске компьютера. Даже если коллектор востанавливает соединение с базой - а где он хранит "пропущенные" задания (информацию о незаписанных в базу логах)? В памяти? Перезапуск - и их нет! Значит опять только ручками... Хотелось бы, чтобы "само"... |
Автор: | Yagoda [ 04 июн 2009, 08:03 ] |
Заголовок сообщения: | |
Несколько вопросов разработчикам. Коллектор на комманду isload (если все нормально) выдает "OK log is marked, process started..". Что конкретно это обозначает? Что задание принято "к исполнению"? Что задание поставлено в очередь обработки? Что данные корректные и загружены? Имеется ли очередь заданий? Т.е. корректно подряд давать много? А если подряд несколько заданий за один интервал времени (один и тотже час), то как это работает? Так все подряд и выполняются? Дополнительно, пожелания. - Иметь возможность загружать порции меньше чем за час. В идеале - просто указав файл логов. - Хотелось бы иметь коды возврата на комманду isload - все хорошо, ошибка в файле, внутренняя ошибка и т.д. (0,1,2...). Это позволит строить какую-то логику. Пойдет даже вывод какого-то кода в стандартный вывод (там его можно подхватить и обработать). - Иметь возможность "дождаться окончания обработки". Т.е. на выходе (по коду возврата) точно знать успешность выполнения. |
Автор: | Администратор [ 04 июн 2009, 14:32 ] |
Заголовок сообщения: | |
Цитата: Что задание принято "к исполнению"? Что задание поставлено в очередь обработки? Что данные корректные и загружены? Помечено на обработку, задание добавлено в таблицу task_proccess. Т.е. по сути в очередь добавлено. Цитата: Имеется ли очередь заданий? Т.е. корректно подряд давать много? А если подряд несколько заданий за один интервал времени (один и тотже час), то как это работает? Так все подряд и выполняются? Можно несколько раз давать, порядок обработки не гарантирован. Цитата: Дополнительно, пожелания.
- Иметь возможность загружать порции меньше чем за час. В идеале - просто указав файл логов. - Хотелось бы иметь коды возврата на комманду isload - все хорошо, ошибка в файле, внутренняя ошибка и т.д. (0,1,2...). Это позволит строить какую-то логику. Пойдет даже вывод какого-то кода в стандартный вывод (там его можно подхватить и обработать). - Иметь возможность "дождаться окончания обработки". Т.е. на выходе (по коду возврата) точно знать успешность выполнения. Не получится, файл не проверяется при этом. Просто задание добавляется в очередь. |
Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |