что такое отладочный лог

Логирование как способ отлаживать код

Почему так важно запретить самому себе отладку руками?

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

Поэтому вам надо будет несколько раз запускать этот код в отладочном режиме, проводя часы отладки над одним и тем же куском кода. И это только вы один столько времени потратили над этой частью программы. Каждый член команды, кому «посчастливится» работать с этим кодом, будет вынужден прожить ту же самую историю, которую прожили вы.

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

Проблематика: Сложно отлаживать составной код

Возможный алгоритм решения проблемы:

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

Давайте посмотрим пример. Вы знаете, что по отдельности все реализации интерфейсов работают (т.к. написаны тесты, доказывающие это). Но при взаимодействии всего вместе возникает некорректное поведение. Что вам нужно? Нужно логировать ответы от «корректных» интерфейсов:

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

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

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

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

Источник

Логирование. NLog Platform. Зачем нужны логи в приложении

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

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

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

Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.

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

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

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

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

Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.

Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.

Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.

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

Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.

То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.

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

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

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

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

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

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

Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).

Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:

Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):

Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.

Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:

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

Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():

Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:

Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:

Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:

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

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

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

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

Источник

Профессиональный подход к ведению логов

Jun 11, 2020 · 8 min read

Логи можно сравнить с уликами на месте преступления, а разработчиков — с криминалистами. Роль логов трудно переоценить, ведь когда необходимо найти баг или причину сбоя, сразу обращаются к ним. Подобно тому, как отсутствие улик приводит к нераскрытым делам, отсутствие содержательных логов осложняет диагностику и устранение ошибок, превращая их в затянувшийся или вовсе невыполнимый процесс. Мне приходилось наблюдать, как люди мучились с такими инструментами, как Strace и tcpdump, или развертывали новый код в продакшене во время сбоя лишь затем, чтобы получить больше лог-файлов для выявления проблемы.

Как говорится: “ Хорошо подготовиться — половину дела сделать”, так что каждому профессиональному разработчику следует научиться эффективно вести логи и быть готовым к работе с ними. В данной статье мы не только рассмотрим список полезных практик логирования в приложении, но и разберем теоретические основы данного процесса: что записываем, когда и кто этим должен заниматься.

Как осуществляется процесс отладки?

Прежде чем начать разговор о логах, необходимо ответить на два вопроса:

Программа как переходы состояний

Программа — это серия переходов между состояниями.

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

Отладка

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

Понимая суть процесса отладки, мы с легкостью ответим на этот вопрос:

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

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

Переход в критическое состояние

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

Предположим, что существуют 3 фазы запуска приложения:

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

Ключевые характеристики

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

Например, когда HTTP-сервер переходит из состояния ожидания запроса в состояние получения запроса, он должен зафиксировать в логе HTTP-метод и URL, так как они описывают основы HTTP-запроса. Остальные его элементы (заголовки или часть тела сообщения) записываются в том случае, если их значения влияют на бизнес-логику. Например, если поведение сервера сильно отличается между состояниями Content-Type:application/json и Content-Type:multipart/form-data, заголовок следует записать.

Причина перехода состояния

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

Пример

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

Вот несколько анти-шаблонов логов, в которых отсутствуют ключевые характеристики состояния и причины:

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

[2020–04–20T03:36:57+00:00] server.go: Received a SSN request(track id: “e4a49a27–1063–4ab3–9075-cf5faec22a16”) from user uuid “123e4567-e89b-12d3-a456–426655440000”( previous state), rejecting it( next state) because the server is expecting SSN format AAA-GG-SSSS but got **-***( why)

([2020–04–20T03:36:57+00:00] server.go: Получен запрос номера социального страхования (трек id: “e4a49a27–1063–4ab3–9075-cf5faec22a16”) от пользователя user uuid “123e4567-e89b-12d3-a456–426655440000” ( предыдущее состояние), запрос отклонен ( следующее состояние), так как сервер требует номер социального страхования в формате AAA-GG-SSSS, а получил **-*** ( причина)

Кто должен записывать логи?

Типичная ошибка, которую многие допускают, связана с тем, “кто” должен фиксировать информацию. Ведение логов не теми функциями оборачивается дублированием или дефицитом информации.

Программа как уровни абстракции

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

Например, веб-сайт может состоять из следующих уровней: бизнес-логика, HTTP и TCP/IP. Реагируя на URL-запрос, уровень бизнес-логики решает, какую веб-страницу показать, и отправляет ее контент на уровень HTTP, где он превращается в HTTP-ответ. Следующий уровень TCP/IP преобразует HTTP-ответ в пакеты TCP и рассылает их.

Ведите логи только на правильных уровнях

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

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

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

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

Сколько должно быть логов?

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

Установите соотношение между логами и рабочей нагрузкой

Для контроля объема логов сначала важно его правильно измерить. Большинство программ имеют 2 типа рабочей нагрузки:

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

# логов = X * # рабочих элементов+ константы

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

Используйте уровни логов

Что, если X все еще слишком большой даже после оптимизации? На помощь приходят уровни логов. Если X намного больше, чем 1, то можно поместить логи на уровень DEBUG, тем самым снизив X уровня INFO. В процессе устранения неполадок программа может временно выполняться на этом уровне для предоставления дополнительной информации.

Краткие выводы

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

1.Когда писать логи? В момент перехода в критическое состояние.

2.Что записывать в лог? Ключевые характеристики текущего состояния и причину перехода состояния.

3.Кто должен записывать логи? Логирование должно происходить на правильном уровне, содержащем достаточно информации.

4.Каким должно быть количество логов? Определите X-фактор (по формуле # логов = X * # рабочих элементов+ константы) и настройте его экономно, но выгодно.

Источник

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

Значение полей одной записи в лог-файле приведено в таблице

Основные группы записей.¶

ERR_MSG¶

Включается: Отладочные логи\Опции\Сообщения об ошибках

ADEV_WAVE: Query buffers timeout¶

Фатальная ошибка в системе воспроизведения звука:Драйвер звуковой карточки перестал возвращать блоки данных.
Синхронно с этим сообщением прекращается воспроизведение звука. Причиной сообщения является некорректная работа драйвера звукового устройства. Обычно проблема устраняется обновлением версии драйвера звукового устройства.

MAIN_THREAD_LAG¶

Включается: Отладочные логи\Опции\Блокировка главного потока
Зависит от: Отладочные логи\Опции\Писать время блокировки главного потока, если оно больше (ms)

TIMER LAG¶

5.5 сек. Это просто констатация данного факта. Запись появляется, если главный поток был блокирован более 2х секунд. Симптомы:

Причиной могут быть:

100%. Причем не обязательно его загрузил работой именно Джин, Это может быть любой приложение, в т.ч. вредоносное (червь, вирус). Причину в логе не видно, могут быть только неявные косвенные проявления.

PLAYER_io¶

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

Включается: Отладочные логи\Опции\Работа плеера.

Общие поля для всех записей

AutoLoadOperation¶

Выполнение операции автоматической загрузки следующего элемента в очередь плеера. Название указывается сразу после длительности.

В примере загружен элемент News 00_00 длительностью и рантаймом 00:05.1.

PasteElem¶

Факт внесения элемента в очередь плеера.

REASON признаки выполнения операции (обычно, несколько)

OnCueCrossFade¶

В плеере запущена прослушка склейки.

Open elem¶

Факт открытия звукового файла для воспроизведения, т.е. начало воспроизведения элемента в плеере. Название элемента указывается после длительности.

SearchStartPoint¶

Запущен поиск точки старта.

ShowContextMenu¶

Открыто контекстное меню от одного из элементов в плеере.

SetFocusSelElem¶

На элементе в плеере установлен фокус ввода (например, щелчком мыши).

START¶

STOP SIGNALED¶

END OF DATA¶

Завершения очереди воспроизведения в одном из потоков в канале

Delete¶

PLAYER_MODE¶

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

Get_AudioData¶

Включается: Отладочные логи\Опции\Время чтения аудио блока.
Зависит от: Отладочные логи\Опции\Писать ’время чтения аудио блока’ только если оно больше (ms).

Содержит единственное безымянное сообщение, пример:

40 сек) заполнялся один блок данных (стандартной длительностью 0.1 сек). Вещание велось в устройство WAVE: Axia Wave02.

В эфире, при этом была, естественно, пауза.

Данное сообщение не имеет отношения к работе самого аудиоустройства. Сообщение говорит о недопустимо медленном получении звуковых данных из файла. Причины возникновения такого сообщения изложены тут.

Однократное появление такой записи с небольшим таймаутом само по себе не является проблемой. Пауза в эфире возникнет, только если в устройстве воспроизведения опустеет звуковой буфер, стандартно имеющий длину 1 сек (10 блоков по 0.1 сек).

Create_File¶

Группа сообщений, фиксирующих длительность выполнения работы с файлами.

Включается: Отладочные логи\Опции\Время открытия файлов
Зависит от:

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

HOTRES. Горячий резерв¶

Переключение состояний модуля горячего резерва.

Главная станция послала на резервную запрос запрос на переключение режима.

Переключение автоматического режима плеера на другой стороне.

DDB_UI¶

Сообщения о действиях с пользовательским интерфейсом модуля DDB.

Включается: Отладочные логи\Опции\Пользовательский интерфейс DDB

Логируются операции на панели DDB и в списке соединений.

Сообщения бывают двух видов:

Не связанные с выбранным соединением, вида:
DDB_UI @ ИСТОЧНИК @ Сообщение; REASON: причина @

Связанные с выбранным соединением:
DDB_UI @ ИСТОЧНИК @ Сообщение; CONN: название соединения; REASON: причина @

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

Примечание: в текущей реализации REASON: SYSTEM в типе сообщений DDB_UI появляется по событиям только от 2х кнопок в окне DDB: Selected, Refresh.

Группа сообщений о некоторых «основных» событиях.
Включается: Отладочные логи\Опции\Основной

SCHEDULE UPDATE¶

С версии 2.15.2. Информация о фоновом считывании изменений, внесенных в расписание с других рабочих мест. Вносится в лог в случае, если программа заметила (получила нотификацию от системы отслеживания файлов, см. [#CH_FIXER CH_FIXER, что изменился файл блока расписания, считала этот блок и действительно внесла в расписание изменения. При этом в логе фиксируется только название файла блока и версия файла (счетчик модификаций). Само содержимое блока в этот лог не попадает. Содержимое, соответствующее определенной версии можно посмотреть в Логе редактирования расписания.
Если программа явно считала изменения, например, при редактировании блока, то данная запись в логе не формируется.

При изменении указываются новые и старые значения.

CH_FIXER¶

С версии 2.15.3. #2104 добавлена группа сообщений, относящихся к системе отслеживания изменений в файловой системе.

Включается: Отладочные логи\Опции\Система отслеживания изменений в файловой системе.

Информация о том, какая именно операция вызывает задержки интересна, обычно, только разработчикам.
При нормальной работе допускаются единичные таймауты длительностью до секунды (по умолчанию установлено значение «Нет»).

В дополниельной строке кажного сообщения указывается адрес объекта запроса на отслеживание каталога (WISH_ADDR=%Xh) и путь к отслеживаемому каталогу (Dir=full path)

Видео логгер¶

Группа сообщений, фиксирующих возникшие ошибки, события, сообщения от графа.

Произошло разъединение моста между получающим и записывающим графами.

Остановка записывающего графа

Уничтожение записывающего графа.

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

FKEEPER. Резервное копирование (Подкачка)¶

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

Включается: Отладочные логи\Опции\Система подкачки файлов

Существуют записи следующих типов

Для всех записей указывается успех/ошибка завершения, исходный и результирующий файлы и код ошибки в случае ее наличия.

WAVE_IO. Операции со звуковой картой¶

Включается: Отладочные логи\Опции\Операции со звуковой картой.

Зависит от: Отладочные логи\Опции\Писать время операции со звуковой картой, если оно больше (ms)

Обычной записью является название выполняемой операции и ее результат и время выполнения. По умолчанию, отсечка записи о времени выполнения равна 50 мс.

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

OPEN_AHEAD. Предзагрузка расписаний.¶

Записи данного типа относятся к системе предзагрузки расписаний

RETR. Плеер 777 Изменение состояния ретрансляции¶

При переходе плеера в режим ретрансляции в лог вносится запись вида

При завершении ретрансляции в лог вносится запись вида:

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

DJINFS. Сообщения файловой системы в отладочном логе¶

Логгирование файловых операций заносит в отладочный лог записи примерно такого вида:

Управление¶

В 2.16.x лог файловой системы управляется с помощью двух опций на вкладке «Доп» локальных параметров, раздел «Отладочные логи»/»Опции»:

— «Операции DJinFS»
— «Записывать в лог ‘время выполнения операции с файлом’ только если оно больше (ms)»
Сообщения об ошибках выполнения файловых операций в лог попадают всегда. Также, сообщения попадают в лог всегда, когда их длительность выполнения превосходит значение, заданное второй опцией из перечисленных выше. Для остальных вызовов файловых операций (т.е. окончившихся успехом и не превысивших указанную длительность) первый параметр задаёт уровень логгирования: если логгирование операции разрешено, то сообщение попадает в отладочный лог. Включив самый верхний уровень, можно увидеть вообще всю работу Джина с файлами. На самом нижнем уровне в логе будут только сообщения об ошибках. Нижний уровень включен по умолчанию.

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

Источник