Уже 24 страницы речь идет о Velocity.

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

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

Вот, скажем, у бота яндекса подпись такая: Yandex/1.01.001 (compatible; Win16; I) . Но мы не можем быть уверены, что она останется такой и в будущем. Поэтому нужно ориентироваться на какой-то паттерн. Вопрос - какой именно? Если выискивать в тексте слово Yandex, то это может показаться надежным, но вот беда: помимо основного бота есть еще бот картинок с индексом P: Yandex/1.01.001 (compatible; Win16; P), и дифференциальный с индексом D, и даже какой-то Yandex/2.01.000 (compatible; Win16; Dyatel; Z) сейчас промелькнул. Можно, конечно, свалить их все в одну категорию - Yandex, а там уж разбираться, что к чему. Но можно и дать им индивидуальные имена и различать по отдельности. Единого рецепта тут нет.

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

Теперь о том, где и как разместить код распознавания ботов. Можно, конечно, навалить все кучей в конструкторе LogEntry, а то и еще того хлеще - в логике сервлета-контроллера. Но это, как мы понимаем, будет не комильфо. Правильнее изолировать это хозяйство в отдельное место, чтобы его легко можно было найти и при необходимости подкорректировать. Как, например, нам такая иерархия: интерфейс BotDetector - реализации под конкретные боты?





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

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

Как, кстати, вообще система логирования, получается?

Пиши

Сама система логирования готова.  Выше, можно сказать, что я представил ее в полном объеме.

На счет ботов: Когда то, блуждая по просторам интернета, я натыкался на огромный список "хороших ботов". Попробывал его найти и пока, не получилось. Кто видел, дайте линк?

Начал думать над отчетами и запросами. Пишу запросы потихоньку. Давно я не замарачивался с SQL:)  Вспоминаю, разбираюсь...

В данный момент работа стоит, грипп напал, мать его за ногу...

Тебе не нужен огромный список хороших ботов. Хорошие - только те, которые могут привести трафик, а их можно сосчитать по пальцам: яндекс, рамблер, гугль и мейл.ру. От мсн и яху ничего кроме ботов не видел, так что толку ноль. Вот этим вот хорошим ботам и нужно разрешить доступ в robots.txt. А всех остальных отлавливать по referer и сразу бить по рукам - возвращать, например, код 403 (доступ запрещен). А потому как не уважают директивы robot.txt. Но такой блокировщик лучше написать отдельно, и оформить его в виде фильтра со своей конфигурацией.

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

[data]
[manager]
[report]
[util]
[robot]
[SGPSD.class]

см. прикрепленный файл.

ControllerServlet принял следующий вид:




Это желание уже появилось. Поискал в инете, инфу у самих поисковиков, и так и не нашел как идентифицировать эти данные.

Это сообщение отредактировал(а) diablero - 15.4.2008, 19:41

Присоединённый файл ( Кол-во скачиваний: 32 )
 sgpsd.zip 4,15 Kb

Ну что я могу сказать - молодец, растешь. Все четко и грамотно. Что изолировал - тоже очень правильное решение: позволит легко переиспользовать в других проектах. Так что держи от меня плюса - впервые в сериале! 



Ну, что касается анализа заходов с поисковиков, то тут все проще пареной репы: заходишь браузером в рамблер/яндекс/гугл с любым запросом, и изучаеншь УРЛ страницы выдачи. Например:

www.google.com/search?q=%D0%B2%D0%B8%D0%BD%D0%B3%D1%80%D0%B0%D0%B4&hl=en&start=40&sa=N

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

Проанализировал пока Rambler, Yandex и Google. В этом деле мне помогла Опера, которая если навести курсор на вкладку, показывает запрос и кодировку.

Гемор вылез с яндексом. Мне абсолютно не понятено почему урл для первой страницы в utf-8, а для всех последующих они перекодируют его в windows-1251. 

Реализованно все следующим образом:





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

Тестировал на пару тройках запросах. Если что подправлю.

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

Чтобы исправить сие, я решил разбить исходную таблицу на две:
- ClientEntry
- HintEntry

Вновь испеченные сущности имеют следующую структуру:
HintEntry:
- id;
- userName;
- date;
- method;
- bytes;
- millis;
- search;
- postTitle.

ClientEntry:
- id;
- date;
- host;
- refererUrl;
- userAgent;
- bot;
- query;
- page;

Объект ClientEntry создается только один раз при открытии сессии, а HintEntry на каждый хинт.

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

ControllerServlet принял следующий вид:


Вся система в аттаче.



Ты можешь объяснить сей механизм? Очень хочу реализовать эту фичу


Присоединённый файл ( Кол-во скачиваний: 21 )
 sgpsd.zip 7,99 Kb

diablero, да на здоровье! Сайт все-таки твой, и его потребности тебе известны лучше как кому бы то ни было. Нравится в две таблицы - пускай будет в две.

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

• Юзера, к сожалению, не так просто идентифицировать. если только он не зареген и залогинен. И лучше всего это делать через кукисы, а не через сессию. Через долгоживущие кукисы у тебя будет возможность выявлять постоянных посетителей, смотреть как часто и с какой страницы они начинают просмотр, где и сколько времени проводят, на какой странице заканчивают. Пускай у него нет имени, но уникальный ID в куку прописать-то можно. И еще один нюанс: в самый первый заход этой куки в запросе еще не будет, а между тем первый заход представляет исключительную важность - из него мы узнаем, откуда человек пришел (заголовок referer). Выход заключается в том, чтобы при формировании лога использовать не само значение куки, а какую-то переменную, инициализируемую значением куки, а если таковое отсутствует, то вновь сгенерированное значение.
  
• Поле userName относится скорее к клиенту, а вот refererUrl - к хиту. Кстати, хинт - это по-английски подсказка, намек, а применительно к логированию используется понятие хита (hit - здесь: заход).
  
• Поскольку поисковики не поддерживают кукисы, каждый заход бота будет порождать отдельную сессию (ну, если только не использовать для всех внутренних ссылок URL rewriting, но это запаришься) и соостветственно кучу записей в таблице ClientEntry. Чтобы этого избежать, специально для ботов (то есть если клиент распознался как один из известных системе ботов) вместо client ID лучше использовать имя бота.

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

Думал, думал, не выходит у меня каменный цветок Либо я чего-то не понимаю, либо не до понимаю.

1.    Вариант с кукисами. Как мне кажется, это может стать ахиллесовой пятой в системе. Создавать объект ClientEntry лучше при открытии сессии, а выявлять постоянных посетителей, смотреть как часто и с какой страницы они начинают просмотр, где и сколько времени проводят, на какой странице заканчивают уже можно на основе кукисов. 

2.    Про поле userName и refererUrl. Имеет значение только первое значение refererUrl, что у меня берется один раз при открытии сессии. Все последующие значение смысла не имеют.  Лучше добавить к hit поле url. Поле userName в hit, чтобы иметь информацию от зарегистрированных пользователей. Все остальные, это просто все остальные.





Тут я вообще ничего не понял. Ну создам я ClientEntry зная что это бот, куда я потом дену этот объект, ведь при следующем запросе к сайту, в любом случае создаться новая сессия. Чтобы не пораждать кучу записей ClientEntry, придется ложить объект в сессия независемый контент.




какие?

Знаете, уважаемые. А меня всё равно утомляет писать на Java. Смотрите сами: я пишу быстренько какой-то код, теперь чтобы его запустить я должен запустить приложение на сервере, а это на моей тачке занимает около 10-20 секунд. Обидно. чтобы ввести изменение в программный код мне нужно столько времени! На стадии разработки руки просто опускаются. Слава Богу с Velocity проще, подсунул на сервере в нужную папку новую версию верстки и наслаждаешься результатами. Но в целом за Web on Java браться ой как не хочется!

Platon
У меня средних размеров проект стартует на Tomcat 6 в Eclipse WTP секунд 5-7. Нормально, чтобы вздохнуть и перевести дух  Это конечно зависит от стиля программирования -- кому как часто надо собирать и запускать то что пишешь..

Это сообщение отредактировал(а) Maksym - 14.5.2008, 17:15

Я уж не знаю чего такого можно быстренько написать, да так чтобы старт сервера занимал столько времени.
У меня например сейчас в основном проекте более 100 классов, и куча еще всего. На ноутбуку старт занимает в среднем 2-3 секунды.
Может вам стоит подумать об апгрейде. Или вплотную занятся ос?

Во-первых, Думаю моя машинка с 2ГГц проц и 768 МБ ОЗУ еще имеет право на жизнь. а с ОС я не понял. 
Во-вторых, я не говорил о сервере, я говорил о приложении, как называют, редеплой из IDE.

У меня Jboss в дебаг-режиме из-под иде стартует больше минуты.