Re: Traffic tracking
On Tue, Jan 22, 2002 at 08:44:56AM +0500, Viktor Vislobokov wrote: Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. -- dg
Re: Traffic tracking
On Tue, Jan 22, 2002 at 08:44:56AM +0500, Viktor Vislobokov wrote: Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. Я не смотрел исходники, но исходя из общих соображений увеличение размера буфера раз в 20 может вылечить ситуацию...
Re: Traffic tracking
On Wed, Jan 23, 2002 at 02:25:56PM +0300, Nikita V. Youshchenko wrote: On Tue, Jan 22, 2002 at 08:44:56AM +0500, Viktor Vislobokov wrote: Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. Я не смотрел исходники, но исходя из общих соображений увеличение размера буфера раз в 20 может вылечить ситуацию... Не вылечит, а отсрочит появление. Кажется мне, что traffic accounting через анализ логов - затея странная. -- dg
Re: Traffic tracking
Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. Я не смотрел исходники, но исходя из общих соображений увеличение размера буфера раз в 20 может вылечить ситуацию... Не вылечит, а отсрочит появление. Кажется мне, что traffic accounting через анализ логов - затея странная. Хорошо, тогда посоветуйте. Есть потребность иметь детальный протокол вида: SRC_IPSRC_PORTDEST_IPDEST_PORTSIZE Как это можно организовать на Linux-машине, если не анализировать логи? Виктор
Re: Traffic tracking
On Wed, Jan 23, 2002 at 05:06:34PM +0500, Viktor Vislobokov wrote: Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. Я не смотрел исходники, но исходя из общих соображений увеличение размера буфера раз в 20 может вылечить ситуацию... Не вылечит, а отсрочит появление. Кажется мне, что traffic accounting через анализ логов - затея странная. Хорошо, тогда посоветуйте. Есть потребность иметь детальный протокол вида: SRC_IPSRC_PORTDEST_IPDEST_PORTSIZE Как это можно организовать на Linux-машине, если не анализировать логи? Есть net-acct. Сам я не пробовал, но отзывы о нем весьма положительные. Принцип функцонирования похож на trafd'шный, т.е. несколько более здравый, чем разбор логов пакетного фильтра. Но потеря статистики все равно не полностью исключена. -- dg
Re: Traffic tracking
Viktor Vislobokov wrote: Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Прав. Там кольцевой буфер. Лог сообщения вполне могут теряться. Это by design, так сказать. Я не смотрел исходники, но исходя из общих соображений увеличение размера буфера раз в 20 может вылечить ситуацию... Не вылечит, а отсрочит появление. Кажется мне, что traffic accounting через анализ логов - затея странная. Хорошо, тогда посоветуйте. Есть потребность иметь детальный протокол вида: SRC_IPSRC_PORTDEST_IPDEST_PORTSIZE Как это можно организовать на Linux-машине, если не анализировать логи? Виктор -- Я уже месяца два пользую nacctd (net-acct) Работает вполне прилично. Правда разхождения на 1.5-2 % с провайдером остаются Я думаю это связвно с механизмом сброса ежечасной статистики, когда необходимо приостанавливать nacctd сигналом TSTз, сбрасывать статистику и продолжать работу nacctd сигналом CONT -- С Уважением ICQ: 64629878 Алексей Костарев
Re: Traffic tracking
On Wed, 19 Dec 2001 10:57:12 +0300 Ingvarr Zhmakin [EMAIL PROTECTED] wrote: Доброго утра. Хочется чем-то траффик считать. Кроме ipac-ng есть что-то удобоваримое? Linux-2.4, iptables. могу посоветовать squid+(calamaris|sarg) но ограничить не получится, зато есть squid2mysql(freshmeat.net) - этот ограничивает, а я его сейчас переписываю как squid2dbi :)
Re: Traffic tracking
Хочется чем-то траффик считать. Кроме ipac-ng есть что-то удобоваримое? Linux-2.4, iptables. Кстати. Тут у меня на одном серваке сдела подсчет пакетов через ipchains и протоколирование. Так вот замечена странность. Почему-то в kern.log попадают не все пакеты, которые фактически приходят - факт проверяется через cisco. Т.е. в логе cisco есть записи о таких пакетах, которых нет в kern.log хотя всюду ключик -l на правилах стоит и протоколируется все. Иногда в kern.log попадаются некондиционные записи в которых скажем нет адресов но есть цепочка куда пакет попал, дата время и SYN. Есть подозрение, что при довольно сильной нагрузке ядро просто не успевает протоколировать. Я прав? Виктор
Traffic tracking
Доброго утра. Хочется чем-то траффик считать. Кроме ipac-ng есть что-то удобоваримое? Linux-2.4, iptables. Ingvarr.
