TrafStat

Был у меня лет 6 назад опыт работы с Netflow.
Недостаток Netflow в UDP-транспорте и, как следствие, в отсутствии контроля передачи. Т.е. если принимающий процесс будет чем-то занят и буфер UDP-сокета переполнится, то данные будут потеряны. Занятость приложения может возникнуть при работе с БД (например, заблокирована таблица, в которую приложению необходимо поместить запись).
Понизить вероятность такого события - настройка большего буфера и большего периода его сброса на шлюзе. Но тогда статистика будет больше запаздывать.
Предлагаю вариант решения без потерь: своевременное чтение из сокета и организация в приложении буфера данных, ожидающих записи в БД. Еще можно применить транзакционный тип таблиц, дабы сократить вероятность блокировки.

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

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

По такому же принципу надо будет сделать и коллектор для приема информации о трафике через протокол netflow.

Я делал по другому принципу: двухпоточное приложение, очередь данных. Т.е. никаких суммирований и внешнего квантования - чистые исходные данные. Один поток принимает, выбирает из пакета нужное и помещает в очередь, а второй уже занимается всей прочей логикой (например, группирование по времени, если нужно) и записью в БД. Как резерв, при доходе очереди до некого предела второй поток сбрасывал ее в отдельный файл и доставал данные в первую очередь из таких файлов. В большинстве случаев проблем нет и потоки справляются, но СУБД может падать - это факт.

Сие привел как пример реализации. Может решение не очень красиво, но на практике показало себя надежным.

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