Перейти к содержимому
Калькуляторы

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

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

http://xenoeye.com/docs

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

 

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

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

 

Плюсы:

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

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

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

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

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

 

Минусы:

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

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

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

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

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

 

 

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

- триггеры;

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

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

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

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

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

 

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

http://nfsen.sourceforge.net/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

http://nfsen.sourceforge.net/

 

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда мне нужно найти информацию по 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-синдрома), мы набрались мужества, уселись и написали то что нам нужно. Если кто-то хочет пользоваться плодами - пожалуйста, пользуйтесь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

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

 

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

15T /mnt/netflow/

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

[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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

15T /mnt/netflow/

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Используем 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

+1

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.