Hi! On Tue, Oct 10, 2006 at 11:18:05AM +0300, Vladimir Litovka writes: VL> посоветуйте open source софт (список - ниже), который практически VL> зарекомендовал себя по следующим критериям: VL> VL> 1) надежность VL> 2) высокая производительность для работы в операторской среде с VL> большим количеством клиентов (до N Kusers) VL> 3) наличие вменяемой истории развития (то есть - исправление ошибок, VL> добавление новых фич во вменяемо скором времени от момента VL> возникновения необходимости, инсталлированная база пользователей, VL> которым можно задавать вопросы, etc) VL> 4) открытый доступ ко всем ресурсам (обновлениям, поддержке, etc), что VL> не исключает наличие опции платного саппорта. VL> VL> Софт нужен следующий (surprise! :) ): VL> VL> 1) Netflow Collector. Специфические пожелания - интерфейс к SQL VL> (отправка Netflow-записей непосредственно в SQL сервер), но это хоть и VL> большой плюс, но не принципиальный; VL> 2) Radius. Тот же интерфейс к SQL, но уже mandatory. VL> VL> Комментарии: VL> VL> - я не знаю, как выглядит API к SQL :) У оператора установлен Oracle - VL> что это значит в практическом смысле? Конечно, идеальная картина мира VL> - это если каждый вендор поставляет свои библиотеки, в который API VL> соответствует стандарту, а интерфейс к SQL-серверу - свой собственный, VL> но насколько реальная картина соответствует идеалу? Я считаю, что в данном случае наиболее разумная поддержка SQL - это через perl. То есть, в netflow collecter или в radius делается perl hook, из которого уже происходит запись куда угодно в каком угодно формате с использованием любых перловых модулей. И производительность от этого не снизится, потому что, во-первых, она важнее для обработки трафика, а не для записи результатов, а во-вторых, собственно интерпретации перлового кода получается минимум. А гибкость сразу повышается очень сильно. VL> - интересуют комментарии в таком формате - "пробовали (1), (2) и (3); VL> остановились на (3) потому что в (1) были такие-то проблемы, в (2) - VL> такие-то, а в (3) есть такие-то проблемы, но это наименьшее из всех VL> зол" :) Я использую flowd. cvs -d :pserver:cvs@happy.kiev.ua:/cvs co flowd Причина одна - зачем использовать чужое, если можно написать свое ненамного хуже? ;-) Соответственно, там есть то, что мне нужно (snmp, perl hooks и т.п.), в остальном - простой как угол дома (что, btw, положительно сказывается на эффективности и надежности). Недостатков гораздо больше, главный из которых - практически полное отсутствие документации. Другой существенный недостаток - поддерживаются только netflow версий 1 и 5. В общем, глянуть можешь, советовать использовать в production не рискну. :) -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message