[DECLAIMER]
- Я в курсе решения от SilverBullet и @lustin. Но момент когда оно было в свободном доступе я упустил, а денег на покупку чего-то, что не нужно бизнесу непосредственно сейчас никто не даст 🙁
- Уже сильно позже я прочитал статью @milut "Простейшее использование Elasticsearch для работы с журналом регистрации". И, сравнивая с объемом проделанной работы, я совсем не уверен, что надо было городить такого монстра. Хотя тут можно подогнать базу про "независимость от работы сервера 1С", "меньшую нагрузку на кластер" и "контролируемую загрузку журналов для большого количества баз из одного места"
- Зато если бы у меня была такая штука на прошлом месте работы (немецкая контора, которую аудировал deloitte & touche) — я бы точно представил ее аудиторам как "система хранения аудиторского следа независимая от разработчиков и администраторов 1С". Меня там очень гнобили за отсутствие "аудиторского следа".
Можно рассматривать данную статью как один из вариантов решения или пример хождения по граблям, которое лучше избегать 😉 Итак.
Для начала поставили EventLogLoader Aleksey.Bochkov, настроили загрузку журналов в MS SQL Server и последующую выгрузку в ELK и решили, что всё. Оказалось не всё. Программисты 1С посмотрели и заявили, что работать в этом не будут, т.к. записи журнала идут вперемешку, а они привыкли и готовы работать только со "стандартным журналом". Стало понятно, что загруженные данные надо трансформировать. Кроме тогоEventLogLoader временами подвисал и всё вставало, а чистку загруженных логов все равно надо делать руками
Решили улучшать — собрали группу из трех человек — я, как идеолог, @klimov_andrey как спец по ELK и программист C# и T-SQL Роман и погнали.
Роман переписал EventLogLoader на C# — стало работать без зависаний плюс добавилось удаление загруженных журналов (только для файловых журналов и параллельно я под это дело написал переключатель форматов журналов на Python).
После нескольких итераций, Роман успешно нарисовал трансформацию данных на T-SQL, которая брала данные из таблиц EventLogLoader и преобразовывала все это в формат, который уже был похож на привычный 1С журнал. При трансформации записи накапливались в буфере, чтобы потом собирать несколько штук в единую запись журнала. В процессе очень помогла статья "Формат файлов журнала регистрации 1С 8.1/8.2 — ELF/LOG/LGF/LGP"
Финальным аккордом загрузили все журналы для 35 баз с 2 серверов с января 2024 го года. Теперь оно все в ELK и доступно для поиска. В общем получилась вот такая красота:
Итого как это выглядит с технической точки зрения.
- Все журналы переключены в файловый режим
- Переписанный на C# EventLoader запускается в командной строке (сделать как сервис руки не дошли) и мониторит папку с журналами (для каждой базы стартует свой поток).
- Как только 1С сервер "отпускает" файл, EventLoader забирает его, обрабатывает и выгружает во временные таблицы SQL Server (структура таблиц как у оригинального EventLoader) и удаляет.
- На SQL Server крутится регламентное задание, которое мониторит временные таблицы и собирает записи в "человеческий" вид, ориентируясь на запись о начале (_$Transaction$_.Begin) и о том что транзакция закончилась — зафиксирована (_$Transaction$_.Commit) или отменена (_$Transaction$_.Rollback)
- "человеческие" записи перегружаются в таблицу event2
- В таблицу event2 за записями приходит logtash и забирает их в ELK
- На Kibana cделаy простенький dashboard,который все это красиво визуализирует.
В приложенном архиве:
Солюшен EventLogLoader, который включает всю разработку Aleksey.Bochkov. на VB.Net плюс проект EventLogApp на C#
database.sql — скрипт создания БД для MS SQL
Для работы трансформации надо создать Job urgent c следующим шагом:
declare @counter int
set @counter = 1
while @counter <= 5
begin
exec up_AddEvents2rowsDirect 100
set @counter = @counter + 1
end
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
(0) плюс!
Читать было очень интересно. Как будто еще раз свою задачу пережил 🙂
А на GitHub не публиковали проект для совместной с сообществом разработки?
Почему логстеш только забирает? Он же всю вашу трансформацию делает влёт и сразу складывает в эластик. Sql Server в этой цепочке вообще не нужен.
(1) С удовольствием если расскажете как это правильно делать. Особенно учитывая что EventLogLoader по чесноку взят у Aleksey.Bochkov и просто переписан на C# и немного допилен. Я честно не знаю как корректно опубликовать финальный проект, который содержит большую часть чужого кода.
(2) У нас не вышло корректно разобраться с флагами начала — окончания транзакций. Плюс были ситуации когда в логе запись об окончании транзакции шла раньше записи о ее начале. Реально SQL содержит буфер на миллион записей с использованием которого обрабатываются такие ситуации. Если есть подробности и код как с этим бороться используя чистый logtash, то делитесь :-). Мы на глубокое знание ELK не претендуем 🙂 Любители 🙂
Я тоже любитель. Но зная возможности логстеша, для него это рядовая задача. Работа с логами — основное для чего его используют во всем мире. Главное правильно настроить конвейеры приема и модификации. Ваше решение кажется слишком переусложненным.
(5) Осталось дождаться вашей статьи с описанием как это сделать. Тут будет много благодарных.
А мы используем вот это решение
и очень довольны
(7) Возьму на заметку. Навскидку я все-таки предпочел логгирование конкретных баз (у нас очень много всяких архивов) ну и наличие у нас автооосвобождение места на диске тоже радует 🙂
(3)
Сделать пулреквест Алексею Бочкову на гитхаб
(9) Тогда проект уедет к Алексею и будет зависеть от него и его свободного времени. А у него я смотрю Latest commit 2f830f1 on 16 Apr 2017
Лучше все-таки наверное честный fork.
(10) не уедет. Ваш форк так и останется у вас. А вливаться Алексею от вас или нет — пусть решит сам. Форк в любом случае можете развивать как угодно, ПР, на мой взгляд, это просто спасибка такая, респект автору.
И сколько раз твердили миру… Не надо ЖР в эластик грузить. Это дорого! Кто то «очень продвинутый» поигрался и понеслась….
(11) Т.е. я могу создать отдельную репу как fork (вопрос у меня как ее корректно оформить со ссылкой на оригинальную репу) и отдельно отправить ПР Алексею? Может какая статья для чайников есть как это правильно оформлять.
(12) Можно подробнее почему дорого?
(14) Размеры посчитайте. В нормальном хранилище логов их размер должен быть в 10 раз меньше чем основной ЖР как минимум. Правильнее в 100. Не создавать нагрузку на процессор и диски. Ну не для этого эластик. Не нужен вам полнотекст по логам. А если нужен полнотекст по логам — у вас проблема или в архитектуре или бизнес процессах.
(15) Ну не знаю. 2 сервера, 25 баз. В Elastic логов на 24 гига с июля 2018 года. Стандартно я чищу логи раз в пол-года вычищая по 50-60 гигов на сервере. К сожалению размер журналов 1С перед загрузкой я не посмотрел, но там явно сильно больше должно быть.
PS В «ёлку» будет пускать бизнес-юзеров. Они без полнотекстового поиска работать просто не умеют.
(16) в вашем миникейсе вообще штатного ЖР хватило бы. Эластик расжимает данные а не сжимает. Почитайте описания движка. Не будет меньше. Для пользователей надо делать интерфейс истории а не «пускать в ёлку» или ещё куда
(17) Хм… Вам конечно виднее, но давать права на журнал в 1С бизнесам (когда даже программеры ухитряются подвесить сервак) я не хочу. И следить за местом на дисках где живут журналы тоже. Ну и на тендерах, в которых мы участвуем, с нас всегда требуют наличие «централизованной системы сбора и управления логами».
(18) и вы им продаёте эластик? :))))))). Централизованная система сбора логов обычно о другом.
Ну для маленькой базы не нужен он. Если вы за год только 50гб набираете….
Бизнесу вообще ЖР давать это зло. Есть менеджер инфобеза которому оно нужно.
(19) Простите, а что им продать? 25 журналов 1С для 25 баз? comol, а давайте вместо тонкого троллинга вы мне будете предлагать имеющиеся готовые решение? И, ключевой момент, бесплатные. Я в целом на infostart и пишу, чтобы услышать альтернативные предложения.
(13) в гитхабе нажимаете у Алексея кнопку Fork и в вашем аккаунте создастся новая репа с копией оригинала и со ссылкой на оригинал. Делаете в ней что хотите, а часть изменений можете отправить назад в виде пулреквеста. Стандартная схема, посмотрите уроки работы с гитхабом в Сети. При этом ваша копия — только ваша и можете делать с ней что хотите.
(21) Рома . Бросьте, пожалуйста, взгляд. Если все нормально я еще в статью внесу.
(22) Ну да, так и делается форк, все ок.
есть отчет Журнал регистрации на СКД. И пользователям можно дать, и отборы есть,
и работает быстро
(20) На Инфостарте есть. ClickHouse или любая другая столбцовая СУБД. Перед вами не стоит задачи поисковых запросов, а вполне себе запросов аналитических. Это не троллинг, это я Вас пытался навести на решение к которому Вы можете прийти самостоятельно.
Троллинг только в том что «повторять за другими их ошибки это плохо» :).
(24) Для объемов выше вполне подойдёт
(25) т,е. мне надо поднять и изучить еще одну СУБД (кроме Эластика), сделать туда выгрузку (причем очевидно с тем же ETL — вряд ли оно из коробки умеет склеивать записи 1сного журнала), нарисовать интерфейс для работы (Kibana я знаю, Clickhousе нет и можно ли получить данные без отдельного интерфейса тоже не знаю) и это будет считаться не зря потраченным временем? И это все не уже даже толстый троллинг?
@lustin призывал использовать «ёлку», а так же пенял, что никто не хотел учить Go, чтобы сделать красивую выгрузку журнала 1С в ELK с использование filebeat. Это решение он теперь продаёт. @comol теперь учит меня, что ELK — это «плохо и ошибка». И куда крестьянину податься?
(27) Я не призываю переделывать конечно… в Вашем случае даже трудозатраты на Эластик уже наверное лишние.
Не умоляя достоинств всё-таки своя голова на плечах должна тоже быть.
Вы же в магазине не покупаете всё что вам продают…
А вот тут Флант (знаете же кто такие) «не продают» систему хранения логов в кликхаус.
А вот тут это делают вконтакте…
Но я не призываю «верить мне или кому бы то ни было». Выгрузите и туда и туда по пару десятков миллионов записей и проверьте объем и скорость.
ETL там будет один и тот же ClickHouse поддерживает вполне себе нормальный SQL (правда записи надо добавлять не им а порциями)
ClickHouse поддерживает Grafana т.е. не нужен вам Kibana. Да и для ELK я бы тоже графану использовал.
(28) Почитал. При моих «маленьких» объемах почему бы просто не оставить все в таблицах MS SQL?
(29) Всё верно. MS SQL просто будет пытаться там транзакции лепить где они не нужны… но вцелом если освоите BULK INSERT норм. решение
(30) Если вы все-таки прочитали мою статью не по диагонали, то там уже все есть. Только «ёлку» надо оторвать за «ненадобностью» (по вашему мнению). И интерфейс с поиском написать. Ну или всех дружно отправить в консоль SQL и запросами его, запросами.
В общем и целом не убедили от слова вообще.
(31) Сорри. По диагонали. Интерфейс с поиском я считаю надо писать для любой СУБД. И встраивать в 1С. А grafana прекрасно работает и с ms sql. Что вы к kibana приаезались. Оно убогое.