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

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

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

Поговорим о лог-файлах веб-серверов, ибо их чаще всего просматривает почти каждый первый системный администратор.

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

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

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

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

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

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

Но при анализе файлов журнала событий (лог -файлов) системным и сетевым администраторам следует учитывать, что полученные данные все же не являются на 100% реальными, отклонение в них обычно составляет 5-10% в силу различных технических и технологических особенностей используемого оборудования и его настроек. Однако если нагрузка на сайт является более-менее постоянной (иначе говоря, администрация не проводит каких-либо активных рекламных кампаний по привлечению посетителей, вследствие чего посещаемость сайта увеличивается на порядки), то полученные при передаче значения ошибок можно считать более-менее постоянными и становится возможным осуществление сравнение статистики за прошедшие периоды.

Конечно, можно читать и анализировать и сами логи , но это довольно неудобно и весьма трудоемко. Для получения сводных отчетов и статистики по лог-файлам используется специальное программное обеспечение, которое называется «Анализаторы лог-файлов». Наиболее популярными и известными являются следующие программные продукты: Analog, Webalizer, Webtrends, NetPromoter, WebAnalizer, Loganalyzer.

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

Как мы видим, логи являются весьма мощным средством для анализа деятельности посетителей на сервере.

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

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

Есть такая linux утилита, а также по совместительству сетевой протокол под названием syslog. И есть целый набор RFC посвящённый syslog, один из них описывает уровни логирования https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Согласно rfc 5424 для syslog определено 8 уровней логирования, для которых также дается краткое описание. Данные уровни логирования были переняты многими популярными логерами для разных языков программирования. Например, http://www.php-fig.org/psr/psr-3/ определяет те же самые 8 уровней логирования, а стандартный Ruby logger использует немного сокращённый набор из 5 уровней. Несмотря на формальное указание в каких случаях должен быть использован тот или иной уровень логов, зачастую используется комбинация вроде debug/info/fatal - первый для логирования во время разработки и тестирования, второй и третий в расчёте на продакшен. Потом в какой то момент на продакшене начинает происходить что то не понятное и вдруг оказывается, что info логов не хватает - бежим включать debug. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:

• что-то происходит и надо знать что
• что-то сломалось и нужно дополнительно активировать триггер

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

В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:

• Fatal - вывод в лог и немедленный выход в ОС.
• Panic - вывод в лог и возбуждение «паники» (аналог исключения)
• Print - просто выводит сообщение в лог

Запутаться, что использовать в конкретной ситуации уже практически невозможно. Но сообщения в таком сильно усеченном виде сложно анализировать, а также настраивать системы оповещения, типично реагирующих на какой нибудь Alert\Fatal\Error в тексте лога.

Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.

Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) - то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug { entity.values } . В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.

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

Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:

+ +
Где:

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

Для того, чтобы связать пары запрос\ответ часто используется http заголовок X-Request-ID . Такой заголовок может сгенерировать клиент, или он может быть сгенерирован на стороне сервера. Добавив его в контекст каждой строчки лога появится возможность лёгким движением руки найти все сообщения возникшие в рамках выполнения конкретного запроса. А в случае распределенных систем, заголовок можно передавать дальше по цепочке сетевых вызовов.

Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:

ReqLog:= log.WithField("requestID", requestID)
После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.

Резюмируя:

• Логируйте с избытком. Никогда заранее не известно сколько и какой информации в логах понадобится в критический момент.
• Восемь уровней логирования - вам действительно столько надо? По опыту должно хватить максимум 3-4, и то при условии, что для них настроены обработчики событий.
• По возможности используйте ленивые вычисления для вывод сообщений в лог
• Всегда добавляйте текущий контекст в каждое сообщение лога, как минимум requestID.
• По возможности настраивайте сторонние библиотеки таким образом, чтобы они использовали логер с текущим контекстом запроса.

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

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

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

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

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

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

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

Лог-файл

Лог-файл

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

По-английски: Log file

См. также: Лог-файлы Файлы Веб-серверы

Финансовый словарь Финам .

Смотреть что такое "Лог-файл" в других словарях:

Файл, содержащий системную информацию о работе сервера и информацию о действиях пользователей: дату и время визита пользователя; IP адрес компьютера пользователя; наименование браузера пользователя; URL запрошенной пользователем страницы; реферер … Словарь бизнес-терминов

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

Файл регистрации, протокол, журнал или лог (англ. log) файл с записями о событиях в хронологическом порядке. Ведение протокола, или протоколирование, хронологическая запись c различной (настраиваемой) степенью детализации сведений о происходящих… … Википедия

файл - у, ч. 1) спец. Сукупність взаємопов язаних блоків інформації, яка розпізнається комп ютером як одне ціле. || Набір даних на логічному рівні розглядання. Контро/льний файл файл, створений виконуваними операторами для забезпечення контролю за… … Український тлумачний словник

лог - 1) овраг с пологими травянистыми склонами и плоским дном; 2) комп.жарг. создаваемый комп. программой файл отчёта, содержащий сведения о выполненных операциях … Универсальный дополнительный практический толковый словарь И. Мостицкого

На иллюстрации Джона Чарльза Доллмана … Википедия

Radminer сетевой червь, занимающийся самораспространением посредством протокола крэкерами, освоившими протокол RAdmin и решившими применить знания на практике, для создания сообственного децентрализованного ботнета. В качестве примера будет… … Википедия

- (кейлоггер) (англ. key клавиша и logger регистрирующее устройство) это программное обеспечение или аппаратное устройство, регистрирующее каждое нажатие клавиши на клавиатуре компьютера. Содержание 1 Виды информации, котор … Википедия

Кейлогер, кейлоггер (англ. keylogger, правильно читается «ки логгер» от англ. key клавиша и logger регистрирующее устройство) это программное обеспечение или аппаратное устройство, регистрирующее различные… … Википедия

SHARE

TWEET

Untitled

A guest Jan 16th, 2017 335 Never

Что такое лог игры?=

""Log (лог)"" – это файл в котором содержится подробный список событий из приложений, производительности системы, или действий пользователей, в хронологическом порядке. Лог или логи могут быть полезны для выявления ошибок в игре. Логи Танков X хранятся в специальном файле под названием "output_log". Чтобы посмотреть лог, нужно зайти в папку игры, далее в папку "tankix_Data".

Как предоставить лог игры?=

Если у Вас возникли какие-то проблемы с игрой, частые вылеты, лаги и так далее, то разработчики могут попросить Вас предоставить им логи игры. Как это сделать:

*В папке с игрой tankix_data есть файл output_log.txt

*Сохраните файл в любое облачное хранилище (Яндекс.Диск, Google Docs, Dropbox, где можно просмотреть файл, не скачивая его). Либо можно скопировать содержимое файла и выложить его на ресурсе http://сайт/

*Создайте новую тему на сайте http://echo.tankix.com/ (или добавьте свой лог в тему другого игрока с идентичной проблемой) вместе с подробным описанием проблемы.

Главное, после проявления ошибки не перезапускать клиент, иначе логи будут стёрты.

RAW Paste Data

Что такое лог игры?= ""Log (лог)"" - это файл в котором содержится подробный список событий из приложений, производительности системы, или действий пользователей, в хронологическом порядке. Лог или логи могут быть полезны для выявления ошибок в игре. Логи Танков X хранятся в специальном файле под названием "output_log". Чтобы посмотреть лог, нужно зайти в папку игры, далее в папку "tankix_Data". =Как предоставить лог игры?= Если у Вас возникли какие-то проблемы с игрой, частые вылеты, лаги и так далее, то разработчики могут попросить Вас предоставить им логи игры. Как это сделать: *В папке с игрой tankix_data есть файл output_log.txt *Сохраните файл в любое облачное хранилище (Яндекс.Диск, Google Docs, Dropbox, где можно просмотреть файл, не скачивая его)..tankix.com/ (или добавьте свой лог в тему другого игрока с идентичной проблемой) вместе с подробным описанием проблемы. Главное, после проявления ошибки не перезапускать клиент, иначе логи будут стёрты.