[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