Jump to content
Калькуляторы

Еще один Netflow-коллектор и анализатор

Если кому-то интересен простой Netflow-коллектор и анализатор, open source, с веб-интерфейсным управлением и просмотром отчетов -

http://xenoeye.com/docs

Анализирует он очень условно, просто фильтрует фловы, агрегирует и показывает, но раз уж такая терминология устоялась, то анализатор.

 

Понятно что это сейчас довольно нишевая штука - в сетях с безлимитами и аццкими скоростями такое ставить почти бессмысленно.

Мы используем его для контроля за трафиком пользователей в подшефных компаниях, это, скорее всего, лучший профиль использования.

 

Плюсы:

Достаточно быстрый, netflow хранится в файлах, агрегированные данные тоже в файлах - Berkeley DB.

Не нужно разворачивать и тюнить СУБД, запустил и заработало.

Управляется веб-интерфейсом, отчеты генерируются тоже веб-интерфейсом.

Разделение отчетов по пользователям - кому-то одни отчеты, кому-то другие, есть публично доступные.

Не RRD-based. Данные хранятся в точности как прилетели, нет округлений и сглаживаний, на старых данных можно строить любые отчеты.

 

Минусы:

Коллектор простой, поддерживаются только Netflow v1 и v5 с IPv4.

Построитель диаграмм тоже не очень сложный. Если нужен какой-то заковыристый график из нескольких источников - он такой построить не сможет.

Веб-интерфейс и коллектор выполняются в одном процессе, если что-то упадет, упадет все (такого, правда, еще не случалось,

но мы у нервных клиентов на всякий случай держим на одном узле по два запущенных коллектора)

Не RRD-based. Если данных много, нужно их периодически удалять.

 

 

В среднесрочной перспективе планируется добавить:

- триггеры;

- возможность из пользовательского интерфейса выполнить внешние скрипты;

- сделать "гиперссылочные" отчеты - ткнул, например в столбик на диаграмме, а он переходит в другой отчет с подробностями;

- добавить "отложенные" отчеты и таблицы, которые не пересчитываются при каждом новом netflow-пакете, а считаются при запросе к отчету,

и потом через какое-то время самоудаляются

Share this post


Link to post
Share on other sites

Есть вот такая штука: http://code.google.com/p/flowd/ . Коллектор умеет v5/v9 (то есть +ipv6), а позитивен тем, что может отдавать в unix-сокет распарсенные фловы, что позволяет у себя в софте не заморачиваться парсингом N протоколов.

 

Можно было упростить себе жизнь и использовать его. Я, в принципе, могу поделиться частью кода, который из этого сокета читает фловы, если есть желание.

 

Единственное, что хочется понять - под какой лицензией живет существующий код :)

Share this post


Link to post
Share on other sites

Есть вот такая штука: http://code.google.com/p/flowd/ . Коллектор умеет v5/v9 (то есть +ipv6), а позитивен тем, что может отдавать в unix-сокет распарсенные фловы, что позволяет у себя в софте не заморачиваться парсингом N протоколов.

 

Можно было упростить себе жизнь и использовать его. Я, в принципе, могу поделиться частью кода, который из этого сокета читает фловы, если есть желание.

 

Единственное, что хочется понять - под какой лицензией живет существующий код :)

 

Да можно сделать поддержку v9 (и IPv6) прямо в коллекторе, без привлечения внешних утилит. Просто у нас даже оборудования нет, которое его умеет отдавать, да и IPv6 нет. То есть нам пока это не нужно. Ну, можно, наверное, стенд какой-то сделать, поставить softflowd сенсором, но это же делать надо :-)

 

Лицензия - ISC, это фактически BSD, можете делать с кодом что хотите. Но используется Oracle Berkeley DB, у них какая-то драконовская лицензия, использовать можно только в open source проектах. Возможно (а возможно и нет) мы что-то будем думать с этим, заменять Berkeley DB чем-то другим, например, но пока тоже не до этого

Share this post


Link to post
Share on other sites

Коллектор должен быть надежным и стабильным. Любой его сбой приводит к потери критических данных.

Вебинтерфейс должен быть с переделками и свистелками. Какой смысл объединения коллектора и анализатора?

Share this post


Link to post
Share on other sites

Коллектор должен быть надежным и стабильным. Любой его сбой приводит к потери критических данных.

Вебинтерфейс должен быть с переделками и свистелками. Какой смысл объединения коллектора и анализатора?

 

Так получилось, э-э, исторически. Задумывалось все красиво и модульно, конечно.

Вот коллектор, вот интерфейс, они по IPC друг с другом общаются.

Но после того как начали программировать выяснилось что не все так просто. IPC решили заменить на сетевой обмен данными и сообщениями.

Логично было не выдумывать свой протокол обмена, а использовать HTTP. Так в коллекторе появился собственно HTTP сервер.

Потом, чтоб не париться с написанием отдельного интерфейса, решили управление (временно) делать прямо этим вебсервером.

Ну а потом уже стало проще добавить туда показ отчетов и вообще забыть про отдельный веб-интерфейс.

 

Возможно, если будет свободное время, или нужно будет обеспечить какую-то повышенную надежность, мы к этому вернемся и вынесем интерфейс отдельно.

Там, в общем-то все для этого есть - более-менее унифицированный AJAX, то есть работы не так уж много.

Но, как я уже написал, сейчас проще запускать два коллектора для надежности. Да и в таком виде нас все устраивает, нет никакой мороки с разворачиванием веб-серверов,

их настройкой, просто собрал, запустил, заработало.

 

Сейчас мы планируем делать порт под Windows - там что делать? Таскать с собой nginx с PHP? Или apache с tomkat'ом? Это же инсталлятор какой-то адовый делать, получать лучи проклятий от пользователей. А карма-то одна. То есть если сильно нужно будет, сделаем, конечно, но пока вот так

Share this post


Link to post
Share on other sites

Вот коллектор, вот интерфейс, они по IPC друг с другом общаются.

Нафига им общаться?

Коллектор - вот он, получил данные, сагрегировал их если надо и пихнул в БД. Интерфейс - отдельно, выгреб из БД данные, переварил и выплюнул. БД - отдельно (тоже не стоит изобретать велосипед, заюзать ту же постгрю к примеру). Причем в идеале коллектор живет отдельно, высокодоступная (кластеризированная) СУБД - отдельно, веб-морда - вообще нафиг вынесена туда, где ддос или еще какой катаклизЬм не зацепят критических сервисов.

Где тут место для IPC?

Share this post


Link to post
Share on other sites

Где тут место для IPC?

Ну, технически, обычный TCP'шный сокет - уже и есть IPC :)

Share this post


Link to post
Share on other sites

Вот коллектор, вот интерфейс, они по IPC друг с другом общаются.

Нафига им общаться?

Коллектор - вот он, получил данные, сагрегировал их если надо и пихнул в БД. Интерфейс - отдельно, выгреб из БД данные, переварил и выплюнул. БД - отдельно (тоже не стоит изобретать велосипед, заюзать ту же постгрю к примеру). Причем в идеале коллектор живет отдельно, высокодоступная (кластеризированная) СУБД - отдельно, веб-морда - вообще нафиг вынесена туда, где ддос или еще какой катаклизЬм не зацепят критических сервисов.

Где тут место для IPC?

 

А. Похоже, я как-то непонятно написал. Такого же навалом, почти все так делают - коллектор пишет в (Р)СУБД (или в текстовые файлы), веб-интерфейс оттуда забирает и визуализирует.

У нас такое тоже было, хранили в том числе и в PostgreSQL. Но это оказалось довольно ресурсозатратно. PostgreSQL, как и все версионники, при обновлении таблиц не "обновляет" их, а дописывает новую версию, то есть до vacuum full (которому нужен exclusive lock) место не высвобождается.

А если хочется хранить фловы, а не только агрегированные данные - вообще туши свет, место жрется, для построения какого-нибудь заковыристого отчета только

sequence scan, ну максимум что-то можно наоптимизировать секционированием.

Вот мы и решили пойти другим путем - сделали такую специализированную микро-СУБД, очень простую, без транзакций, резервирования и сетевого доступа,

но быструю и почти без лишнего расходования дискового пространства.

Эта штука как раз для простых установок, когда не хочется вникать в тонкости работы СУБД, а хочется потыкать в веб-интерфейс, минимально напрячь моск

и чтоб оно само там что-то сразу считало, показывало и при этом не особо сильно загружало компьютер

Share this post


Link to post
Share on other sites

Хорошо, спрошу так - чем ваш коллектор лучше связки nfdump/nfsen ?

 

http://nfsen.sourceforge.net/

 

Да он не лучше или хуже, просто по-другому сделан. nfsen (как и многие другие) - RRD-based, старые данные "сглаживаются".

У нас все хранится как прилетело, удалить можно только руками. Отчеты по старым данным, соответственно, не меняются со временем.

Ну и в целом подход отличается: nfsen (как и многие другие) - Perl, PHP, данные берутся из nfdump, картинки генерируются на сервере, все монументально.

У нас программа на С с встроенным веб-сервером, минимум зависимостей, AJAX, диаграммы немного интерактивные (при наведении мышки показывают подробности),

генерируются в браузере.

Остальное почти то же самое, чему там отличаться - фильтры, поля для агрегации. У нас полей меньше, но мы делали только то что нам нужно.

 

Если вы пользуетесь nfsen (или каким-то своим решением) и это вас устраивает - не надо даже и пробовать,

вам фактически придется после отлаженной системы пробовать такую раннюю альфу, там криво нарисует, здесь что-нибудь еще не так

Share this post


Link to post
Share on other sites

Я не пользуюсь nfsen, я месяц назад поставил nfcapd который пишет файлы. Он использует бинарный формат, к тому же сжимает компрессом.

Когда мне нужно найти информацию по IP я запускаю nfdump c условием "host 1.2.3.4" как в tcpdump и он очень быстро делает выборку.

 

Будет RRD или нет - вопрос скрипта, который должен визуализировать данные. Его можно менять, править ломать не опасаяь за демон и данные.

 

Вы же написали "свой http сервер", "свою базу данных" это конечно очень круто и интересно но боюсь что шаг влево и шаг вправо даст неизлечимое количество багов, т.е. это хорошо для студента с горящими глазами который хочет изменить мир. Но ужасно для админа, которого будут трахать за секунды простоя сервиса.

Share this post


Link to post
Share on other sites

Когда мне нужно найти информацию по IP я запускаю nfdump c условием "host 1.2.3.4" как в tcpdump и он очень быстро делает выборку.

 

 

xenoeye работает немного не так. Вы создаете таблицу, пишете фильтр "(daddr == 1.2.3.4) or (saddr == 1.2.3.4)" и выбираете поля

которые нужны - допустим откуда летело, куда, протокол и сколько пакетов: "saddr, daddr, proto, packets". Выбираете интересующий период (или весь период наблюдений),

периоды за которые будет агрегация (минуты, часы, сутки, месяцы), жмете кнопку и оно строит таблицу.

Если вам нужно постоянно следить за этим адресом, период наблюдений оставляете без даты окончания, таблица будет обновляться как только прилетит netflow-пакет.

Но вообще это мне кажется не очень интересный пример.

Вы можете сделать таблицу из, скажем, адресов подсети и количества байт которые на них прилетают за месяц. Или от них улетают. И это отдавать в виде отчета: таблицей, диаграммой. Или делать еще и разбивку по протоколам. Конечно, это можно получить из любого коллектора, но в xenoeye это делается без всяких мозголомств, из веб-интерфейса, несколько раз ткнул мышкой, набрал две строчки текста и типа готово

 

Вы же написали "свой http сервер", "свою базу данных" это конечно очень круто и интересно но боюсь что шаг влево и шаг вправо даст неизлечимое количество багов, т.е. это хорошо для студента с горящими глазами который хочет изменить мир. Но ужасно для админа, которого будут трахать за секунды простоя сервиса.

Я уже писал, не поленюсь и напишу еще раз - там где трахают за секунды простоя его ставить не надо. Альтернатив - масса. Это для тех кого по разным причинам эти альтернативы не устраивают. Ну вот нас, например, не устраивали (и не только из-за NIH-синдрома), мы набрались мужества, уселись и написали то что нам нужно. Если кто-то хочет пользоваться плодами - пожалуйста, пользуйтесь

Share this post


Link to post
Share on other sites

Вот мы и решили пойти другим путем - сделали такую специализированную микро-СУБД, очень простую, без транзакций, резервирования и сетевого доступа,

но быструю и почти без лишнего расходования дискового пространства.

Зачем ее было прикручивать жестко к коллектору (почему бы ее не вынести по сети, как нормальную СУБД), и чем не устраивали NoSQL СУБД? Сравнение производительности с NoSQL, той же MongoDB?

Share this post


Link to post
Share on other sites

Зачем ее было прикручивать жестко к коллектору

 

А куда ее еще прикручивать? Похоже, слово СУБД смутило. Но я же написал - "микро". Он хранит фловы в файлах (с выравниванием по страницам),

имена файлов - таймстампы, все довольно просто, самое сложное - это разбор фильтров, и выполнение байткода для фильтрации (хотя в этом тоже ничего сложного).

 

почему бы ее не вынести по сети

Ну никто не мешает смонтировать каталог с данными откуда-нибудь из сети (да хоть из люстры), будет вынесено в сеть

 

чем не устраивали NoSQL СУБД

Агрегированные данные и немного всякой служебной ерунды хранятся в Berkeley DB. Я же написал прямо в первом сообщении.

Впрочем, мне не лень еще раз написать

 

Сравнение производительности с NoSQL, той же MongoDB?

А что именно сравнивать? У кого быстрее B-tree реализовано - у MongoDB или Berkeley DB?

Сейчас, в 2013 году, чтобы упереться в производительность CPU на таких задачах надо, наверное, пройти какие-то специальные курсы. Ну, изредка я запускаю callgrind,

основное время расходуется как раз на обновление (агрегированных) записей в Berkeley DB, еще немного на localtime_r, остальное совсем ерунда.

Было бы интереснее сравнить кто больше израсходует дискового пространства :-)

Share this post


Link to post
Share on other sites

Похоже, слово СУБД смутило. Но я же написал - "микро". Он хранит фловы в файлах (с выравниванием по страницам),

имена файлов - таймстампы, все довольно просто, самое сложное - это разбор фильтров, и выполнение байткода для фильтрации (хотя в этом тоже ничего сложного).

Ну если так то да. Однако - вы уверены, что произвольная ФС корректно переварит 100500 мелких файлов, да в одном каталоге, без значительного падения производительности? И какой оверхид будет на хранение записей о файлах?

 

Ну никто не мешает смонтировать каталог с данными откуда-нибудь из сети (да хоть из люстры), будет вынесено в сеть

Скорость однако унылая будет...

 

Агрегированные данные и немного всякой служебной ерунды хранятся в Berkeley DB. Я же написал прямо в первом сообщении.

Угу. Которая намертво прикручена к коллектору. В который из-за этого пришлось тянуть все вплоть до веб-морды. Вместо того, чтобы разделить адекватно мухи и котлеты.

 

А что именно сравнивать? У кого быстрее B-tree реализовано - у MongoDB или Berkeley DB?

Откуда быстрее данные выгрести - с кластера MongoDB или с вашей одиночной базы через вами придуманное API.

 

Было бы интереснее сравнить кто больше израсходует дискового пространства :-)

При цене террабайта менее сотни $ - потенциально масштабируемые системы предпочтительнее, чем монолитные немасштабируемые, даже если и будут менее экономично расходовать место.

Share this post


Link to post
Share on other sites

вы уверены, что произвольная ФС корректно переварит 100500 мелких файлов

 

А, неточно выразился. Там таймстампы со сброшенными последними битами, получается приблизительно файл в день

 

потенциально масштабируемые системы предпочтительнее, чем монолитные немасштабируемые

 

Да, все так, только у нас этому потенциалу негде развернуться.

Мы системные интеграторы, у нас не одна-две инсталляции, которые можно холить и лелеять, а много разных, некоторые вообще никем не поддерживаются. И мы последовательно прошли все эти стадии - "взять какой-то готовый продукт, его допилить под свои нужды", "написать свой, потенциально масштабируемый, но круче чем вот этот весь шлак" и, наконец, осмысление того что нам это все не очень подходит, вся эта потенциальность в большинстве случаев остается только потенциальностью, а ресурсов требует раз в несколько больше.

Я уже писал в первом сообщении, на всякий случай напишу еще раз:

 

Понятно что это сейчас довольно нишевая штука - в сетях с безлимитами и аццкими скоростями такое ставить почти бессмысленно.

Мы используем его для контроля за трафиком пользователей в подшефных компаниях, это, скорее всего, лучший профиль использования.

 

Чтобы разбавить дискуссию цифрами - у нас 1Т трафика (входящего+исходящего) генерирует около 10Г netflow (т.е. съедает столько дискового пространства, мы грубо считаем как 1%). Обычно просто удаляем фловы старше полугода, но если сжимать то с того же 1Т получится около 2Г.

Вот на узле который обрабатывает как раз около 1Т в месяц: Memory usage (grep VmSize /proc/22681/status): 576692 kB, CPU usage не поднимается выше 1%.

Share this post


Link to post
Share on other sites

1T трафик это загрузка канала 10 Мбит.

 

Даже нечего обсуждать!

Share this post


Link to post
Share on other sites

[root@netflow ~]# du -sh /mnt/netflow/

15T /mnt/netflow/

 

Здесь нетфлоу нашего трафика с начала 2012 года. Внешний канал - десятка...

Share this post


Link to post
Share on other sites

[root@netflow ~]# du -sh /mnt/netflow/

15T /mnt/netflow/

 

Здесь нетфлоу нашего трафика с начала 2012 года. Внешний канал - десятка...

А как вообще скорость поиска информации? К примеру типовая задачу - за сутки выделить трафик от/к одному ип адресу?

К примере у нас с одного BRAS:

gawriloff@albatros2 ~ $ du -xh /var/tmp/backup/flows/21-02-2013/rtr9

45G /var/tmp/backup/flows/21-02-2013/rtr9

 

Используем flow-tools-ng и там с этим все печально:

time flow-cat /var/tmp/backup/flows/21-02-2013/ | flow-nfilter -b big -f filter.cfg -F client | flow-print -f 25

real 117m23.177s

user 102m37.970s

Share this post


Link to post
Share on other sites

[root@netflow ~]# du -sh /mnt/netflow/

15T /mnt/netflow/

 

Вот я же несколько раз уже написал: это не провайдерское решение.

То есть можно в него зарядить какие-то тысячи нетфловов в секунду, наверное как-то будет работать, но он не для этого делался.

И на 10Гбитах же все немного не так? Вы же не подробный нетфлоу собираете, какой-то уже слегка агрегированный? sFlow?

Share this post


Link to post
Share on other sites

подробный нетфлоу. Снимается с брасов.

Скорость поиска низкая, но пока устраивает...

 

Вот кстати, я могу ваше решение использовать? Т.е. у меня уже есть база нетфлоу, вашим коллектором посмотреть ее получится?

Share this post


Link to post
Share on other sites

у меня уже есть база нетфлоу, вашим коллектором посмотреть ее получится?

 

А как вы эти фловы храните?

В общем случае только если эти нетфлоу "перепослать".

Если у вас база в текстовом виде (или можно сделать ее текстовый дамп) можно сделать flow-import + flow-send, например.

Если храните "сырые" фловы (прямо как они прилетают), можно сконвертировать, наверное.

 

С одной стороны, мне интересно было бы посмотреть как это будет выглядеть на больших данных.

С другой стороны, для провайдеров есть довольно много решений в которые вложены десятки и сотни человеко-лет разработки. Использовать наше решение - ну, можно, но с осторожностью.

Если мы и будем развивать проект дальше, то не в сторону решений для провайдеров, а в нашу, системно-интергаторскую, возможно будем добавлять какой-то DPI, у нас часто просят отчеты которые не получить из нетфлоу, а проксировать не всегда хочется (да и не всегда можется), ну и т.п.

 

То есть если хотите попробовать - я конечно же помогу чем смогу, можете написать на vmx@krasnaya.net, почтой скорее всего быстрее отвечу

Share this post


Link to post
Share on other sites

А как вообще скорость поиска информации? К примеру типовая задачу - за сутки выделить трафик от/к одному ип адресу?

 

Используем flow-tools-ng и там с этим все печально:

time flow-cat /var/tmp/backup/flows/21-02-2013/ | flow-nfilter -b big -f filter.cfg -F client | flow-print -f 25

real 117m23.177s

user 102m37.970s

 

Вот поэтому я выбрал nfdump

root@mon:/tmp/1# time nfdump -r nfcapd.2013.02.28 'host 8.8.8.8' > res

real    0m2.654s
user    0m2.392s
sys     0m0.260s
root@mon:/tmp/1# ls -l
total 305464
-rw-r--r-- 1 root root 302491860 Mar  1 06:07 nfcapd.2013.02.28
-rw-r--r-- 1 root root   9978554 Mar 18 16:18 res

Share this post


Link to post
Share on other sites

+1

Тоже выбрал nfdump - не могу нарадоваться.

Все просто, логично, понятно.

Работает и в ус не дует.

Share this post


Link to post
Share on other sites

есть почти 40 мбит нетфлоу потока с одной железки flow-capture из-за слабого проца не успевает все пережевать.. в результате в netstat вижу кучу пакетов в recvq, ну и что не влазит естественно дропается.. nfdump пока еще не развернул.. готовлюсь )

Есть у кого success story по принятию такого?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this