![]() |
Джагги, не проси так громко. Ведь другим тоже может захотеться. ;)
Кроме того вот тов. нирва рекламировал awstats. |
а что есть awstats он логи небось анализирует?
|
Да. В этом-то и дело.
|
именно так, австатс это логаналайзер (не путать с одноименным). а тут. красотища, понимаешь ли.не я вот каждый раз смотрю и все более проникаюсь.
|
Я вообще-то подумывал (и сейчас тоже подумываю) прикрутить в качестве дополнения анализатор логов, ибо на некоторых сервантах логи ведутся независимо от того, читают их или нет. Зачем тогда добру пропадать? :)
Вот на моем сервере логи пожно отключить, но даже включенные хранятся максимум 8 дней (хотя скриптом это можно поправить) |
надо различать логи апача и твой вариант...
1 - логи апача ведут ПОЛНЫЕ ЛОГИ сервера... это значит что туда включаются и обращения КО ВСЕМ файлам а не только к файлам поддерживающим пхп и т.п. полезности 2 - логи апача записывают ОШИБКИ которые твой скрипт даже и увидеть не сможет... в плане удобства это каждому своё, я не хочу ничего утверждать... но моё мнение что логи апача намного информативнее и полезнее, не смотря на их размеры... повторюсь - это моё мнение. ну и как итог, мне кажется, что анализатор апачевских логов правильно построенный - хранящий сводную статистику в мюскле - это самый оптимальный вариант. запускаться он должен по крону раз в день. |
nagash, я отлично понимаю что такое логи апача. Единственный их недостаток - это размеры. А сверх информативность требуется редко. Но, опять-таки, если сервер независимо от того, хочешь ты или нет, ведет эти логи, то грех не анализировать их в качестве бонуса. Хотя часто логи можно отключать по желанию пользователя, и на ограниченном дисковом пространстве отлично встанет моя статистика.
А крон и мускл - это чисто технические аспекты. Например, то, что сейчас стоит у меня на сервере будет работать с мускулом медленнее, чем просто с файлами. Ибо файлы маленькие и нечего нагружать сервер SQL-запросами. Вот такое моё мнение. |
=)))
ок |
Вынужден согласиться что лучше
Цитата:
Но с вариантом крона вынужден не согласиться. Заставлять сервер чрезмерно "пукать" в определенное время (даже заведомо "слабое" относительно количеству юзеров) не есть гуд. имхо, опять-же. Надо как-нибудь нагрузку десцентрировать. Предлагаю следующюю схему : (под *никс) в хттпд.конф прописать Код:
# Задать формат. Это стандарт который есть в хттпд.конф последних апачейЧто это? Это файл выполняемый файл через которого пройдут данные изрыгаемые апачем. Эту роль должен исполнять хорошо настроенный и оптимизированный бинарник. Но я его не дам :p Так как "нема" :( Но, рассмотрим мы такой вариант : PHP код:
/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 |
А зачем скрипт-посредник (даже если это "хорошо настроенный и оптимизированный бинарник")? Не проще ли доверить запись лога самому апачу, а при просмотре статистики этот лог открывать? Да, если апач будет хранить только последние 8 дней (как у меня), то скрипты просмотра статистики могут эти логи копировать куда-нибудь к себе в папку. Если нужно, разумеется.
|
| Часовой пояс GMT +4, время: 17:33. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.