За последнюю неделю практически каждый день стал выпадать netup_netflow, можно ли посмотреть по какой причине он это делает ?
Таблицы при съеме данных проверяются.
Подозрение вызывает увеличение внутрисетевого траффика, проскакивающего через VPN тунель (до 3 гиг/ день), может по этому и вылетает коллектор.
Как контролировать netup_netflow? по кронду ?
П.С. Как запретить прохождение локального траффика в виндах через тунель ВПН ? Это связано с сменой маршрута по умолчанию.
Выпадает из процессов netup_netflow и ndsad
Нетфлоу, слава Богу, не слетает. А вот ндсад... это бедствие какое-то. Причем он может висеть в процессах, но информации от него никакой. У меня запущен скрипт, который проверяет наличие потока от сервера и если что - убивает ндсад до конца и запускает снова. Через мегафон получаю сообщение об этом.
ipcad конечно умеет netflow v5, но дело в том что
при большой нагрузке и непрерывном получением и вставлнием в базу
mysql netup_netflow упайдет, есть альтернатива, конечно.
НАпример такая, прога get_xyz, задав параметры, скажем что бы каждый 20 секунд
собирл данные у ipcad'a и передавал netup_netflow. Хотя такая возможность у самого ipcad'a
уже есть(netflow timeout active 5; говорит через сколько минут он передаст накопленную информацию
Космический зеленый лазер разных размеров.
netup_netflow, который сразу же занесет данные в MYsql, и будет
ждать опять 5минут ipcad'a,) при таком способе собирании траффика
через netflow шансов, что бы что нибудь упайдет минимальный. Но если вдруг, Mysql упайдет, то весь
траффик который прошел через ipcad уже netup_netflow его не получит, траффик будет висеть в памяти ipcad'a
которого можно будет снять путем изменения в конфигурационном файле utm.cfg строку (collector_type=ipcad)
и только после этого можно будет забрать тот висячий траффик у ipcad'a. Хотя так это гемаройно.
Но дело в том, что get_xyz собирая информацию может записывать все в файл. В этом случае
можно не боятся не Mysql и netup_netflow.
Если бы netup_netflow, или путем обработки tsave, можно было бы с этого файла,
собирать траффик, но увы.
Програмиты такое уже предусмотрели в UTM5, но вот в UTM4 такого нету.
Вот мое предложение, создать обработку траффика, из файла, путем программы get_xyz для Netup UTM4!
при большой нагрузке и непрерывном получением и вставлнием в базу
mysql netup_netflow упайдет, есть альтернатива, конечно.
НАпример такая, прога get_xyz, задав параметры, скажем что бы каждый 20 секунд
собирл данные у ipcad'a и передавал netup_netflow. Хотя такая возможность у самого ipcad'a
уже есть(netflow timeout active 5; говорит через сколько минут он передаст накопленную информацию
Космический зеленый лазер разных размеров.
netup_netflow, который сразу же занесет данные в MYsql, и будет
ждать опять 5минут ipcad'a,) при таком способе собирании траффика
через netflow шансов, что бы что нибудь упайдет минимальный. Но если вдруг, Mysql упайдет, то весь
траффик который прошел через ipcad уже netup_netflow его не получит, траффик будет висеть в памяти ipcad'a
которого можно будет снять путем изменения в конфигурационном файле utm.cfg строку (collector_type=ipcad)
и только после этого можно будет забрать тот висячий траффик у ipcad'a. Хотя так это гемаройно.
Но дело в том, что get_xyz собирая информацию может записывать все в файл. В этом случае
можно не боятся не Mysql и netup_netflow.
Если бы netup_netflow, или путем обработки tsave, можно было бы с этого файла,
собирать траффик, но увы.
Програмиты такое уже предусмотрели в UTM5, но вот в UTM4 такого нету.
Вот мое предложение, создать обработку траффика, из файла, путем программы get_xyz для Netup UTM4!
Последний раз редактировалось tariely Вт ноя 17, 2009 22:30, всего редактировалось 1 раз.
Мммм.... На самом деле, большинство из того, что ты говоришь, легко и непринужденно реализовывается при помощи специальной версии netup_netflow - которая не сразу кладет в базу, а в файлик, а из него перед запуском tsave все банально импортируется одной строчкой в скрипте (только что-то эту версию не выложать никак... И вроде существует она только для Бзди, что устроило бы меня, но не многочисленные массы линухятников 
). Ведь при большой загрузке падает не сам netflow, а начинаются теряться INSERT'ы по пути в базу, т.к. они даже не отложенные... У кого база на отдельном компе уже давно с этим столкнулись....
Про get_xyz думал и в итоге забил - во-первых, прога ни фига не развивается и сомнительно, что ее будут дорабатывать, править глюки и т.п., а во-вторых - вставлять лишнее звено в процесс подсчета трафика как-то не хочется... С точки зрения надежности...
Так что, мое предложение: использовать ipcad с таймаутом, netup_netflow со сбросом в файлик и все будет замечательно.
). Ведь при большой загрузке падает не сам netflow, а начинаются теряться INSERT'ы по пути в базу, т.к. они даже не отложенные... У кого база на отдельном компе уже давно с этим столкнулись....Про get_xyz думал и в итоге забил - во-первых, прога ни фига не развивается и сомнительно, что ее будут дорабатывать, править глюки и т.п., а во-вторых - вставлять лишнее звено в процесс подсчета трафика как-то не хочется... С точки зрения надежности...
Так что, мое предложение: использовать ipcad с таймаутом, netup_netflow со сбросом в файлик и все будет замечательно.
была такая проблема с netup_netflow. из-за чего падает так и не понял.
инфы ноль.
решилось запуском по крону каждую минуту. т.е. если и упадет, то через минуту опять его поднимают.
еще на прошлом форуме было обсуждение ..... э...разветвителя портов (сорри забыл как это по русски красиво). прога которая слушает порт, принимает пакеты и потом сама же их пересылает их например на порт netflow и в файл.
инфы ноль.
решилось запуском по крону каждую минуту. т.е. если и упадет, то через минуту опять его поднимают.
еще на прошлом форуме было обсуждение ..... э...разветвителя портов (сорри забыл как это по русски красиво). прога которая слушает порт, принимает пакеты и потом сама же их пересылает их например на порт netflow и в файл.
UTM4, mysql, ipcad (netflow), netup_netflow
как сказать tsave, что бы он в таком формате из файла забирал весь траффик?
srcaddr dstaddr dOctets First Last srcport dstport pad tcp_flags prot
10.40.10.2 10.40.10.0 640 2147817 2147817 1537 80 0 20 6
10.40.10.0 10.40.10.2 23371 2147817 2147817 80 1537 0 25 6
10.40.10.0 10.40.10.2 25970916 2147817 2197147 80 1540 0 18 6
10.40.10.2 10.40.10.0 499630 2147817 2197147 1540 80 0 26 6
траффик в формате netflow5 из проги new netflow collector, модуль немножко переделан.
srcaddr dstaddr dOctets First Last srcport dstport pad tcp_flags prot
10.40.10.2 10.40.10.0 640 2147817 2147817 1537 80 0 20 6
10.40.10.0 10.40.10.2 23371 2147817 2147817 80 1537 0 25 6
10.40.10.0 10.40.10.2 25970916 2147817 2197147 80 1540 0 18 6
10.40.10.2 10.40.10.0 499630 2147817 2197147 1540 80 0 26 6
траффик в формате netflow5 из проги new netflow collector, модуль немножко переделан.