Господа. Статистику поставляю по NetFlow.
Что-то никак не могу разобраться, как можно разнести ядро и коллектор статистики?
Нужно: что бы вся информация лилась на отдельную машину, а NetUp ее уже забирал от туда и заносил записи в базу. Где в настройка ядра указать, где лежит для него трафик который надо разгребсти?
Коллектор статистики
-
Renaissance87
- Сообщения: 58
- Зарегистрирован: Вс май 25, 2008 11:55
Re: Коллектор статистики
может тебе поможет в этом, get_xyzRenaissance87 писал(а):Господа. Статистику поставляю по NetFlow.
Что-то никак не могу разобраться, как можно разнести ядро и коллектор статистики?
Нужно: что бы вся информация лилась на отдельную машину, а NetUp ее уже забирал от туда и заносил записи в базу. Где в настройка ядра указать, где лежит для него трафик который надо разгребсти?
-
Renaissance87
- Сообщения: 58
- Зарегистрирован: Вс май 25, 2008 11:55
Там ты можешь только указать, где он будет этот трафик хранить, если под трафиком ты понимаешь детальную статистикуRenaissance87 писал(а):Да нет, у меня же все и так по NetFlow.
Мне хочется, что бы mysql стоял отдельно - это уже готово.
utm_core -стоял отдельно - на машине с минимальным объемом харда.
Трафик лился бы на третью машину - здесь у меня заготовлено 2 ТБ.
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
Ну вообще логичнее было бы вынесли коллектов в виде отдельного модуля и там осуществлять операции связаные с пребиллинговыми процессами: например агрегация трафика в зависимости от тарифа (так для безлимитчиков агрегацию можно вообще проводить с большими периодами). В результате бы получили распределение нагрузки для ядра и коллектора, опять же плюс к стабильности системы. Но увы... в UTM5 этого нет.
Поэтому для вас навереное логичным будет подмонтировать разделы /netup/log и /netup/db по nfs к выделеному NAS
Поэтому для вас навереное логичным будет подмонтировать разделы /netup/log и /netup/db по nfs к выделеному NAS
-
Renaissance87
- Сообщения: 58
- Зарегистрирован: Вс май 25, 2008 11:55
Именно это и хочется сделать...AndrewE писал(а):Ну вообще логичнее было бы вынесли коллектов в виде отдельного модуля и там осуществлять операции связаные с пребиллинговыми процессами: например агрегация трафика в зависимости от тарифа (так для безлимитчиков агрегацию можно вообще проводить с большими периодами). В результате бы получили распределение нагрузки для ядра и коллектора, опять же плюс к стабильности системы.
Очень жаль, что нет. Если больше не будет идей, буду делать через NFS.AndrewE писал(а):Но увы... в UTM5 этого нет.
Поэтому для вас навереное логичным будет подмонтировать разделы /netup/log и /netup/db по nfs к выделеному NAS
Да это ерунда, у меня в среднем биллинг до недавнего времени обсчитывал около 250Tb, это не та нагрузка за которую стоит пыхтеть, лучше сервер статистики переписать для того чтобы можно было вынести на ведомый мускул.AndrewE писал(а):Ну вообще логичнее было бы вынесли коллектов в виде отдельного модуля и там осуществлять операции связаные с пребиллинговыми процессами: например агрегация трафика в зависимости от тарифа (так для безлимитчиков агрегацию можно вообще проводить с большими периодами). В результате бы получили распределение нагрузки для ядра и коллектора, опять же плюс к стабильности системы. Но увы... в UTM5 этого нет.
Поэтому для вас навереное логичным будет подмонтировать разделы /netup/log и /netup/db по nfs к выделеному NAS
Есть реальный выйгрыш в произовдительности если все отчеты будут браться со slave mysql?Magnum72 писал(а): Да это ерунда, у меня в среднем биллинг до недавнего времени обсчитывал около 250Tb, это не та нагрузка за которую стоит пыхтеть, лучше сервер статистики переписать для того чтобы можно было вынести на ведомый мускул.
Кстати, какое время синхоронизации делали для slave?
У меня по закрытии очередного файла детальки вызывается raw_fd_script, который пакует файл (bzip2, 100M -> 18M) и отсылает через scp на другую машину. А там уже скрипты раскладывают в хранилище. И так она там и хранится, и обрабатываю когда надо самописной штукой. Мороки значительно меньше.
Про время синхронизации для slave mysql. Что имеется в виду? это репликация, там синхронизация идет так - как только master проглотил запрос, он появляется в бинарном логе, как только он там появляется, его читает slave и выполняет у себя.
Про время синхронизации для slave mysql. Что имеется в виду? это репликация, там синхронизация идет так - как только master проглотил запрос, он появляется в бинарном логе, как только он там появляется, его читает slave и выполняет у себя.
