Чиста похвастаться

[kompadre]

Джагги, не проси так громко. Ведь другим тоже может захотеться.

Кроме того вот тов. нирва рекламировал awstats.

[juggy]

а что есть awstats он логи небось анализирует?

[[subway]design]

Да. В этом-то и дело.

[Nirva]

именно так, австатс это логаналайзер (не путать с одноименным). а тут. красотища, понимаешь ли.не я вот каждый раз смотрю и все более проникаюсь.

[[subway]design]

Я вообще-то подумывал (и сейчас тоже подумываю) прикрутить в качестве дополнения анализатор логов, ибо на некоторых сервантах логи ведутся независимо от того, читают их или нет. Зачем тогда добру пропадать? :)
Вот на моем сервере логи пожно отключить, но даже включенные хранятся максимум 8 дней (хотя скриптом это можно поправить)

[nagash]

надо различать логи апача и твой вариант...
1 - логи апача ведут ПОЛНЫЕ ЛОГИ сервера...
это значит что туда включаются и обращения КО ВСЕМ файлам а не только к файлам поддерживающим пхп и т.п. полезности
2 - логи апача записывают ОШИБКИ которые твой скрипт даже и увидеть не сможет...

в плане удобства это каждому своё, я не хочу ничего утверждать...
но моё мнение что логи апача намного информативнее и полезнее, не смотря на их размеры...
повторюсь - это моё мнение.

ну и как итог, мне кажется, что анализатор апачевских логов правильно построенный - хранящий сводную статистику в мюскле - это самый оптимальный вариант.
запускаться он должен по крону раз в день.

[[subway]design]

nagash, я отлично понимаю что такое логи апача. Единственный их недостаток - это размеры. А сверх информативность требуется редко. Но, опять-таки, если сервер независимо от того, хочешь ты или нет, ведет эти логи, то грех не анализировать их в качестве бонуса. Хотя часто логи можно отключать по желанию пользователя, и на ограниченном дисковом пространстве отлично встанет моя статистика.

А крон и мускл - это чисто технические аспекты. Например, то, что сейчас стоит у меня на сервере будет работать с мускулом медленнее, чем просто с файлами. Ибо файлы маленькие и нечего нагружать сервер SQL-запросами. Вот такое моё мнение.

[nagash]

=)))
ок

[kompadre]

Вынужден согласиться что лучше

ну и как итог, мне кажется, что анализатор апачевских логов правильно построенный - хранящий сводную статистику в мюскле - это самый оптимальный вариант.

просто придумать трудно. Мускул - база все таки как ни как, а базы данных придумали ... ну вобщем придумали и все. А статистику брать из них приприятно и "лекко" =).

Но с вариантом крона вынужден не согласиться. Заставлять сервер чрезмерно "пукать" в определенное время (даже заведомо "слабое" относительно количеству юзеров) не есть гуд. имхо, опять-же. Надо как-нибудь нагрузку десцентрировать.

Предлагаю следующюю схему :
(под *никс)

в хттпд.конф прописать

# Задать формат. Это стандарт который есть в хттпд.конф последних апачей
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined 
# И собственно делаем "каку" (pipe)
CustomLog "|/usr/bin/al" combined
# Не забыв за"#"оментировать то что было раньше ... на всякий пожарный

Закончив потрошение .конфы примемся за дело /usr/bin/al
Что это? Это файл выполняемый файл через которого пройдут данные изрыгаемые апачем. Эту роль должен исполнять хорошо настроенный и оптимизированный бинарник. Но я его не дам Так как "нема"

Но, рассмотрим мы такой вариант :

PHP код:

#!/usr/bin/php
<?
        $fh = fopen ("php://stdin", "r");
        $rows = fgets($fh, 512); // 256 гета + еще столько же        
                                                //Должно типа хватить
        fclose($fh);
        $fh = fopen ("/var/log/apache/php_generated_log", "a");
        fwrite($fh, $rows);
        fclose($fh);
?>

проверяем все права

/var/log/apache должен получить для такого случая 777 (что-бы создался php_generated_log).
/usr/bin/al - 755

Теперь можно из промта делать /etc/rc.d/rc.httpd restart или как там у вас...

Что-бы проверить фурычит ли изобретение можно воспользоваться тэйлом

tail -f /var/log/apache/php_generated_log

Если всё прошло успешно это должно привести к тому-же результату что и

tail -f /var/log/apache/access_log

только до сией белиберды.

Я думаю к хостингам (смотря к каким, конечно) это прикрутить будет тоже не сложно. CustomLog - такая-же дериктива виртуального хоста. Главное прописать правильно директории и разобраться с правами.

А туду - изменить пхп-файл что-бы он акуратненько вносил в базу тынных ...

Что бы зделать подобное под виндой ... Просто изменить директориии на знакомые (/var/log/apache на с:\Program Files\Apache Group\Apache\logs например). И в CustomLog-e прописать что нибудь типа

CustomLog "|c:\php\php.exe с:\Program Files\Apache Group\Apache\bin\al.php" combined

[[subway]design]

А зачем скрипт-посредник (даже если это "хорошо настроенный и оптимизированный бинарник")? Не проще ли доверить запись лога самому апачу, а при просмотре статистики этот лог открывать? Да, если апач будет хранить только последние 8 дней (как у меня), то скрипты просмотра статистики могут эти логи копировать куда-нибудь к себе в папку. Если нужно, разумеется.