Журнал регистрации 1С разросся и тормозит: полумеры, которые помогут, и решение, которое работает

Знакомая картина: папка 1Cv8Log занимает сотни гигабайт, журнал регистрации из конфигуратора открывается минутами, любой отбор по пользователю превращает ожидание в лотерею, а когда инцидент наконец случился - выясняется, что история за нужную дату уже затёрта. Журнал вроде бы есть, “вроде бы ведётся” - но в момент, когда он нужен, пользоваться им нельзя.

Сразу разведём термины: речь о журнале регистрации - файлах платформы с историей действий пользователей. Если у вас растёт журнал транзакций SQL Server (файл .ldf) - это другая болезнь, её разбор в отдельной статье.

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

Почему штатный журнал умирает на нагрузке

Журнал регистрации хранится в файлах .lgp (+ словарь .lgf) в каталоге 1Cv8Log каждой рабочей базы. Формат последовательный: платформа дописывает события в конец файла. Для чтения с отбором это худший из вариантов - чтобы найти “все ошибки за вчера”, просмотрщику нужно пройти файл насквозь. Пока журнал весит мегабайты, это незаметно. Дальше арифметика беспощадна:

• Средняя торговая база на пару сотен активных пользователей и развитыми регламентными заданиями легко пишет десятки миллионов событий в сутки (у нагруженных - за сотню миллионов: на одном нашем внедрении - 150-194 млн в день, и это не предел).
• Каждое событие - сотни байт. Десятки миллионов событий = гигабайты прироста в день на дисках боевого сервера.
• Просмотр “за последнюю неделю” на таком объёме - это чтение десятков гигабайт последовательного формата. Отсюда зависания, таймауты и знаменитое “журнал не открывается вообще”.

Важно понимать: это не баг и не “кривая настройка”. Формат ЖР спроектирован для дешёвой записи, а не для аналитики. На малых объёмах компромисс невидим, на больших - фатален.

Штатные полумеры: что дают и где предел

1. Сокращение журнала регистрации

Штатная операция (Администрирование → Сокращение журнала регистрации) удаляет события старше даты, при желании - с выгрузкой в архивный файл. Плюс: место освобождается, просмотр ускоряется. Минусы принципиальные: история исчезает (архивный .elf-файл для расследований малопригоден - его нужно загружать обратно), а на больших журналах сама операция сокращения идёт часами и грузит сервер. Это гигиена, а не решение: вы просто регулярно отрезаете себе память.

2. Периодичность разделения файлов

Платформа умеет резать журнал на файлы по периодам (день/неделя/месяц). Обязательная настройка для нагруженной базы: маленькие файлы быстрее читаются за “свой” период и проще обслуживаются. Но глобально это ничего не меняет - суммарный объём тот же, поиск по длинному периоду всё так же читает всё.

3. Отбор регистрируемых событий

Можно отключить регистрацию части событий (например, “Примечания”) или снизить детальность. Работает, пока вы режете действительно лишнее. Дальше начинается торговля с самим собой: каждое отключённое событие - дыра в будущем расследовании. Классический сценарий: отключили регистрацию чтения данных ради места - через полгода безопасность спрашивает, кто открывал документ с зарплатами, а ответа нет. Урезать аудит ради производительности - почти всегда ошибка, которая проявится в самый дорогой момент.

4. “Перевести в SQLite” (старый формат .lgd)

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

Итого: штатными средствами можно отсрочить проблему - настроить периодичность, аккуратно выбрать события, регулярно сокращать. Но фундаментальный конфликт “формат для записи против запросов на чтение” никуда не денется. Если журнал нужен вам как рабочий инструмент - читать, искать, анализировать - данные надо уносить туда, где чтение стоит дёшево.

Решение: журнал уезжает во внешнее хранилище

Идея проста: боевой сервер продолжает писать журнал как писал, а рядом работает служба-экспортёр, которая в реальном времени читает файлы ЖР “хвостом” (как tail -f) и отправляет события во внешнюю аналитическую СУБД. Штатные файлы после подтверждённой выгрузки автоматически удаляются - диски боевого сервера перестают расти.

Вариантов хранилища несколько (Elasticsearch, PostgreSQL, ClickHouse); для логовых нагрузок лучше всего подходит ClickHouse - колоночная СУБД, созданная ровно под такой профиль: массовая вставка, редкие точечные обновления, быстрые агрегаты. Экспортёры под неё есть открытые (мы используем OneSTools.EventLog - без лицензионных затрат).

Что это даёт на практике - цифры с нашего внедрения, где конвейер работает в промышленной эксплуатации больше двух лет:

	Штатный ЖР	ЖР в ClickHouse
Поиск ошибок за сутки	минуты, часто зависает	0,11 секунды
Глубина истории онлайн	дни-недели	7+ месяцев
Место	~3 ТБ на боевых серверах	440 ГБ на отдельном (сжатие 6,7-9,2×)
Аналитика по всей истории	невозможна	~1 минута на 30 млрд строк
Задержка появления события	-	секунды

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

И самый недооценённый эффект - поведенческий. Когда ошибки перестают тонуть в нечитаемых файлах и начинают считаться и трендиться, их начинают чинить: на том же внедрении число ошибок в проде за полгода снизилось в 23 раза. Полная история этого проекта с архитектурой и всеми цифрами - в кейсе “Журнал регистрации в ClickHouse: 35 млрд событий”.

Частые вопросы

Можно ли просто отключить журнал регистрации?

Технически - да, практически - не надо. Журнал - единственный источник ответов на “кто изменил”, “почему упало”, “что происходило перед сбоем”. Его отсутствие всплывает в худший момент: при инциденте, споре с контрагентом или проверке безопасности. Правильный вопрос не “как отключить”, а “как сделать, чтобы он не мешал и работал”.

Сокращение журнала регистрации - это безопасно?

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

Файлы .lgp можно просто удалить руками?

Файлы закрытых периодов (при настроенной периодичности) - можно, платформа переживёт: вы потеряете только историю этих периодов. Текущий файл трогать нельзя. Но “удалить руками” - это то же сокращение, только без контроля; если приходится делать это регулярно - у вас как раз тот случай, когда журнал пора уносить из файлов.

У нас не миллионы событий в сутки. Нам это нужно?

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

Насколько это дорого?

Стек полностью открытый: ClickHouse + открытый экспортёр + обработки 1С, лицензионных платежей ноль. Из железа - один сервер (можно виртуальный) под хранилище: за счёт сжатия в 7-9 раз ему нужно на порядок меньше диска, чем занимали бы сырые журналы. Основные трудозатраты - первичная настройка конвейера, мониторинга его живости и интерфейсной обработки. Эту часть мы закрываем услугой журнал регистрации 1С в ClickHouse - стек остаётся у вас со всей документацией, без абонентской привязки к нам.

Итог

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

Технический разбор нашего конвейера - со схемой хранения, форматом таблиц и цифрами с боевого сервера - опубликован на Инфостарте: “Журнал регистрации 1С на 35 миллиардов событий: как заставить его открываться за 0,11 секунды”.

Мы разворачиваем такой конвейер под ключ: услуга журнал регистрации 1С в ClickHouse - от экспортёра и хранилища до Telegram-алертов и привычной формы журнала для пользователей. Если нужны ещё и метрики серверов с СУБД, это соседняя услуга мониторинга 1С. Оценить своё положение можно с бесплатного экспресс-аудита: посмотрим на объёмы вашего журнала и честно скажем, хватит ли вам штатной гигиены или пора выносить.

Когда нужен разовый ответ по журналу

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