vmx

Натинги это NSEL/NEL? Не уверен что мы сможем быстро это сделать. Мы вообще про Netflow v9 не сильно думали. Но присылайте конечно, будем думать. Прямо на xenoeye@xenoeye.com если небольшие образцы. Или выложите куда-то, а ссылку пришлете. Общее потребление трафика по времени - это что-то типа такого: http://xenoeye.com/extradl/tmp/dgr150414.png ? В trunk версии это есть, график можно зумить/скролить мышкой. Разбивку (это разноцветные столбики) можно делать по любому полю netflow(v5), протокол там, as и т.п. Или можно не делать. Мы даже сделали отчеты с автообновлением, но понятно что они показывают текущую ситуацию очень условно - когда сенсор решит отдать флов

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

Гм. Вот я из любопытства решил посмотреть сколько этот наш коллектор сможет теоретически переработать нетфловов. Немолодой офисный писюк, Core2 Quad, на loopback интерфейсе. Физическими железками проверять лень, да и скорее всего порядок будет тот же. Проверял так: $ time flow-gen -V5 -n 10000000 | flow-send -x 10 -V5 0/127.0.0.1/9500 real 0m27.438s user 0m3.812s sys 0m3.908s Немного покрутил -x (xmit_delay), 10 дало где-то 170 мегабит. На такой скорости разброс потерь пакетов где-то от 0,1% до 0,7%. top показывает использование CPU: flow-send 24%, flow-gen 4%, xenoeye 12%. Это все кажется довольно логичным, там же нечему в CPU упираться, сплошной IO. Ну, разве что на каждый пакет несколько раз выделять/освобождать память и вызывать localtime. То есть если коллектор не умничает, минимально парсит пакет и складывает на диск, в CPU упереться не должно. Тем более, судя по тому что вы тут пишете, провайдерам нетфлов нужен больше для форс-мажора, отдать данные по IP-адресам за какое-то время. Предварительно просчитывать ничего не нужно, складывай себе и все. На всякий случай повторюсь: использовать в провайдерском хозяйстве на таких скоростях наш коллектор не очень осмысленно. Если бы нужда заставила хранить столько фловов только ради того чтоб отдавать IP-адреса и время, я бы скорее всего думал о какой-то агрегации, для такого часть информации не нужна, а все хранить - дисков не напасешься

А как вы эти фловы храните? В общем случае только если эти нетфлоу "перепослать". Если у вас база в текстовом виде (или можно сделать ее текстовый дамп) можно сделать flow-import + flow-send, например. Если храните "сырые" фловы (прямо как они прилетают), можно сконвертировать, наверное. С одной стороны, мне интересно было бы посмотреть как это будет выглядеть на больших данных. С другой стороны, для провайдеров есть довольно много решений в которые вложены десятки и сотни человеко-лет разработки. Использовать наше решение - ну, можно, но с осторожностью. Если мы и будем развивать проект дальше, то не в сторону решений для провайдеров, а в нашу, системно-интергаторскую, возможно будем добавлять какой-то DPI, у нас часто просят отчеты которые не получить из нетфлоу, а проксировать не всегда хочется (да и не всегда можется), ну и т.п. То есть если хотите попробовать - я конечно же помогу чем смогу, можете написать на vmx@krasnaya.net, почтой скорее всего быстрее отвечу

Вот я же несколько раз уже написал: это не провайдерское решение. То есть можно в него зарядить какие-то тысячи нетфловов в секунду, наверное как-то будет работать, но он не для этого делался. И на 10Гбитах же все немного не так? Вы же не подробный нетфлоу собираете, какой-то уже слегка агрегированный? sFlow?

А, неточно выразился. Там таймстампы со сброшенными последними битами, получается приблизительно файл в день Да, все так, только у нас этому потенциалу негде развернуться. Мы системные интеграторы, у нас не одна-две инсталляции, которые можно холить и лелеять, а много разных, некоторые вообще никем не поддерживаются. И мы последовательно прошли все эти стадии - "взять какой-то готовый продукт, его допилить под свои нужды", "написать свой, потенциально масштабируемый, но круче чем вот этот весь шлак" и, наконец, осмысление того что нам это все не очень подходит, вся эта потенциальность в большинстве случаев остается только потенциальностью, а ресурсов требует раз в несколько больше. Я уже писал в первом сообщении, на всякий случай напишу еще раз: Чтобы разбавить дискуссию цифрами - у нас 1Т трафика (входящего+исходящего) генерирует около 10Г netflow (т.е. съедает столько дискового пространства, мы грубо считаем как 1%). Обычно просто удаляем фловы старше полугода, но если сжимать то с того же 1Т получится около 2Г. Вот на узле который обрабатывает как раз около 1Т в месяц: Memory usage (grep VmSize /proc/22681/status): 576692 kB, CPU usage не поднимается выше 1%.

А куда ее еще прикручивать? Похоже, слово СУБД смутило. Но я же написал - "микро". Он хранит фловы в файлах (с выравниванием по страницам), имена файлов - таймстампы, все довольно просто, самое сложное - это разбор фильтров, и выполнение байткода для фильтрации (хотя в этом тоже ничего сложного). Ну никто не мешает смонтировать каталог с данными откуда-нибудь из сети (да хоть из люстры), будет вынесено в сеть Агрегированные данные и немного всякой служебной ерунды хранятся в Berkeley DB. Я же написал прямо в первом сообщении. Впрочем, мне не лень еще раз написать А что именно сравнивать? У кого быстрее B-tree реализовано - у MongoDB или Berkeley DB? Сейчас, в 2013 году, чтобы упереться в производительность CPU на таких задачах надо, наверное, пройти какие-то специальные курсы. Ну, изредка я запускаю callgrind, основное время расходуется как раз на обновление (агрегированных) записей в Berkeley DB, еще немного на localtime_r, остальное совсем ерунда. Было бы интереснее сравнить кто больше израсходует дискового пространства :-)

xenoeye работает немного не так. Вы создаете таблицу, пишете фильтр "(daddr == 1.2.3.4) or (saddr == 1.2.3.4)" и выбираете поля которые нужны - допустим откуда летело, куда, протокол и сколько пакетов: "saddr, daddr, proto, packets". Выбираете интересующий период (или весь период наблюдений), периоды за которые будет агрегация (минуты, часы, сутки, месяцы), жмете кнопку и оно строит таблицу. Если вам нужно постоянно следить за этим адресом, период наблюдений оставляете без даты окончания, таблица будет обновляться как только прилетит netflow-пакет. Но вообще это мне кажется не очень интересный пример. Вы можете сделать таблицу из, скажем, адресов подсети и количества байт которые на них прилетают за месяц. Или от них улетают. И это отдавать в виде отчета: таблицей, диаграммой. Или делать еще и разбивку по протоколам. Конечно, это можно получить из любого коллектора, но в xenoeye это делается без всяких мозголомств, из веб-интерфейса, несколько раз ткнул мышкой, набрал две строчки текста и типа готово Я уже писал, не поленюсь и напишу еще раз - там где трахают за секунды простоя его ставить не надо. Альтернатив - масса. Это для тех кого по разным причинам эти альтернативы не устраивают. Ну вот нас, например, не устраивали (и не только из-за NIH-синдрома), мы набрались мужества, уселись и написали то что нам нужно. Если кто-то хочет пользоваться плодами - пожалуйста, пользуйтесь

Да он не лучше или хуже, просто по-другому сделан. nfsen (как и многие другие) - RRD-based, старые данные "сглаживаются". У нас все хранится как прилетело, удалить можно только руками. Отчеты по старым данным, соответственно, не меняются со временем. Ну и в целом подход отличается: nfsen (как и многие другие) - Perl, PHP, данные берутся из nfdump, картинки генерируются на сервере, все монументально. У нас программа на С с встроенным веб-сервером, минимум зависимостей, AJAX, диаграммы немного интерактивные (при наведении мышки показывают подробности), генерируются в браузере. Остальное почти то же самое, чему там отличаться - фильтры, поля для агрегации. У нас полей меньше, но мы делали только то что нам нужно. Если вы пользуетесь nfsen (или каким-то своим решением) и это вас устраивает - не надо даже и пробовать, вам фактически придется после отлаженной системы пробовать такую раннюю альфу, там криво нарисует, здесь что-нибудь еще не так

Нафига им общаться? Коллектор - вот он, получил данные, сагрегировал их если надо и пихнул в БД. Интерфейс - отдельно, выгреб из БД данные, переварил и выплюнул. БД - отдельно (тоже не стоит изобретать велосипед, заюзать ту же постгрю к примеру). Причем в идеале коллектор живет отдельно, высокодоступная (кластеризированная) СУБД - отдельно, веб-морда - вообще нафиг вынесена туда, где ддос или еще какой катаклизЬм не зацепят критических сервисов. Где тут место для IPC? А. Похоже, я как-то непонятно написал. Такого же навалом, почти все так делают - коллектор пишет в (Р)СУБД (или в текстовые файлы), веб-интерфейс оттуда забирает и визуализирует. У нас такое тоже было, хранили в том числе и в PostgreSQL. Но это оказалось довольно ресурсозатратно. PostgreSQL, как и все версионники, при обновлении таблиц не "обновляет" их, а дописывает новую версию, то есть до vacuum full (которому нужен exclusive lock) место не высвобождается. А если хочется хранить фловы, а не только агрегированные данные - вообще туши свет, место жрется, для построения какого-нибудь заковыристого отчета только sequence scan, ну максимум что-то можно наоптимизировать секционированием. Вот мы и решили пойти другим путем - сделали такую специализированную микро-СУБД, очень простую, без транзакций, резервирования и сетевого доступа, но быструю и почти без лишнего расходования дискового пространства. Эта штука как раз для простых установок, когда не хочется вникать в тонкости работы СУБД, а хочется потыкать в веб-интерфейс, минимально напрячь моск и чтоб оно само там что-то сразу считало, показывало и при этом не особо сильно загружало компьютер

Так получилось, э-э, исторически. Задумывалось все красиво и модульно, конечно. Вот коллектор, вот интерфейс, они по IPC друг с другом общаются. Но после того как начали программировать выяснилось что не все так просто. IPC решили заменить на сетевой обмен данными и сообщениями. Логично было не выдумывать свой протокол обмена, а использовать HTTP. Так в коллекторе появился собственно HTTP сервер. Потом, чтоб не париться с написанием отдельного интерфейса, решили управление (временно) делать прямо этим вебсервером. Ну а потом уже стало проще добавить туда показ отчетов и вообще забыть про отдельный веб-интерфейс. Возможно, если будет свободное время, или нужно будет обеспечить какую-то повышенную надежность, мы к этому вернемся и вынесем интерфейс отдельно. Там, в общем-то все для этого есть - более-менее унифицированный AJAX, то есть работы не так уж много. Но, как я уже написал, сейчас проще запускать два коллектора для надежности. Да и в таком виде нас все устраивает, нет никакой мороки с разворачиванием веб-серверов, их настройкой, просто собрал, запустил, заработало. Сейчас мы планируем делать порт под Windows - там что делать? Таскать с собой nginx с PHP? Или apache с tomkat'ом? Это же инсталлятор какой-то адовый делать, получать лучи проклятий от пользователей. А карма-то одна. То есть если сильно нужно будет, сделаем, конечно, но пока вот так

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

Если кому-то интересен простой Netflow-коллектор и анализатор, open source, с веб-интерфейсным управлением и просмотром отчетов - http://xenoeye.com/docs Анализирует он очень условно, просто фильтрует фловы, агрегирует и показывает, но раз уж такая терминология устоялась, то анализатор. Понятно что это сейчас довольно нишевая штука - в сетях с безлимитами и аццкими скоростями такое ставить почти бессмысленно. Мы используем его для контроля за трафиком пользователей в подшефных компаниях, это, скорее всего, лучший профиль использования. Плюсы: Достаточно быстрый, netflow хранится в файлах, агрегированные данные тоже в файлах - Berkeley DB. Не нужно разворачивать и тюнить СУБД, запустил и заработало. Управляется веб-интерфейсом, отчеты генерируются тоже веб-интерфейсом. Разделение отчетов по пользователям - кому-то одни отчеты, кому-то другие, есть публично доступные. Не RRD-based. Данные хранятся в точности как прилетели, нет округлений и сглаживаний, на старых данных можно строить любые отчеты. Минусы: Коллектор простой, поддерживаются только Netflow v1 и v5 с IPv4. Построитель диаграмм тоже не очень сложный. Если нужен какой-то заковыристый график из нескольких источников - он такой построить не сможет. Веб-интерфейс и коллектор выполняются в одном процессе, если что-то упадет, упадет все (такого, правда, еще не случалось, но мы у нервных клиентов на всякий случай держим на одном узле по два запущенных коллектора) Не RRD-based. Если данных много, нужно их периодически удалять. В среднесрочной перспективе планируется добавить: - триггеры; - возможность из пользовательского интерфейса выполнить внешние скрипты; - сделать "гиперссылочные" отчеты - ткнул, например в столбик на диаграмме, а он переходит в другой отчет с подробностями; - добавить "отложенные" отчеты и таблицы, которые не пересчитываются при каждом новом netflow-пакете, а считаются при запросе к отчету, и потом через какое-то время самоудаляются