Как сделать лог ошибки игры
Запись логов на WarcraftLogs. Техническая сторона рейда часть 1.
Всем привет. В свое время я занимался управлением рейдом, проще говоря был РЛом. Решение им стать было для меня достаточно неожиданным, поэтому приходилось все осваивать на лету. Спустя некоторое время работу с рейдерами я переложил на другие плечи, а всю техническую составляющую взял на себя. За общее время (а это 2 года) накопился неплохой багаж знаний в этой области, коим я бы и хотел поделиться с вами. А начну я с самого важного — с логов. Данный цикл статей будет разбит на несколько частей, каждая из которых также может существовать из нескольких. Для упрощения навигации по статьям ниже расположено меню.
Так что же это такое, эти ваши «логи»?
Логи — это такая штучка, которая позволяет в режиме оффлайн просматривать очень подробную статистику боя, повторы, сверять свои показатели с показателями других игроков и так далее. Проще, это просто удобная платформа для «разбора полётов».
А какая статистика там ведётся?
Наверняка вы в рейде сталкивались с таким понятием как ДПС или ХПС. Что это такое вы также наверняка знаете. Но для тех, кто остался в танке, поясню:
Изображение ДПСа рейда на сайте warcraftlogs.com
DPS — Damage per Second — Наносимый урон в секунду. Иногда этим сокращением обозначают людей, исполняющих роль бойца.
HPS — Healing per Second — Количество лечения в секунду. Но почему-то аналогии с людьми, исполняющими роль бойца, тут нет.
Изображение ХПСа рейда на сайте warcraftlogs.com
Обычно для быстрого анализа подобных и некоторых других характеристик используют аддоны типа Skada или Recount. Существуют ещё аддоны, существенно упрощающие просмотр статистики вайпа или кила. В пример подойдут такие аддоны, как Exorsus Raid Tools или Phoenix Style.
Отображение текущего ДПСа рейда в представлении аддона Skada
Для последнего существует дополнительная надстройка, называется Combat Replay, позволяющая посмотреть повтор боя в схематичном варианте. Подобные аддоны хороши тем, что они «подхватывают» статистику в реальном времени, хотя иногда не совсем точно. Это позволяет производить анализ прямо во время боя. Но об этих аддонах мы поговорим немного позже.
Логи тоже, в свою очередь, записываются в бою, но они охватывают более обширную область боя, чем аддоны, и требуют времени для их загрузки и расшифровывания системой. Поэтому для подробного анализа боя потребуется чуть больше времени, чем при работе с аддонами.
Если Вас интересует как это все организовать, то давайте начнем с простого:
Как записать логи?
Перед тем как начать запись логов стоит обратить внимание на одну настройку в интерфейсе. Она позволяет вести запись в более объемном виде (то есть c указанием всех мелочей). Это не сложно, нужно просто вызвать Настройки, открыть вкладку «Соединение» и поставить галочку рядом с надписью «Расширенный журнал боя».
Настроить настроили. Теперь следует запустить саму запись. Для этого нужно ввести в игровой чат команду /combatlog. Если игра отреагирует таким сообщением:
Бой записывается в файл Logs/WoWCombatLog.txt
значит всё в порядке, и все ваши действия начали записываться в файлик! Вообще, запуск записи командой довольно неудобный процесс. Как минимум потому, что легко можно запутаться включена ли сейчас запись, а также в суматохе дел можно просто забыть её включить. Поэтому существуют аддоны, которые позволяют привязать начало записи логов к какому-то событию. Например, в Exorsus Raid Tools, помимо его основного функционала, есть опция записи логов при входе в актуальный рейд. (Сейчас это Цитадель Адского Пламени, Литейная клана Черной Горы и Верховный молот). Включить эту функцию можно во вкладке «Запись лога».
Если Вы не хотите ставить столь громоздкий аддон только ради записи логов, то я могу Вам посоветовать аддон LoggerHead. Настройки его элементарны и позволяют записывать логи в любой установленной вами локации (хоть в Черном Храме).
Куда записываются логи?
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!» и рвёмся в бой! Теперь все ваши достижения можно будет не только увидеть во время рейда, но и после него 🙂
Далее мы рассмотрим прямой анализ уже записанных логов на примере нашей гильдии.
Логирование в Python
Пакет Logging является очень полезным инструментом в наборе инструментов программиста. Он может помочь вам лучше понять суть программы и обнаружить сценарии, о которых вы, возможно, даже не задумывались при разработке.
Логи предоставляют разработчикам дополнительный набор глаз, которые постоянно смотрят на поток, через который проходит приложение. Они могут хранить информацию о том, какой пользователь или IP получил доступ к приложению. Если возникает ошибка, то они могут предоставить больше информации, чем трассировка стека, сообщив вам, в каком состоянии находилась программа до того, как она достигла строки кода, где произошла ошибка.
Записывая полезные данные из нужных мест, вы можете не только легко отлаживать ошибки, но и использовать данные для анализа производительности приложения, планирования масштабирования или просмотра схем использования для планирования маркетинга.
В этой статье вы узнаете, почему использование модуля logging является лучшим способом добавления логов в ваше приложение, а также узнаете как быстро начать работу с ним.
Модуль Logging
Модуль logging в Python — это готовый к использованию, мощный модуль, предназначенный для удовлетворения потребностей как начинающих, так и корпоративных команд. Он используется большинством сторонних библиотек Python, поэтому вы можете интегрировать ваши логи с сообщениями из этих библиотек для создания единого журнала логов в вашего приложении.
Добавить logging в вашу программу на Python так же просто, как написать эту строчку:
С импортированным модулем logging вы можете использовать то, что называется «logger», для логирования сообщений, которые вы хотите видеть. По умолчанию существует 5 стандартных уровней severity, указывающих на важность событий. У каждого есть соответствующий метод, который можно использовать для логирования событий на выбранном уровне severity. Список уровней в порядке увеличения важности:
Модуль logging предоставляет вам логер по умолчанию, который позволяет вам начать работу без дополнительных настроек. Соответствующие методы для каждого уровня можно вызвать, как показано в следующем примере:
Вывод вышеупомянутой программы будет выглядеть так:
Вывод показывают уровень важности перед каждым сообщением вместе с root, который является именем, которое модуль logging дает своему логеру по умолчанию. Этот формат, который показывает уровень, имя и сообщение, разделенные двоеточием (:), является форматом вывода по умолчанию, и его можно изменить для включения таких вещей, как отметка времени, номер строки и других деталей.
Обратите внимание, что сообщения debug() и info() не были отображены. Это связано с тем, что по умолчанию модуль ведения журнала регистрирует сообщения только с уровнем WARNING или выше. Вы можете изменить это, сконфигурировав модуль logging для регистрации событий всех уровней. Вы также можете определить свои собственные уровни, изменив конфигурации, но, как правило, это не рекомендуется, так как это может привести к путанице с журналами некоторых сторонних библиотек, которые вы можете использовать.
Базовая конфигурация
Вы можете использовать метод basicConfig (**kwargs) для настройки ведения логов:
«Вы можете заметить, что модуль logging нарушает руководство по стилю PEP8 и использует соглашения camelCase в именнование переменных. Это потому, что он был адоптирован из пакета Log4j (утилиты ведения логов в Java). Это известная проблема в пакете, но к тому времени, когда было решено добавить ее в стандартную библиотеку, она уже была принята пользователями, и изменение ее в соответствии с требованиями PEP8 вызовет проблемы обратной совместимости ». (Источник)
Вот некоторые из часто используемых параметров для basicConfig():
Используя параметр level, вы можете установить, какой уровень сообщений журнала вы хотите записать. Это можно сделать, передав одну из констант, доступных в классе, и это позволило бы регистрировать все вызовы logging на этом уровне или выше. Вот пример:
Теперь будут регистрироваться все события на уровне DEBUG или выше.
Аналогично, для записи логов в файл, а не в консоль, можно использовать filename и filemode, и вы можете выбрать формат сообщения, используя format. В следующем примере показано использование всех трех переменных:
Сообщение будет записано в файл с именем app.log вместо вывода в консоль. Для filemode значение w означает, что файл журнала открывается в «режиме записи» каждый раз, когда вызывается basicConfig(), и при каждом запуске программы файл перезаписывается. Конфигурацией по умолчанию для filemode является a, которое является добавлением.
Вы можете настроить корневой logger еще больше, используя дополнительные параметры для basicConfig(), которые можно найти здесь.
Следует отметить, что вызов basicConfig() для настройки корневого logger работает, только если корневой logger не был настроен ранее. По сути, эта функция может быть вызвана только один раз.
debug(), info(), warning(), error() и crit() также автоматически вызывают basicConfig() без аргументов, если он ранее не вызывался. Это означает, что после первого вызова одной из вышеперечисленных функций вы больше не сможете изменить настройки корневого logger.
Формат вывода
Хотя вы можете передавать любую переменную, которая может быть представлена в виде строки из вашей программы в виде сообщения в ваши журналы, есть некоторые базовые элементы, которые уже являются частью LogRecord и могут быть легко добавлены в выходной формат. Если вы хотите записать идентификатор процесса ID вместе с уровнем и сообщением, вы можете сделать что-то вроде этого:
format может принимать строку с атрибутами LogRecord в любом порядке. Весь список доступных атрибутов можно найти здесь.
Вот еще один пример, где вы можете добавить информацию о дате и времени:
%(asctime)s добавляет время создания LogRecord. Формат можно изменить с помощью атрибута datefmt, который использует тот же язык форматирования, что и функции форматирования в модуле datetime, например time.strftime():
Вы можете найти больше информации о формате datetime в этом руководстве.
Логирование переменных
В большинстве случаев вам нужно будет включать динамическую информацию из вашего приложения в журналы. Вы видели, что методы ведения журнала принимают строку в качестве аргумента, и может показаться естественным отформатировать строку с переменными в отдельной строке и передать ее методу log. Но на самом деле это можно сделать напрямую, используя строку формата для сообщения и добавляя переменные в качестве аргументов. Вот пример:
Аргументы, передаваемые методу, будут включены в сообщение в качестве переменных.
Хотя вы можете использовать любой стиль форматирования, f-строки, представленные в Python 3.6, являются лучшим способом форматирования строк, поскольку они могут помочь сделать форматирование коротким и легким для чтения:
Вывод стека
Модуль регистрации также позволяет вам захватывать стек выполнения в приложении. Информация об исключении может быть получена, если параметр exc_info передан как True, а функции ведения журнала вызываются таким образом:
Если для exc_info не задано значение True, выходные данные вышеприведенной программы не сообщат нам ничего об исключении, которое в реальном сценарии может быть не таким простым, как ZeroDivisionError. Представьте, что вы пытаетесь отладить ошибку в сложной кодовой базе с помощью журнала, который показывает только это:
Совет: если вы логируете в обработчике исключений (try..except…), используйте метод logging.exception(), который регистрирует сообщение с уровнем ERROR и добавляет в сообщение информацию об исключении. Проще говоря, вызов logging.exception() похож на вызов logging.error (exc_info = True). Но поскольку этот метод всегда выводит информацию об исключении, его следует вызывать только в обработчике исключений. Взгляните на этот пример:
Использование logging.exception() покажет лог на уровне ERROR. Если вы не хотите этого, вы можете вызвать любой из других методов ведения журнала от debug() до critical() и передать параметр exc_info как True.
Классы и функции
До сих пор мы видели logger по умолчанию с именем root, который используется модулем logging всякий раз, когда его функции вызываются непосредственно таким образом: logging.debug(). Вы можете (и должны) определить свой собственный logger, создав объект класса Logger, особенно если ваше приложение имеет несколько модулей. Давайте посмотрим на некоторые классы и функции в модуле.
Наиболее часто используемые классы, определенные в модуле logging, следующие:
Из всего перечисленного мы в основном имеем дело с объектами класса Logger, которые создаются с помощью функции уровня модуля logging.getLogger(name). Многократные вызовы getLogger() с одним и тем же именем возвращают ссылку на один и тот же объект Logger, что избавляет нас от передачи объектов logger в каждую часть, где это необходимо. Вот пример:
Этот код создает пользовательский logger с именем example_logger, но в отличие от корневого logger, имя настраиваемого регистратора не является частью выходного формата по умолчанию и должна быть добавлена в конфигурацию. Конфигурирование его в формате для отображения имени logger даст вывод, подобный этому:
Опять же, в отличие от корневого logger, пользовательский logger нельзя настроить с помощью basicConfig(). Вы должны настроить его с помощью Handlers и Formatters:
Использование Handlers
Обработчики используются, когда вы хотите настроить свои собственные logger и предназначены для отправки сообщений в сконфигурированные места назначения мест, такие как стандартный поток вывода или файл или HTTP, или на вашу электронную почту через SMTP.
У созданного вами logger может быть несколько обработчиков, а это значит, что вы можете настроить его на сохранение в файл журнала, а также на отправку по электронной почте.
Подобно logger, вы также можете установить уровень severity в обработчиках. Это полезно, если вы хотите установить несколько обработчиков для одного и того же logger, но хотите иметь разные уровни severity для каждого из них. Например, вы можете захотеть, чтобы журналы с уровнем WARNING и выше регистрировались на консоли, но все с уровнем ERROR и выше также должно быть сохранены в файл. Вот пример кода, который делает это:
Здесь logger.warning() создает LogRecord, который содержит всю информацию о событии, и передает ее всем имеющимся обработчикам: c_handler и f_handler.
c_handler является StreamHandler с уровнем WARNING и берет информацию из LogRecord для генерации вывода в указанном формате и выводит его на консоль. f_handler — это FileHandler с уровнем ERROR, и он игнорирует LogRecord, так как его уровень — WARNING.
Когда вызывается logger.error(), c_handler ведет себя точно так же, как и раньше, а f_handler получает LogRecord на уровне ERROR, поэтому он продолжает генерировать вывод точно так же, как c_handler, но вместо вывода на консоль, он записывает сообщение в указанный файл в этом формате:
Имя logger, соответствующее переменной __name__, записывается как __main__, то есть имя, которое Python присваивает модулю, с которого начинается выполнение. Если этот файл импортируется каким-либо другим модулем, то переменная __name__ будет соответствовать его имени logging_example. Вот как это будет выглядеть:
Другие методы настройки
Вы можете настроить ведение журнала, как показано выше, используя функции модуля и класса или создав файл конфигурации или словарь и загрузив его с помощью fileConfig() или dictConfig() соответственно. Это полезно, если вы хотите часто менять конфигурацию ведения журнала в работающем приложении.
Вот пример файла конфигурации:
В приведенном выше файле есть два logger, один обработчик и один форматер. После того, как определены их имена, они настраиваются путем добавления слов logger, handler и formatter перед их именами, разделенными подчеркиванием.
Чтобы загрузить этот файл конфигурации, вы должны использовать fileConfig():
Путь к файлу конфигурации передается в качестве параметра методу fileConfig(), а параметр disable_existing_loggers используется для сохранения или отключения logger, которые присутствуют при вызове функции. По умолчанию установлено значение True, если не упомянуто.
Вот та же конфигурация в формате YAML для подхода с dictionary:
Пример, который показывает, как загрузить конфигурацию из файла yaml:
Заключение
Модуль logging считается очень гибким. Его дизайн очень практичен и должен подходить для любого случая использования. Вы можете добавить базовое ведение логов в небольшой проект или даже создать собственные настраиваемые уровни журналов, классы обработчиков и многое другое, если вы работаете над большим проектом.
Если вы не использовали логирование в своих приложениях до сих пор, сейчас самое время начать. Если все сделаете правильно, ведение логов, несомненно, устранит много проблем как в процессе разработки так и в процессе эксплуатации и поможет вам найти возможности поднять ваше приложение на новый уровень.