Логирование. NLog Platform. Зачем нужны логи в приложении. Про логирование времени работы над задачей
В данном разделе представлены рекомендации по работе с программами для сбора логов. Данная информация необходима службе технической поддержки для точной диагностики проблемы на рабочем месте пользователя. Ниже доступны инструкции для приложений.
Сбор логов 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.3 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», указать папку для сохранения и имя файла (рекомендуется оставить по умолчанию) и нажать на кнопку «Сохранить».
В окне параметров сохранения файла нажать на кнопку «Сохранить». Создание лога завершено.
Ведение логов помогает разработчику в процессе создания и последующего сопровождения приложения, при поиске ошибок в коде и в разрешении непонятных ситуаций, когда наше приложение в момент работы ведет себя странным образом, и нам нужно найти причину такого поведения.
Любой разработчик сталкивается с подобными ситуациями, когда какой-то компонент приложения отрабатывает странным образом, выдает не тот результат или вообще перестает работать. Использование логов поможет нам в подобных ситуациях. Время поиска проблемных мест в нашем коде сократится в разы, и мы быстрее сможем решить ту или иную проблему.
Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.
Лог (log) - это специальный журнал, в котором хранится информация о состоянии работы приложения (программы).
Под таким журналом можно понимать и записи в обычный текстовый файл, и записи в базу данных, и записи на удаленный веб-сервис, и даже email-письма на определенный адрес о тех или иных состояниях нашего приложения.
Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.
Всего существует шесть уровней логирования, каждый из которых предназначен для сообщений того или иного типа, той или иной важности:
Trace - максимально детальная информация о том, что происходит с целевым участком кода, по шагам . Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.
Debug - это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции . Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.
Info - это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.
Warn - сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.
Error - сообщения об ошибках в приложении. Подобные сообщения - это уже большая проблема, которую нужно решить для дальнейшей правильной работы системы. Например: Ошибка сохранения нового студента в БД. Невозможно загрузить студентов в данной группе. Ошибка при входе в личный кабинет студента.
Fatal - сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.
То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.
Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.
Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.
Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.
К какой группе отнести то или иное сообщение решает сам разработчик. К данному вопросу следует подойти с максимальной серьезностью. Очевидно, что ошибки не следует помечать как Info, не следует игнорировать ошибки и просто не записывать их в лог. От правильно настроенной системы логирования будет зависеть простота сопровождения всей системы, оперативность реагирования на ошибки и время, затраченное на устранение проблемы.
Иногда разработчики ленятся писать логи, не хотят тратить на это время. В дальнейшем оказывается, что время, затраченное на поиск и исправление ошибок, в разы больше времени, которое потребовалось бы на создание системы логов.
Естественно, многое зависит от сложности проекта. Если вы создаете простейший трехстраничный сайт-визитку или консольное приложение для собственных нужд у себя на локальном компьютере, то написание сложной системы логирования может быть дольше, чем создание самого проекта. В таком случае в логи можно записывать только сообщения об ошибках или почему упал сайт. Но если вы работаете над сложным проектом в команде с другими разработчиками, то грамотное ведение логов просто обязательно.
Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно .
- ${basedir} - корневой каталог нашего приложения
- ${shortdate} - текущая дата в формате yyyy-MM-dd
- ${longdate} - текущая дата в формате yyyy-MM-dd HH:mm:ss.ffff
- ${callsite} - место вызова лога (название класса, название метода)
- ${uppercase:${level} - уровень логирования
- ${message} - непосредственно сообщение, которое будет записано в лог
- ${newline} - символ новой строки
Public class StudentsRepository { private static Logger logger = LogManager.GetCurrentClassLogger(); //... }
Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.
Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:
Public Student GetStudentById(int id) { //здесь моделируется ситуация реальной выборки студента из базы данных... logger.Trace("Запрашиваемый id студента: " + id); logger.Trace("Попытка подключения к источнику данных"); logger.Trace("Подключение к источнику данных прошло успешно. Затраченное время(мс): " + new TimeSpan(0, 0, 0, 0, 20).Milliseconds); var student = _studentsList.FirstOrDefault(x => x.Id == id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); return student; }
Обратите внимание, что мы на объекте logger вызываем метод Trace(). Он имеет соответствующее значение - запись в лог сообщения типа Trace. Если обратиться к определению класса Logger, то можно обнаружить, там также присутствуют и другие методы для всех уровней лога, которые мы будем использовать далее.
Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:
Public List
Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():
Public ActionResult GetStudent(int id) { logger.Info("Преподаватель запросил студента с id == " + id); StudentsRepository repository = new StudentsRepository(); Student student = repository.GetStudentById(id); return View(student); }
Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:
//... Student student = repository.GetStudentById(id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет"); //...
Var student = _studentsList.FirstOrDefault(x => x.Id == id); if (student == null) logger.Error("Ошибка. Не найден студент с id == " + id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет");
Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:
//... logger.Fatal("Достигнут максимально допустимый в приложении предел использования оперативной памяти 90%"); //...
Мы рассмотрели все шесть уровней логирования и описали процесс работы нашего приложения максимально подробно. Теперь мы можем сразу проанализировать работу сайта, просто изучив логи, и не заглядывать в исходный код.
Подобным образом происходит логирование. В нашем простейшем примере, где мы моделируем работу со студентами, все предельно ясно и прозрачно даже без логов. Но в сложных проектах ведение логов является неотъемлемой частью разработки.
Конечно, это далеко не полные возможности настройки платформы NLog. В конфигурационном файле можно настроить запись логов в другие места, например, в базу данных, на консоль, в оперативную память, отправлять как емаил-сообщение, отправлять сообщения по сети и так далее. Также можно настроить фильтрацию сообщений, более сложный шаблон сообщений. Если вас не устраивает стандартный функционал логгера, то можно написать свое собственное расширение и подключить.
На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования - это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.
Давайте научимся следить за выполнением логики в нашей программе, для этого мы научимся использовать логирование, поймем зачем оно и где используется.
Шаг 0. Обзор
Логирование – не используя термины википедии, то это возможность следить за процесом выполнения бизнес-логики проекта.
Зачем нужно логирование и что оно даёт?
Допустим у вас есть WEB-проект, и он что-то делает, сейчас не важно что именно. Допустим это интернет магазин, на котором при оформлении заказа нужно отправить на почту покупателю отчет о его покупке, но почтовый сервер вышел из строя, и программно письмо не отправилось.
Вы, как человек который администрирует магазин начнет разбераться в чем же проблема. Неопытный человек будет долго искать проблему, а опытный сразу полезет в логи сервера, но там все логи сервера и найти то что нужно вам сложно.
В этом случае решение следующее, выводить нужные вам логи в отдельный файл. Но как понять, какие из всех логов, которые сыпятся в общий лог сервера нужны вам? Для этого нужно реализовать свою систему логирования, где вы сможите указать какие логи куда выводить, или же настроить уровни логирования.
В данном уроке мы рассмотрим как сконфигурировать и начать использовать Log4j.
Шаг 1. Создаем проект и добавляем завимости
Запускаем всеми любимую Intellij IDEA и тыкаем New Project выбираем Maven Module и называем его:
Теперь в pom.xml жлбавим зависимость:
Это все зависимости, которые надо было подключить.
Шаг 2. Создание примитивной логики для примера
Давайте создадим класс в котором была бы бизнес-логика, назовем его OrderLogic :
Package com.devcolibri.logpack; public class OrderLogic { public void doOrder(){ // какае-то логика System.out.println("Заказ оформлен!"); addToCart(); } private void addToCart() { // добавление товара в корзину System.out.println("Товар добавлен в корзину"); } }
Хочу обратить ваше внимание на то, что логика данного проекта не важна, так как мы рассматриваем логирование, для этого я и подготовил примитивную логику класса OrderLogic.
И теперь создаем Main класс:
Package com.devcolibri.logpack; public class Main { private static OrderLogic logic; public static void main(String args) { logic = new OrderLogic(); logic.doOrder(); } }
В результате выполнения данного кода, мы получим следующее:
Заказ оформлен! Товар добавлен в корзину
Как видите пока ничего нового.
Шаг 3. Конфигурируем Log4j
Чтобы гибко управлять логированием стоит создать в resources/ файл log4j .properties:
Теперь в этот файл добавим пару строк конфигураций:
# Уровень логирования log4j.rootLogger=INFO, file # Апендер для работы с файлами log4j.appender.file=org.apache.log4j.RollingFileAppender # Путь где будет создаваться лог файл log4j.appender.file.File=C:\\TMP\\log_file.log # Указываем максимальный размер файла с логами log4j.appender.file.MaxFileSize=1MB # Конфигурируем шаблон вывода логов в файл log4j.appender.file.layout=org.apache.log4j.PatternLayout log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
Теперь давайте более детальней разберем строку формирования шаблона:
Log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
Значения:
%d{yyyy-MM-dd HH:mm:ss} – выводит дату в формате 2014-01-14 23:55:57
%-5p – выводит уровень лога (ERROR , DEBUG , INFO …), цифра 5 означает что всегда использовать 5 символов остальное дополнится пробелами, а минус (-), то что позиционирование по левой стороне.
%L – номер строки в которой произошёл вызов записи в лог.
%m – сообщение, которое передали в лог.
%n – переход на новую строку.
Шаг 4. Добавляем примитивное логирование
Теперь в класс OrderLogic добави логирование и посмотрим на результат:
Package com.devcolibri.logpack; import org.apache.log4j.Logger; public class OrderLogic { // Инициализация логера private static final Logger log = Logger.getLogger(OrderLogic.class); public void doOrder(){ // какае-то логика System.out.println("Заказ оформлен!"); // логируем инфо log.info("Это информационное сообщение!"); addToCart(); } private void addToCart() { // добавление товара в корзину System.out.println("Товар добавлен в корзину"); // логируем ошибку log.error("Это сообщение ошибки"); } }
Теперь давайте запустим код опять. Мы получим тот же результат, вот только уже по пути C://TMP/ будет лежать файл log_file.log со следующим содержимым:
2014-01-14 23:55:57 INFO OrderLogic:12 - Это информационное сообщение! 2014-01-14 23:55:57 ERROR OrderLogic:19 - Это сообщение ошибки
Резюме : есть много статей в интернетах о том как это полезно и прекрасно логировать время и проделанную работу. Однако это для себя. Но зачем этого требует от вас руководство? Наверно из благих целей.
Есть одна менеджерская мечта - команда должна хорошо логировать свою работу и время, потраченное на нее. Ведь тогда будет понятно кто сачкует, а кто перегружен; кому медаль золотую вручить, а кому - позолоченную; какие задачи сложно даются, а какие - просто; сколько денег нужно потратить, а сколько - отобрать. Но на практике хренушки, к сожалению это не работает для большинства команд. Как правило по двум причинам:
Кто-то слишком ленивый, ведь логирование отвлекает от прямых обяазанностей ради “какой-то бюрократии”.
У кого-то просто нет для этого навыков. Есть люди, которые не умеют этого делать - когда забудут, а когда вовсе не придумают что написать… А чукча, оказывается, не писатель. Всему конечно можно обучиться при желании, но желания нет.
Чаще всего дело в обоих причинах, но если копнуть чуть глубже - обычные смертные не видят полезности в логировании работы, а понимать менеджеров никто не хочет - их принято нелюбить.
Полезность в логировании на самом деле огромная - человек упорядочивает свою работу; понимает насколько он завершил задачу, а сколько еще осталось; дает возможность другим понять и продолжить его труд если вдруг кирпич на голову. В общем-то это важная практика для time management’a.
Хоть и трудно переоценить необходимость логирования, стоит все же смириться, что делать это готов далеко не каждый, а всех жизни учить тоже плохо - раздражает. И нужно ли это на самом деле для руководства - спорный вопрос. Вот почему…
Как Agile начистил рожу логированию
По залогированному времени видно кто сачкует, а кто работу работает . На самом же деле в плане отчетности люди постоянно мухлюют. Если прошло 2 часа, а на реальную работу человек потратил лишь час, залогирует он все равно 2 часа. Даже если говорить про инструменты записывающие состояние рабочего стола и активность нажатий, народ заводит доп. компьютеры и/или пытается отдохнуть кликая без цели по окошкам.
Отдых тоже важен, без него продуктивность упадет, это нормально. Но человек чувствует себя неловко если начальство видит что он просиживает время, поэтому и не отдохнуть, и не поработать.
Если же говорить про выявление совсем ленивых, так их продуктивность будет и так видна по количеству и качеству сделанной работы, для этого не нужно ничего логировать. Вы, как ни крути, заметите разницу между продуктивными людьми и лежебоками (жопосидами).
По залогированному времени видно насколько правильно мы оцениваем задачи . Если вы до сих пор оцениваете задачи во временных единицах, пора задумываться, пора прислушиваться.. Оценка времени давно показала себя с плохой стороны - не умеет человек оценивать временные рамки. Поэтому задачи оценивают в более грубых единицах - по сложности (story points), либо, и это приобретает популярность, просто на глаз определяют сколько задач брать в итерацию. Ведь в итоге важно не то сколько времени потратил конкретный человек, а сколько задач он сделал.
Залогированное время помогает находить проблемы . Т.е. если человек потратил слишком много времени на какую-то задачу, то либо он плохо разбирается в этой области (и ему нужно помочь), либо задача поставлена неверно, либо та часть приложения с которой он работает - проблематична. Да, это правда может помочь, но только если эти все проблемы не обсуждаются на ежедневных статус-митингах. Т.е. логирование времени тут заменяет общение с людьми. На самом деле общение с людьми не заменить, это всегда более эффективно, поэтому в данном случае (логирование времени как инструмент для выявления проблем) - это один из симптомов того что команда мало общается. На daily standups проблемы и так бы выявились при правильном подходе.
Если логировать, то как?
Во-первых, главное - это логировать не время, а сделанную работу. Лучшее место для этого - commit message если вы работаете с кодом и/или issue tracker. Так мы прогресс держим близко к тому где все крутится, не нужно далеко ходить чтоб узнать что конкретно сделал тот или иной член команды.
У красноглазых есть отличные гайдлайны о том как должны выглядеть сообщения в коммитах и что там должно помещаться, вот еще статейка по-короче . Как правило если ваш коллега подошел к вам с вопросом, ему что-то не понятно о вашем изменении, значит коммит был описан плохо. Это важно во-первых для повседневной работы: не все можно обсудить на статус-митингах, а дергать по каждой мелочи коллег - значит мешать им делать свои задачи. Во-вторых, это история изменений - то что было сделано определить хоть как-то можно по содержимому, то зачем вы сделали это и почему не по-другому - об этом коллегам прийдется догадываться, а ведь не каждая фирма готова оплатить курсы молодого телепата.
По логированию времени (или в общем по time management’у) есть много всего, повторять чужое не хочу, но посоветую все-таки очередной раз попробовать Pomodoro ;) У меня получилось где-то с третьего, и все равно периодически забрасываю.
Подытожим
Логирование как работы, так и потраченного времени - безусловно полезные вещи. Особенно для себя любимого. Научить кого-то это делать - тоже полезно. Но строить по этому какие-то метрики - бесполезная затея.
Все события, происходящие при работе кассового ПО, записываются программой в файлы журналов или лог-файлы, которые впоследствии можно использовать для анализа сбоев, получения статистики, расследования инцидентов.
Лог – это текстовый файл, в котором каждому событию соответствует одна строка со временем и некоторыми дополнительными сведениями. Ведение лог-файлов позволяет восстановить картину неполадки либо последовательность действий, которая к ней привела. Для удобства пользователей лог-файлы размещаются в одной директории.
Icon
Для текущей смены лог-файлы сохраняются в директорию /linuxcash/logs/current .
Помимо лог-файлов сохраняются образы всех чеков, которые были закрыты в течении смены, а также журналы регистрации в ККМ сумм для данных документов.
- Файлы с образами чеков сохраняются в директорию /linuxcash/logs/current/documents и именуются по правилу <номер_смены>-<номер_чека>.img , здесь номер_смены - номер текущей смены, номер_чека - номер завершенного чека.
- Журналы регистрации сохраняются в директорию /linuxcash/logs/current/trs и именуются как <номер_чека>.<метка_времени> , здесь - номер_чека - номер завершенного чека, метка_времени - текущее время на момент начала регистрации в ККМ в формате unixtime .
| Директория | Содержимое |
|---|---|
| documents | образы закрытых чеков |
| trs | журнал регистрации в ККМ текущего документа (файл присутствует, если произошло аварийное завершение работы программы во время печати чека) |
| trs/commited | журналы успешно зарегистрированных документов в ККМ |
| trs/canceled | журналы документов, которые не были зарегистрированы в ККМ |
| trs/critical | журналы регистрации в ККМ, содержащие критические ошибки, возникшие при регистрации |
Для упрощения разбора информации "задним" числом при закрытии смены выполняется ротация директорий с лог-файлами. Таким образом, для каждой смены в каталоге /linuxcash/logs/cashlogs создается директория, название которой соответствует номеру смены.
Уровень детализации записей в лог-файлах
Правила ведения логов, события, которые подлежат записи, их подробность и полнота задаются в файле /linuxcash/cash/conf/Artix/artix.conf . Используемая подсистема ведения логов позволяет гибко настраивать виды журналов, объединять данные в один файл, распределять данные по нескольким файлам или выводить информацию в консоль. После установки кассового ПО логирование всех модулей осуществляется по умолчанию на уровне INFO. Запись логов ведется в несколько файлов. Наиболее важные из них:
Допускается использование одного из уровней:
- TRACE,
- DEBUG,
- INFO,
- WARN,
- ERROR.
Самый детальный уровень называется TRACE, самый строгий - ERROR. В зависимости от выбранного уровня в лог записывается информация, которая соответствует уровню, или строже.
| Уровень | Описание |
|---|---|
| ERROR | ошибка в приложении, приложение может работать дальше без возникновения проблем, причина проблемы может состоять в неправильных входных данных или доступе к внешним сервисам |
| WARN | некритичная ошибка, приложение может работать дальше без возникновения проблем, вероятно одна из функций приложения дала сбой, который может быть исправлен |
| INFO | важная информация о работе приложения, например, запуск/остановка приложения, использование конфигурационных файлов или аутентификация пользователя в системе |
| DEBUG | отладочная информация работы приложения, например, технические данные, полученные при работе с внешними системами, или информация о вызове методов объектов, включая список параметров |
| TRACE | трассировка выполнения приложения, например, информация о вызываемых методах и времени их работы, информация о времени вызова внешних сервисов. |
Для изменения уровня детализации достаточно установить требуемый уровень первым параметром требуемого логгера.
Пример настройки записи информации в файл terminal.log
Ротация данных после закрытия смены
Запуск процесса ротации файлов осуществляется после закрытия смены при помощи shell-скрипта /linuxcash/cash/bin/oncloseshift.sh, выполнение которого настраивается через макрос «Закрытие смены», как вызов внешнего скрипта.
Icon
За реорганизацию файлов отвечает модуль artix-maint-mysql . Журналы событий за текущую смену переименовываются в соответствии с правилами ротации , заданными в разделе shiftly .
Остановка работы кассы при ошибке логирования
Начиная с версии 4.6.105 кассовая программа приостанавливает функционирование в случае прекращения записи в любой из логов, которые пишет сама касса, до устранения неполадок.
Остановка логирования при работе кассы - серьезная проблема, она может быть следствием прекращения правильной работы кассы. Такие ситуации возможны при непредвиденном отключении электроэнергии в процессе функционирования кассы, а также при проблемах с комплектующими.
При возникновении ошибки, связанной с прекращением логирования, программа остановит работу и выдаст сообщение:
Необходимо восстановить возможность логирования данных, после чего нажать ОК - программа перезапустится в нормальном режиме.
