Автоматизация восстановления последовательности. Часть 2: логирование работы системы – выбор подхода

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

Постараюсь сформулировать основные требования к системе логирования:

  1. Доступность из разных источников и удобство доступа.
  2. Независимость от базовой системы (если не работает система, это не значит, что мы не видим логов работы).
  3. Гибкость структуры – в одном хранилище необходимо хранить разные виды ошибок с разным набором параметров.
  4. Возможность управления правами доступа к хранилищу ошибок.
  5. Хранение больших объемов данных.
  6. Скорость доступа к логам работы.

Рассмотрим возможные варианты хранения логов работы системы:

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

ПараметрКомментарии
ДоступностьДоступ к базе SQL можно получить множеством способом:Из 1С (с помощью кода или специальной консоли запросов)Из Microsoft ExcelC помощью прямых запросов к базе данныхИз разнообразных средств проектирования отчетов (пр. Microsoft Reporting Services)и т.д.
НезависимостьБаза полностью независима от 1С и, в общем случае, основываясь на информации в базе данных, можно определить, доступна ли 1С в принципе.
ГибкостьГибкость хранения достигается за счет специальных типов данных (пример XML).
ПраваОчень гибкие права доступа
Объемы храненияПочти неограниченные (во всяком случае для нашей задачи). При этом удаление старых записей делается быстро и безболезненно.
Скорость доступаС помощью грамотно построенных индексов возможно обеспечить приемлемую скорость доступа к логам для анализа.

Таким образом, единственным вариантом, который удовлетворяет всем критериям, является внешнее хранилище в базе данных, и ниже я постараюсь обосновать свой выбор по каждому требованию к системе логирования на базе MS SQL Server (именно на ней я остановил свой выбор):

Структуры для хранения логов достаточно подробно описаны по следующей ссылке http://borisfrolovsqlservertips.wordpress.com/2013/02/03/database-structure-to-store-performance-metrics/, но для наших целей придется создать гибридную таблицу. Набор столбцов представлен указанным ниже образом, чтобы в будущем использовать созданную таблицу не только для логирования разнообразных процессов, но и для хранения ошибок возникающих в системе:

ПолеКраткое описание
IDУникальный идентификатор записи
ErrorDateДата вставки записи в таблицу
UserNameИмя пользователя, под которым работал процесс
ErrorTypeIDТип ошибки (ссылка на справочник типов ошибок, чтобы предотвратить зоопарк)
ErrorMessageСообщение об ошибке
StackPathМесто возникновения ошибки
ErrorLogДетальный текст ошибки (полный лог)
ErrorXMLКолонка с типом XML, которая позволит нам для каждого вида записи формировать свой набор дополнительных параметров.

В следующий раз подробно разберем, как из 1С выполнять запись в таблицу на стороне SQL Server.

Добавить комментарий

Ваш адрес email не будет опубликован.