|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alexander V. Naumochkin 2:5020/59 29 May 2002 21:56:09
To : Dmitry Frolov
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
DF> В некоторых областях trafd подходит лучьше, чем ng_ipacct. Пока для
DF> ng_ipacct не написали простых и понятных тулзов. Я это и хотел
DF> сказать, но видимо растекся мыслью...
Ага, я даже знаю эти области :) Это когда есть тощенький канал в интернет для
сетюшки из пяти компутеров и типа администратор. Которому не то, чтобы лениво
что-то написать, он просто не умеет пока ещё ничего. Вот ему trafd - самое оно.
Уже "всё" написано.
AN>> Из личного опыта: знающему Python/ruby/Tcl/Perl/ещё_какая_хрень
AN>> сделать
DF> Обычно достаточно awk.
В обозначенной мной области? Конечно достаточно awk. Трафика-то дай бог, чтобы
пара гигабайт в месяц набежало :) И отклика ждать не лениво.
AN>> укладку данных из ng_ipacct в SQL - полчаса с перекуром. А
AN>> прочее - фильтрацию всякую, выборки за любой период времени,
AN>> красивый вид - сделают сам SQL и хатэмээльщик. Hа фига бы Роман
AN>> этим занимался :)
DF> Ок, вот у нас кол-во роутеров -- около 50-ти. Ты предлагаешь, на
DF> каждый роутер поставить по sql'ю, вебу, и смотреть на них статистику?
DF> ;) Ладна, можно хранить статистику централизованно. Может ты нам
DF> советуешь написать новую систему сбора и учета трафика?
Это trafd - система? Сильно :) Особенно для 50 рутеров. Под FreeBSD. Hе
подскажешь название своей могучей организации, мне чертовски любопытно, прямо до
соплей :)
Впрочем, не надо. В смысле, сочинять не надо.
DF> Как насчет аудита? Какая производительность и объем баз должен быть
DF> у sql-сервера, чтобы посмотреть какой ip куда ходил через определенный
DF> интерфейс на определенном роутере за определенное время и при этом не
DF> ждать результата 2 часа?
Секунды - устроит? Из SQL. Hе устраивает? Тогда trafd, КБСС :) Текст парсить
и обрабатывать awk'ом всяко быстрее раз так в 50, чем цифры из толстой
индексированной базы силами специально тому обученной (и нередко -
multithreaded) софтинки :))))
DF> Проблема совсем не в написании срипта, который будет парсить
DF> вывод какой-либо программки.
Правильно. Проблема не в написании скрипта, а в наличии знаний о написании
оных. И организации БД.
Сообщаю: MySQL на Celeron800/256Mb. Объём базы по входящему трафику - ~80
миллионов записей. Самых разных. Hа чуть меньше сотни клиентов. Суммарная
статистика по клиенту (по которой он деньги платит) - мгновенно. За любой месяц
с тех пор, как система запущена. С разблюдовкой по основным сервисам
(smtp/pop/news/dns/web/прочее) - почти мгновенно (3-5 секунд устроит?). Куда и
зачем ходил клиент и сколько при этом накачал? За последние три месяца -
пожалуйста. Подождать придётся, конечно же, некоторое время (сильно зависящее
от активности клиента, периода, за который хочется это получить), но только это
будет сильно быстрее, чем ты думаешь; это будет точно до байта в отличие от awk;
это очень просто реализуется; и в конце концов, если бы такие идиотские отчёты
требовались действительно часто, а не в очень редких конфликтных ситуациях, то
реорганизовать базу под хранение промежуточных результатов и, как следствие,
очень быстрое получение суммарного результата - работа копеечная. Если в SQL
что-то понимаешь, разумеется, а не смотришь на него, как на какое-то подобие
SuperCalc'а.
Alexander
... Графиня изменившимся лицом бежит пруду.
--- GoldED/W32 3.00.Beta4+
* Origin: ASH Project Co., Moscow (2:5020/59)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
