Есть у меня несколько механизмов, которые делают магию - создают несколько или много объектов (чаще всего это документы) по каким-то алгоритмам. Часть обработок запускаются пользователями по кнопке "Сделать всё", часть - по расписанию, или другим способом - не суть.

Необходимо иметь способ узнать:
- Когда и с какими параметрами запускалась обработка;
- Какие-то ключевые расчётные параметры, которые получались по ходу работы алгоритма;
- Самое главное - что в результате было сделано.

Сейчас что-то пишется в ЖР, но его средств для этого недостаточно, да и анализ - так себе развлечение.
Использование внешних средств, типа "выгрузи всё в эластик", в голове держатся, но пока не рассматриваются.

Интересно послушать ваши предложения.

Напрашивается РС

(1) Да

(1) +1
Но надо знать подробности. Или примеры.
Описание задачи в (0) слишком расплывчатое.

(0) Что такое журнал регистрации?

Ключевой вопрос - в каком виде все эти данные нужны.
Может вообще достаточно будет формировать протокол выполнения обработки (текстовый, xml, mxl, xls,...) и сохранение файла с этим протоколом в справочнике или регистре "Файлы".

архитектурно тут всего 2 решения:
1. городить РС внутри 1с.
2. пулять данные наружу (Elasticsearch, Logstash, Kibana, микросервисы на GO, файлик)

как-то юзал подсисьтемы доп.журнала. точно не помню которую из них

https://infostart.ru/public/16379/


или такую?

https://softonit.ru/catalog/products/journal/

в целом неплохо работало... давно это было, когда версионирование в платформу еще не завезли :)

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

(8) В данной задаче - писать лог, относящий к конкретному документу закрытия месяца.

Допилить версионирование
Добавить свои "признаки"-реквизиты в РС ВерсииОбъектов кроме АвторВерсии, ДатаВерсии, Комментарий
Ну там интерактивно или обработкой, какой механизм и т.д.

+(9) Или сейчас в типовых это уже не документ? Тогда "лог, относящийся к конкретному запуску" процедуры закрытия, т.е. да - к запуску обработки. И он получается весьма специфический.

Если человек хочет логировать также и то, что запускалось, но не было зафиксировано транзакцией по каким-то причинам, то хранить в ЭТОЙ БД не вариант. Можно и в стандартный журнал писать всякие JSON-объекты структурированные

(9) закрытие месяца не всегда документ, например

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

Можно завести регистр сведений с измерениями Дата, GUID
не периодический

Ресурсы:
Субъект, Действие, Параметры, Объект, Результат, Отчет

В "Отчет" сохранять текстовый или табличный документ. Лучше табличный, чтобы работали расшифровки.

(15) РС (и любой другой объект) плох тем, что его из под транзакции не вытащить. Ну, точнее, можно, конечно, собирать всё в памяти, а после всего записывать, но это тоже такое...

(16) эээ отдельное фоновое же

(16) Ну и чем это плохо? Если всё работает штатно - то пишешь всё в транзакции. Если же транзакция отменилась - то, имхо, достаточно фиксировать ошибку и причины ошибки - а это можно и всне транзакции. Объекты же всё равно не созданы.

(18) В курсе что типовые механизмы используют транзакции и последующий плановый откат для расчета разного?

(19) И какое это имеет отношение к записи журнала? Или ты предполагаешь, что ТС будет втыкать записи беспорядочно и наобум и случайно может попасть внутрь транзакции, которую типовой механизм откатывает?

(18) Для анализа ошибок первые два пункта хотелок очень нужны

(21) Два пункта из (0)? Да это не противоречит.  Запуск обычно пишут ещё ДО транзакции.
А ключевые расчетные параметры - непонятно, что ты имеешь ввиду. Если это обычные типа количество обработанных, количество созданных, скорость обработки и т.п. - то нет проблем считать их в переменных и записывать после транзакции.

(16) Другой вариант:
микросервис "Лог", куда отправлять данные через корп.шину. Он кладёт события в базу. Затем анализировать базу. Всё по-взрослому. Это вам не какие-то файлы в специальной папке...

Новомодная "Шина"? Или любой брокер. Можно в другую систему, а можно в этой же получать и пихать в РС (или распихивать по разным РС, в зависимости от вида события)

(23) Файловая система - самая популярная корп шина.

(24) Это уж как корпорация решит. Rabbit MQ кажется более надёжным

(23) (24) да, но...
"но" расшифровывается как "скорость и консистентность". во-первых, оно не должно замедлять основной алгоритм. во-вторых, этого внешнего сервиса должна быть не меньше надежности основной системы, иначе нафига?

(27) >не должно замедлять основной алгоритм
это фантастика
любые доп. действия включая логи и отладочная информация обязательно замедлят
и увеличат объем базы

(27) Отправка сообщения занимает секунду времени. Сообщение гарантированно не потеряется. Надёжность обеспечивается простотой. Надо просто положить сообщение в базу без парсинга. А потом прикрутишь BI-отчёты. Под них понадобится новый сервер, разумеется. Придётся нанять ещё аналитика бигдата...

Вот так 1С-ники умеют раздувать из мухи слона. :)

может просто хранить разностные бэкапы средствами скуля?

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

чтобы если что взять до и повторить закрытие с отладчиком?

(30) и потом бекапы между собой сравнивать? ну, такое
закрытие месяца я только как понятный пример привел.

(31) почему бы и не сравнивать уже развернутые средствами 1С?
чтобы понять что изменилось

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

(29) секунда - это очень много!

(32) потому что у меня таких обработок - десятки. потому что пользователю не объяснить, что перед каждым его нажатием "Сделать всё" мы будем бекап снимать. А если он потом сам захочет посмотреть что сделалось, восстанавливать бекап и сравнивать?

По типу формирования резервные копии бывают трёх видов:
Full (Полная)
Differential (Дифференциальная, разностная)
Log (Резервная копия журналов транзакций, учитывая, то, насколько часто этот термин используется, будем сокращать до РКЖТ)

Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени (на тот в который начато формирование резервной копии). Состоит из постраничной копии используемой части файлов данных и активного куска журнала транзакций за то время пока формировалась резервная копия.

Разностная резервная копия
Хранит страницы данных, изменившиеся с момента последней полной резервной копии. При восстановлении нужно сначала восстановить полную резервную копию (в режиме NORECOVERY, примеры будут приведены ниже), потом можно к получившейся "заготовке" применить любую из последующих разностных копий, но, конечно только из тех, которые сделаны до следующей полной резервной копии. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии.

Суть что утром делаем Full, а затем перед каждой логируемой операцией Differential

(34) >А если он потом сам захочет посмотреть что сделалось

А это уже совсем другая задач с другими сроками ))

(35) разностная копия у нас делается раз в пять минут на основных базах

(27) Ну, скорость в любом случае замедлится, даже при записи "внутрипроцесса". а отправка в брокер возможна асинхронно..

(35) Не понял, ты асмодея беэкапам учишь, чтоль? :-)

(37) Это ж как сервер  напрягается каждые 5 минут спустя сутки после фулл бэкапа?

(35) а если логируемых операций несколько, и выполняются они параллельно несколкими пользователями/роботами?

Комментарий обычной рядовой записи обмена данными в журнале:

Пример

[22.03.2023 10:05:01] [SlaveUser] Начат автоматический обмен данными по настройке "Загрузка данных из *** (Полный)" (10:05:01).
[22.03.2023 10:05:01] [SlaveUser] Копирование файла из  \\***\Obmen 1C\UPPCRM\Message_02_01.zip в
                      C:\Users\USR1CV8\AppData\Local\Temp\Полный\Загрузка данных из *** (Полный)\Message_02_01.zip
[22.03.2023 10:05:02] [SlaveUser] Начало распаковки файла обмена данными C:\Users\USR1CV8\AppData\Local\Temp\Полный\Загрузка
                      данных из *** (Полный)\Message_02_01.zip
[22.03.2023 10:05:02] [SlaveUser] Окончание распаковки файла обмена данными C:\Users\USR1CV8\AppData\Local\Temp\Полный\Загрузка
                      данных из *** (Полный)\Message_02_01.zip.
                      Распакованные данные помещены в файл C:\Users\USR1CV8\AppData\Local\Temp\v8_7E51_1eb.xml
[22.03.2023 10:05:02] [SlaveUser] Начало чтения изменений из файла обмена C:\Users\USR1CV8\AppData\Local\Temp\v8_7E51_1eb.xml
[22.03.2023 10:05:13] [SlaveUser] Окончание чтения изменений из файла обмена C:\Users\USR1CV8\AppData\Local\Temp\v8_7E51_1eb.xml
[22.03.2023 10:05:13] [SlaveUser] Чтение данных из файла обмена успешно завершено.
[22.03.2023 10:05:14] [SlaveUser] Удаление файла: \\***\Obmen 1C\UPPCRM\Message_02_01.zip
[22.03.2023 10:05:14] [SlaveUser] Обмен данными по настройке "Загрузка данных из *** (Полный)" завершен (10:05:14).

.... эээ... так много информации сразу, что я забыл чего автору нужно, не напомните?

(42) Потом анализировать по ЖР так себе удовольствие.

(42)
SlaveUser - звучит как часть приключений DM.

(39) самый лучший лог это история изменений в привязке к событиям
вот и предлагаю просто привязать свои механизмы-алгоритмы к бэкапам
чтобы потом можно было удобно анализировать, какой механизм что поменял и даже воспроизвести-прогнать снова на тех же данных

(43) Согласен. Не самый лучший вариант для просмотра и анализа. Но, имхо, самый надёжный из того, что предлагает 1С.

Может быть, придумать свой текстовый формат лога, удобный для парсинга; писать по прежнему в ЖР с отдельным событием и полным текстом в комментарии
а потом регламентным заданием (например - раз в 10 минут) считывать записи за период, разбирать и писать в свой регистр сведений?

(0) мой вариант:

1. платформенная (не программная) реализация версионирования объектов - это ответ на вопросы "что/когда/кем поменялось", плюс возможность откатится назад
2. дополнительный регистр для хранения промежуточных данных (привязываем к документам) - это ответ "почему так вышло"

(48) а если документ не сформировался - почему так вышло?

(49) на это должен отвечать журнал регистрации (по тому как это скорее всего ошибка)

(25) " Файловая система - самая популярная корп шина." - тоже брокерами вообще никак не проникся, куда тока не пытался их натянуть - в папку проще быстрей очевидней ненагруженей.

(50) очень неплохо смотреть всю необходимую информацию для анализа "в одном окне"

(52) для этого нужны специальные отчеты

(51) брокер облегчает ситуации, когда "открывают недописаный файл", или два сеанса пытаются писать файл с одним именем, или перезаписывают файл, или что-то очищает файлы...
(53) а специально подготовленные данные сильно облегчат и ускорят эти специальные отчеты

(54) Логирование всегда оптимизируется на скорость записи а не на скорость чтения

(48) >платформенная (не программная) реализация версионирования объектов

это как?

(56)+ добавить некий общий разделитель = версия объекта?
и при любой записи копию сохранять с разделителем, в отдельный РС ссылку на копию и что ее сделало с доп данными?

(56) это именно платформенная реализация, без всяких подписок, регистров и т.д. то есть 1с сделала замечательный механизм и сама им не пользуется а изобретает всякие велосипеды.

(57) версия обьекта - там есть, так-же как и сравнение произвольных версий и возможность перейти на любую (в рамках совместимости метаданных) предыдущую версию

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

(54) понятно что это учитывается.
Логи это техническая помойка, писать их в учетное систему где они нужны только прогеру - такое себе решение.

(58) ты про "История данных", которые в любой типовой конфе "Не использовать"?
и вместо этого юзается версионирование из БСП на основе РС ВерсииОбъектов

(58) а как это История данных умеет с расширениями?

(60) да, про это...
(61) не проверял, но думаю нормально работает, я расширения почти не использую

И кто эти логи смотреть будет? Одмин/1Сник? И потом в базе править?
Писал как-то такое логгирование для хитрого алгоритма для бухии, чуть ли не пошагово логгировал какие слагаемые, что куда что считается, какой результат с чем сравнивается.
В п...у! для ТП это нихрена не помощь. ОЙ, неверно посчиталось, ну, ...я! открой протокол - и посмотри как считалось. здесь 2, здесь 3 , сумма = 5, а не 5.5 как ты хочешь.
Впустую все.
Оператор он и есть оператор.
Писать для себя? - тогда уже банковски е билеты рисовать... для себя...

(63) В разных случаях по разному.
Нажал кнопу "Сделать всё" - хочу посмотреть что ж я наделал.
Закинул обработку в планировщик на ночь - утром глянуть как оно там.
Регламентное нафигачило всякого - узнать а чёй-то оно

(58) Когда то делали типа такого тупо куча файлов в папке работало мгновенно. Всегда было видно кто что когда  чего изменил, но фишкой было что можно ловить тех кто менял документы которые "нельзя менять" (склад). Тут такого не увидел.

(64) имхо сериализуешь свои объекты при записи в json
добавляешь еще чего надо
и пуляешь в брокер, который будет складывать в mongo/postgre или еще куда для анализа

(66) было в (23)

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

(68) По регистру в (15) я предложил Дата и GUID.
По дате можно будет отбирать достаточно быстро.
GUID генерируется одной строчкой.

(68) из регистра не глядя данные достанешь, жр устанешь анализировать, хотя последнее время вроде летает.

(70) Подтверждаю. Можно начать с регистра, потом прикрутить микросервисы, развернуть новые сервера и нанять новых аналитиков бигдата.

(71) "Необходимо иметь способ узнать:
- Когда и с какими параметрами запускалась обработка;
- Какие-то ключевые расчётные параметры, которые получались по ходу работы алгоритма;
- Самое главное - что в результате было сделано."

Как всегда хочется видеть конртектс задачи - что люди такого творят что им вдруг надо это смотреть на постоянной основе.
"несколько механизмов, которые делают магию" - Человек написал непредсказуемый алгоритм, теперь хочет понять как сильно он обогнал гпт ))))

(0) Предложения нет, есть общее соображение. Если механизм начинает выходить из-под контроля, то есть требовать постоянного анализа своей работы, то надо его налаживать либо менять. Для регистрации редких ошибок и отладки (редкой же) неструктурированных данных типа ЖР должно быть достаточно.

(73) Любая система со временем начинает выходить из-под контроля. И здесь проявляется суть программистов, аналитиков, руководителей проекта: смогут ли они совладать с этой сложностью.

Кстати, небольшое отступление: самая сложная система во Вселенной — это тело человека. Биологи, врачи пока не могут даже понять ЭТО.

Регистр сведений - это все та же таблица в СУБД, которая является строчным хранилищем. Когда это дело начнет вставать колом из-за генерации индексов при записи и проблемы "большого хвоста", придется переходить на что-то колоночное, которое будет крутиться вне 1С и будет парсить журнал раз в какое-то количество времени. Запись будет реже и типа bulk insert, но поиск по колоночкам у вас будет работать быстро. Ведь это именно то, ради чего все затевается - поиск по колонкам.

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

(76) Тогда уж документ. У него хотя бы дата есть

(0) как человек, пользующийся этой штукой уже год, могу сказать - это супер вещь. посмотрите видео Овсянкина - https://www.youtube.com/watch?v=HnZ0Of-YpW0&t=1s

(76) ClickHouse — это колоночная аналитическая СУБД с открытым кодом...

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