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

Логирование сценариев

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

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

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

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

Лог (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 GetStudents() { //здесь моделируется ситуация реальной выборки студентов из базы данных... logger.Debug("Произведено подключение к базе данных"); logger.Debug("Произведена выборка всех студентов"); return _studentsList; }

Идем далее. На уровне 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, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.

Когда программа ведет запись действий в лог-файл (как правило, это файлы с расширением *.log), можно выяснить когда произошло то или иное событие, в какой момент времени произошел сбой приложения или возникла ошибка. Логирование позволяет отследить время старта сервера и его остановку, время подключения пользователя к базе данных, время попытки взлома веб-сервера и другие важные события, в зависимости от того, какая программа ведет запись истории в файл лога. Просмотр лога помогает отладить тот или другой программный процесс. LogViewer Pro - бесплатная для домашнего использования программа для просмотра логов. С её помощью Вы сможете читать лог-файлы в удобном виде, с выделением строчек лога цветом, в зависимости от того, какую информацию несет запись.

Просмотр логов

Просмотрщик логов LogViewer Pro можно адаптировать под любую структуру записи файла лога. Для выделения цветом отдельных строчек лога достаточно задать выражение - слово или символы, встречающиеся в строке. Утилита распознает большое количество кодировок, выполняет поиск по файлу лога, умеет переносить строчки при недостаточной ширине окна, выводит содержимое лога на печать, поддерживает открытие сразу нескольких файлов в одном окне. К файлу лога можно применить фильтр, при просмотре лога можно устанавливать закладки, для удобства просмотра LogViewer Pro пронумерует строчки. Для оперативности и постоянного мониторинга программа может читать лог в режиме реального времени. Интерфейс программы изменяется - можно изменить цвет фона, выбрать шрифт, добавить или убрать отдельные элементы приложения. LogViewer Pro поддерживает работу из командной строки, является portable-приложением. Программа бесплатна для частного, домашнего использования. При бесплатном использовании утилиты LogViewer Pro будет при запуске открывать окно на 25 секунд с предложением о покупке лицензии - это единственное ограничение функционала программы.

Скриншоты программы LogViewer Pro

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

Лог – это текстовый файл, в котором каждому событию соответствует одна строка со временем и некоторыми дополнительными сведениями. Ведение лог-файлов позволяет восстановить картину неполадки либо последовательность действий, которая к ней привела. Для удобства пользователей лог-файлы размещаются в одной директории.

Icon

Для текущей смены лог-файлы сохраняются в директорию /linuxcash/logs/current .

Помимо лог-файлов сохраняются образы всех чеков, которые были закрыты в течении смены, а также журналы регистрации в ККМ сумм для данных документов.

• Файлы с образами чеков сохраняются в директорию /linuxcash/logs/current/documents и именуются по правилу <номер_смены>-<номер_чека>.img , здесь номер_смены - номер текущей смены, номер_чека - номер завершенного чека.
• Журналы регистрации сохраняются в директорию /linuxcash/logs/current/trs и именуются как <номер_чека>.<метка_времени> , здесь - номер_чека - номер завершенного чека, метка_времени - текущее время на момент начала регистрации в ККМ в формате unixtime .

Для упрощения разбора информации "задним" числом при закрытии смены выполняется ротация директорий с лог-файлами. Таким образом, для каждой смены в каталоге /linuxcash/logs/cashlogs создается директория, название которой соответствует номеру смены.

Уровень детализации записей в лог-файлах

Правила ведения логов, события, которые подлежат записи, их подробность и полнота задаются в файле /linuxcash/cash/conf/Artix/artix.conf . Используемая подсистема ведения логов позволяет гибко настраивать виды журналов, объединять данные в один файл, распределять данные по нескольким файлам или выводить информацию в консоль. После установки кассового ПО логирование всех модулей осуществляется по умолчанию на уровне INFO. Запись логов ведется в несколько файлов. Наиболее важные из них:

Допускается использование одного из уровней:

• TRACE,
• DEBUG,
• INFO,
• WARN,
• ERROR.

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

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

Пример настройки записи информации в файл terminal.log

Ротация данных после закрытия смены

Запуск процесса ротации файлов осуществляется после закрытия смены при помощи shell-скрипта /linuxcash/cash/bin/oncloseshift.sh, выполнение которого настраивается через макрос «Закрытие смены», как вызов внешнего скрипта.

Icon

За реорганизацию файлов отвечает модуль artix-maint-mysql . Журналы событий за текущую смену переименовываются в соответствии с правилами ротации , заданными в разделе shiftly .

Остановка работы кассы при ошибке логирования

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

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

При возникновении ошибки, связанной с прекращением логирования, программа остановит работу и выдаст сообщение:

Необходимо восстановить возможность логирования данных, после чего нажать ОК - программа перезапустится в нормальном режиме.

Естественной потребностью системного администратора или специалиста по безопасности является некий анализ того, что происходит как на конкретном компьютере конкретного пользователя, так и в локальной сети. Технически задача выполнима, ибо разработчики множества приложений, которыми мы пользуемся, заложили в свои продукты функцию логирования информации. Информация, которую хранят логи конкретного компьютера в сети, может сказать много тому, кто, с некоторым знанием предмета, рискнет заглянуть внутрь. Нельзя сказать, что чтение логов является тайной дисциплиной, которая доступна только просвященным гуру, впрочем, для того, чтобы легко ориентироваться и четко сопоставлять информацию, которая встречается в логах различных приложений, надо действительно иметь представление о том, что и как, почему и зачем пишется в логи, а кроме того, четко представлять предметную область изучаемого ПО. Дело в том, что запись информации в логи (вероятно, в силу некой меньшей приоритетности, чем работа самого приложения) страдает хаотичными веяниями различных производителей. Соответственно, и интерпретировать такую информацию надо с учетом специфики и, может быть, каких-то рекомендаций производителя.

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

Типы логов (механизмы логирования информации)

Конфигурирование логирования

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

Интенсивное логирование может серьезно повлиять на производительность системы

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

1. Имя файла, директория или полный путь к тому файлу, в который пишется лог. Это очень полезно, если логирование необходимо и есть возможность или необходимость организовать запись логов на отдельный жесткий диск, сетевой диск и т. п. Такой способ удобен, если логи будут интерпретироваться сторонним приложением, которое находится на отдельном компьютере и каким-либо образом может повлиять на работу основной системы.
2. Критерий замены лога (Log Rotation). Рано или поздно логи становятся большими или их становится слишком много. Чтобы избежать проблем, которые с этим связаны (постоянная работа с огромным файлом отрицательно сказывается на производительности системы), программы, осуществляющие логирование, обычно используют что-нибудь из следующего списка возможностей управления логами:
   • Каждый день (неделю, месяц и т. д.) система использует новый лог-файл. Обычно если смена лог-файлов связана с каким-либо исчислением времени (каждый день, каждый год и т. п.), то в имени используется время (дата и время или только дата, иногда какая-нибудь производная) создания или финального закрытия (финализации) данного лог-файла. Если система использует уникальное имя (а имя с датой, временем или их производной можно считать уникальным, так как время монотонно возрастает), то такие логи обычно не очищаются системой. К примеру, Symantec Antivirus или Tivoli Access Manager for e-Business используют лог-файлы, которые хранят в своем имени время смены лог-файла. В множестве таких логов, которые, к примеру, скопились за долгое время, очень удобно искать информацию, относящуюся к конкретному промежутку времени. Кроме того, выработав критерий длительности хранения старых логов, довольно легко очищать уже устаревшие логи.
   • Смена файла происходит по достижении им определенного размера. Старый файл обычно сохраняется определенное время. Может быть, удаление старых файлов оставлено на решение пользователя, то есть в случае с файлами, которые хранят в своем имени дату и время, они могут храниться вечно, так как система не заботится о них, но пользователь в любой момент может решить, что старые файлы ему не нужны, и удалить их. В этом, кстати, дополнительное удобство — в имени файла хранится дата его создания, то есть всегда легко понять, нужен такой файл или нет. Имя файла может содержать порядковый номер этого лога, то есть каждая последующая смена увеличивает счетчик на единицу. Количество таких файлов тоже может быть произвольно, кроме того, они могут быть дополнительно заархивированы, что экономит некоторое место при длительном хранении. Типичным примером является Linux (UNIX) Syslog, который позволяет настраивать как размер файла, так и количество используемых файлов.
   • Смена файла происходит одновременно с перезапуском сервиса, который пишет лог. Случай представляет собой некоторую опасность, так как в некоторых случаях сервис может не перезапускаться месяцами, а то и годами. Это приводит (точно-точно, такие случае не очень часты, но все равно бывают) к тому, что в определенный момент становится понятно, что лог-файл уже занимает огромное место на жестком диске, которое рациональнее использовать для чего-либо иного. Используется, к примеру, HP Tru64 UNIX (вообще говоря, HP Tru64 имеет некое ограничение на размер Audit Log, которые пишутся между перезапуском сервисов, но это ограничение довольно велико – около 300 Mб).
   • Частота сброса информации в файл. Такой параметр редко предоставляется для открытой модификации, но довольно часто он все же присутствует (к примеру, Tivoli Access Manager for e-Business). Он хорош тем, что при грамотной настройке несколько уменьшает число обращений к жесткому диску от логирующей программы, а плох тем, что, модифицировав его, довольно легко серьезно снизить производительность сервера.

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

Набор событий, которые будут логироваться. Довольно часто важно иметь возможность настроить логирование только тех событий, которые реально необходимы. К примеру, часто нет необходимости логировать информацию обо всех транзакциях в базе данных, особенно если это куча select-запросов, которые, вероятно, не содержат угрозы с точки зрения безопасности. В таком случае можно изрядно снизить нагрузку на сервер, выключив логирование транзакций, но оставив учет только реально необходимых событий: попыток авторизации, попыток доступа к файлам, изменения системных настроек и т. п. Обычно производитель предоставляет свои профили логирования: от полного выключения и до полного логирования всего происходящего. Довольно часто есть возможность указать даже не профиль, а настройки логирования для каждого конкретного события (например, такая возможность есть в MS SQL Server C2 Audit). Такие настройки позволяют сделать очень гибкое логирование информации, которая нужна в конкретном случае. Увы, но настройка логируемых событий встречается далеко не во всех программах.

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