[Comm] Подсчёт трафика
=?iso-8859-1?q?=22Evgenii_Terechkov=22_=CE=C1_mail=2Eyartelecom=2Enet?=
=?iso-8859-1?q?=22Evgenii_Terechkov=22_=CE=C1_mail=2Eyartelecom=2Enet?=
Пт Июл 28 19:03:40 MSD 2006
Eugene Prokopiev пишет:
Предложу и я вариант, которые использую сам (и доволен):
>> которое может считать входящий и исходящий раздельно и между
>> перезагрузками сохранять эту статистику.
Хранит в файлах. Бинарных, если это важно (места немного занимают). См.
далее.
>> Желательно и раз в N минут сохранять, т.к. пару раз были замечены
>> зависания (мать и видео не дружат).
Интервал сброса настаивается.
>> Сетевых карт несколько, но считать нужно _только_ одну.
Это смотря какой трафик ей сказать считать, как настроить. См. далее.
>> Если оно, помимо базовой функциональности, ещё и статистику показывать
>> может по типу той, что у ntop, то вообще замечательно. ntop не беру
>> потому, что статистику сохранять не придумаю как (с NetFlow не знаком, и
>> кучу посторонних лишних сервисов поднимать не хочу).
Средства получать красивую статистику, отчеты и т.п. я не искал, за это не
скажу. Про NetFlow это вы зря так, там всё довольно прозрачно. И сервисов
много не надо: всего два (сенсор и коллектор). Ведь всё равно эта считалка
будет демоном висеть. Два это немного, тем более что они выполняют
отдельные функций и их можно по отдельности заменять на альтернативы. См.
далее.
>> И важное дополнение: крайне не желательно, чтобы принуждало это средство
>> использовать внешнюю СУБД. Т.е. пусть оно умеет MySQL и прочие, но мне
>> нужно, чтобы в свои файлы сохраняло статистику, т.к. будет
>> использоваться и на тех уровнях исполнения, когда СУБД выключена, а инет
>> есть.
Оно в принципе может собираться с умением экспорта в мускул или постгрес,
но в альте насколько я знаю это никогда не включали (в смысле "пересобрать
пакет с" легко, но лишние зависимости не навязываются). Также см. далее.
>> Какие есть варианты для ALM2.4?
> Например, ulog-acctd из бэкпортов. Работает так: описываете в iptables
> цепочки, по которым необходимо вести учет (например, все проходящее
> через требуемую карту), и указываете цель ULOG. ulog-acctd ловит эти
> пакеты и время от времени складывает их в файл в описанном вами формате.
> Как вы будете потом этот файл обрабатывать - уже не его забота :)
Это тоже вариант. Предлагаю альтернативу: связка из flow-capture (коллектор
NetFlow, собственно складывает данные о трафике в файлы) и сенсора.
Сенсоров могу предложить два (которые пробовал и остался доволен):
1) fprobe-ulog - только сенсор NetFlow. Использую его и дома на боевых
серверах (где пригождаются его тонкие настройки). Также как и
ulog-acctd, интегрируется с iptables (тоже указываете, где нужно
считать, цель ULOG).
2) ipcad - поуниверсальнее. Умеет брать информацию из ULOG, pcap и IPQ.
Выдавать может или в NetFlow или в ip accounting по типу циски (и то и
другое, разумеется, нужно чем-то собирать). У меня лично с ним были
проблемы с ядрами 2.4.
Различий между ними (помимо умений) немного - мелочи, которые нужны только
тем, кому нужно (типа меня). Об этом в принципе можете узнать, поискав по
архивам рассылок sysadmins@ и backports@ .
Все упомянутые пакеты для M24 есть в backports/2.4. Некоторые из них
собраны и поддерживаются мной (всё вышеописанное, разумеется, бессовестная
самореклама :-)
P.S.: а ntop я тоже, повертев в руках и почесав в затылке, оставил на
светлое будущее. Тогда оно показалось сложноватым.
P.P.S.: Есть ещё интересная штука: nnfc. Жаль сырая пока.
P.P.P.S.: Вообще-то это тема для sysadmins на .
--
Терешков Евгений, ALT Linux team.
Подробная информация о списке рассылки community