Access log что это
Анализ лог файлов сайта
Для начала анализа надо подключить логи на хостинге, что можно в несколько кликов сделать в панели управления, после чего фиксация посещения сайта и ошибок на нём при визитах посетителей и ботов будет отображаться в лог файлах, расположенных в корне домена. Для их просмотра открываем ftp-соединение с сервером через Total Commander и видим возле папки public_html (на Joomla)файлы логов, открыть которые в свою очередь можно нажав F4 и выбрав текстовой редактор.
Error.log
Этот файл показывает ошибки, возникшие при визите на сайт, и часто помогает найти косяки, которые не видны взгляду простого смертного снаружи сайта. Так в строке ошибок мы видим –
В основном анализ error.log интересен тем, что позволяет увидеть, какие документы сайта недоступны, что поможет быстро устранить недоработки по программной линии без банального тыканья пальцем в небо. Лично мне анализ лог файлов помог вывести блог из-под АГС (нервных просят не смотреть – не этот), так как там было полно программных ошибок.
Access.log
В этом документе можно посмотреть, что творится на сайте при посещениях ботами и пользователями, то есть какие HTTP-статусы отдаёт сайт при визитах, с какого адреса пришли на какую страницу, с какого адреса IP и какие боты. С помощью access.log можно отследить активность роботов и увидеть, как они читают web-документы, то есть access я бы назвал более широкоформатным дополнением к error.log.
Для тех, кто не в танке предлагаю перед анализом логов ознакомиться с HTTP-статусами, иначе пользы от напряжения ума и глаз не будет, а упростить задачу по анализу поможет бесплатная программа Awstats, которую можно поставить в панели управления практически любого хостинга.
Конечно, сидеть сутками и изучать внутренность файлов посещений и ошибок не стоит, но как часть анализа сайта сие деяние необходимо, ибо оно часто помогает понять за 5 минут то, что было тайной за семью печатями очень долго и создавало проблемы и продвижению сайта и, как следствие, заработку на нём.
Где посмотреть и как читать логи с ошибками сервера
Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
Записи в системные журналы выполняет установленный софт.
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.
Парсинг access.log апача
Как вам наверное уже известно формат записи логов можно менять настройками апача. Выше представлен формат, который устанавливается по умолчанию. В нем можно увидеть IP адрес клиента, дату и время, протокол, размер запроса, строку запроса, браузер и ОС.
Если описать кратко, то сам алгоритм разбора лога представляет из себя обработку по отдельности каждой строки файла. При обработке строки формируется массив, Каждое поле которого содержит один элемент: адрес, длину запроса, протокол и т.д. Затем уже каждый по необходимости делает с этими данными то, что ему захочется: заносит в базу данных, сразу выводит в браузер, собирает статистику, в общем решает нужную ему задачу. И так повторяется для каждой строки или для нужного количества строк.
А теперь подробнее:
Чтобы разобрать каждую строку сначала будет удобнее занести их все в один массив, где каждый элемент это строка из файла. Сделать это можно проще простого функцией file
$file_array = file(‘путь к файлу’);
Но этот метод не всегда уместен так как файл лога может состоять из нескольких тысяч строк и скрипт просто зависнет или вернет ошибку. Поэтому если вы наверняка знаете, что файл может быть или есть большого размера, то лучше реализовать задачу с помощью цикла, в котором мы просто берем следующую строку файла, разбираем ее и обрабатываем данные. Таким образом не придется создавать огромный массив сразу со всеми строками.
Вот примерно так выглядит функция для получения строки
($fp – указатель на файл, полученный ранее функцией fopen)
function get_log_string()
<
if (feof($fp))
<
return false;
>
$bits=»;
Таким образом, мы считываем по одному биту до тех пор пока не достигнем конца строки. Если достигнут конец файла то возвращаем false.
Теперь собственно переходим непосредственно к самому разбору строки.
Я сделал это с помощью функции preg_match и регулярных выражений. Задаем шаблон
$pattern – наш шаблон
$line – строка для разбора
$result – массив, в который будут записаны полученные результаты
Для удобства массив можно привести в удобочитаемый формат
Вот собственно и все. Мы получили массив с данными из строки лога. Теперь с этими данными можно делать то, что вам необходимо в конкретном случае.
Блокировка по access_log, легкий способ прострелить ногу или устранение конкурентов
Очередной пример, как легко прострелить себе ногу, на этот раз «переусердствовав» при защите сайта.
Имён как всегда не называю, однако история показательна как-таковая, т.е. в качестве примера, как не надо «защищать» свои сервера. Эх говоришь им, говоришь — а все без толку.
Пришлось тут намедни делать «аудит» одного коммерческого проекта… ну очень просили.
Упала посещаемость сайта, не совсем чтобы совсем, но довольно заметно. Смотрели логи, аналитику поисковиков и т.д. и т.п. Все вроде нормально, и кто приходит, тот даже не уходит сразу.
Но не буду ходить вокруг, да около — проанализировав логи банов по IP выяснилась одна закономерность — за короткое время в бан попадало огромное количество IP-адресов. Все поголовно по одной причине — якобы как botsearch. Отротированные логи за последний месяц тоже ужасали своими размерами и даже заглядывать туда не нужно было, и так все ясно. Т.е. случилось следующее: куча клиентов просто не могла попасть на сайт.
На вопрос «что-то меняли где-то с месяц назад?» был получен отрицательный ответ.
Однако тем же самым образом можно выстрелить себе в ногу, например просто активировав в fail2ban некоторые jail, использующие такие фильтры как «nginx-botsearch», «apache-botsearch» или множество других фильтров, натравливаемых на access-log веб-сервера, в огромном количестве курсирующих в интернете для «защиты» от ботов. Вот например, очередной такой фильтр, ожидающий пул-реквестом в fail2ban. И таких сотни и описаний к ним еще больше.
Но вернемся к самой атаке. Что примечательно, скорее всего эти нехорошие люди наняли кого-то из blackhat-ов (ну не сами же они до этого дошли) вероятно для взлома сайта конкурентов. Возможно нужна была база клиентов, или искали способ для лучшего ддоса, да мало ли чего еще. Ну а те, обнаружив такую «защиту» от дурака, уже вероятно продали им несколько URL или же сам include, как простую возможность «устранить конкурента». В любом случае, вероятность, что такая практика уже массово не взята на вооружение, отлична от нуля.
Домыслы — домыслами, однако факт «атаки» и какой-никакой урон налицо.
Поэтому будьте бдительны и включайте уже голову. Ну или зовите знакомого ресерчера…
Access-логи сайта для seo: автоматический анализ и отправка отчетов в Telegram
В данной статье описан пошаговый мануал по скачиванию логов с сервера, их объединении и парсинге с помощью Python, а также формирование необходимых отчетов с последующей отправкой в Telegram. Подробные комментарии приведены в коде соответствующих скриптов.
В предыдущей статье “Набор Python-скриптов для автоматизации seo задач” я уже затрагивал тему анализа access-логов сайта в целях seo-оптимизации. В данной статье не будет подробного описания, что такое логи и для чего их анализировать. В качестве теории приведу несколько ссылок на ресурсы, которые встречал за последнее время:
Данный подход будет полезен для изучения логов больших сайтов (от 1 млн. строк). Преимущества подхода: делаем свой бесплатный инструмент с кастомными отчетами.
Работа над логами будет проходить в несколько этапов:
Каждый этап вынесен в отдельный скрипт, который отрабатывает в установленное время на выделенном сервере по cron.
Логи анализируемого сайта в моем случае хранятся на выделенном сервере в виде gz архивов.
Подход по скачиванию файлов, представленный в данной части, индивидуален, и предназначен для работы конкретного анализируемого сайта. Однако, часть рассмотренных подходов поможет вам настроить получение файлов для вашего сайте.
Задача данного скрипта каждый день в 23:55 скачивать с сервера и разархивировать логи за последние 7 дней.
Следующим шагом будет предобработка получившихся лог-файлов, построение и сохранение отчетов. Предобработка файлов заключается в их склейке, парсинге нужных полей и сохранении в csv.
Важно отметить, что большая часть отчетов, например, отчет по посещаемым разделам, также формируется для конкретного сайта, поэтому не забываем перестроить отчет под анализируемый проект.
В результате работы данного скрипта получаем csv файл с распарсенными логами (в моем случае анализируемый файл получился 644 MB) и набор сохраненных отчетов, которые будем использовать в дальнейшем для отправки.