LINUX.ORG.RU

Ответ на: комментарий от hizel

Да что вы говорите... Т.е. по вашему мнению сырой нетфлоу никак не сторится для дальнейшего анализа ? :)

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

я говорю о том, что спека netflow никак не определяет хранение, следовательно нельзя говорить о файлах netflow

hizel ★★★★★
()
Ответ на: комментарий от hizel

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

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

Netflow - это протокол и определен только формат датаграмм.
Формат файлов определяется конкретным ресивером датаграмм Netflow.

Ресивер может просто сохранять сырые датаграммы в файл или может парсить на лету. Первое предпочтительнее, так как поток Netflow с больших железок может быть ОЧЕНЬ интенсивным и UDP датаграммы будут дропаться если тратить время на парсинг.

Когда я писал свой ресивер все было просто - в файл сначала писался timestamp (4 байта, UNIX time), а потом сама сырая UDP датаграмма.
Таймстамп был нужен, так как только время сервера считалось 100% корректным (нельзя было завядываться на время на железках).

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

И вот тут возникает вопрос про «быстрый поиск». Очевидно, что формат который я описал вообще не оптимизирован под поиск. Возможно из этого формата можно данные переконвертировать в другой, более подходящий под конкретные выборки (и наверняка можно агрегировать записи, что существенно уменьшит размер файла и увеличит скорость поиска).
Основная идея - любой парсинг/переконвертазию/агрегацию должен выполнять не ресивер, а отдельный парсер, работающий на уже собранных данных (опять же для скорости приема и во избежание потери UDP датаграмм).

Krivenok_Dmitry
()
Ответ на: комментарий от Krivenok_Dmitry

Хм... А зачем вы МНЕ такую простыну написали? Я в курсе что да как, в отличии от.
И не ресивер, а коллектор :))) Хотя с функциональной стороны они весьма подобны.

P.S. Автор просил ответа на вопрос, а не теоретического флуда. Оцените мой ответ и Ваш ответ.

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

вам он озвучил простую мысль, что хранить, даже в таком простом случае, можно в стопицот разных форматах

hizel ★★★★★
()

дотошники с хабры такие дотошники

Существует-ли какой-нибудь софт, позволяющий собирать и сохранять netflow с возможностью быстрого поиска и выборки в сохраненной им информации?

//FIXED

redixin ★★★★
()
Ответ на: комментарий от hizel

ТС спросил конкретную вещь. А вы вместо конкретного и нормального ответа начали какойто теоретический бред нести, который мало того что бесполезен в контексте вопроса, так еще и легко запутает ТСа...

Jetty ★★★★★
()
Ответ на: комментарий от redixin

Смотря что вкладывать в понятие «быстрый» xD

Jetty ★★★★★
()
Ответ на: комментарий от redixin

А еще смотря какие объемы флоу...
когда-то с помошью nfilter и stat нормально выгребалась информация...

Jetty ★★★★★
()

Использую nfsen. Удобнее чем flow-tools, хотя и не без недостатков.

kernelpanic ★★★★★
()

Буду невежливым, задам новый вопрос не проверяя указаный вами софт.

А flow-tools/nfsen индексируют свои файлы, или при просто пишут как есть, а последующие выборки и поиск производятся методом последовательного чтения?

dmitryalexeeff
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.