Что в себе содержит лог файл. Что такое «логи сервера», как посмотреть логи сервера
Логи (лог-файлы) - это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы. Иногда также употребляется русскоязычный аналог понятия - журнал.
Их предназначение - протоколирование операций, выполняемых на машине, для дальнейшего анализа администратором. Регулярный просмотр журналов позволит определить ошибки в работе системы в целом, конкретного сервиса или сайта (особенно скрытые ошибки, которые не выводятся при просмотре в браузере), диагностировать злонамеренную активность, собрать статистику посещений сайта.
Виды логов
Поскольку основное программное обеспечение, установленное на сервере, чаще всего производит запись в системные журналы, то для каждой из таких программ будет свой журнал. В частности, можно выделить такие наиболее распространенные логи:
- основной файл лога (общая информация - данные о действиях с ядром системы, работе FTP-сервисов, DNS-сервера, файервола);
- лог загрузки системы (помогает выполнить отладку системы в случае, если она не загружается, сохраняет основные системные события (например, сбои оборудования));
- логи веб-сервера (данные об обращениях к серверу, информация об ошибках веб-сервера);
- логи сервера баз данных (запросы к базам данных, ошибки сервера);
- логи хостинговой панели, через которую осуществляется (попытки входа в панель, обновления лицензии и панели, статистика использования ресурсов сервера);
- логи почтового сервера (записи о всех отправленных и доставленных сообщениях, ошибки почтового сервера, причины отклонения писем);
- логи планировщика задач - cron (протоколирование выполнения задач, ошибок при запуске крона).
Расположение
Месторасположение журналов зависит от программного обеспечения, реализации настроек по умолчанию или пути, заданного администратором. То есть, в зависимости от того, что вы используете (возможно, это виртуальный хостинг, -план или или США), доступность и расположение логов будут значительно отличаться. Как правило, большая часть логов сервера хранится по пути /var/log/, но некоторые сервисы могут хранить логи в других каталогах. Для удобства всегда можно задать подходящий путь в конфигурационных файлах нужного программного обеспечения. Например, на сервере можно настроить демон syslog/rsyslog, который будет упорядочивать поступающие в него записи о работе сервисов и сохранять их в заданные пользователем файлы логов.
Рассмотрим расположение основных логов для наиболее распространенных дистрибутивов Linux. По умолчанию журналы в Linux хранятся в /var/log.
CentOS / Fedora
Для распространенного веб-сервера Apache файлы журналов называются access.log (журнал доступа к серверу) и error.log (журнал ошибок и уведомлений). Путь по умолчанию для журнала ошибок Apache - /var/log/httpd/error_log .
Логи nginx сохраняются по пути /var/log/nginx. Журнал ошибок MySQL - /var/lib/mysql/$hostname.err , где вместо $hostname указан хостнейм (имя) сервера.
Основной файл лога - /var/log/syslog .
Лог загрузки системы - /var/log/dmesg .
Debian / Ubuntu
По умолчанию логи Apache будут сохраняться по пути /var/log/apache2 .
Логи nginx - /var/log/nginx .
Журнал ошибок MySQL - /var/log/mysql/error.log .
Основной файл лога - /var/log/syslog .
Лог загрузки системы - /var/log/dmesg .
Вам нужно ? У нас вы найдете лучшие предложения от Центров сертификации Comodo, GeoTrust и Symantec.
Понятие
Логи сервера (лог-файлы, журнал сервера) - фалы, хранящиеся на сервере, которые содержат системную информацию сервера, а так-же протоколирующие все возможные данные о посетителе веб-ресурса.
Логи используются системными администраторами для анализа посетителей , изучения закономерности поведения определенных групп пользователей, а так-же получения различной информации о них, такой как: используемый браузер, 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 и т.д., тем самым упрощая нам жизнь. Однако, если вы планируете развиваться, расти и познавать что-то новое, несомненно рекомендую вам познакомиться с данной темой поближе.
Лог-файл
Лог-файл
Лог-файл - файл, содержащий системную информацию о работе сервера и информацию о действиях пользователей:
- дату и время визита пользователя;
- IP-адрес компьютера пользователя;
- наименование браузера пользователя;
- URL запрошенной пользователем страницы;
- реферер пользователя.
Эта информация используется для анализа и оценки сайтов и их посетителей.
По-английски: Log file
См. также: Лог-файлы Файлы Веб-серверы
Финансовый словарь Финам .
Смотреть что такое "Лог-файл" в других словарях:
Файл, содержащий системную информацию о работе сервера и информацию о действиях пользователей: дату и время визита пользователя; IP адрес компьютера пользователя; наименование браузера пользователя; URL запрошенной пользователем страницы; реферер … Словарь бизнес-терминов
Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей. Файл регистрации, протокол … Википедия
Файл регистрации, протокол, журнал или лог (англ. log) файл с записями о событиях в хронологическом порядке. Ведение протокола, или протоколирование, хронологическая запись c различной (настраиваемой) степенью детализации сведений о происходящих… … Википедия
файл - у, ч. 1) спец. Сукупність взаємопов язаних блоків інформації, яка розпізнається комп ютером як одне ціле. || Набір даних на логічному рівні розглядання. Контро/льний файл файл, створений виконуваними операторами для забезпечення контролю за… … Український тлумачний словник
лог - 1) овраг с пологими травянистыми склонами и плоским дном; 2) комп.жарг. создаваемый комп. программой файл отчёта, содержащий сведения о выполненных операциях … Универсальный дополнительный практический толковый словарь И. Мостицкого
На иллюстрации Джона Чарльза Доллмана … Википедия
Radminer сетевой червь, занимающийся самораспространением посредством протокола крэкерами, освоившими протокол RAdmin и решившими применить знания на практике, для создания сообственного децентрализованного ботнета. В качестве примера будет… … Википедия
- (кейлоггер) (англ. key клавиша и logger регистрирующее устройство) это программное обеспечение или аппаратное устройство, регистрирующее каждое нажатие клавиши на клавиатуре компьютера. Содержание 1 Виды информации, котор … Википедия
Кейлогер, кейлоггер (англ. keylogger, правильно читается «ки логгер» от англ. key клавиша и logger регистрирующее устройство) это программное обеспечение или аппаратное устройство, регистрирующее различные… … Википедия
Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков 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. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:
- что-то происходит и надо знать что
- что-то сломалось и нужно дополнительно активировать триггер
В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:
- Fatal - вывод в лог и немедленный выход в ОС.
- Panic - вывод в лог и возбуждение «паники» (аналог исключения)
- Print - просто выводит сообщение в лог
Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.
Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) - то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug { entity.values } . В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.
После того, как разобрались с использованием уровней логов, нужно ещё уметь связывать разрозненные сообщения, особенно это актуально для многопоточных приложений или связанных между собой отдельных сервисов, когда в логах все сообщения оказываются вперемешку.
Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:
+ +
Где:
- system info: метка времени, ид процесса, ид потока и другая служебная информация
- message: текст сообщения
- context: любая дополнительная информация, контекст может быть общим для сообщений в рамках какой то операции.
Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:
ReqLog:= log.WithField("requestID", requestID)
После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.
Резюмируя:
- Логируйте с избытком. Никогда заранее не известно сколько и какой информации в логах понадобится в критический момент.
- Восемь уровней логирования - вам действительно столько надо? По опыту должно хватить максимум 3-4, и то при условии, что для них настроены обработчики событий.
- По возможности используйте ленивые вычисления для вывод сообщений в лог
- Всегда добавляйте текущий контекст в каждое сообщение лога, как минимум requestID.
- По возможности настраивайте сторонние библиотеки таким образом, чтобы они использовали логер с текущим контекстом запроса.
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/ (или добавьте свой лог в тему другого игрока с идентичной проблемой) вместе с подробным описанием проблемы. Главное, после проявления ошибки не перезапускать клиент, иначе логи будут стёрты.