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

Для анализа статистики доступа необходимо соответствующее стандартное программное обеспечение, например, система Analog и некоторое количество модулей (как правило, собственной разработки) для решения узкоспециализированных задач.
Система обработки статистики Analog

Почему именно Analog? Когда-то я перепробовал много различных пакетов для анализа статистики и выбрал именно этот. С ним я прошел от версии 1.9 до нынешней, третьей версии. Система бесплатная, доступна под разные платформы, постоянно обновляется, легко конфигурируется, быстро работает (это мне было особенно важно при работе с гигабайтными файлами логов).

Автор системы - Stephen Turner, sret1@cam.ac.uk, подробное описание и саму систему можно найти по адресу http://www.statslab.cam.ac.uk/~sret1/analog/.

Эта система по умолчанию генерирует:

    сводный отчет
    отчеты по месяцам, неделям и дням
    сводные отчеты дням и часам
    отчеты по доменам и хостам
    отчеты по директориям, типам и размерам файлов
    отчет по запросам и результатам запросов
    отчет по ссылкам и браузерам
    сводный отчет по браузерам

Для общей оценки того, что происходит на узле достаточно следующих данных:

    Количество успешных запросов, иначе говоря хитов (hits). Запросы ко всем возможным файлам.
    Количество успешных запросов к страницам. Не путайте это с предыдущим параметром, страницы - это html файлы.
    Количество уникальных обслуженных хостов. За счет использования шлюзов и прокси это число не является количеством уникальных посетителей, но тем не менее является довольно точной его оценкой.

Эти данные доступны в сводном отчете. Из них путем несложных преобразований можно получить среднее количество пользователей узла за определенный период времени, среднее количество страниц, которой прочитывает пользователь и сделать выводы о ресте популярности узла и о проценте повторных посещений узла.

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

С помощью отчетов по доменам и хостам можно оценить существующую аудиторию узла и относительную активность ее частей. По ним же можно выявить хосты с ненормальной генерацией траффика.

Отчеты по директориям показывают популярность разных разделов узла относительно друг друга (если ваши логические разделы находятся в разных директориях.)

Отчет по запросам показывает сколько раз был запрошен тот или иной документ.

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

Из отчета по браузерам получается информация о том, под какой браузер в первую очередь стоит затачиваться при разработке дизайна и разметке.

Помимо перечисленных генерируемых по умолчанию отчетов, существуют возможности гибкого конфигурирования каждого из них, по дате, по количеству запросов, по маске файлов и проч. Например, наложив ограничение на показ всех документов кроме корневого в отчетах по запросам, по хостам и по дням, получим количество запросов к корневой странице узла, их распределение по дням и количество уникальных хостов, с которых страница была просмотрена. То же самое можно проделать для любого другого документа узла.

Что этот пакет не позволяет делать (к сожалению):

    показывать в нормальном виде запросы поисковых машин, по которым были найдены документы.
    анализировать переходы пользователей от страницы к странице внутри узла.

Типичные задачи и способы их решения
Что есть страница и посетитель

Типичный вопрос новичка "А как может быть 41220 успешных тычков и при этом ~8000 запросов к страницам?". Все очень просто, если у в HTML-файле есть картинки или что либо в этом роде, то хитов будет много, а страница всего одна. При одном запросе к документу, содержащему десять картинок, хитов будет одиннадцать, а запросом к странице будет только один из них. В случае использования фреймовых структур следует конфигурировать отчеты так, чтобы файл с управляющей конструкцией за страницу не считался, иначе результат будет неправдой.

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

Обратная ситуация для пользователя, которому провайдер выдает динамический IP - вчера он зашел под одним адресом, сегодня - под другим. В итоге в логах записи о двух различных хостах.

Таким образом количество уникальных хостов может считаться лишь приблизительной оценкой количества посетителей.
Отсечение запросов обслуживающего персонала

Для корректного соотношения цифр необходимо не учитывать в отчетах запросы обслуживающего персонала. Особенно если траффик еще мал и такие запросы составляют значительную часть от общего числа.
Определение популярности (ссылки) и выявление ведущих рефереров

Есть такая замечательная вещь как отчет по ссылкам (Referer report). Вещь сама по себе исключительно полезная, поскольку дает знать откуда пользователи приходят на ваш узел. Сюда попадают адреса документов, по ссылкам из которых приходят пользователь, будь то сборник любимых ссылок на чьей-то домашней странице или ответ на запрос к поисковой машине.

Этот отчет выявляет наиболее популярные ссылки, по которым приходят пользователи. Выводы можно делать следующие:

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

Всплески (действие рекламы, прокси, зеркалисты)

Любое рекламное мероприятие для узла сопровождается всплеском посещения. Если речь идет о рекламе в баннерных сетях, то в предоставляемой ими статистике есть количество заходов к вам на узел. В логах вашего узла отражается прирост количества запросов за промежуток времени. Из этих данным можно определить эффективность предпринятых вами усилий. Если прирост равен количеству кликов по отчетам баннерной системы - значит дело плохо - пользователи взглянули на одну страницу и разочарованно откатились обратно - ваш узел "не готов к приему посетителей".

Если прирост больше, чем количество кликов по отчетам баннерной системы, то вычисляется среднее количество страниц, которые были прочитаны заинтересовавшимися рекламой пользователями. Понятно, что чем больше это количество, тем лучше.

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

Второй причиной всплесков являются "зеркалисты". По этим я понимаю ситуацию, когда с одного адреса запрашивают большое количество документов сервера. Если при просмотре отчетов выясняется, что всплеск вызван запросами одного хоста, да еще с юзерагентом типа Teleport Pro или Wget, то все становится ясно. Дальше вы вольни либо закрывать на это глаза, либо следить за тем, как используется скачанная с узла информация, либо для чистоты дальнейшего анализа статистики не учитывать такие запросы.

Теперь о прокси: у меня был случай, когда постоянно шли всплески по вине одного хоста, но не для зеркалирования. После некоторого исследования выяснилось, что это делает неправильно настроенный прокси-сервер в Башкирии. Я списался с тамошним администраторам и проблема была решена.
ОС и браузеры пользователей

Отчет по браузерам дает представление о том, какими браузерами пользователи смотрят узел. Вывод прост: на основании этого отчета вы принимаете решение о том, под какие браузеры в первую очередь затачивать узел. То же самое с операционными системами: какую кодировку на сервере ставить по умолчанию.
Выводы об актуальности снижения нагрузки на сервер или канал

Для больших узлов с высоким траффиком рано или поздно встает вопрос об оптимизации траффика. Когда появляется много "зеркалистов" - стоит задуматься о реорганизации процесса зеркалирования. Например, предоставить логические законченные части узла (раздел или книгу) или все документы сервера в виде архивов с доступом по FTP.

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

Знание точных цифр по траффику на каждый момент времени это, конечно, замечательно, но знание тенденции его развития вещь значительно более ценная. Анализ тенденций изменения траффика основывается на средних значениях за период времени. Прежде всего интересны средние значения уникальных хостов за неделю, среднее количество успешных запросов и запросов к страницам за неделю. Зависимость, по которой изменяются перечисленные средния значения и есть тенденция изменения траффика узла. От этих данных можно отталкиваться при долгосрочном планировании развития проекта.
Нетривиальные задачи и рекомендации по этому поводу
Отслеживание кликабельности

Исходная задача: необходимо узнать, на каких страницах и в каком именно месте этих страниц следует размещать рекламу.

Рекомендации по решению задачи: на самом деле задача сводится к отслеживанию кликов. Для этого необходимо, чтобы клики попадали в логи вашего узла. Сначала вам нужно сделать ссылку на локальный скрипт, который по передаваемому параметру делает редирект на соответствующий URL. Скрипт крайне прост, вот его код (Си):

main()
{
 char *query;
 query=getenv("QUERY_STRING");
 printf("Location: %s/n/n",url);
}

Вызов скрипта выглядит следующим образом:

<a href=/cgi-bin/click.cgi?http://url.ru>контролируемая ссылка</a>

В итоге в логи узла попадают все вызовы скрипта, которые потом обсчитываются и анализируются. Для идентификации разных ссылок в одно и то же место достаточно ввести для каждой уникальный идентификатор.
Клик за клик

Исходная задача: необходимо узнать, каким образом меняться ссылками с другими узлами, когда невозможно узнать каков траффик на чужих узлах.

Рекомендации по решению задачи: для отслеживания траффика на удаленном узле опять-таки следует сделать так, чтобы и показы и клики ссылки попадали в логи вашего узла. С кликами мы разобрались в предыдущей задаче, поэтому перейдем к отслеживанию показов. При показе вышей ссылки на удаленном узле с вашего должна дергаться картинка. Этом может быть жесткий .GIF размером 1 на 1 пиксел, но при этом картина будет искажаться за счет прокси-серверов и кэширования в браузерах, поэтому логичнее вызывать скрипт со случайным параметром, результатом выполнения которого будет тот же самый однопиксельный .GIF. Не будеи сильно извращаться и слегка видоизменим предыдущий click.cgi:

main()
{
 printf("Location: 1.gif/n/n");
}

т.е. просто сделаем редирект на готовый однопиксельный .GIF. Добавим в параметры скрипта случайное число и все. Вызов скрипта выглядит следующим образом:

<a href=http://your.server.ru/cgi-bin/click.cgi?target=http://url.ru&id=your_id&
random=random_number>контролируемая ссылка</a>
<img src=http://your.server.ru/cgi-bin/img.cgi?id=your_id&random=random_number>

В итоге в логи узла попадают все вызовы click.cgi, являющиеся кликами и все вызовы img.cgi, являющиеся показами. Полученные данные обсчитываются и анализируются.
Поисковые запросы (внешние и внутренние)

Исходная задача: необходимо узнать, по каким запросам пользователи приходят на узел из внешних поисковых машин и что именно они ищут на узле.

Рекомендации по решению задачи: опять используем логи своего узла. Для решения этой задачи на вашем узле должна собираться информация по переменной HTTP_REFERER для каждого запроса.

Практически все поисковые машины выдают ответы на запросы методом GET, и в строке статуса вы можете наблюдать что-то типа

http://www.altavista.com/cgi-bin/query?pg=q&kl=XX&q=%E2%E5%E1%EC%E0%F1%F2%E5%F0

В параметрах содержится поисковый запрос, который нам и интересен. Осталось только представить его в читабельной форме. Для этого можно воспользоваться следующей функцией перекодировки (Си):

void decode(char *querystr)
{
 int i=0, j=0, max=0;
 char c;
 if (querystr) max=strlen(querystr)+1;
 for (i=0, j=0; j<max; ++i, ++j)
  {
   querystr[i]=querystr[j];
   if('+'==querystr[i])
    {
     querystr[i]=' ';
    }
   else if('%'==querystr[j])
    {
     c=((querystr[j+1]>='A') ? ((querystr[j+1] & 0xdf)-'A')+10:
     (querystr[j+1]-'0'));
     c*=16;
     c+=((querystr[j+2]>='A')? ((querystr[j+2] & 0xdf)-'A')+10:
     (querystr[j+2] -'0'));
     querystr[i]=c;
     j+=2;
    }
  }
}

Применив такую функцию ко всем записям логов, содержащим символ '?' мы получим декодированные параметры любых скриптов, не только поисковых машин, которые затем можем использовать для анализа.
Точное определение количества пользователей

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

Рекомендации по решению задачи: задача весьма нетривиальная, сам я ее не решал, но, тем не менее принцип решения мне представляется так: известно, что есть целые подсетки адресов, находящихся за прокси-серверами или шлюзами. В логи при запросе любого пользователя из множества находящихся за шлюзом попадает только адрес шлюза. Обратная ситуация с dial-up пользователями, которым провайдер в момент подключения выдает динамический ip-адрес. В итоге один пользователь с разными адресами выглядит в записях лог-файла как разные. Выходом может служить только использование механизма cookie, когда каждому новому пользователю выдается уникальный идентификатор и в момент выдачи такого идентификатора данные о пользователе сохраняются сервером. Тут уже не обойдешься стандартными возможностями веб-сервера Apache, хотя у меня есть подозрение, что у некоторых коммерческих веб-серверов такие возможности имеются...
Точки входа, точки выхода, маршруты пользователей

Исходная задача: необходимо узнать, как пользователи попадают на узел (точки входа), как они уходят с узла (точки выхода), основные маршруты пользователей.

Рекомендации по решению задачи: такую задачу по слухам может решить WebTrends Log Analyzer, но он стоит денег. Мне кажется, что такую задачу следует решать так: при заходе пользователя сервер проверяет наличие в его cookies уникального идентификатора. Если такового нет сервер его выдает. То место на сервере, где происходит выдача идентификатора, будет являться точкой входа. Затем пользователь ходит по документам узла и к каждому адресу добавляется его идентификатор (что-то вроде http://your.server.ru/dir/file.ext?identifier) Все это попадает в логи и соответствующим анализатором вычисляется путь пользователя. Точкой ухода может быть либо некий тайм-аут, либо клик по внешней ссылке (внешняя ссылка должна быть сделана в форме click.cgi, только в этом скрипте еще должен быть режим уничтожения идентификатора пользователя в его cookies).