В больших БД журнал регистрации занимает гигайбайты, может содержать повреждения журнала, и вообще выбрать из такого текстового файлика порцию нужных данных задача для платформы настолько тяжелая, что порой даже не решаемая. Конфигурация Event Log Manager выгружает из системных журналов регистрации данные в свою базу и избавляет от подобных проблем.
Функционал продукта
* Импорт реализован без XML файлов
в асинхронном режиме через фоновые задания. Com подключение к базе-источнику и перекачка через ОЗУ, без лишних преобразований, парсингов, записей\чтения и пр. Возможен одновременный импорт из нескольких баз.
* Регламентные задания
периодически подгружают свежие данные стандартных журналов регистрации в общую базу.
* Фильтры событий
При импорте доступны различные фильтры выгружаемых и загружаемых записей, пропуск ошибок журнала регистрации. Позволяет в десятки раз сократить время и объем обработки логов. Подробнее...
* Выбор объектов по OLE
Позволяет отбирать события ЖР выбором объекта из базы-источника. Т.е. через OLE Automation открывается база, выбираете ссылку на документ или справочник, получаете все события в Logs_manager. Или в обратную сторону — выбираете событие в LM и можете открыть сам объект из базы-источника. Подробнее...
* Разделения прав доступа
Релизован RLS для событий. Т.е. можно предоставить доступ к событиям ЖР только по пользователям своего филиала. Можно раздать айтишникам удаленных подразделений через тонкий клиент доступ к ЖР своего филиала. И они смогут сами отслеживать малоработающих сотрудников или искать ответы на вопросы "кто изменил документ" Подробнее...
* Журнал регистрации не пропадает
В случае переустановки сервера 1С (после сбоя или администрирования) журнал регистрации не пропадает. Исходные журналы регистрации можно настроить на автоматическое ежемесячное усечение и каталог сервера 1С перестанет пухнуть в десятки гигабайт
* Отчеты
Например, отчет статистики событий по объектам метаданных и пользователям поможет понять что происходит в ваших БД. Все отчеты на СКД.
* Отправка уведомлений по фильтрам событий.
Например, позволяет отправлять программисту на почту ошибки времени выполнения, отслеживать проблемы до обращения пользователей.
Условия для лицензионных пользователей
- - открытый код, конфигурация на поддержке поставщика с возможностью внесения собственных изменений
- - персональная поддержка, консультации по внедрению
- - встроенная система проверки и получения обновлений
- - первый год после покупки подписка на обновление и сопровождение конфигурации бесплатно
- - техническая поддержка бесплатна в течение года
- - гарантия возврата денег без указания причин.
Изменения версий
Версия 4.3.2 от 21.02.2018
Версия 4.2.2 от 28.08.2016
Версия 3.02 от 01.03.2013
Версия 3.0.1 от 27.02.2013
Группа публикации - инструкции, обсуждения
log_manager.adaptersoft.ru - отдельный сайт проекта
Демоверсия
Вы можете скачать cf файл бесплатно. Для ознакомления лучше развернуть в файловой варианте. В файловом варианте не будут выполняться регламентные задания по расписанию. Используйте кнопку в карточке ИБ \ ручная загрузка \ Загрузить журнал, или в консоле регламентных заданий кнопку "Выполнить задание". В файловом варианте удобней использовать\регистрировать com-коннекторы платформа 8.2\8.3 (в серверном варианте возможно потребуется перезагрузка сервера 1С). Подробнее о работе файловой демоверсии смотрите во встроенном справочнике функций.
Ограничения: демоверсия поставляется с закрытым программным кодом. Загружать можно не более 50 тыс. событий
Причины купить
Не требует встраивания в рабочие базы данных.
Все журналы разных ИБ-источников, настройки, фильтры, уведомления, история импорта - все в одной месте.
Разделямый доступ филиалов к событиям журналов по подразделениям.
Пропуск ошибок "журнал регистрации поврежден". Позволяет выбрать даже если есть события "Повреждения журнала" и 1С завершает работу с ошибкой.
Повышенная производительность и улучшенный функционал!
Достоинства
Принципиальные отличия продукта от других. Чтобы не потеряться во всем этом многообразии.. есть несколько подходов:
Версионирование.
Встраивание в рабочие базы, по подпискам на события добавления, изменения, проведения делаются записи в регистр сведений. Потом можно сравнить версии, например раньше в накладной было количество 10, а теперь 20. Это дает дополнительный функционал, которого нет в стандартном ЖР, но за это надо платить производительностью, размерами базы, снятием с поддержки и т.д.
В таком варианте рабочую базу данных ждет увеличение объема. Это приводит к снижению производительности базы, ведь кроме записи информации о самой приходной накладной система будет записывать еще и информацию о событиях. Увеличение объема также негативно повлияет на организацию резервного копирования. Для рабочей БД, как правило, хранится несколько рабочих копий, т.е. «лишний» объем будет умножаться. Встраивание подсистем в рабочую БД может вызывать дополнительные сложности при последующих обновлениях, хотя бы за счет увеличения времени реструктуризации более больших баз данных.
Подсистема версионирования уже есть в большинстве современных типовых конфигураций. Но по умолчанию выключена, надо расставить галочки по интересующим объектам метаданных. В самописную можно добавить из БСП. Также в ближайших релизах платформы вендор обещает добавить уже такой встроенный механизм.
Вынос за рамки 1С.
Хранение событий ЖР в отдельности от 1С - в специализированных базах, файловых, внешних sql, встроенный формат sql-Lite в свежих платформах, различные выгрузки и пр. Все это облегчает жизнь серверу, позволяет ускорить выборку событий, но отвязывает от документов и справочников в режиме предприятия. Т.е. в стандартном режиме ЖР вы можете открыть накладную №15 и выбрать по ней все события - кто когда ввел, менял и пр. А тут нет, вам придется морочится с идентификаторами или представлниями объектов. Из прикладного инструмента задача превращается в "спортивное программирование" - надо освоить какие то внешние для 1С методики, настроить обмен, перегрузить данные, затем выбирать идентификаторы вручную и фильтровать по ним внешнюю базу. В общем то не самый плохой подход и расширяет горизонты.
Дублирование справочников объектов рабочей ИБ. Такой подход встречается в бесплатных аналогах LM. В системе хранения журналов заводятся справочники, которые повторяют пользовательские данные из рабочей ИБ. Т.е. если в бухгалтерской базе создано 1000 приходных накладных, то в справочнике объектов будет также создано 1000 записей от «Приходная накладная №1″ до «Приходная накладная №1000″. Конечно одна запись при этом не занимает столько же места, как весь документ «Приходная накладная» с табличными частями и проводками, но размер базы хранения журналов все равно будет существенно увеличен. Кроме того при загрузке ЖР наблюдается значительное снижение производительности за счет поиска ссылок и создания новых объектов. Также производительность снижается еще на порядок при использовании промежуточных файлов для перегрузки, xml и им подобных.
LogManager решает проблему за счет интеграции через COM и OLE
В рабочую БД ничего не встраивается, а в LM не хранится лишних данных. При необходимости фильтрации по объекту открывается рабочая БД через OLE подключение и Приходная накладная № 5 выбирается там. Механизм работает и в обратную сторону — выбрав событие в LogManager можно открыть в рабочей ИБ объект к которому оно относится.
Загрузка данных ЖР осуществляется через com штатными средствами 1С, т.е. напрямую в оперативной памяти и без лишних преобразований. Есть настройки порционности итераций обмена, чтобы случайно не занять все ресурсы сервера или ОЗУ.
