Где находится файл access log
Логи сервера это текстовые файлы, которые генерирует сервер для протоколирования доступа к нему.
Текстовый файл может быть без расширения. Находится обычно в папке logs на сервере. В него заносятся результаты обращений к серверу.
Где найти и как выглядят логи
Специалисты знают где смотреть, а обычному пользователю доступ на сервер, как правило, закрыт. Однако большинство хостингов выводит логи через графический интерфейс. Таким образом позволяя пользователям самим анализировать результаты работы сайта. Чтобы найти логи посмотрите внимательно интерфейсы панели управления сайтом.
Так выглядит папка с логами на хостинге hostland через фтп проводник:
В данном случае это запакованные текстовые файлы. Скачиваем на компьютер нужный (по дате и веремни создания), распаковываем и смотрим любым тестовым редактором.
Если затруднились найти, то почитайте справку или обратитесь в техподдержку.
Вот это, например, строки из одного такого файла
Не очень показательно тут. На самом деле одна запись занимает одну строку. Записи разделены в файле построчно. Новая запись - новая строка.
Как читать лог сервера
Разбиваем строку на части:
1. 109.173.59.49 - IP адрес с которого был запрос
2. [03/Apr/2015:12:56:18 +0300] - дата и время запроса
3. GET или POST - тип запроса, иногда можно встретить определение "метод запроса"
4. /sites/all/modules/fivestar/widgets/default/star.jpg - объект запроса
6,7. 200 434 - коды ответа сервера . В данном случае запрос прошел (код 200 ОК), но запрашиваемая страница недоступна (код 434 запрашиваемый адрес недоступен)
9. "Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.16" - данные о постетителе , с какой системы пришел запрос
В целом это какая страница запрашивалась, с какой странице пришел запрос и что в ответ выдал сервер. А что в каком порядке утверждать не возьмусь без справочника. Главное, что общая картина понятна.
В целом иерархия такая: сайт - страница - объект на странице - объект на объекте.
Коды лога сервера
Можно особо не заморачиваться, если понимать общий принцип кодов. Он прост. Первая цифра определяет группу кодов. Последние уточняют сам код.
2хх - всё хорошо и ответ получен
3хх - ответ получен, но будет перенаправление
4хх - ответ получен, но в результате объект недоступен. Сайт доступен, но материала нет.
5хх - ошибка сервера. Тут проблемы глобальные. Или база данных рухнула или сервер полетел.
Деление лог файлов по типам
Хорошим тоном считается деление файлов по типам. Типов может быть множество. В основном встречаем два:
- файл с нормальными ответами.
Выше привел файл с нормальными ответами. Вот лога ошибок у меня нет. Точнее есть, но он пустой. Нет ошибок в работе сервера.
Методы POST и GET в лог файлах
Эти методы часто встречаются в лог файлах. Кроме них еще есть и другие.
МетодыOPTIONS · GET · HEAD · POST ·PUT · DELETE · TRACE ·CONNECT · PATCH
Метод указывает на тип операции с ресурсом. За подробностями можно снова сходить в википкдию и прочитать про методы доступа. На а тут кратенько.
GET - получить содержимое.
POST - метод обработки данных с возможностью отправки. Используется для диалога с пользователем (ввод пароля, комментария, адреса..).
Про остальные - в вики читайте.
Используете материал на своем ресурсе - ставьте ссылку на оригинал!
Спасибо! И пусть не будет ошибок 5 группы в логах!
Помог материал - поставьте лайк, оставьте комментарий. Это поможет и другим пользователям интернета найти решение аналогичной проблемы.
Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
Записи в системные журналы выполняет установленный софт.
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
- поиск ошибок и сбоев в работе системы;
- выявление вредоносной активности;
- сбор статистики посещения веб-ресурса.
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.
Лог-файл access.log в папке /var/log/nginx/ очень быстро наполняется.
Не совсем пойму как читать лог-файл. Вот несколько строк:
В строках нет ни URL-адресов моего сайта, ни ip-адресов. Я так понимаю выполняется GET запрос по одному из адресов выше. Только причем тут мой сервер? Как это остановить? =)
Из-за быстрого увеличения логов пропадает место на диске.
Я попробовал настроить logrotate для nginx вот так. Поставил ограничение на 5М, но толку нет. После преодоления размера в 5М лог продолжает расти, а не превращается в архив.
Простой 5 комментариев
какой-нибудь fail2ban
Или забить Похоже на работу сканера прокси, учитывая GET запросы к чужим сайтам
Тут у человека такая же проблема
по факту - на 99% это запроса от бота:
* ip адрес 5.9.89.80 - из пула хостера Hetzner
* 499 - бот не дождался ответа сервера и сразу закрыл соединение
* да и запросы некорректные (если стандартный формат лога не меняли) - там не должно быть протокола и хоста, то есть вместо должно быть "GET /en/?DT9FBEYS4L71I1P8OS HTTP/1.1"
- самое простое забанить ip на firewall
по поводу logrotate:
Обычно он запускается всего 1 раз в сутки (скрипт лежит в /etc/cron.daily) и сразу по достижению 5М ничего не произойдет. Более того параметр delaycompress говорить что первая копия (*.log.1) архивироваться не будет, сожмется только вторая.
хотите - можете перенести /etc/cron.daily/logrotate в /etc/cron.hourly и запуск logrotate будет каждый час
Обратите внимание на запросы, они все со статусом 499, вас тупо атакуют, чтобы загрузить ваш сервер.
Логи Apache в Windows
В Windows имеются особенности настройки имени файла журнала — точнее говоря, пути до файла журнала. Если имена файлов указываются с начальной буквы диска, например "C:/", то сервер будет использовать явно указанный путь. Если имена файлов НЕ начинаются с буквы диска, то к указанному значению добавляется значение ServerRoot — то есть «logs/access.log» с ServerRoot установленной на "c:/Server/bin/Apache24", будет интерпретироваться как "c:/Server/bin/Apache24/logs/access.log", в то время как "c:/logs/access.log" будет интерпретироваться как "c:/logs/access.log".
Apache error: ошибки сервера и сайтов
Путь до файла журнала с ошибками указывается с помощью ErrorLog, например, для сохранения ошибок в папке "logs/error.log" относительно корневой папки веб-сервера:
Журнал ошибок обычно записывается в файл (обычно это error_log в системах Unix и error.log в Windows и OS/2). В системах Unix также возможно, чтобы сервер отправлял ошибки в системный журнал или передавал их программе.
Если поместить токен %L в журнал ошибок и журнал доступа, будет создан идентификатор записи журнала, с которым вы можете сопоставить запись в журнале ошибок с записью в журнале доступа. Если загружен mod_unique_id, его уникальный идентификатор запроса также будет использоваться в качестве идентификатора записи журнала.
Во время тестирования часто бывает полезно постоянно отслеживать журнал ошибок на наличие проблем. В системах Unix вы можете сделать это, используя:
Apache access: логи доступа к серверу
Журнал доступа к серверу записывает все запросы, обработанные сервером. Расположение и содержимое журнала доступа контролируются директивой CustomLog. Директива LogFormat может быть использована для упрощения выбора содержимого журналов. В этом разделе описывается, как настроить сервер для записи информации в журнал доступа.
Общий формат журнала (Common Log)
Типичная конфигурация для журнала доступа может выглядеть следующим образом.
В первой строке задано имя (псевдоним) common, которому присвоено в качестве значения строка "%h %l %u %t \"%r\" %>s %b".
Строка формата состоит из директив, начинающихся с символа процента, каждая из которых указывает серверу регистрировать определённый фрагмент информации. Литеральные (буквальные) символы также могут быть помещены в строку формата и будут скопированы непосредственно в вывод журнала. Символ кавычки (") должен быть экранирован путём размещения обратной косой черты перед ним, чтобы он не интерпретировался как конец строки формата. Строка формата также может содержать специальные управляющие символы "\n"для новой строки и "\t" для обозначения таба (табуляции).
В данной строке значение директив следующее:
Директива CustomLog устанавливает новый файл журнала, используя определённый псевдоним. Имя файла для журнала доступа относительно ServerRoot, если оно не начинается с косой черты (буквы диска).
Приведённая выше конфигурация будет сохранять записи журнала в формате, известном как Common Log Format (CLF). Этот стандартный формат может создаваться многими различными веб-серверами и считываться многими программами анализа журналов. Записи файла журнала, созданные в CLF, будут выглядеть примерно так:
Каждая часть этой записи журнала описана ниже.
127.0.0.1 (%h)
Это IP-адрес клиента (удалённого хоста), который сделал запрос к серверу. Если для HostnameLookups установлено значение On, сервер попытается определить имя хоста и зарегистрировать его вместо IP-адреса. Однако такая конфигурация не рекомендуется, поскольку она может значительно замедлить работу сервера. Вместо этого лучше всего использовать постпроцессор журнала, такой как logresolve, для определения имён хостов. Указанный здесь IP-адрес не обязательно является адресом машины, на которой сидит пользователь. Если между пользователем и сервером существует прокси-сервер, этот адрес будет адресом прокси, а не исходной машины.
- (%l)
frank (%u)
[10/Oct/2000:13:55:36 -0700] (%t)
Время получения запроса. Формат такой:
Можно отобразить время в другом формате, указав %t в строке формата журнала, где формат такой же, как в strftime(3) из стандартной библиотеки C, или один из поддерживаемых специальных токенов. Подробности смотрите в строках формате строки mod_log_config.
200 (%>s)
2326 (%b)
Последняя часть указывает размер объекта, возвращаемого клиенту, не включая заголовки ответа. Если контент не был возвращён клиенту, это значение будет "-". Чтобы записать «0» без содержимого, вместо %b используйте %B.
Логи комбинированного формата (Combined Log)
Другая часто используемая строка формата называется Combined Log Format. Может использоваться следующим образом.
Дополнительными полями являются:
Настройки логов в Apache по умолчанию
По умолчанию в главном конфигурационном файле Apache прописаны следующие настройки логов:
Как можно увидеть, установлены три псевдонима: combined, common и combinedio. При этом по умолчанию используется common. При желании вы без труда сможете переключиться на combined или настроить формат строки лога под свой вкус.
Например, если вы предпочитаете, чтобы в файле лога доступа также присутствовала информация о пользовательском агенте и реферере, то есть Combined Logfile Format, то вы можете использовать следующую директиву:
Логи сервера (журнал сервера) – это файлы, где в хронологическом порядке содержатся данные о работе сервера, записаны все действия посетителей на веб-ресурсе (откуда пришли, в каком браузере сидят, какой IP-адрес, сколько времени пробыли, какие данные получали или отправляли), а также информация, с помощью которой анализируется и оценивается сайт и его посетители.
Зачем нужны логи?
Есть несколько видов логов:
- Логи доступа. Показывают, какой пользователь, в какую дату и время, по какой ссылке перешел на ресурс и каков был получен ответ. Данные записи помогают найти уязвимое место, если ресурс взломают.
- Логи ошибок. Показывают ошибки, выдаваемые при функционировании сайта либо в процессе обращения к его некоторым функциям. Здесь есть возможность отыскать и ликвидировать баг, приводящий к ошибке.
- Другие логи. Фиксируют события в различных серверских компонентах: логи почты сервера и т.п.
Если веб-сайт работает нормально, в штатном режиме, нет необходимости просматривать лог-файлы. Но бывают случаи, когда сервер внезапно перегружается, ресурс подвергается спаму, выдает изобилие ошибок или возникают проблемы в ранжировании в поисковых системах.
В таком случае системные администраторы или seo специалисты начинают анализировать посетителей, идентифицировать доступ к файлам со стороны постороннего лица, а именно IP-адрес, откуда он был осуществлен, после чего делают соответствующие выводы.
На заметку. Для обычного пользователя такие файлы будут представлять случайный набор символов, однако для разработчиков сайтов, seo специалистов и системных администраторов логи читабельные и несут важную информацию.
Как включить журнал записей?
Здесь же вы видите путь, где располагаются ваши логи
Если у вашего хостинга в админ панели нет функции включить запись самостоятельно, то для получения логов потребуется обратиться в техподдержку хостинга и запросить их, так как они могут быть просто отключены.
Как посмотреть логи сервера?
Включив лог-файлы на сервере, уже через час соберется довольно большое количество записей, после чего можно скачать файл в директорию сайта и открыть его через визуальный редактор для просмотра.
Логи хранятся в файле access.log в системной папке любого сервера, будь то Nginx, Apache или любой другой. Лог-файлы открываются через текстовые редакторы. Любая строчка здесь соответствует не больше, чем одному обращению.
Отыскать логи можно и через панель управления хостинга, а именно в разделах Логи или Журналы.
Анализ логов сервера
Рассмотрим строку, взятую с записи одного из логов сервера:
И рассмотрим значение всех символов, которые здесь есть:
Это один из множества логов, и чтобы прочитать их все вручную, нужно потратить невероятное количество сил и времени. Но на помощь вебмастерам приходят специальные анализаторы данных, трудно читаемых человеком. Они анализируют данные, а затем структурируют их. К часто используемым программам можно отнести:
И это далеко не все программные обеспечения, которые можно найти в сети. Они есть и в платном, и в бесплатном доступе.
Успешно анализируя лог-файлы, вы сможете отыскать слабое место на сайте, из-за которого он работает нестабильно, или же идентифицировать IP, с которого вам хотят навредить. Особенно стоит обращать внимание на запросы POST, потому что именно с их помощью мошенники взламывают ресурсы чаще всего.
Лог ошибок error.log
Это файл, где тоже протоколируются логи, но они относятся не к пользователям, а к ошибкам, возникающим на сервере. Аналогично файлу access.log, в error.log каждая отдельная строка показывает запись только одной ошибки. Благодаря этому файлу можно узнать причину возникновения ошибки и ее тип, а также IP пользователя, которому она была показана. Рассмотрим пример:
- Первая строка: дата и время/тип записи error (ошибка), а также IP адрес пользователя.
- Вторая: событие PHP Notice – уведомление, расшифровка Undefined variable – неизвестная переменная.
- Третья: путь к файлу с уведомлением и строка.
Здесь мы наблюдаем ошибку в модуле контактов, в файле default.php в строке 14.
Заключение
Журнал сервера – это эффективный инструмент, позволяющий быстро получить информацию о том, где у сайта есть лазейка, из-за которой перегружается сервер. Но просматривать логи вручную – дело хлопотное, поэтому и были созданы такие специальные сервисы-анализаторы, помогающие куда быстрее найти ошибки и указать на слабые места веб-ресурса.
Оцените эту статью. Чтобы мы могли делать лучший контент! Напишите в комментариях, что вам понравилось и не понравилось!
Читайте также: