Разработчики фреймворка Netfilter (http://www.netfilter.org/), используемого для фильтрации и преобразования пакетов в ядре Linux, после четырёх лет разработки представили (http://lists.netfilter.org/pipermail/netfilter-announce/2012...) релиз ulogd 2.0.0 (http://netfilter.org/projects/ulogd/index.html), демона для сбора информации, связанной с работой netfilter/iptables. После выхода ulogd 2.0.0 объявлено о прекращении развития ветки 1.x, которая переведена в разряд устаревших. Ключевым отличием ulogd 2 является переход на гибко расширяемую архитектуру на базе плагинов и внешних библиотек, позволяющих легко менять методы сбора, хранения и фильтрации данных.
Ulogd способен накапливать данные на уровне отдельных пакетов или потоков (сессий c учетом соединений), что может быть использовано с целью аккаунтинга активности пользователей, сбора статистики о трафике или фиксации сетевых атак. Данные помещаются в лог в соответствии с правилами, которые могут задаваться через инфраструктуру nfacct (http://www.netfilter.org/projects/nfacct/index.html). Накопленная информация может быть сохранена с использованием различных плагинов, в том числе в SQLite3, MySQL и PostgreSQL, или с использованием дампов в форматах PCAP, CSV, XML, а также в виде в виде текстовых логов Netfilter. Плагины (https://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=...) могут быть использованы для выбора источника сбора данных и для предварительной обработки данных (например, плагин PWSNIFF позволяет выделять пароли из трафика).
В процессе работы ulogd 2.x использует несколько внешних библиотек:
- libmnl и libnfnetlink для обеспечения связи через Netlink.
- libnetfilter_log для получения данных о проходящих пакетах с использованием nfnetlink_queue;
- libnetfilter_conntrack для оценки состояний соединений с использованием nf_conntrack_netlink.
- libnetfilter_acct для гибкого аккаунтинга трафика через nfnetlink_acct и правила iptables nfacct;
URL: http://netfilter.org/news.html#2012-06-17
Новость: http://www.opennet.me/opennews/art.shtml?num=34170
Надо же, он ещё жив.Строго говоря, он был бы актуален лет 7 назад, а сейчас морально устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct заруливает сабж в гибкости и опять же по ресурсам.
> Надо же, он ещё жив.
> Строго говоря, он был бы актуален лет 7 назад, а сейчас морально
> устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct
> заруливает сабж в гибкости и опять же по ресурсам.Доброго!
Есть результаты тестов?
Делал только для себя, на 100мбитном канале, с десятком пользователей. Насчёт объективности - смотри сам.Так вот, Данные о трафике у меня хранятся в базе, чтобы выборки делать кто/сколько выкачал.
Поставил ulogd (я говорю о первой ветке) - считать считает, на этом его преимущества заканчиваются. Он любую базу может поставить раком, если что-то качнуть во всю ширину канала. Даже при простом подсчёте - тоже грузит систему (примерно 15-20% от тогдашнего 3ГГц Прескотта). Вменяемых средств записи логов "хоть куда" при отказе бд - нет, если упала - потеряешь все данные о трафике за время, пока бд не поднимется.
ulog-acct - пишет только текстовый лог, с базой напрямую работать не умеет. Пришлось писать парсер логов для закидывания в базу. При подсчёте трафика - в топе процессов его видно только в момент записи логов (меньше секунды раз в 2 минуты). А вот загрузка лога в бд занимала ещё секунд по 5 (это с применением многострочных инсёртов и транзакций). Лучше, но хочется большего.
pmacct - аналогично выше, но умеет работать с базой. Может создавать таблицы по шаблону. В топе вообще не видно. Перешёл полгода назад - полёт нормальный - сейчас только отчёты смотрю.
По базе: изначально думал обойтись sqlit'ом. Фиг, как только база переваливает за гиг - всё начинает тормозить, там сплошные инсёрты. Поставил мускул - полегче, но всё равно тормозило (на innodb - дохло аналогично с sqlit'ом, с myisam - нормально). Посгре не пробовал.
Спасибо, товарищ. Очень познавательно.
> Спасибо, товарищ. Очень познавательно.Примерно как сравнение по фичам windows 7 и Linux 1.0.
Все вышесказанное относится только к первой ветке ulogd, и никак не связано со второй.
Для логов в БД рекомендую использовать более специализированные для этого движки.
А то через некоторое время myisam у вас тоже начнет нехило тормозить.
Что-то конкретное подсказать не могу.
Я бы попробовал csv движок.
Что-то мне подсказывает, что там с индексами будет проблема. Но тем не менее - пока работает и нагрузку держит - менять не буду.
После появления nfacct, всякие юзерспейсные pmacct можно отправлять на свалку истории :)
А доку по нему где брать?
> Строго говоря, он был бы актуален лет 7 назад, а сейчас морально устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct заруливает сабж в гибкости и опять же по ресурсам.Теперь его переписали с нуля, и в пору объявлять устаревшими и тормозными уже ulog-acct и pmacct :)