URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID12
Нить номер: 3821
[ Назад ]

Исходное сообщение
"Sarg извечная проблемма (+)"

Отправлено X_Max_X , 24-Янв-06 10:07 
Есть лог за 10 дней. 1.2 Г.б. В нём есть порченная запись на которой sarg зависает. Как мона из такой громадины эту запись почикать или есть какой хитрый вариантик?


Содержание

Сообщения в этом обсуждении
"Sarg извечная проблемма (+)"
Отправлено AlexVS , 24-Янв-06 12:32 
>Есть лог за 10 дней. 1.2 Г.б. В нём есть порченная запись
>на которой sarg зависает. Как мона из такой громадины эту запись
>почикать или есть какой хитрый вариантик?

Сколько времени такой файлик обрабатывает sarg?
Сейчас пишу перловский скриптик для преобразования squid лога в mysql базу и анализ уже с помощью мускула. Это делаю для собственных нужд. Возник вопрос: необходимо ли кому-то это, стоит ли это переводить из разряда для "себя" в разряд "для всех"?

Из плюсов такого подхода я вижу: преобразование в мускул лога занимает столько ж сколько создать с помощью sarg простейший отчёт (index only), а анализ уже такой базы выполняется на несколько порядков быстрее. Можно каждый день складывать в базу логи, а в конце месяца за пару минут получить отчёт. И база получается 65% от размера лога (на 35% меньше).

Из минусов: необходимо держать мускул. Не законченость скрипта анализа.



"Sarg извечная проблемма (+)"
Отправлено anonymous , 24-Янв-06 14:34 
>>Есть лог за 10 дней. 1.2 Г.б. В нём есть порченная запись
>>на которой sarg зависает. Как мона из такой громадины эту запись
>>почикать или есть какой хитрый вариантик?
>
>Сколько времени такой файлик обрабатывает sarg?
>Сейчас пишу перловский скриптик для преобразования squid лога в mysql базу и
>анализ уже с помощью мускула. Это делаю для собственных нужд. Возник
>вопрос: необходимо ли кому-то это, стоит ли это переводить из разряда
>для "себя" в разряд "для всех"?
>
>Из плюсов такого подхода я вижу: преобразование в мускул лога занимает столько
>ж сколько создать с помощью sarg простейший отчёт (index only), а
>анализ уже такой базы выполняется на несколько порядков быстрее. Можно каждый
>день складывать в базу логи, а в конце месяца за пару
>минут получить отчёт. И база получается 65% от размера лога (на
>35% меньше).
>
>Из минусов: необходимо держать мускул. Не законченость скрипта анализа.

Опять изобретение велосипеда. Есть много систем, в том числе написанных на perl, хранящих данные в mysql и  выполняющих функции учета трафика и управления пользователями. sams, squid2mysql кажется и т.д.  

Отдельных прог для лечения логов squid я не встречал. Обычно это дается на откуп самим программам подсчета трафика.


"Sarg извечная проблемма (+)"
Отправлено ram_scan , 26-Янв-06 11:12 
>Отдельных прог для лечения логов squid я не встречал. Обычно это дается
>на откуп самим программам подсчета трафика.

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


"Sarg извечная проблемма (+)"
Отправлено Дмитрий , 02-Мрт-06 17:51 
Я пошёл другим путём. Есть утилита http://lightsquid.sf.net, которая делает ту же работу, что и Sarg, не глючит, работает шустрее, данные на выходе занимают  в десятки раз меньше места. Никаких баз данных ей не нужно.