Логи сервера где посмотреть

Логи сервера где посмотреть

Зачем нужны логи?

Есть несколько видов логов:

  1. Логи доступа. Показывают, какой пользователь, в какую дату и время, по какой ссылке перешел на ресурс и каков был получен ответ. Данные записи помогают найти уязвимое место, если ресурс взломают.
  2. Логи ошибок. Показывают ошибки, выдаваемые при функционировании сайта либо в процессе обращения к его некоторым функциям. Здесь есть возможность отыскать и ликвидировать баг, приводящий к ошибке.
  3. Другие логи. Фиксируют события в различных серверских компонентах: логи почты сервера и т.п.

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

В таком случае системные администраторы или seo специалисты начинают анализировать посетителей, идентифицировать доступ к файлам со стороны постороннего лица, а именно IP-адрес, откуда он был осуществлен, после чего делают соответствующие выводы.

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

Анализ логов сервера

Рассмотрим строку, взятую с записи одного из логов сервера:

site.ru 85.91.97.104 — — «GET /page/3/ HTTP/1.0» 200 70214 «-» «Ahrefs Bot (http://www.ahrefs.com/bot; bot@ahrefs.com)»

И рассмотрим значение всех символов, которые здесь есть:

  • site.ru – адрес рассматриваемого ресурса
  • 85.91.97.104 – IP-адрес пользователя, посетившего сайт, после которого идет дата и время перехода на страницу и часовой пояс
  • GET – запрос, означающий получение данных. Может быть еще запрос POST, то есть, отправка данных, к примеру, авторизация на сайте
  • page/3 – обращение сделано к 3-й странице
  • HTTP/1.0 – протокол пользователя, посредством которого он зашел на ресурс
  • 200 – код ответа, отправленного сервером посетителю
  • 70214 – число байт, переданных пользователю
  • Ahrefs Bot (http://www.ahrefs.com/bot; bot@ahrefs.com) – данные о пользователе или боте, с какого устройства он зашел, какую ОС использует и т.п. В нашем случае это бот парсера ahrefs.

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

  • WebAlyzer;
  • Webtrends;
  • Awstats.

И это далеко не все программные обеспечения, которые можно найти в сети. Они есть и в платном, и в бесплатном доступе.

На некоторых хостингах их можно установить при включении логов. Например в ранее нами рассматриваемом хостинге Beget.com когда мы включаем логи, нам предлагается установить Awstats.

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

Лог ошибок error.log

Это файл, где тоже протоколируются логи, но они относятся не к пользователям, а к ошибкам, возникающим на сервере. Аналогично файлу access.log, в error.log каждая отдельная строка показывает запись только одной ошибки. Благодаря этому файлу можно узнать причину возникновения ошибки и ее тип, а также IP пользователя, которому она была показана. Рассмотрим пример:

PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14

  • Первая строка: дата и время/тип записи error (ошибка), а также IP адрес пользователя.
  • Вторая: событие PHP Notice – уведомление, расшифровка Undefined variable – неизвестная переменная.
  • Третья: путь к файлу с уведомлением и строка.

Здесь мы наблюдаем ошибку в модуле контактов, в файле default.php в строке 14.

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

Что такое «логи сервера», как посмотреть логи сервера

Понятие
Логи сервера (лог-файлы, журнал сервера) — фалы, хранящиеся на сервере, которые содержат системную информацию сервера, а так-же протоколирующие все возможные данные о посетителе веб-ресурса.
Логи используются системными администраторами для анализа посетителей, изучения закономерности поведения определенных групп пользователей, а так-же получения различной информации о них, такой как: используемый браузер, IP адрес, данные о географическом положение клиента и многое другое. По мимо анализа, таким образом можно узнать о несанкционированных доступах к сайту, точнее узнать, кем именно он был произведен, и передать данные о данном случае в соответствующие органы.
Данные в лог-файле, в чистом виде, будут не понятным рядовым пользователям, которые увидят во всем этом всего-лишь набор символов в непонятном порядке. Но для системных администраторов и веб-разработчиков, это является вполне читабельным текстом, и довольно полезной информацией.
log.jpg (60.14 КБ) Просмотров: 20496
Последовательность событий
При каждом обращении клиента к веб-ресурсeсе, срабатывают сразу несколько событий, о последовательности которых мы и поговорим.
1. Осуществление запроса страницы. При вводе адреса в браузерную строку, либо при переходе по активный веб-ссылке, допустим, со страницы поисковой выдачи, браузер осуществляет поиск и соединение с сервером, на котором расположена страницы, и осуществляет ее запрос. При этом, он передает серверу такую информацию:
— IP-адрес компьютера клиента, который запрашивает страницу (в случае использования прокси-сервера, IP адрес вашего прокси);
— адрес запрашиваемой пользователем интернет-страницы (IP-адрес);
— точное время и дата, когда был осуществлен запрос;
— данные о фактическом местонахождении клиента (в случае если используется прокси-сервер, то фактический адрес прокси);
— информация об используемом клиентом браузере (название, версия и т.д.);
— данные о веб-страницы, с которой был осуществлен переход клиента.
2. Передача запрашиваемых данных. Происходит передача запрашиваемых данных (интернет-страница, файлы, cooki, и др.) от сервера на компьютер пользователя.
3. Запись в журнал сервера. После всего, происходит запись в журнал, в котором указываются все данные, которые фигурировали в прошлых двух событиях. Это вся информация отправленная в первом пункте, а так-же информация о переданных данных.
Как посмотреть логи сервера
Лог-файлы, хранятся в файле access.log не зависимо от того, каким типом веб-сервера вы пользуетесь (Apache, Nginx, прокси-сервером squid и т. д.) Данный файл является текстовым документом, на каждой строчке которого, записывается по одному обращению. Форматов записи в access.log довольно много, но наиболее популярным является combined, при котором, запись имеет следующий вид и последовательность:
Код: Выделить всё %h %l %u %t \»%r\» %>s %b \»%{Referer}i\» \»%{User-Agent}i\»
Где:
%h — хост/IP-адрес, с которого произведён запрос;
%t — время запроса к серверу и часовой пояс сервера;
%r — версия, содержимое и тип запроса;
%s — код состояния HTTP;
%b — количество отданных сервером байт;
%{Referer} — URL-источник запроса;
%{User-Agent} — HTTP-заголовок, с информацией о запросе (клиентское приложение, язык и т.д.);
%{Host} — имя Virtual Host, к которому идет обращение.
в готовом виде данная строка имеет примерно следующий вид:
На чтение логов в ручную, уйдет довольно много времени и сил. Поэтому, опытные веб-мастера используют специальное программное обеспечение, которые называют «Анализаторы лог-файлов». Они анализируют все данные, которые довольно сложны к прочтению человеком, и выдают структурированные данные. Это такие программы как: Analog, WebAnalizer, Webalizer, Awstats, Webtrends, и т.д. Видов специального программного обеспечения довольно много, среди них есть как платные программы, так и бесплатные. Поэтому я уверен, что каждый найдет себе что-то по душе.
Где найти логи сайта
Если у вас обычный хостинг, то скорей всего вам придется написать своему хостеру и запросить у него логи. Так-же, довольно часто, вы можете запросить их через панель хостера. У разных хостеров — по разному. Для примера, что бы запросить у моего хостера, достаточно сделать один клик на главной странице панели:
logi-sayta.png (23.46 КБ) Просмотров: 20496
Если у вас есть доступ к системным папкам сервера, то вы можете найти логи по адресу /etc/httpd/logs/access_log в 99 случаях из 100.
Журнал ошибок error.log
Error.log — файл, в котором так-же ведутся логи. Но не посетителей, а возникших на сервере ошибок. Как и в случае с access.log, каждая строка файла — отвечает за одну возникшую ошибку. Запись ведется с учетом такой информации, как: точная дата и время возникновения ошибки, IP-адрес которому была выдана ошибка, тип ошибки, а так-же причина ее возникновения.
Заключение
Логи являются довольно мощным и информативным инструментом, с которыми необходимо работать. Но в наше время, их заменяют такие инструменты, как Яндекс.Метрика, Google Analytics и т.д., тем самым упрощая нам жизнь. Однако, если вы планируете развиваться, расти и познавать что-то новое, несомненно рекомендую вам познакомиться с данной темой поближе.

Один из лучших способов отследить письмо — это изучить логи почтового сервера. В данной заметке речь пойдет о разборе файла журналов exim.

Стоит отметить, что предварительный отбор необходимо сделать с помощью утилиты exigrep, она позволяет собрать в воедино все сообщения о пути следования письма в пределах вашего сервера.

Перемещение сообщения

Рассмотрим вариант успешного прохождения письма:

2012-09-21 22:35:13 SMTP connection from :39655 I=:25 (TCP/IP connection count = 1) 2012-09-21 22:35:14 1TF5G6-0007S7-Bw <= munin@domain.ru H=host.domain.ru :39655 I=:25 P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=742 id=E1TF5G5-0000dd-6G@host.domain.ru T=»Munin notification for host.domain.ru» from <munin@host.domain.ru> for monitoring@mydomain.ru
2012-09-21 22:35:14 1TF5G6-0007S7-Bw => monitoring <monitoring@mydomain.ru> F=<munin@host.domain.ru> P=<munin@host.domain.ru> R=virtual_user T=virtual_localdelivery S=862 QT=0s DT=0s
2012-09-21 22:35:14 1TF5G6-0007S7-Bw Completed QT=0s

Начало строк

Каждая строка начинается с временной отметкой:

2012-09-21 22:35:14

сразу же за ней идет ID процеса Exim:

а следом внутренний ID полученного письма:

1TF5G6-0007S7-Bw

Утилита exigrep собирает разбросанные строки в файле логов Exim воедино именно по ID письма. В нагруженном сервере, строки относящиеся к одному и тому письму могут идти разрозненно.

Строка информации о SMTP соединении

Здесь более или менее все понятно: нам сообщается с какого хоста:порта :39655 произошло подключение к нашему серверу I=:25. Чаще всего эту строку вы не увидите, и в выводе exigrep будет всего три строки.

Первая строка “<=”

Первая строка начинается со знака “<=”, который означает, что в этой строке содержится информация о прибытие письма на наш сервер. Сразу же за этим знаком идет адрес электронной почты, с которой это письмо было отправлено.

Далее с “H=” указывается имя хоста, с которого пришло письмо, в квадратных скобках следом идет IP адрес сервера отправителя, и следом TCP порт. Информация о сервере получателя начинается с “I=” и обозначения схожи.

После обозначений сервера отправителя “H” и получателя “I” идет информация о протоколе, который использовался для доставки письма. В данном случае это esmtps. Обратите внимание, что “P” в этой строке означает протокол только потому, что это строка с “<=”, в случае, если знак был бы “=>”, то за буквой “P=” следовал бы “return path” полученного сообщения.

Буква “X” сообщаем нам и шифре, который использовался для установления соединения. В большинстве случаев, это не та информация, которая может потребоваться при решении вопросом с прохождением почты. “CV” символизирует статус проверки сертификата, а “S=742” обозначает размер письма.

Далее, информация в “id=” относится к ID сообщения, т.е. идентификатору письма, который был сформирован на сервере отправителя и добавлен в почтовые заголовки. “T” (topic) — это тема письма, и наконец строка завершается “for monitoring@mydomain.ru”, сообщая нам для кого предназначено данный email, т.е. адрес получателя.

Вторая строка “=>”

Вторая строка с “=>” очень простая для трактовки, ничего сложного нет. Стоит еще раз отметить, что буквы здесь в совокупности с “=>” могут обозначать совсем иное нежели в предыдущей строке с “<=”. Первое, что мы видим здесь после знака, это имя и адрес получателя письма, дальше “F=” — это адрес отправителя. Адрес для возврата письма идет сразу после “P=”.

Буквой “R=” обозначен (в нашем примере “virtual_user”) локальный идентификатор роутера, который и стал причиной записи этой строки в журнал Exim. Транспорт, с помощью которого было доставлено письмо обозначен буквой “T” (здесь “virtual_localdelivery”). Опять размер “S=”, время ожидания в очереди “QT” и время ожидания доставки “DT”.

Третья строка

Сообщение об успешной доставке.

Дополнительные ссылки

Как читать логи сервера

05.10.2017 15:33

Что такое логи?

Краткая справка из Википедии:

Файл регистрации, протокол, журнал или лог (англ. log) — файл с записями о событиях в хронологическом порядке. Различают регистрацию внешних событий и протоколирование работы самой программы — источника записей (хотя часто всё записывается в единый файл). Например, в лог-файлы веб-сервера записывается информация, откуда пришёл тот либо иной посетитель, когда и сколько времени он провел на сайте, что там смотрел и скачивал, какой у него браузер и какой IP-адрес у его компьютера.

Для чего нужны логи?

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

Как включить запись логов?

Обычно, по умолчанию, для экономии дискового пространства ведение логов на хостинге выключено.

Приведу включение записи на примере панели управления хостингом Таймвеб.

В панели управления переходим во вкладку «Логи», выбираем из выпадающего сайта нужный (если их несколько) и активируем ползунок «Лог доступа (access_log)»

Примерно через час, когда накопится достаточное количество записей, переходим в директорию сайта и скачиваем файл.

Открываем в любом текстовом редакторе (на примере второй столбец, с адресом сайта закрашен).

Разберем для примера строку № 49

site.ru 85.93.93.102 — — «GET /page/2/ HTTP/1.0» 200 80195 «-» «Linguee Bot (http://www.linguee.com/bot; bot@linguee.com)»

site.ru – адрес нашего сайта

85.93.93.102 – IP-адрес посетителя, с датой и вренем посещения, а также его часовой пояс

GET – тип запроса, возможен вариант POST, чем отличается GET и POST можно почитать в сети, если говорить упрощено, GET – получение данных, POST – отправка, например авторизация

page/2 – к какой странице было обращение, в нашем случае это site.ru/ page/2

HTTP/1.0 – протокол, по которому пришел посетитель

200 – код ответа сервера, более подробную информацию о кодах состояния можно прочитать в Википедии — https://ru.wikipedia.org/wiki/Список_кодов_состояния_HTTP

80195 – количество байт полученных посетителем

Linguee Bot (http://www.linguee.com/bot; bot@linguee.com) – данные о посетителе, тут также может быть информация о браузере, операционной системе, устройстве и так далее

Итог

Даже при беглом взгляде видно, что с адреса 85.93.93.102 идет множество запросов, обращение было как раз по чрезмерной нагрузке на сайт, как только адрес бота Linguee Bot был запрещен, нагрузка практически сразу вернулась в норму.

И все за несколько минут, благодаря логам; без них на выяснение причины понадобилось бы гораздо больше времени. Также были замечены обращения по адресам, содержавшим вставки типа — xd0\xbe\xd1\x82\xd0\xb7\ …

Кто занимается «лечением» сайтов, знает, что подобные запросы могут создавать запредельные нагрузки на сервер.

Иногда самые простые методы – самые действенные, а защита на уровне сервера самая надежная.

Засим прощаюсь


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *