Из разговора двух веб-мастеров:

– Вчера был на твоём сайте…

– Так это был ты!..

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

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

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

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

Что такое лог-файл веб-сайта

Лог-файл веб-сайта (log file , log -файл, лог-файл, лог) – это текстовый файл, в котором регистрируются все запросы к сайту, а также все ошибки, связанные с этими запросами.

Как происходит запись событий в лог-файл сайта

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

Примечания

1. По подсчётам исследовательской компании Netcraft , в июне 2009 г. в Интернете насчитывалось 238 027 855 сайтов. При этом доля веб-серверов Apache составила около 47%, Microsoft IIS – 24,80%, qq,com – 12,79%, Google – 4,98%, nginx – 3,69%, Sun – 0,30%.

2. Лог-файлы серверов Apache

Лог-файлы (logs или логи) - это текстовый файл, в котором ведется запись абсолютно всех событий, которые происходили на сервере (на котором расположен Ваш сайт). Запись событий ведется так - каждому событию соответствует определенная строчка, с указанием времени события и прочих сведений. Обычно все логи сортируются по датам - одним суткам соответствует один файл.

Как их посмотреть?

Чаще всего хостинг-провайдеры позволяют скачать эти файлы по FTP. Где именно они находятся зависит только от хостера, поэтому ищите это в FAQ или обращайтесь в поддержку. Также доступ к лог-файлам можно получить из панели управления хостингом.

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

Все лог-файлы можно разделить на три группы:

1. логи доступа (access_log) записывают информацию о посетителях сайта (IP-адрес, время запроса, страница которую он запросил)
2. логи ошибок (error_log) сохраняют все ошибки, которые происходили на сайте, и показывают файлы в которых они случились
3. логи FTP-авторизаций собирают данные о попытках входа по FTP-соединению

Как их использовать?

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

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

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

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

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

Где используются лог-файлы

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

Полезные примеры

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

Понятие

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

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

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

Последовательность событий

При каждом обращении клиента к веб-ресурс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, к которому идет обращение.

в готовом виде данная строка имеет примерно следующий вид:

127.0.0.1 - - "GET /index.php HTTP/1..0 (compatible; MSIE 7.0; Windows NT 5.1)"

На чтение логов в ручную, уйдет довольно много времени и сил. Поэтому, опытные веб-мастера используют специальное программное обеспечение, которые называют «Анализаторы лог-файлов». Они анализируют все данные, которые довольно сложны к прочтению человеком, и выдают структурированные данные. Это такие программы как: Analog, WebAnalizer, Webalizer, Awstats, Webtrends, и т.д. Видов специального программного обеспечения довольно много, среди них есть как платные программы, так и бесплатные. Поэтому я уверен, что каждый найдет себе что-то по душе.

Где найти логи сайта

Если у вас обычный хостинг, то скорей всего вам придется написать своему хостеру и запросить у него логи. Так-же, довольно часто, вы можете запросить их через панель хостера. У разных хостеров - по разному. Для примера, что бы запросить у моего хостера, достаточно сделать один клик на главной странице панели:

Если у вас есть доступ к системным папкам сервера, то вы можете найти логи по адресу /etc/httpd/logs/access_log в 99 случаях из 100.

Журнал ошибок error.log

Error.log - файл, в котором так-же ведутся логи. Но не посетителей, а возникших на сервере ошибок. Как и в случае с access.log , каждая строка файла - отвечает за одну возникшую ошибку. Запись ведется с учетом такой информации, как: точная дата и время возникновения ошибки, IP-адрес которому была выдана ошибка, тип ошибки, а так-же причина ее возникновения.

Заключение

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

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

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

Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.

Лог (log) - это специальный журнал, в котором хранится информация о состоянии работы приложения (программы).

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

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

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

Trace - максимально детальная информация о том, что происходит с целевым участком кода, по шагам . Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.

Debug - это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции . Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.

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

Warn - сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.

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

Fatal - сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.

То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.

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

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

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

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

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

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

Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно .

• ${basedir} - корневой каталог нашего приложения
• ${shortdate} - текущая дата в формате yyyy-MM-dd
• ${longdate} - текущая дата в формате yyyy-MM-dd HH:mm:ss.ffff
• ${callsite} - место вызова лога (название класса, название метода)
• ${uppercase:${level} - уровень логирования
• ${message} - непосредственно сообщение, которое будет записано в лог
• ${newline} - символ новой строки

Public class StudentsRepository { private static Logger logger = LogManager.GetCurrentClassLogger(); //... }

Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.

Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:

Public Student GetStudentById(int id) { //здесь моделируется ситуация реальной выборки студента из базы данных... logger.Trace("Запрашиваемый id студента: " + id); logger.Trace("Попытка подключения к источнику данных"); logger.Trace("Подключение к источнику данных прошло успешно. Затраченное время(мс): " + new TimeSpan(0, 0, 0, 0, 20).Milliseconds); var student = _studentsList.FirstOrDefault(x => x.Id == id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); return student; }

Обратите внимание, что мы на объекте logger вызываем метод Trace(). Он имеет соответствующее значение - запись в лог сообщения типа Trace. Если обратиться к определению класса Logger, то можно обнаружить, там также присутствуют и другие методы для всех уровней лога, которые мы будем использовать далее.

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

Public List GetStudents() { //здесь моделируется ситуация реальной выборки студентов из базы данных... logger.Debug("Произведено подключение к базе данных"); logger.Debug("Произведена выборка всех студентов"); return _studentsList; }

Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():

Public ActionResult GetStudent(int id) { logger.Info("Преподаватель запросил студента с id == " + id); StudentsRepository repository = new StudentsRepository(); Student student = repository.GetStudentById(id); return View(student); }

Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:

//... Student student = repository.GetStudentById(id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет"); //...

Var student = _studentsList.FirstOrDefault(x => x.Id == id); if (student == null) logger.Error("Ошибка. Не найден студент с id == " + id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет");

Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:

//... logger.Fatal("Достигнут максимально допустимый в приложении предел использования оперативной памяти 90%"); //...

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

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

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

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