Экспорт журнала регистрации. Набор инструментов (приложения + исходный код)

Публикация № 1240376

Администрирование - Администрирование данных 1С - Журнал регистрации

Набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.

Что в коробке

В прошлой статье "Работа с журналом регистрации. Выходим за границы платформы" были представлены библиотеки на базе .NET Core для чтения файлов данных журнала регистрации, а также экспорта их во внешние хранилища (на текущий момент это базы SQL Server или PostgreSQL). Основными причинами для экспорта данных могут быть:

  • Низкая производительность стандартного журнала регистрации для Ваших задач: мониторинга работы системы, рассылок по ошибкам, различного рода отчеты и многое другое. Сценариев использования журнала регистрации может быть великое множество.
  • Необходимость хранить и бэкапировать журнал регистрации в удобном, единообразном виде с возможностью бэкапирования и быстрого развертывания.
  • Влияние на стабильность работы использование стандартного журнала регистрации, вплоть до зависания рабочих процессов или менеджера кластера 1С.
  • Другие причины. Если их перечислять, то вся публикация будет об этом.

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

Поехали дальше!

Перед началом

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

  • Добавление поддержки экспорта в ElasticSearch
  • Добавление поддержки экспорта в MySQL
  • Добавление поддержки экспорта в MongoDB
  • Добавление поддержки экспорта в CosmosDB (да, есть такая, если кто не знал)
  • Создание LINQ-провайдера для файлов данных журнала регистрации
  • Библиотека для диагностики процесса реструктуризации и динамического обновления
  • И многие, многие другие идеи.

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

А теперь к делу.

Требования

Для работы приложений требуется установленный .NET Core 3.1.

Работа библиотек тестировалась со старым текстовым форматом (*.LGF) и новым SQLite (*.LGD) для платформ от версии 8.3.5 до 8.3.16 включительно).

Под Windows и Linux (в основном Ubuntu последний версий и CentOS).

Сценарии использования

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

GUI-приложение

Решение будет привычным для тех, кто не любит консоль :). Классическое приложение для экспорта данных журнала регистрации. Работа с ним проста:

  • В поле "Каталог журнала" указываем путь к файлу журнала регистрации, который необходимо выгрузить в базу данных.
  • Настраиваем информационную систему:
    • Указываем имя. Будет создана запись для указанной информационной системы и все записи журнале будут загружены от ее имени. Таким образом, в базе можно хранить журналы регистрации разных информационных баз, разделяя их по системам.
    • Указываем описание. Это справочная информация об информационной системе.
  • Выбираем тип хранилища, куда будут выгружаться данные. Пока доступны только SQL Server и PostgreSQL.
  • Указываем размер порции данных для выгрузки. По умолчанию это 10000 записей. Именно столько за одну итерацию будет выгружено из журнала в хранилище. Можно подобрать его под свои ресурсы, учитывая правило: чем больше порция, тем больше требуется аппаратных ресурсов приложению, но при этом скорость выгрузки может быть значительно ускорена. Если порция слишком маленькая, то время на получение каждой этой порции может занимать основную часть времени экспорта данных, снижая производительность. Но при этом и аппаратных ресурсов приложение будет использовать меньше. Везде нужен баланс.

Выглядит это вот так.

При открытии / закрытии приложения настройки сохраняются, поэтому не рекомендую хранить логины и пароли в строке подключения. Будьте бдительны :). NTLM наше все.

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

 
 База данных для хранения данных журналов регистрации (SQL Server)

Приложение только для Windows и требует установки .NET Core 3.1. Может использоваться для ручной выгрузки данных из файлов журнала регистрации. Например, если Вы их ранее бэкапировали, а теперь желаете перевести в другие хранилище. Для регулярной выгрузки использовать крайне неудобно.

Консоль наше все

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

{
  "StorageType": "SQLServer",
  "ConnectionStrings": {
    "EventLogDatabase": "Data Source=<ВашСервер>;Initial Catalog=<ИмяБазыДанных>;Integrated Security=True"
  },
  "InformationSystem": {
    "Name": "Бухгалтерия 3.0",
    "Description": "Информационная база для бухгалтерского учета."
  },
  "EventLog": {
    "SourcePath": "C:\\Program Files\\1cv8\\srvinfo\\reg_1541\\0c00509b-1c70-4e5c-8bd4-fe01221561a4\\1Cv8Log\\1Cv8.lgd",
    "UseWatchMode": true,
    "DelayMs": 60000,
    "Portion": 10000
  }
}

Подробнее о каждой настройке:

  • StorageType - тип хранилища для экспорта данных. Доступные значения: SQLServer и PostgreSQL.
  • ConnectionStrings - раздел с настройками подключения к хранилищу.
    • EventLogDatabase - строка подключения к базе данных для экспорта.
  • InformationSystem - настройки информационной системы, журнал регистрации которой будет выгружаться.
    • Name - имя информационной системы.
    • Description - описание информационной системы.
  • EventLog - настройки обработки данных журнала регистрации.
    • SourcePath - путь к каталогу с файлами данных журнала регистрации. Может быть указан как каталог, так и конкретный файл журнала (LGF или LGD).
    • UseWatchMode - булево. False - означает, что при запуске приложение выгрузит все данные, которые удастся получить и после завершит работу. True - выгрузка данных будет выполняться порциями и с некоторой периодичностью. После выгрузки всех данных приложение не завершит работу, а будет ожидать появления новых данных в журнале регистрации.
    • DelayMs - время в миллисекундах, с которым приложение будет проверять наличие новых данных для экспорта. Используется, если параметр UseWatchMode  установлен в True.
    • Portion - максимальное количество событий, которое выгружается за одну итерацию обработки данных журнала регистрации.

Кроме этого, консольное приложение может использоваться как для Windows, так и для Linux. Оно полностью переносимое. Вот так выглядит работа приложения.

Это был запуск без явного указания файла конфигурации, т.к. "appsettings.json" находился в каталоге самого приложения. Вот то же самое под Linux (в этом конкретном случае под Ubuntu 20.04 с установленным .NET Core 3.1).

Скорость экспорта ниже в последнем случае только потому, что Ubuntu запущена на виртуальной машине с весьма ограниченными ресурсами. Стоит отметить, что приложение позволяет и под Linux выполнять экспорт во все доступные хранилища (как SQL Server, так и PostgreSQL). На анимации выше как-раз процесс выгрузки данных в базу SQL Server из-под Ubuntu. Как уже говорилось ранее, база данных на PostgreSQL почти такая же по структуре как и для SQL Server. Файл конфигурации экспорта данных также очень похож на то, что делается для экспорта в базу SQL Server.

 
 База данных для хранения данных журналов регистрации (PostgreSQL)
 
 Пример файла конфигурации для экспорта в PostgreSQL

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

E:\YY.EventLogManager\YY.EventLogManager.ConsoleApplication.exe -config "C:\Configs\appsettings-buh3.json"
E:\YY.EventLogManager\YY.EventLogManager.ConsoleApplication.exe -config "C:\Configs\appsettings-ut11.json"

Перейдем к следующему сценарию использованию.

Служба

Все мы знакомы со службами Windows. Было бы логично использовать службу, если экспорт журнала регистрации будет вестись на постоянной основе. Это позволит иметь во внешнем хранилище журнал регистрации, максимально приближенный по состоянию к журналу самой 1С. Сейчас рассмотрим такой сценарий. При этом создадим службу как в Windows, так и демон в Linux. Да, да. В Windows это служба, а в Linux это демон :)

Начнем со службы Windows.

На стороне Windows

Фактически исполняемый файл службы похож по логике работы на консольное приложение, только взаимодействие с ним производится не через графический / консольный интерфейс, а через специальный API управления службой. С помощью этого API можно запускать, останавливать службу, приостанавливать (если доступно), регистрировать, удалять и др. Для регистрации службы достаточно распаковать соответствующее приложения в каталог, создать файл конфигурации экспорта и зарегистрировать службу.

Допустим, содержимое архива со службой было распаковано в каталог "E:\YY.EventLogManager" (это просто для примера). После этого создаем файл конфигурации экспорта аналогичный тем, что были в примерах выше.

{
  "StorageType": "SQLServer",
  "ConnectionStrings": {
    "EventLogDatabase": "Data Source=<ВашСервер>;Initial Catalog=<ИмяБазыДанных>;Integrated Security=True"
  },
  "InformationSystem": {
    "Name": "Бухгалтерия 3.0",
    "Description": "Информационная база для бухгалтерского учета."
  },
  "EventLog": {
    "SourcePath": "C:\\Program Files\\1cv8\\srvinfo\\reg_1541\\0c00509b-1c70-4e5c-8bd4-fe01221561a4\\1Cv8Log\\1Cv8.lgd",
    "UseWatchMode": true,
    "DelayMs": 60000,
    "Portion": 10000
  }
}

По этим настройкам экспорт данных журнала регистрации будет выполняться в базу данных SQL Server в режиме ожидания изменений. Каждые 60 секунд служба будет проверять наличие изменений и отправлять их по 10000 событий за раз. Поместим этот файл конфигурации в тот же каталог "E:\YY.EventLogManager".

Теперь нужно зарегистрировать службу. Тут важный момент - это необходимость при регистрации службы указать в качестве параметра запуска путь к созданному файл конфигурации. С помощью любимого PowerShell (никто не запрещает использовать старый добрый cmd.exe или, о святые угодники на мопеде, OneScript) зарегистрируем службу:

sc.exe create YY.EventLogManager.Service BinPath="E:\YY.EventLogManager\YY.EventLogManager.Service.exe --config ""E:\YY.EventLogManager\appsettings.json""" start=auto
sc.exe description YY.EventLogManager.Service "Экспорт данных журнала регистрации во внешнее хранилище (SQLServer, база БУХ 3.0)"

Проверим результат, открыв оснастку управления службами в "Панель управления - Администрирование - Службы" (примерно такой путь, но зависит от версии Windows).

Грандиозный успех! Остается только запустить службу и проверить ее работу. Т.к. пользовательского интерфейса нет, то единственный вариант диагностики - это изучение логов. Каталог с логами "Logs" создается в том же каталоге, где находится файл конфигурации. В нашем случае это "E:\YY.EventLogManager". В примере все прошло хорошо (на то он и пример) и в файле с логами можно увидеть следующее:

 
 Содержимое файла логов службы

Инициализация настроек выполнена успешна и начата процедура экспорта данных. Все ОК.

Но могут быть ситуации, когда сначала нужно будет настроить права доступа к каталогу с данными журнала регистрации, настроить доступ к базе данных, фаерволы, другие настройки безопасности, установить .NET Core 3.1 и так далее. Но это уже другая история, да и на что нам нужны еще сисадмины :).

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

На стороне Linux

Но как создать службу, или демона, в Linux? Рассмотрим пример на дистрибутиве Ubuntu 20.04 с уже установленным .NET Core 3.1. Опять же, распаковываем соответствующую сборку в каталог. Например, вот в такой:

/home/<YourUserName>/Apps/EventLogExportDaemon

Далее уже в который раз создаем файл конфигурации экспорта. Пусть в этот раз экспорт будет выполняться в базу PostgreSQL, не зря же мы в Linux пришли.

A279;{
  "StorageType": "PostgreSQL",
  "ConnectionStrings": {
    "EventLogDatabase": "Host=<СерверБазДанных>;Port=5432;Database=<ИмяБазыДляВыгрузки>;Username=<ИмяПользователя>;Password=<Пароль>"
  },
  "InformationSystem": {
    "Name": "EventLogFromLinux",
    "Description": "Тестовая выгрузка из Linux с помощью демона."
  },
  "EventLog": {
    "SourcePath": "/home/usr1cv8/.1cv8/1C/1cv8/reg_1541/231724bb-bb58-402d-ac21-9b61e7be1ae9/1Cv8Log/1Cv8.lgf",
    "UseWatchMode": true,
    "DelayMs": 30000,
    "Portion": 1
  }
}

Пусть Вас не смущает настройка выгрузки 1 события раз в 30 секунд. Это просто для теста. Файл конфигурации сохраним в тот же каталог, где находиться приложение.

Далее проверим запуск. Выполним команду (из-под sudo для упрощения примера, иначе пришлось бы настраивать права и др.):

sudo dotnet /home/<YourUserName>/Apps/EventLogExportDaemon/YY.EventLogManager.Daemon.dll

--config /home/<YourUserName>/Apps/EventLogExportDaemon/appsettings.json

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

 
 Пример логов службы в Linux

Как мы видим, ручной запуск показал, что файл конфигурации корректен и приложение работает. Пойдем дальше и зарегистрируем приложение в качестве демона в системе. Вместо того, чтобы описать каждый шаг этой процедуры я предложу отличную статью по этому поводу: "How to install a .NET Core service on linux server". В разделе "Create a systemd service" описаны пару простых шагов для регистрации демона в системе и управления им. Все просто и, думаю, Вас ничего не удивит, раз уж Вы дочитали до этой строки и зашли так далеко :).

Немного про диагностику ошибок

Экспорт журнала регистрации во внешнее хранилище требует сопровождения и это нормально. Не важно как эта выгрузка реализовано, даже если средствами платформы 1С, все равно нужен будет контроль работы.

Для всех предложенных решений реализовано ведение логов. Для консольного и GUI-приложения создается каталог "Logs" в текущем рабочем каталоге. Там сохраняется вся необходимая информация о происходящем и именно она может помочь в поиске причин ошибок или нерабочей конфигурации экспорта. Для служб (Windows и Linux) каталог с логами находится рядом с файлом конфигурации экспорта, который передается в качестве параметра запуска.

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

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

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

Немного 1С

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

 
 Работа с журналом регистрации в отчете на СКД
 
 Работа с журналом регистрации запросами 1С

Узнаете консоль запросов? Это одно из лучших решений в своем роде и не устану его рекламировать.

Управляемая консоль запросов, отчетов 3.8.8 (расширение, внешняя обработка)

Автору консоли еще раз огромное спасибо за работу!

P.S. На анимации Вы можете видеть, как с помощью стандартного 1С'ного запроса можно получить идентификатор объекта метаданных. Круто, не правда ли? :)

 
 Внешний источник данных журнала регистрации

Отчет и внешний источник данных приложены к публикации в виде файла конфигурации. Это не готовое решение на все времена, но оно может решить большинство простых задач по работе с журналом регистрации, выгруженном во внешнюю базу данных. Подходит как для SQL Server, так и для PostgreSQL. Главное корректно настроить строку подключения.

При желании Вы можете часть функционала вывести во внешние отчеты или вообще в расширение.

Это еще не конец

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

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

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

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

  • Библиотека для получения диагностической информации работы платформы 1С
  • Чтение и экспорт технологического журнала
  • Анализатор и диагностика реструктуризации информационной базы
  • Некоторые решения за рамками желтой платформы :)
  • И многое другое.

Как быстро это будет происходить зависит от Вас.

P.S. Подписывайтесь на канал, ставьте лайки Linux, оставляйте комментарии issues и пишите на почту или в личку.

 
 История изменений

26.05.2020 - Добавлены исходные коды всех приложений и изменена цена для загрузки.

25.05.2020 - Выпущена основная публикация

Другие ссылки

Авторские разработки

 
 Другие разработки

 

Скачать файлы

Наименование Файл Версия Размер
Исходный код всех приложений. Проект Visual Studio 2019

.zip 121,25Kb
26.05.20
0
.zip 1.0.0.0 121,25Kb
Консольное приложение для экспорта журнала регистрации (Windows, Linux)

.zip 21,22Mb
26.05.20
0
.zip 1.0.0.0 21,22Mb
Графическое приложения для экспорта журнала регистрации (только для Windows)

.zip 20,46Mb
26.05.20
1
.zip 1.0.0.0 20,46Mb 1
Служба Windows для экспорта журнала регистрации (только Windows)

.zip 21,60Mb
26.05.20
2
.zip 1.0.0.0 21,60Mb 2
Демон (служба) для Linux (systemd) (только Linux)

.zip 21,56Mb
25.05.20
0
.zip 1.0.0.0 21,56Mb
Внешний источник данных журнала регистрации + отчет

.cf 105,51Kb
26.05.20
2
.cf 1.0.0.0 105,51Kb 2

Специальные предложения

Автор запретил комментарии

См. также

Как сломать работу 1С, будучи пользователем

Пользователю системы v8 Бесплатно (free)

Шуточные и не только истории, как сломать работу 1С на пустом месте. И, возможно, остановить работу компании.

14.06.2020    5096    0    YPermitin    50