Сбор логов с помощью FiddlerCap. Сбор логов с помощью FiddlerCap Сбор логов с помощью FiddlerCap

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

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

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

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

Изображение ДПСа рейда на сайте 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 . Настройки его элементарны и позволяют записывать логи в любой установленной вами локации (хоть в Черном Храме).

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

Логи записываются в.txt файлик. Называется он WoWCombatLog.txt, а расположен в папке Logs, которая в свою очередь находится в корневой папке игры. В моём случае адрес выглядит вот так:
D:\Battle.net\World of Warcraft\Logs
Обычно, за рейд этот файлик набегает в размере ~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!» и рвёмся в бой! Теперь все ваши достижения можно будет не только увидеть во время рейда, но и после него 🙂

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

Сбор логов https с помощью FiddlerCap

Установка FiddlerCap

Необходимо скачать и запустить приложение .

В открывшемся окне нажать на кнопку «Install». В строке Destination Folder будет указан путь до папки, в которую установится FiddlerCap. По умолчанию там указывается Рабочий стол.

Дождаться окончания установки и нажать кнопку «Close».

Сбор логов с помощью FiddlerCap

Найти папку FiddlerCap в той директории, которая была выбрана на этапе установки. По умолчанию FiddlerCap устанавливается на Рабочий стол. В папке FiddlerCap запустить файл «FiddlerCap.exe».

В пункте «Настройки захвата» установить три галки:

сохранять двоичные данные,
расшифровать HTTPS трафик,
хранить куки и POST формы.

Если появится предупреждение об установке сертификата, то в нем следует нажать кнопку «Да». При необходимости, сертификат будет предложено удалить при сохранении логов.

Закрыть все браузеры, открытые на компьютере. Нажать на кнопку «Начать захват». Открыть программу, при работе с которой появляется ошибка (например, Контур.Экстерн), и воспроизвести ошибку.

После того, как ошибка будет воспроизведена, необходимо нажать на кнопку «Остановить захват» в окне программы FiddlerCap. Логирование завершится.

Выбрать папку для сохранения.

Файл с логами будет сохранен в выбранной папке.

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

Запись сетевого трафика в Internet Explorer

Для записи сетевого трафика в Internet Explorer необходимо открыть необходимую страницу в Internet Explorer. В Internet Explorer перейти в меню «Сервис» > «Средства разработчика F12» ("Tools" > «Developer Tools F12") F12 .

Если меню «Сервис» не отображается, то нажать клавишу «Alt» на клавиатуре .

Перейти на вкладку «Сеть (Network)» > «Ctrl+4». Включить сбор сетевого трафика: в Internet Explorer 9 нажать «Начать сбор». В Internet Explorer 11 нажать на кнопку с зеленым треугольником.

Воспроизвести ошибку (например, обновить страницу, либо перейти по нужной ссылке). Сохранить собранный лог, нажав на изображение дискеты.

В ыбрать папку для сохранения, ввести имя файла, нажа ть «Сохранить». Файл будет создан в xml формате. Создание лога завершено.

Запись сетевого трафика в Mozilla Firefox

Для записи сетевого трафика в Mozilla Firefox необходимо открыть необходимую страницу в Mozilla Firefox. В IMozilla Firefox перейти в меню «Сервис» > «Разработка» > «Средства разработчика (Ctrl + Shift + I) либо нажать на клавиатуре клавишу F12 .

Перейти на вкладку «Сеть» и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Выделите любую запись из лога — нажмите по нему правой кнопкой мыши и нажмите на «Сохранить все как HAR».

Запись сетевого трафика в Google Chrome

Для записи сетевого трафика в Google Chrome необходимо открыть необходимую страницу в Google Chrome. В Google Chrome перейти в меню «Сервис» > «Дополнительные инструменты» >«Средства разработчика (Ctrl +Shift +I) либо нажать на клавиатуре клавишу F12 .

Передите в раздел Network и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Если запись логов не началась автоматически, нажмите на кнопку «Record Network Log».

Выделите любую запись из лога, нажмите по нему правой кнопкой мыши и нажмите на «Save as HAR with content».

Выберите папку для сохранения, введите имя файла, нажмите на сохранить. Файл будет сохранен в формате har.

Установка

Необходимо скач ать и запустить приложение . На предложение начать установку следует ответить утвердительно, нажав на кнопку «Да».

В открывшемся окне нажать на кнопку «Next».

В следующем окне необходимо установить переключатель «I accept the terms in the Licence Agreement» и кликнуть по кнопке «Next».

Выбрать тип установки «Typical».

Отметить пункт «Create shortcut for Microsoft Network Monitor on the desktop» (Создать ярлык на рабочем столе) и нажать на кнопку «Install».

Нажать на кнопку «Finish» для завершения установки.

После окончания установки необходимо дождаться окончания автоматической настройки компонента Microsoft Network Monitior 3.4 Parsers.

Запуск логирования

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов). Запустить программу с помощью ярлыка на рабочем столе.

В главном окне программы выбрать меню «File» > «New» > «Capture».

Нажать на кнопку «Start», после чего свернуть программу и воспроизвести ошибку.

Воспроизвести ошибку, нажать на кнопку «Stop».

В ыбрать меню «File» > «Save As», указать каталог для сохранения и имя файла и нажать на кнопку «Сохранить». Создание лога завершено.

Process Monitor

Чтобы начать логирование при помощи программы Process Monitor, необходимо выполнить следующие шаги:

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов), скач ать и запустить приложение .

После запуска программы выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «Edit» > «Clear Display». Автоматически записанный лог будет удален. Программа готова к работе.

Выбрать меню «File» > «Capture Events». Логирование будет запущено. Свернуть приложение и воспроизвести ошибку.

Восстановить приложение и выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «File» > «Save». Установить переключатель «All Events».

Кликнуть по кнопке с тремя точками справа от поля «Path», указать папку для сохранения и имя файла (рекомендуется оставить по умолчанию) и нажать на кнопку «Сохранить».

В окне параметров сохранения файла нажать на кнопку «Сохранить». Создание лога завершено.

Доброго времени суток, господа! Сегодня речь пойдет о неотъемлемой части рейдовой жизни — о комбат-логах.

Для начала давайте определимся, что же это такое (для тех, кто впервые увидел данный термин).

WWS или WMO логи — это записи боев в World of Warcraft, которые размещены на специальных сайтах. Многие пользуются аддоном Recount или его аналогами. По сути — это тот же Recount, но во-первых данные не нужно хранить у себя на компьютере, а во-вторых с этими записями можно делать такое, что встроенными аддонам WoW и не снилось.
Идея создания такого сервиса принадлежит сайту WowWebStats.com , отсюда и пошло название логов. Сайт функционирует и по сей день, но очень давно не обновлялся и уступает по функциональности аналогичным ресурсам.

На данный момент WWS заменили два более продвинутых проекта — WoWMeterOnline.com и WorldofLogs.com . Оба сервиса приблизительно равны по функционалу и я не стану углубляться в их сравнение — каждый выберет себе по вкусу. Отмечу лишь, что на WMO присутствует кое-какая поддержка русского языка в интерфейсе (хотя назвать ее "русским интерфейсом" язык не поворачивается — настолько она сейчас сырая), и в то же время сервис явно перегружен запросами — очень часто просматривая лог, связь с сервером обрывается. Я никогда не пользовался этим сайтом, так как сразу после появления World of Logs я пересел с WWS на него. И ни разу еще не пожалел.

Можете найти отличия самостоятельно. Вот ссылки на один и тот же лог, но залитый на два разных сервиса:
http://www.wowmeteronline.com//combat/log/1253276
http://www.worldoflogs.com/reports/11wtgwut6rs10l31/

Я буду вести свое повествование основываясь на WoL и по мере возможности давая ссылки на аналогичные действия на WMO.

Итак — поехали!

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

О, это очень просто. Достаточно перед началом боя ввести команду /combatlog в чат игры. Появится соответствующее уведомление о том, что запись лога запущена или отключена, а так же место, откуда этот лог можно забрать. Так можно делать, если вас интересует какой-то конкретный бой. Например, вы пришли траить Ануб"арака и перед началом боя вводите команду. Бой будет вестись до тех пор, пока вы не сделаете логаут или не пропишете команду на остановку ведения лога. В общем же случае, если вам требуется вести ежедневные логи рейдов, вы наверняка скоро устанете вводить эту команду. Можно, конечно, макрос написать и вынести на панельку соответствующую кнопочку, но я более чем уверен — когда-нибудь в ответственный момент вы забудете его нажать и вся запись боя канет в лету. Я не исключение, поэтому я нашел замечательный аддон, которым пользуюсь уже около года.

Встречайте — AutoCombatLog . Аддон представляет из себя простенький скрипт, который прописывает за вас команду /combatlog , как только вы входите в инстанс (в настройках /acl можно включить/выключить ведение логов в рейдах или в подземельях на 5 человек). Очень удобная вещь. Но не без недостатков — если вы забудете удалить или переименовать использованный комбат-лог, то на следующий день запись продолжится в тот же файл. На выходе мы получим большущий (от 300 МБ и выше) текстовый файл, который не примет ни один парсер (от англ. parser — анализатор, см. далее) логов. В этом случае придется вручную открывать файл WoWCombatLog.txt и удалять ненужные данные за прошлый день. Отчасти решить эту проблему поможет парсер от World of Logs. Об этом ниже.

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

Тут все не намного сложнее. На обоих сайтах можно найти ссылку на парсер. Чтоб вы не утруждали себя поисками, вот ссылки на оба. Скачать клиент для WoL . Скачать клиент для WMO . Клиент написан на Java и поэтому будет необходимо установить себе соответствующий пакет. Весит он относительно немного, и вы можете скачать его с официального сайта — http://java.com/ .

Теперь от вас требуется войти под своим аккаунтом в клиенте. Если вы еще не зарегистрировались — самое время это сделать. Регистрация на World of Logs . Регистрация на WoWMeterOnline . Оба клиента предельно доступны в плане освоения. Вбейте в нем свои данные, не забудьте указать папку с логами (\\Путь к World of Warcraft\\Logs\), где парсер по умолчанию будет искать файл WoWCombatLog.txt.

Рассмотрим поближе 3 больших кнопочки парсера WoL.
Open a file — с помощью этой кнопки мы можем открыть файл, который находится не в стандартной директории.
Open The WoW Log — открывает файл WoWCombatLog.txt.

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

В парсере WMO все делается точно так же.

Отдельно стоит упомянуть о такой замечательной функции клиента WoL как Live Report Session . Эта опция позволяет загружать лог боя сразу же после его окончания. Парсер ожидает, когда вы закончите битву с босом, и тут же автоматически загрузит лог на сайт. Вот как это выглядит

Как хранятся логи?

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

Сайт самостоятельно определяет тип эвента, подписывая каждого босса и режим (hard mode, normal mode). А если вам этого не достаточно, к каждому логу можно оставить коротенький комментарий. Например "Баджран в ИВК" или "Вайпфест на Ониксии". В отличии от WMO — World of Logs предусматривает апгрейд аккаунта, за определенную оплату. Оплаченный аккаунт дает возможность хранить логи неограниченное время. В других случаях логи удаляются спустя месяц. Весь остальной функционал в бесплатных аккаунтах сохранен.

Как просматривать логи?

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

Кто нанес больше всего урона на конкретном боссе.
Кто и от чего умер во время боя.
Каких мобов пришлось убить во время боя.
Кто дал БЛ.
Кто из друидов использовал батл-рес и кого именно он воскрешал.
а так же другую статистическую информацию, которую дает Recount.

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

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

Pro: Expression Editor

Коротко пробегусь по этой замечательной опции WoL. При помощи редактора можно отсеять лишние сообщения в логе боя и вывести только ту информацию, которая нам нужна. Рассмотрим пример. Идем в этот лог: http://www.worldoflogs.com/reports/11wtgwut6rs10l31/ , на котором записан бой с Ануб"араком в Испытании Великого Крестоносца (10 игроков). Выбираем из выпадающего списка — Expression Editor. А теперь придумываем, что нам хотелось бы узнать. Например, как жил Тэми на третьей фазе — по сколько он лечил босса, и кто излечивал его от дебаффа. Справка по запросам гласит:

Actors: sourceid, targetid, sourceuid, targetuid, sourcemobid, targetmobid, sourcename, targetname
ActorType: sourcetype:String, targettype, sourcereaction, targetreaction
Event type: type, subtype, fulltype (will add more info later)
Amounts: amount, absorbed, overheal, overkill
Spell: spell (name), spellid
Short cuts: damagetaken, healingdone

# Short event types
TYPE_DAMAGE=1
TYPE_MISS=2
TYPE_HEAL=3
TYPE_AURA=4
TYPE_DEATH=5
TYPE_CAST=6
TYPE_DISPEL=7
TYPE_GAIN=8
TYPE_ENCHANT=9
TYPE_DURABILITY=10
TYPE_SUMMON=11
TYPE_OTHER=50

Показать скрытый текст

Соответственно, Тэми лечил босса от дебаффа. Следовательно берем переменную из ряда actor. Поскольку действия выполняются магом (он является источником — source), то sourceName = "Тэми". Но если мы так напишем, нам выдадут все действия, которые он выполнял — все касты аркан бластов и так далее. А нам нужен именно хил. Определяем тип события: type = TYPE_HEAL . Объединяем оба запроса:

sourceName = "Тэми" and type = TYPE_HEAL

Аналогично составляем запрос для входящего в меня исцеления:

targetName = "Тэми" and type = TYPE_HEAL

Оба запроса работают сами по себе, но их можно объединить. Окружаем скобочками и ставим оператор OR (или). Вуаля:

(sourceName = "Тэми" and type = TYPE_HEAL) or (targetName = "Тэми" and type = TYPE_HEAL)

Вместо вывода

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

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