Как пишутся логи

Всем привет. В свое время я занимался управлением рейдом, проще говоря был РЛом. Решение им стать было для меня достаточно неожиданным, поэтому приходилось все осваивать на лету. Спустя некоторое время работу с рейдерами я переложил на другие плечи, а всю техническую составляющую взял на себя. За общее время (а это 2 года) накопился неплохой багаж знаний в этой области, коим я бы и хотел поделиться с вами. А начну я с самого важного — с логов. Данный цикл статей будет разбит на несколько частей, каждая из которых также может существовать из нескольких. Для упрощения навигации по статьям ниже расположено меню.

Так что же это такое, эти ваши «логи»?

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

А какая статистика там ведётся?

Наверняка вы в рейде сталкивались с таким понятием как ДПС или ХПС. Что это такое вы также наверняка знаете. Но для тех, кто остался в танке, поясню:

DPS — Damage per Second — Наносимый урон в секунду. Иногда этим сокращением обозначают людей, исполняющих роль бойца.
HPS — Healing per Second — Количество лечения в секунду. Но почему-то аналогии с людьми, исполняющими роль бойца, тут нет.

Обычно для быстрого анализа подобных и некоторых других характеристик используют аддоны типа Skada или Recount. Существуют ещё аддоны, существенно упрощающие просмотр статистики вайпа или кила. В пример подойдут такие аддоны, как Exorsus Raid Tools или Phoenix Style.

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

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

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

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

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

Настроить настроили. Теперь следует запустить саму запись. Для этого нужно ввести в игровой чат команду /combatlog. Если игра отреагирует таким сообщением:

Бой записывается в файл Logs/WoWCombatLog.txt

значит всё в порядке, и все ваши действия начали записываться в файлик! Вообще, запуск записи командой довольно неудобный процесс. Как минимум потому, что легко можно запутаться включена ли сейчас запись, а также в суматохе дел можно просто забыть её включить. Поэтому существуют аддоны, которые позволяют привязать начало записи логов к какому-то событию. Например, в Exorsus Raid Tools, помимо его основного функционала, есть опция записи логов при входе в актуальный рейд. (Сейчас это Цитадель Адского Пламени, Литейная клана Черной Горы и Верховный молот). Включить эту функцию можно во вкладке «Запись лога».

Если Вы не хотите ставить столь громоздкий аддон только ради записи логов, то я могу Вам посоветовать аддон LoggerHead. Настройки его элементарны и позволяют записывать логи в любой установленной вами локации (хоть в Черном Храме).

Куда записываются логи?

Логи записываются в .txt файлик. Называется он WoWCombatLog.txt, а расположен в папке Logs, которая в свою очередь находится в корневой папке игры. В моём случае адрес выглядит вот так:
D:Battle.netWorld of WarcraftLogs
Обычно, за рейд этот файлик набегает в размере ~400Мб, поэтому следите за тем, чтобы его вовремя удалять.

Как «заливать» логи?

Скажу сразу, рассматривать логи мы будем на сайте WarcraftLogs, так как он предлагает самый объемный и расширенный выбор опций для оценки боя. Начнем мы с того, что зарегистрируемся на платформе. Регистрация потребует придумать никнейм и парольку, а также ввести адрес Вашей электронной почты. Также после регистрации Вы сможете прикрепить учетную запись Battle.net к аккаунту Warcraftlogs.

Далее нужно скачать клиент. Клиент Warcraftlogs представляет из себя программу, написанную на базе Adobe Air. Поэтому сначала нужно установить её. Сделать это можно на сайте Adobe. А после установки нужно поставить сам клиент Warcraftlogs. Ну а дальше всё по накатанной.

Запускаем приложение, вводим логин и пароль.

Попадаем на страницу выбора типа записи логов.

Разберем по порядку функции по порядку.

Функция Upload a Log запустит загрузку уже сохраненного лога. Этот вариант подходит для случаев, когда вы хотите записать лог боя и уже после окончания рейда его начать анализировать.
Функция Live Log будет загружать кусок боя, в котором вы только что участвовали. Хорошо подходит для анализа сразу после схватки с боссом. Загрузка происходит сразу после окончания боя, но требует постоянно включенной программы.
Split a Log — Функция для «разделки» логов. Полезна в случае, если вы случайно не удалили файлик с предыдущего дня. Делит логи на куски в нужном для Вас месте для того, чтобы после залить нужную часть.

Итак, как не крути, самая удобная функция — это запись логов онлайн. Поэтому рассматривать будем именно её. Нажимаем на кнопку — попадаем в меню.

Для начала указываем путь до Вашей папки Logs.

Теперь надо выбрать от чьего имени записывать логи. Я обычно пишу от своего имени, но существует возможность загружать логи от имени гильдии. Второй вариант интересен тем, что при анализе появляется дополнительный фунционал. (Например, список персонажей гильдии, процент явки людей в рейд и т.д.). Если гильдия не «приватизирована», то это можно сделать, если Ваш ранг в гильдии 0 или 1 (То есть Вы или Гильд Мастер или Офицер). ГМ определяет настройки для вступления в гильдию. В случае, когда Вы не являетесь офицером, а выставлено приватное вступление, то ГМ должен выслать приглашение для предоставления доступа выкладывать логи от имени гильдии.

Ну и последнее, что надо выбрать — это приватность Вашего лога.
Public — Открытый лог. Просматривать лог может любой пользователь WarcraftLogs.
Private — Закрытый лог. Просматривать лог могут только участники гильдии.
Unlisted — Закрытый лог. Чтобы посмотреть лог, нужно иметь ссылку.

Нажимаем «Go!» и рвёмся в бой! Теперь все ваши достижения можно будет не только увидеть во время рейда, но и после него 🙂

Далее мы рассмотрим прямой анализ уже записанных логов на примере нашей гильдии.

Навигация:

Как правильно писать логи (?) +15

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

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

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

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

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

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

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

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

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

[system info] + [message] + [context]

Где:

• 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.
• По возможности настраивайте сторонние библиотеки таким образом, чтобы они использовали логер с текущим контекстом запроса.

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

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

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

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

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

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

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

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

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

Маркетинг. Логи — источник ценной информации для развития сайта. Они позволяют собрать статистику по посещаемости с «сырыми» техническими данными. Например, понять, откуда приходят пользователи, где они находятся и какими устройствами пользуются для визита.

Какими бывают логи

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

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

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

Что может содержаться в логах

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

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

Как правильно читать лог

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

Например, так выглядит формат по умолчанию для лога доступа с веб-сервера:

[доменное имя сайта][IP-адрес пользователя][дата и время визита][тип запроса][URL, к которому обратился пользователь][протокол, по которому пользователь соединился с сайтом][код ответа сервера][количество байт информации, которую передали пользователю][дополнительная информация]

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

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

С помощью анализатора. Второй вариант — не просматривать лог вручную, а воспользоваться специальной программой-анализатором. Она парсит лог-файл — «разбирает» его на составляющие и представляет в удобном для пользователя виде. Так информация показывается в виде понятного отчета, иногда с графиками и диаграммами.

Анализаторы бывают разными, например Weblog Expert, Analog и пр. Некоторые из них также умеют интегрироваться с сервисами для сбора статистики, чтобы показывать более полную картинку.

Проверять и читать логи вам понадобится, если вы будете работать с профессиональным ПО для разработчиков, вебмастеров или инженеров. Это сложно только с первого взгляда — если понять принцип, расшифровать их не составит труда. А анализаторы помогут лучше и быстрее сориентироваться в записях.

Узнать больше о сетевых технологиях и получить новую профессию вы можете на курсах. Записывайтесь и станьте востребованным IT-специалистом.

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

Зачем оно вообще нужно, это логирование?

На анализе логов базируется работа большинства ИТ-специалистов. Администраторы  ищут в файлах логирования причины сбоя сервиса. Разработчики опираются на логи, чтобы локализовать и устранить ошибки приложения или веб-сайта. Служба безопасности по логам, как по физическим уликам, определяет вид взлома, оценивает нанесенный ущерб и даже может идентифицировать взломщика. Вот почему логирование мы рекомендуем отладить в первую очередь: в любой непонятной ситуации ответ на вопрос вы будете искать в логах!

Файлы логирования

Уровни логирования

В идеале логи пишутся во время работы всех IT-систем, однако если писать все подряд и «складывать в кучу», полезная информация превратится в хаос. Чтобы упростить поиск и чтение логов, их делят на уровни. Основных четыре:

1. Debug — запись масштабных переходов состояний, например, обращение к базе данных, старт/пауза сервиса, успешная обработка записи и пр.

2. Warning — нештатная ситуация, потенциальная проблема, может быть странный формат запроса или некорректный параметр вызова.

3. Error — типичная ошибка.

4. Fatal — тотальный сбой работоспособности, когда нет доступа к базе данных или сети, сервису не хватает места на жестком диске.

Дополнительно файл логирования может расширяться записями еще двух уровней:

1. Trace  — пошаговые записи процесса. Полезен, когда сложно локализовать ошибку.

2. Info — общая информация о работе службы или сервиса.

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

Типы логов

Для удобства обработки логов их делят на типы:

• системные, связанные с системными событиями,

• серверные, отвечающие за процесс обращения к серверу,

• почтовые, работающие с отправлениями,

• логи баз данных, которые отражают процессы обращения к базам данных,

• авторизационные и аутентификационные, которые отвечают за процесс входа, выхода из системы, восстановление доступа и пр.

У каждого типа логов свой журнал записи. Для проверки логов авторизации нужно идти в журнал доступов, чтобы проверить загрузку системы — в журнал dmesg, за данными о запросах пользователей — в access_log. Когда одни логи пишутся отдельно от других, проще диагностировать ситуацию и найти источник проблемы.

Логи в access_log

Инструменты для работы с логами

Сбор, хранение и анализ логов вручную хороши, когда у вас один сервер. Когда серверный парк разрастается, а приложений и сервисов становится больше десяти, работу с логами целесообразно автоматизировать и использовать специальные системы логирования, например, Graylog, ELK, Loggy или Splunk. Некоторые из них позволяют организовать полномасштабный мониторинг, настроить алерт раннего обнаружения конкретной проблемы или установить пороговые значения показателей, коррелирующих с угрозами информационной безопасности. 

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

Хранение логов в облаке

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