CC BY
6
УДК 681.3.068 В.Л. Волушкова
ГРНТИ 50.41.25 Тверской государственный университет
DOI: 10.47501/ITNOU.2021.1.60-64
МНОГОУРОВНЕВОЕ ЛОГГИРОВАНИЕ РАБОТЫ ПРОЦЕССОВ И ЗАДАЧ Способ поиска ошибок в работающих системах всегда достаточно трудная задача. Это обусловлено ограниченным временем поиска и отсутствием информации о месте ошибки. Для решения этой проблемы команда поддержки часто использует собственное протоколирование (логгирование), которое пишет сообщения (логи) в критических местах программы. В данной работе представлен способ поиска ошибок, который использует логгирование с многоуровневым подходом. Этот подход позволяет регулировать объем сохраняемой в логе информации.
Ключевые слова: логгирование; Oracle DB; трассировка SQL-операторов; PL SQL.
V. Volushkova
Tver State University
MULTILEVEL LOGGING OF PROCESSES AND TASKS
Finding bugs on live systems is always a difficult task. This is due to the limited search time and the lack of information about the location of the error. To solve this problem, the support team often uses their own logging, which writes messages (logs) at critical points in the program. In this paper, a method for finding errors is presented, which uses logging with a layered approach. This approach allows you to adjust the amount of information stored in the log. Key words: logging; Oracle DB; tracing SQL statements
В рабочих программных системах (вышедших в релиз) всегда возникают ошибки выполнения. Как правило, такие ошибки связаны с работой базы данных (БД). У клиента возникает вопрос - почему программа не работает? Время ответа на такие вопросы сильно ограничено. У программистов, осуществляющих поддержку работы системы, есть три подхода. Первый - тестирование. Второй - воспользоваться стандартным протоколом работы БД. Третий - использовать собственное логгирование, которое пишет сообщения (логи) в критических местах программы. В данной работе представлен способ поиска ошибок, который использует логгирование с многоуровневым подходом.
Рассмотрим стандартные способы поиска ошибок. Тестирование требует постоянного присутствия программиста при работе системы. Очень часто задачи запускаются ночью. Отслеживать ошибки в такое время не реально. Использование протокола работы БД не требует постоянного присутствия программиста. Однако, стандартные трассировки работы системы пишут много лишней информации на диск, что затрудняет поиск нужной информации [2]. Работа системы замедляется, место на диске быстро уменьшается. В силу изложенных причин разработчики используют собственное протоколирование работы системы для быстрого поиска ошибок [3]. Логгирование системы происходит часто на уровне отладки и при переходе в релиз многие логи убирают. Такой подход не исключает ошибок - некоторые ненужные логи остаются, а нужные исчезают. Для гибкой работы с логами предложен подход на основе многоуровневости, которая управляется с использованием таблицы параметров.
Покажем место вставки лога в процедуре, написанной на PL SQL.
BEGIN
SELECT reload_flag INTO l_reload_flag FROM xx_pr_settings WHERE ROWNUM = 1;
EXCEPTION WHEN OTHERS THEN -- сюда можно вставить запись об ошибке l_reload_flag := 'N';
END;
Система поддержки логгирования включает в себя ряд функций (PL SQL) и две таблицы, которые хранятся в БД. Система поддержки логгирования написана для задач, работающих с БД Oracle [1], но ее при небольшой корректировке можно применить и для других БД.
В основную таблицу записываются сообщения об ошибках, возникших при работе системы. Перечислим наиболее часто встречающиеся ошибки:
• логические;
• исключения - блокировка ресурсов, отсутствие данных, нарушение целостности и т.д.;
• ошибка чтения параметра;
• ошибка ожидания типа - вместо числа приходит строка и т.д.;
• ошибка запуска - не запущен ли еще один экземпляр этой же программы в другой сессии;
• ошибка времени - программа выполняется слишком долго.
Таблица логов имеет структуру, представленную таблицей 1.
Таблица 1. Структура таблицы логов
ID NUMBER Уникальный идентификатор записи, заполняется автоматически при вставке записи в таблицу
CREATION_DATE DATE Дата и время создания записи, заполняется автоматически при вставке записи в таблицу
CREATED_BY VARCHAR2(50) ID пользователя, создавшего запись, заполняется автоматически при вставке записи в таблицу
MSG TYPE VARCHAR2(1) Тип записи: M - message, E-error, D - debug
MSG TEXT VARCHAR2(4000) Текст сообщения
RUN NUM NUMBER Номер процесса
EVENT NAME VARCHAR2( 100) Имя процесса
Также в системе логгирования создана таблица настроечных параметров. Особенностью данной таблицы является то, что параметры настройки являются не названиями столбцов, а содержимым полей таблицы. Таким образом, имея «столбчатую», а не линейную структуру таблицы настроечных параметров, можно добавлять параметры, не меняя структуру таблицы. Структура таблицы настроечных параметров представлена таблицей 2.
Таблица 2. Структура таблицы настроечных параметров
ID NUMBER Уникальный идентификатор записи, заполняется автоматически при вставке записи в таблицу
EVENT NAME VARCHAR2(100) Имя процесса
PARAM NAME VARCHAR2(50) Название параметра
PARAM VALUE VARCHAR2(50) Значение параметра
PARAM DESC VARCHAR2(4000) Описание параметра
CREATION_DATE DATE Дата и время создания записи, заполняется автоматически при вставке записи в таблицу
CREATED_BY VARCHAR2(50) ГО пользователя, создавшего запись, заполняется автоматически при вставке записи в таблицу
LAST_UPDATE_DATE DATE Дата и время крайнего изменения записи, заполняется автоматически при вставке записи в таблицу
LAST_UPDATE_ID VARCHAR2(100) ГО пользователя, сделавшего крайнее изменение записи, заполняется автоматически при вставке записи в таблицу
RECORD_VERSION NUMBER Номер версии, увеличивается на 1 при каждом изменении
Приведем пример заполнения таблицы 2. (см. рис 1)
вэк © м вь ^ н о а -
ID EVENT_NAME PARAM_NAME PARAM_VALUE PARAM_DESC
1 140) XX_BLA_BLA - LOG_LEVEL 5 уровень детализации лога: 0 - без лога. 1 - минимальное.: ■■■
2 141 XX_BLA_BLA - LQG_STORE_DAYS - 14 количество дней хранения информации в логе
3 144 XX_BLA_BLA - R В LD_W 0 R K_T AB - M Y ■ ребилд всех индексов, N - только не валидных
4 142 XX_BLA_BLA - RECJJIWT 120000 Количество записей на один цикл обработки
5 143 XX_BLA_BLA - START_MODE WAtT_0NLY possible values: ALWAYS. WAIT_0NLY
Рисунок 1. Пример заполнения таблицы настроечных параметров
В системе имеются пакетные переменные: v_event_name varchar2(100), v_start_date date, v_log_level number := 1, v_log_store_days number := 30.
Эти переменные служат для загрузки и сохранения параметров логгирования. Рассмотрим основные функции системы логгирования. Для сохранения информации в таблицу логов используются процедуры write_log, write_error. write_log сохраняет запись со значением в поле msg_type = M (message). Для сохранения информации об ошибках лучше использовать WRITE_ERROR, которая сохраняет запись с msg_type = E (error).
Для корректной работы этих процедур необходимо, чтобы были заданы необходимые значения в пакетных переменных v_event_name, v_start_date. За инициализацию этих значений отвечают процедуры INIT, SET_INIT_PARAMS. Параметр event_name для этих процедур должен быть уникальным для каждого приложения, иначе будет невозможно найти нужные записи в логе, и будет некорректно работать защита от параллельного старта (SET_LOCK).
Чтобы можно было регулировать объем сохраняемой в логе информации, предусмотрено несколько уровней логгирования, точнее - шесть - от 0 до 5. Второй параметр процедур WRITE_LOG, WRITE_ERROR - определяет минимальный уровень,
начиная с которого запись сохраняется в таблице. Процедура при своей работе сравнивает параметр со значением пакетной переменной v_log_level. Если параметр меньше или равен v_log_level - запись сохраняется в таблице, в противном случае - процедура завершает работу без сохранения записи в таблице. Уровень логгирования для задачи (значение v_log_level) можно задать несколькими способами:
1. Считать из таблицы параметров - процедура/функция LOAD_LOG_LEVEL. Это можно сделать только один раз в текущей сессии программы. Возможные значения: 0(лог запрещен) - 5(сохраняются вся информация).
2. Использовать процедуру SET_LOG_LEVEL, допустимые значения 1 - 5.
3. Процедура DISABLE_LOGGING - устанавливает v_log_level = 0 и сохраняет предыдущее значение.
4. Процедура RESTORE_LOG_LEVEL - восстанавливает значение уровня логгирования, которое было до выполнения DISABLE_LOGGING.
5. Необходимо отметить, что процедура SET_LOG_LEVEL стирает сохраненное процедурой DISABLE_LOGGING старое значение уровня логгирования. Процедуры SET_LOG_LEVEL, DISABLE_LOGGING, RESTORE_LOG_LEVEL можно использовать сколько угодно раз в любой части программы, если это необходимо. Например, можно увеличивать/уменьшать детализацию сохранения в лог при выполнении каких-либо условий и т.д.
6. Чтобы выполнялся всегда только один экземпляр программы, используется функция SET_LOCK. Логика ее работы: проверяется наличие записей в v$session c module = v_event_name. Если такая запись найдена, функция возвращает FALSE. Если запись не найдена, то функция заполняет поле module в текущей сессии значением v_event_name и завершает работу, возвращая TRUE.
Примеры использования процедур.
Пример 1. Самый простой вариант init - write_log
DECLARE
c_event_name CONSTANT VARCHAR2(50) := ' XX_BLA_BLA';
BEGIN
XX_SQL.INIT(c_event_name);
XX_SQL.WRITE_LOG('любая информация');
Здесь XX_SQL - имя пакета системы логгирования, WRITE_LOG - имя процедуры записи лога, INIT - имя процедуры инициализации. Процедура инициализирует значения пакетных переменных (в данном случае c_event_name).
Пример 2. Использования многоуровневого лога
DECLARE
lc_event_name CONSTANT VARCHAR2(50):= 'XX_TEST';
BEGIN
XX_SQL.LOAD_LOG_LEVEL(lc_event_name);
XX_SQL.INIT(lc_event_name);
XX_SQL.WRITE_LOG('program started');
LOOP
XX_SQL.WRITE_LOG ('message in cycle 1', 2); LOOP
XX_SQL.WRITE_LOG('message in cycle 2', 3); END LOOP; END LOOP;
XX_SQL.WRITE_LOG('program finished'); END;
Если загруженный log_level = 1 - в лог попадут только две записи: Program started. Program finished.
Если загруженный log_level = 2 - добавятся записи из первого цикла.
Если загруженный log_level = 3 - добавятся записи из первого и второго цикла.
Как показано в примере 2, управление уровнем логгирования достаточно гибкое. Во время отладки программ можно воспользоваться уровнем логгирования 3 или 5. Это соответствует записи в лог информации из всех циклов программы. Когда программа отлажена и не нужно такое подробное логгирование, уровень можно уменьшить, т.е. сделать его равным 1. Для того чтобы изменить уровень логгирования достаточно поменять значение поля LOG_LEVEL таблицы 2. Это не требует корректировки кода программы, что очень важно, т.к. любая корректировка требует тестирование и установку релиза на продуктивное окружение.
Автор считает, что в данной работе новыми являются следующие положения и результаты:
1. Управление логгированнием, построенное на многоуровневом подходе.
2. Способ хранения настраиваемых параметров системы в таблице БД.
3. Программный продукт, который позволяет производить гибкое логгирование работающих систем.
Литература
1. Кайт Томас, Кун Дарл. Oracle для профессионалов. - Диалектика / Вильямс, 2016. 960 с.
2. Кравчук В. Трассировка в Oracle - прошлое и настоящее. - [Электронный ресурс] http://citforum.ru/database/oracle/oracle_trace01/
3. Холодов E. Логгирование как инструмент повышения стабильности веб-приложения - [Электронный ресурс] https://tproger.ru/articles/logging-on-frontend-and-backend/
Сведения об авторе
Вера Львовна Волушкова к.т.н., доцент
Тверской государственный университет Тверь, Россия
Эл. почта: w2lvera@gmail.com
Information about author
Vera Volushkova
candidate of tech. sciences, associate professors Tver State University Tver, Russia
E-mail: w2lvera@gmail.com
