netflow коллектор какой лучше
Mikhail
Подскажите пожалуйста, у кого есть опыт, какой коллектор лучше использовать?
Присмотрел пока
Flowc http://netacad.kiev.ua/flowc/index_ru.php?id=6
NeTAMS http://www.netams.com/doc/doc_work.html
NeTraMet
FlowScan
Первый попробывал... не понравилось... сыроват и не очень удобен...
На счет остальных не знаю, поэтому и прошу вашего совета...
В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была бы веб
морда.
Спасибо за внимание.
Slawa Olhovchenkov
25 May 05, Mikhail writes to All:
M> Первый попробывал... не понравилось... сыроват и не очень удобен...
M> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle)
У тебя что, трафика нету?
... Рецессивная аллель влияет на фенотип, только когда генотип гомозиготен
Sergey Y. Afonin
> NeTAMS http://www.netams.com/doc/doc_work.html
>
> Первый попробывал... не понравилось... сыроват и не очень удобен...
> На счет остальных не знаю, поэтому и прошу вашего совета...
> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была бы веб
> морда.
Проблема в том, что я пробовал только NeTAMS и только с libpcap. Потому тоже
не сравню. Но все перечисленное (mysql и web-морда) есть. Работает. Правда
не пробовал администрирование через web.
--
С уважением,
Сергей Афонин.
asy*kraft-s.ru
Mikhail
>> Первый попробывал... не понравилось... сыроват и не очень удобен...
>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была бы
>> веб морда.
SA> Проблема в том, что я пробовал только NeTAMS и только с libpcap. Потому
SA> тоже не сравню. Hо все перечисленное (mysql и web-морда) есть. Работает.
И как по ресурсам? А трафик большой ? И база сколько места занимает?
Mikhail
M>> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle)
SO> У тебя что, трафика нету?
Почему же, есть... А к чему этот вопрос?
Предполагаю, что не нравиться именно наличие базы данных, или что то еще?
Maxim Basunov
Тут недавно, 26 Май 05 06:53, пролетала мессага Mikhail для Sergey_Afonin:
>>> NeTAMS http://www.netams.com/doc/doc_work.html
>>> Первый попробывал... не понравилось... сыроват и не очень удобен...
>>> Hа счет остальных не знаю, поэтому и прошу вашего совета...
>>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была
>>> бы веб морда.
SA>> Проблема в том, что я пробовал только NeTAMS и только с libpcap.
SA>> Потому тоже не сравню. Hо все перечисленное (mysql и web-морда) есть.
SA>> Работает.
M> И как по ресурсам? А трафик большой ? И база сколько места занимает?
Hу сам посчитай. у меня голых флов-pекоpдов 200к. pазмеp стpоки в базе - 60
байт. Умножай. 12М. Ах, да, забыл еще сказать - это только за 10 минут...
Dixi.
WBR, Maxim. [Team - Компьютер должен работать, а человек отдыхать]
Gennady Abramov
M> Подскажите пожалуйста, у кого есть опыт, какой коллектор лучше
M> использовать? Присмотрел пока
M> Flowc http://netacad.kiev.ua/flowc/index_ru.php?id=6
M> NeTAMS http://www.netams.com/doc/doc_work.html
M> NeTraMet
^^^^^^ Пятая версия - неработоспособна; документация ублюдочна,
функциональностью не блещет.
M> FlowScan
^^^^^^^Это вообще не коллектор
M> Первый попробывал... не понравилось... сыроват и не очень удобен...
M> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была бы
M> веб морда.
Так тебе коллектор, или аггрегатор, или некое billing/monitoring solution?
Если коллектор, и дисковых ресурсов для твоих объемов хватает - рекомендую
flow-tools, http://www.splintered.net/sw/flow-tools/ .
Там наличествует большинство необходимого инструментария для обработки netflow
/создания отчетов/ etc для различных задач.
Касательно веб-морды... Все зависит от того, что ты хочешь видеть:) Это может
быть flow-scan, либо - с помощью самописных скриптов отдавание результатов
flow-report в SQL и далее по тексту.
/BeSD wishes
Nick 'TARANTUL' Novikov
> Здраствуйте.
>
> Подскажите пожалуйста, у кого есть опыт, какой коллектор лучше использовать?
> Присмотрел пока
> Flowc http://netacad.kiev.ua/flowc/index_ru.php?id=6
Кривее программы я еще не встречал.
> NeTAMS http://www.netams.com/doc/doc_work.html
> NeTraMet
> FlowScan
flow-tools + все что можно прикрутить сверху.
--
TARANTUL
Maxim Basunov
Тут недавно, 26 Май 05 12:59, пролетала мессага Gennady Abramov для Mikhail:
M>> Подскажите пожалуйста, у кого есть опыт, какой коллектор лучше
M>> использовать? Присмотрел пока
M>> Flowc http://netacad.kiev.ua/flowc/index_ru.php?id=6
M>> NeTAMS http://www.netams.com/doc/doc_work.html
M>> NeTraMet
GA> ^^^^^^ Пятая версия - неработоспособна; документация ублюдочна,
GA> функциональностью не блещет.
M>> FlowScan
GA> ^^^^^^^Это вообще не коллектор
M>> Первый попробывал... не понравилось... сыроват и не очень удобен...
M>> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была
M>> бы веб морда.
GA> Так тебе коллектор, или аггрегатор, или некое billing/monitoring solution?
А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
Evgeniy Kozhuhovskiy
а только заданный (a-la netflow)?
--
WBR, Evgeniy Kozhuhovskiy
RCPT TO: e.kozhuhovskiy(at)gmail.com ICQ: 21161835
JID: ug...@jabber.org.by URL: ugenk.bas-net.by
Aleksey Fedorov
At 27 May 05 13:23:12, Evgeniy Kozhuhovskiy wrote to All:
EK> Возможно ли заставить cisco отдавать radius`у в alive/stop пакетах не
EK> весь траффик,
EK> а только заданный (a-la netflow)?
Такие возможности заложены в Intelligent Service Gateway (ISG),
но иосы с этой фичей будут доступны, насколько я знаю, только в районе
сентября.
--
Aleksey
Slawa Olhovchenkov
26 May 05, Mikhail writes to Slawa Olhovchenkov:
M>>> Первый попробывал... не понравилось... сыроват и не очень удобен...
M>>> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M>>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle)
SO>> У тебя что, трафика нету?
M> Почему же, есть... А к чему этот вопрос?
M> Предполагаю, что не нравиться именно наличие базы данных, или что то
M> еще?
Потому что тогда база сдохнет от объема.
У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду или 50
миллионов в сутки.
... Паскаль-программы существуют только для того, чтобы их читали!
Yan Alexandrovsky
27 Май 05 17:26, Slawa Olhovchenkov -> Mikhail:
M>> Почему же, есть... А к чему этот вопрос?
M>> Предполагаю, что не нравиться именно наличие базы данных, или что
M>> то еще?
SO> Потому что тогда база сдохнет от объема.
SO> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
SO> или 50 миллионов в сутки.
500 записей в секунду, причем когда отложенная запись устраивает - это не много
в общем-то. Вопрос лишь в том, нужно ли это :)
До свидания, Yan.
Alexey G Misyuremko
А если сюда еще приплюсовать ситуации когда, кто нибуть в сети поймает
трояна с поведением как сламера .....
Evgeniy Kozhuhovskiy
EK>> Возможно ли заставить cisco отдавать radius`у в alive/stop пакетах
EK>> не весь траффик, а только заданный (a-la netflow)?
AF> Такие возможности заложены в Intelligent Service Gateway (ISG), но
AF> иосы с этой фичей будут доступны, насколько я знаю, только в районе
AF> сентября.
Ура! :) Кстати, вопрос тупого чайника. Эти иосы можно будет поставить на весь
модельный ряд? (5400 в частности)
Slawa Olhovchenkov
27 May 05, Yan Alexandrovsky writes to Slawa Olhovchenkov:
M>>> Почему же, есть... А к чему этот вопрос?
M>>> Предполагаю, что не нравиться именно наличие базы данных, или что
M>>> то еще?
SO>> Потому что тогда база сдохнет от объема.
SO>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
SO>> или 50 миллионов в сутки.
YA> 500 записей в секунду, причем когда отложенная запись устраивает - это
YA> не много в общем-то.
Причем тут отложенная запись, если вопрос в том, что через год записей будет 15
миллиардов?
YA> Вопрос лишь в том, нужно ли это :)
Человеку хочется. Мне -- нет.
... И было у него тpи сына. Один умный, втоpой дуpак, а тpетий вообще фидошник.
Aleksey Fedorov
At 27 May 05 18:58:08, Evgeniy Kozhuhovskiy wrote to Aleksey Fedorov:
EK>>> Возможно ли заставить cisco отдавать radius`у в alive/stop пакетах
EK>>> не весь траффик, а только заданный (a-la netflow)?
AF>> Такие возможности заложены в Intelligent Service Gateway (ISG), но
AF>> иосы с этой фичей будут доступны, насколько я знаю, только в районе
AF>> сентября.
EK> Ура! :) Кстати, вопрос тупого чайника. Эти иосы можно будет поставить на
EK> весь
EK> модельный ряд? (5400 в частности)
Hет конечно. Это для broadband. Т.е. модельный ряд 7200/7300/10k.
--
Aleksey
Maxim Basunov
Тут недавно, 27 Май 05 18:18, пролетала мессага Yan Alexandrovsky для Slawa
Olhovchenkov:
M>>> Почему же, есть... А к чему этот вопрос?
M>>> Предполагаю, что не нравиться именно наличие базы данных, или что
M>>> то еще?
SO>> Потому что тогда база сдохнет от объема.
SO>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
SO>> или 50 миллионов в сутки.
YA> 500 записей в секунду, причем когда отложенная запись устраивает - это не
YA> много в общем-то. Вопрос лишь в том, нужно ли это :)
Гм. Минимальный набоp интеpфейсов пpохождения тpаффика. Лишний тpаффик отсечен
топологией и не допущен в кошку... Пpи всем пpи этом у меня в сpеднем по
330-350 з/с и будет pасти.
За неимением лучшего ваpианта - хpаню сыpые записи в файлах по 10 минут на
толстых винтах - чтобы можно было посмотpеть сыpую инфоpмацию, когда
понадобится. Собственно, вся инфоpмация аггpегиpуется на общих пpинципах по
абонентам и на выходе получается 200-300 записей в БД.
Maxim Basunov
Тут недавно, 28 Май 05 00:32, пролетала мессага Slawa Olhovchenkov для Yan
Alexandrovsky:
M>>>> Почему же, есть... А к чему этот вопрос?
M>>>> Предполагаю, что не нравиться именно наличие базы данных, или что
M>>>> то еще?
SO>>> Потому что тогда база сдохнет от объема.
SO>>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
SO>>> или 50 миллионов в сутки.
YA>> 500 записей в секунду, причем когда отложенная запись устраивает - это
YA>> не много в общем-то.
SO> Причем тут отложенная запись, если вопрос в том, что через год записей
SO> будет 15 миллиардов?
Ты не повеpишь - человеку хочется тоpмознуть кpутейший сан с оpаклом и с
внешним FC накопителем на кучу теpабайт.
ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в одной
таблице за счет многоуpовневого pазбиения на pазделы - всё остальное извpат.
фpивеpные БД издохнут не pодившись. Интеpбейз валится на объеме в несколько
миллионов записей в таблице (около 3-4).
Maxim Basunov
Тут недавно, 27 Май 05 18:50, пролетала мессага Alexey G Misyuremko для Yan
Alexandrovsky:
>> M>> Почему же, есть... А к чему этот вопрос?
>> M>> Предполагаю, что не нравиться именно наличие базы данных, или что
>> M>> то еще?
>> SO> Потому что тогда база сдохнет от объема.
>> SO> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
>> SO> или 50 миллионов в сутки.
>>
>> 500 записей в секунду, причем когда отложенная запись устраивает - это не
>> много
>> в общем-то. Вопрос лишь в том, нужно ли это :)
AGM> А если сюда еще приплюсовать ситуации когда, кто нибуть в сети поймает
AGM> трояна с поведением как сламера .....
У меня в тот момент объем нетфлов выpос пятикpатно, но тогда пpинимал еще по
50-100 ф/с.
Constantin Stefanov
> SO>>> Потому что тогда база сдохнет от объема.
> SO>>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
> SO>>> или 50 миллионов в сутки.
> YA>> 500 записей в секунду, причем когда отложенная запись устраивает - это
> YA>> не много в общем-то.
>
> SO> Причем тут отложенная запись, если вопрос в том, что через год записей
> SO> будет 15 миллиардов?
>
> Ты не повеpишь - человеку хочется тоpмознуть кpутейший сан с оpаклом и с
> внешним FC накопителем на кучу теpабайт.
>
> ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в одной
> таблице за счет многоуpовневого pазбиения на pазделы - всё остальное извpат.
> фpивеpные БД издохнут не pодившись. Интеpбейз валится на объеме в несколько
> миллионов записей в таблице (около 3-4).
73507895
База - PostgreSQL. Не особо напрягается. Не миллиарды, конечно, да и
скорость небольшая - это данные чуть меньше чем за четыре месяца ( с
начала февраля). Так что жить можно. Хотя из такого объема выборки
делать в реальном времени тяжело - для этих целей есть отдельная таблица
с уже агрегированными значениями.
--
Константин Стефанов
Gennady Abramov
>> SO>>> Потому что тогда база сдохнет от объема.
>> SO>>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в секунду
>> SO>>> или 50 миллионов в сутки.
>> YA>> 500 записей в секунду, причем когда отложенная запись устраивает -
>> это YA>> не много в общем-то.
>>
>> SO> Причем тут отложенная запись, если вопрос в том, что через год записей
>> SO> будет 15 миллиардов?
>>
>> Ты не повеpишь - человеку хочется тоpмознуть кpутейший сан с оpаклом и с
>> внешним FC накопителем на кучу теpабайт.
>>
>> ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в
>> одной таблице за счет многоуpовневого pазбиения на pазделы - всё
>> остальное извpат. фpивеpные БД издохнут не pодившись. Интеpбейз валится
>> на объеме в несколько миллионов записей в таблице (около 3-4).
CS> 73507895
Если это неаггрегированные значения - то с февраля ты , получается, прокачал
через себя порядка 50Гб, что , безусловно, очень смешные значения.
CS> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно, да и
CS> скорость небольшая - это данные чуть меньше чем за четыре месяца ( с
CS> начала февраля). Так что жить можно. Хотя из такого объема выборки
CS> делать в реальном времени тяжело - для этих целей есть отдельная таблица
CS> с уже агрегированными значениями.
И - тем не менее - а зачем?
Почему - при несильно больших объемах - нельзя хранить данные в
компрессированных raw бинарниках, а в базу лить только "уже аггрегированные
значения"?
Тем более , что делать аггрегацию силами базы , мягко говоря, неоптимальное
решение задачи при даже небольших объемах.
/BeSD wishes
Gennady Abramov
M>>> Подскажите пожалуйста, у кого есть опыт, какой коллектор лучше
M>>> использовать? Присмотрел пока
M>>> Flowc http://netacad.kiev.ua/flowc/index_ru.php?id=6
M>>> NeTAMS http://www.netams.com/doc/doc_work.html
M>>> NeTraMet
GA>> ^^^^^^ Пятая версия - неработоспособна; документация ублюдочна,
GA>> функциональностью не блещет.
M>>> FlowScan
GA>> ^^^^^^^Это вообще не коллектор
M>>> Первый попробывал... не понравилось... сыроват и не очень удобен...
M>>> Hа счет остальных не знаю, поэтому и прошу вашего совета...
M>>> В идеале хотелось бы чтобы все хранилось в базе (mysql, oracle) и была
M>>> бы веб морда.
GA>> Так тебе коллектор, или аггрегатор, или некое billing/monitoring
MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
В зависимости от желаемого - flow-tools (flow-report, flow-stat, flow-nfilter,
flow-tag). FlowScan. Perl. PHP. *SQL . Руки.
/BeSD wishes
Constantin Stefanov
> >> ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в
> >> одной таблице за счет многоуpовневого pазбиения на pазделы - всё
> >> остальное извpат. фpивеpные БД издохнут не pодившись. Интеpбейз валится
> >> на объеме в несколько миллионов записей в таблице (около 3-4).
> CS> select count(*) from ip_accounting
> CS> 73507895
> Если это неаггрегированные значения - то с февраля ты , получается, прокачал
> через себя порядка 50Гб, что , безусловно, очень смешные значения.
> CS> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно, да и
> CS> скорость небольшая - это данные чуть меньше чем за четыре месяца ( с
> CS> начала февраля). Так что жить можно. Хотя из такого объема выборки
> CS> делать в реальном времени тяжело - для этих целей есть отдельная таблица
> CS> с уже агрегированными значениями.
> И - тем не менее - а зачем?
> Почему - при несильно больших объемах - нельзя хранить данные в
> компрессированных raw бинарниках, а в базу лить только "уже аггрегированные
> значения"?
> Тем более , что делать аггрегацию силами базы , мягко говоря, неоптимальное
> решение задачи при даже небольших объемах.
учет. уже сейчас я думаю именно так и поступить - хранить первичные
данные от netflow, а в базу - только аггрегированные таблицы для показа
через веб. Правда, когда руки дойдут - пока и так работает. Я это к
тому, что даже ьесплатная база вполне может выдержать таблицу с
десятками миллионов записей. То, что такое решение неоптимально -
видимо, я с этим соглашусь.
--
Константин Стефанов
Dark Elf
30 May 05 22:05, Gennady Abramov wrote to Constantin Stefanov:
CS>> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно,
CS>> да и скорость небольшая - это данные чуть меньше чем за четыре
CS>> месяца ( с начала февраля). Так что жить можно. Хотя из такого
CS>> объема выборки делать в реальном времени тяжело - для этих целей
CS>> есть отдельная таблица с уже агрегированными значениями.
GA> И - тем не менее - а зачем?
GA> Почему - при несильно больших объемах - нельзя хранить данные в
GA> компрессированных raw бинарниках, а в базу лить только "уже
GA> аггрегированные значения"? Тем более , что делать аггрегацию силами
GA> базы , мягко говоря, неоптимальное решение задачи при даже небольших
GA> объемах.
Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её сpедствами. Всё
таки она заточена под это...
║ за 20 дней отдыха в Сочи мне было хорошо 34 раза... (девушка, 22 года).
Best regards! Dark Elf
Dark Elf
28 May 05 01:32, Slawa Olhovchenkov wrote to Yan Alexandrovsky:
M>>>> Почему же, есть... А к чему этот вопрос?
M>>>> Предполагаю, что не нравиться именно наличие базы данных, или
M>>>> что то еще?
SO>>> Потому что тогда база сдохнет от объема.
SO>>> У меня поток netflow -- 200Kbit/s. Это порядка 500 записей в
SO>>> секунду или 50 миллионов в сутки.
YA>> 500 записей в секунду, причем когда отложенная запись устраивает
YA>> - это не много в общем-то.
SO> Причем тут отложенная запись, если вопрос в том, что через год записей
SO> будет 15 миллиардов?
Эээ. Hу если за последний месяц деpжать все записи, каждый день суточный лог
месячной давности подитоживать и класть в дpугую базу... То вполне ноpмально,
так то...
║ - Мы живём в свободной стране.
║ В том смысле, что она ничем особенным не занята.
Best regards! Dark Elf
Slawa Olhovchenkov
31 May 05, Dark Elf writes to Gennady Abramov:
GA>> Почему - при несильно больших объемах - нельзя хранить данные в
GA>> компрессированных raw бинарниках, а в базу лить только "уже
GA>> аггрегированные значения"? Тем более , что делать аггрегацию силами
GA>> базы , мягко говоря, неоптимальное решение задачи при даже небольших
GA>> объемах.
DE> Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её сpедствами.
DE> Всё таки она заточена под это...
Выкинь маркетинговые мурзилки. Базы под это не заточены.
... Да освятится имя твое и pасшиpение твое, Господи...
Dark Elf
31 May 05 12:29, Slawa Olhovchenkov wrote to Dark Elf:
GA>>> Почему - при несильно больших объемах - нельзя хранить данные в
GA>>> компрессированных raw бинарниках, а в базу лить только "уже
GA>>> аггрегированные значения"? Тем более , что делать аггрегацию
GA>>> силами базы , мягко говоря, неоптимальное решение задачи при
GA>>> даже небольших объемах.
DE>> Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её
DE>> сpедствами. Всё таки она заточена под это...
SO> Выкинь маркетинговые мурзилки. Базы под это не заточены.
Эээ. Сpоду не читал маpкетинговых муpзилок. Исключительно на личном опыте.
Самое пpостое и достаточно гибкое pешение - лог pаспаpсить и заслать в базу,
из котоpой можно всё и смотpеть. По истечении актуальности подpобного лога он
суммиpуется сpедствами той же СУБД и ложится туда же.
║ Под дубом гpустно я сидел, невзpачен, мал, пузат...
Best regards! Dark Elf
Slawa Olhovchenkov
31 May 05, Dark Elf writes to Slawa Olhovchenkov:
GA>>>> Почему - при несильно больших объемах - нельзя хранить данные в
GA>>>> компрессированных raw бинарниках, а в базу лить только "уже
GA>>>> аггрегированные значения"? Тем более , что делать аггрегацию
GA>>>> силами базы , мягко говоря, неоптимальное решение задачи при
GA>>>> даже небольших объемах.
DE>>> Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её
DE>>> сpедствами. Всё таки она заточена под это...
SO>> Выкинь маркетинговые мурзилки. Базы под это не заточены.
DE> Эээ. Сpоду не читал маpкетинговых муpзилок. Исключительно на личном
DE> опыте.
Поздно отмазываться.
... А я подкpался незаметно! (c) СамиЗнаетеКто
Dark Elf
31 May 05 13:38, Slawa Olhovchenkov wrote to Dark Elf:
GA>>>>> Почему - при несильно больших объемах - нельзя хранить данные
GA>>>>> в компрессированных raw бинарниках, а в базу лить только "уже
GA>>>>> аггрегированные значения"? Тем более , что делать аггрегацию
GA>>>>> силами базы , мягко говоря, неоптимальное решение задачи при
GA>>>>> даже небольших объемах.
DE>>>> Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её
DE>>>> сpедствами. Всё таки она заточена под это...
SO>>> Выкинь маркетинговые мурзилки. Базы под это не заточены.
DE>> Эээ. Сpоду не читал маpкетинговых муpзилок. Исключительно на
DE>> личном опыте.
SO> Поздно отмазываться.
Эээ. Даже не замечен ;-)
║ Это серьезная травма не только для человека, но и для футболиста.
Best regards! Dark Elf
Alexey G Misyuremko
Везет, а мои кастомеры умудрялись породить netscan в 20-30kpps.
Конечно, можно было отсечь flow динною в один пакет и не инчертить их в базу, но
схема "здесь играть, здесь нет, а там рыбу заворачивать..." Посему ушли
на схему с хранием дампов в сыром виде и значения клиенских счетчиков (часовых и дневных) в базе.
В случае несогласия со стороны клиента - можно всегда раскруить дам
и показать все до байтика (ну или почти все :/ )
Victor Sudakov
> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
> В зависимости от желаемого - flow-tools (flow-report, flow-stat, flow-nfilter,
Я так и не нашел в flow-tools средств для того, чтобы посмотреть
распределение трафика по часам/минутам/дням... Приходится делать через
"flow-print | awk", но возможно я что-то пропустил?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Max Mukin
VS> Gennady Abramov wrote:
>> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
>> В зависимости от желаемого - flow-tools (flow-report, flow-stat, flow-nfilter,
VS>
VS> Я так и не нашел в flow-tools средств для того, чтобы посмотреть
VS> распределение трафика по часам/минутам/дням... Приходится делать через
VS> "flow-print | awk", но возможно я что-то пропустил?
flow-cat [-t start_time] [-T start_time]
Или надо именно распределение по дням/часам ?
Victor Sudakov
>>> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
>>> В зависимости от желаемого - flow-tools (flow-report, flow-stat, flow-nfilter,
> VS>
> VS> Я так и не нашел в flow-tools средств для того, чтобы посмотреть
> VS> распределение трафика по часам/минутам/дням... Приходится делать через
> VS> "flow-print | awk", но возможно я что-то пропустил?
> flow-cat [-t start_time] [-T start_time]
> Или надо именно распределение по дням/часам ?
Да, нужно именно распределение.
Хочу, например, знать, на какое время суток или на какой день недели
приходится пик почтового трафика. Явно не хватает еще парочки отчётов
у flow-stat.
Gennady Abramov
VS> Gennady Abramov wrote:
>> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
>> В зависимости от желаемого - flow-tools (flow-report, flow-stat,
>> flow-nfilter,
VS> распределение трафика по часам/минутам/дням... Приходится делать через
VS> "flow-print | awk", но возможно я что-то пропустил?
Пропустил. flow-report, flow-stat. Для выбирания по времени - flow-nfilter,
или выбирать нужный бинарник нетфлоу. Для аггрегированной статистики по
определяемым тобой сетям - flow-tag.
/BeSD wishes
Gennady Abramov
>> >> ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в
>> >> одной таблице за счет многоуpовневого pазбиения на pазделы - всё
>> >> остальное извpат. фpивеpные БД издохнут не pодившись. Интеpбейз
>> валится
>> >> на объеме в несколько миллионов записей в таблице (около 3-4).
>> CS> select count(*) from ip_accounting
>> CS> 73507895
>> Если это неаггрегированные значения - то с февраля ты , получается,
>> прокачал через себя порядка 50Гб, что , безусловно, очень смешные
>> значения.
>> CS> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно, да и
>> CS> скорость небольшая - это данные чуть меньше чем за четыре месяца ( с
>> CS> начала февраля). Так что жить можно. Хотя из такого объема выборки
>> CS> делать в реальном времени тяжело - для этих целей есть отдельная
>> таблица
>> CS> с уже агрегированными значениями.
>> И - тем не менее - а зачем?
>> Почему - при несильно больших объемах - нельзя хранить данные в
>> компрессированных raw бинарниках, а в базу лить только "уже
>> аггрегированные значения"?
>> Тем более , что делать аггрегацию силами базы , мягко говоря,
>> неоптимальное решение задачи при даже небольших объемах.
CS> учет. уже сейчас я думаю именно так и поступить - хранить первичные
CS> данные от netflow, а в базу - только аггрегированные таблицы для показа
CS> через веб. Правда, когда руки дойдут - пока и так работает. Я это к
CS> тому, что даже ьесплатная база вполне может выдержать таблицу с
CS> десятками миллионов записей. То, что такое решение неоптимально -
CS> видимо, я с этим соглашусь.
"Выдержать таблицу" - да. Хотя я бы не стал рисковать. А сколько времени на
мощной машинке PostgreSQL обработает запрос на предмет суммирования пары
милионов записей из этих десятков милионов, попадающих в ту или иную сеть?
И смысл тогда вообще в сборе этой статистики и в существовании этой базы?
/BeSD wishes
Gennady Abramov
CS>>> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно,
CS>>> да и скорость небольшая - это данные чуть меньше чем за четыре
CS>>> месяца ( с начала февраля). Так что жить можно. Хотя из такого
CS>>> объема выборки делать в реальном времени тяжело - для этих целей
CS>>> есть отдельная таблица с уже агрегированными значениями.
GA>> И - тем не менее - а зачем?
GA>> Почему - при несильно больших объемах - нельзя хранить данные в
GA>> компрессированных raw бинарниках, а в базу лить только "уже
GA>> аггрегированные значения"? Тем более , что делать аггрегацию силами
GA>> базы , мягко говоря, неоптимальное решение задачи при даже небольших
GA>> объемах.
DE> Всё таки она заточена под это...
То, что база заточена под хранение табличных данных , еще не говорит о том,
что любые данные целесообразно в нее класть. В добавок с битовые операции в
количестве делать средствами базы уже будет мягко говоря неоптимально.
/BeSD wishes
Constantin Stefanov
например, в свое время машины, зараженные msblast, ловил). Да, запросы
выполняются долго. Но из сырых данных в бинарниках они тоже будут не
быстрые. А пользователям показываются данные из другой таблицы, где все
в аггрегированном состоянии. А по той таблице - чуть больше, чем 4,2
миллиона записей, почасовые данные для каждого адреса из сети /24 на
вход и выход, пакеты и байты, с апреля 2003 года, суммирование с
группировкой по адресу выполняется за 67 секунд. Надо бы ужать
детализацию до суток, да никак руки не дойдут.
--
Константин Стефанов
Victor Sudakov
> >> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
> >> В зависимости от желаемого - flow-tools (flow-report, flow-stat,
> >> flow-nfilter,
> VS> Я так и не нашел в flow-tools средств для того, чтобы посмотреть
> VS> распределение трафика по часам/минутам/дням... Приходится делать через
> VS> "flow-print | awk", но возможно я что-то пропустил?
> Пропустил. flow-report, flow-stat.
Регулярно пользуюсь. Но отчетов по временному распределению трафика в
них нет.
> Для выбирания по времени - flow-nfilter,
> или выбирать нужный бинарник нетфлоу.
И всё это обвязать снаружи скриптом, который будет перебирать нужные
бинарники или параметры flow-nfilter? А потом объединять вывод сотни
flow-report ? Нет уж, через "flow-print | awk" и то проще получается.
> Для аггрегированной статистики по
> определяемым тобой сетям - flow-tag.
Этим никогда не пользовался, хватало flow-nfilter.
Alexey Milevsky
>И все это обвязать снаружи скриптом, который будет перебирать нужные
>бинарники или параметры flow-nfilter? А потом объединять вывод сотни
>flow-report ? Нет уж, через "flow-print | awk" и то проще получается.
зная, что FreeBSD Вам не чужда, попробую предложить
/usr/ports/net-mgmt/flow-extract...
--
A1ex.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Dark Elf
01 Jun 05 14:51, Gennady Abramov wrote to Dark Elf:
CS>>>> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно,
CS>>>> да и скорость небольшая - это данные чуть меньше чем за четыре
CS>>>> месяца ( с начала февраля). Так что жить можно. Хотя из такого
CS>>>> объема выборки делать в реальном времени тяжело - для этих
CS>>>> целей есть отдельная таблица с уже агрегированными значениями.
GA>>> И - тем не менее - а зачем?
GA>>> Почему - при несильно больших объемах - нельзя хранить данные в
GA>>> компрессированных raw бинарниках, а в базу лить только "уже
GA>>> аггрегированные значения"? Тем более , что делать аггрегацию
GA>>> силами базы , мягко говоря, неоптимальное решение задачи при
GA>>> даже небольших объемах.
DE>> Кхем. Как pаз оптимальней хpанить в базе и обpабатывать её
DE>> сpедствами. Всё таки она заточена под это...
GA> То, что база заточена под хранение табличных данных , еще не говорит о
GA> том, что любые данные целесообразно в нее класть. В добавок с битовые
GA> операции в количестве делать средствами базы уже будет мягко говоря
GA> неоптимально.
Хм... Вообще-то вполне логично, если данные пеpед помещением в базу надо
подготовить. Посему это я не упоминал. К тому же 90% pезультата будет зависит
от оpганизации таблиц.
║ Q47: а где нетварь?
║ A47: скоро должна сдохнуть.
Best regards! Dark Elf
Victor Sudakov
>
>>И все это обвязать снаружи скриптом, который будет перебирать нужные
>>бинарники или параметры flow-nfilter? А потом объединять вывод сотни
>>flow-report ? Нет уж, через "flow-print | awk" и то проще получается.
> зная, что FreeBSD Вам не чужда, попробую предложить
> /usr/ports/net-mgmt/flow-extract...
Иногда пользуюсь, когда лень описывать нужное в конфиге flow-nfilter.
Но оно, опять же, позволяет сделать _выборку_ в том числе по времени,
но не статистику в зависимости от времени.
Получить netflow за определенный промежуток времени - нет никакой
проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
_анализа_ в зависимости от временной оси.
Viktor Fomichev
> Alexey Milevsky wrote:
>
>>>И все это обвязать снаружи скриптом, который будет перебирать нужные
>>>бинарники или параметры flow-nfilter? А потом объединять вывод сотни
>>>flow-report ? Нет уж, через "flow-print | awk" и то проще получается.
>>
>>зная, что FreeBSD Вам не чужда, попробую предложить
>>/usr/ports/net-mgmt/flow-extract...
>
>
> Иногда пользуюсь, когда лень описывать нужное в конфиге flow-nfilter.
> Но оно, опять же, позволяет сделать _выборку_ в том числе по времени,
> но не статистику в зависимости от времени.
>
> Получить netflow за определенный промежуток времени - нет никакой
> проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
> _анализа_ в зависимости от временной оси.
>
>
Victor Sudakov
>> проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
>> _анализа_ в зависимости от временной оси.
>>
>>
> FreeBSD: /usr/ports/net-mgmt/TkTopNеtFlow - смотрел?
Настораживает то, что оно GUI. График построить я и сам могу
gnuplot-ом или екселем, а визуализация в самой программе анализа мне
нафиг не нужна.
Viktor Fomichev
>>>Получить netflow за определенный промежуток времени - нет никакой
>>>проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
>>>_анализа_ в зависимости от временной оси.
>>>
>>FreeBSD: /usr/ports/net-mgmt/TkTopNеtFlow - смотрел?
>
> Настораживает то, что оно GUI. График построить я и сам могу
> gnuplot-ом или екселем, а визуализация в самой программе анализа мне
> нафиг не нужна.
>
а второе - это "сервер представлений" - собственно всю обработку
данных делает именно он. И отдает результат по простому текстовому
протоколу через TCP сокет любой другой программке, которая этого хочет,
и которая сама умеет графики строить.
Впрочем, о пригодности пакета для твоих задач можно будет судить
только есть ты подробнее опишешь свою проблему, и что ты хочешь получить
в результате.
Но это уже, наверное, лучше в частной переписке.
Alexey Milevsky
>Получить netflow за определенный промежуток времени - нет никакой
>проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
>_анализа_ в зависимости от временной оси.
тогда никто лучше Вас не знает Ваших требований к анализу:
/usr/ports/net-mgmt/p5-Cflow - не скажу, что быстро; но гибче - некуда :)
и достаточно просто.
Victor Sudakov
>
>>Получить netflow за определенный промежуток времени - нет никакой
>>проблемы. Сложность - в отсутствии в комплекте flow-tools инструментов
>>_анализа_ в зависимости от временной оси.
> тогда никто лучше Вас не знает Ваших требований к анализу:
> /usr/ports/net-mgmt/p5-Cflow - не скажу, что быстро; но гибче - некуда :)
> и достаточно просто.
Ну, я понимаю, что самому можно написать всё :)
Меня в принципе устраивает "flow-print | awk", а говорил я об
отсутствии _готовых_ средств в комплекте flow-tools.
Gennady Abramov
VS> From: Victor Sudakov <v...@mpeks.tomsk.su>
>> >> MB> А можешь подсказать паpу названий аггpегатоpов/монитоpинга?
>> >> В зависимости от желаемого - flow-tools (flow-report, flow-stat,
>> >> flow-nfilter,
>> VS> Я так и не нашел в flow-tools средств для того, чтобы посмотреть
>> VS> распределение трафика по часам/минутам/дням... Приходится делать через
>> VS> "flow-print | awk", но возможно я что-то пропустил?
>> Пропустил. flow-report, flow-stat.
VS> Регулярно пользуюсь. Hо отчетов по временному распределению трафика в
VS> них нет.
>> Для выбирания по времени - flow-nfilter,
>> или выбирать нужный бинарник нетфлоу.
VS> И всё это обвязать снаружи скриптом, который будет перебирать нужные
VS> бинарники или параметры flow-nfilter? А потом объединять вывод сотни
VS> flow-report ? Hет уж, через "flow-print | awk" и то проще получается.
А чего хочется-то?
С помощью flow-nfilter (Или используя фильтрование в flow-report) можно делать
выборку по времени.
Для хранения распределения по времени в rrd и рисования красивых
картинок/графиков/etc подойдет Dave Plonka's FlowScan.
>> Для аггрегированной статистики по
>> определяемым тобой сетям - flow-tag.
VS> Этим никогда не пользовался, хватало flow-nfilter.
Да, при небольших объемах, и если критериев выборки немного, и они
"одноуровневые" - то вполне.
/BeSD wishes