В работе с системами 1С администраторы и разработчики часто сталкиваются с вопросом управления журналом регистрации (ЖР). Особенно актуальны вопросы, связанные с его форматом, производительностью и влиянием на основные данные. Давайте подробно разберем, что представляет собой новый формат журнала регистрации, каковы его плюсы и минусы, и ответим на главный вопрос: стоит ли на него переходить?
Проанализируем ситуацию на основе следующих вопросов:
Изначально в платформе "1С:Предприятие" использовался текстовый формат журнала регистрации (файлы с расширением .lgp). С ростом объемов данных и количества событий анализ таких файлов становился все медленнее. Для решения этой проблемы был представлен новый формат, который использует для хранения логов встроенную базу данных SQLite (файлы с расширением .lgd).
Основная идея была в том, чтобы ускорить чтение и отбор событий из журнала. В отличие от последовательного чтения всего текстового файла, SQLite позволяет использовать индексацию, что теоретически должно было кардинально ускорить формирование отчетов по ЖР. Однако на практике этот подход породил ряд серьезных проблем.
Несмотря на ускорение чтения, новый формат продемонстрировал критические недостатки, из-за которых сообщество и сама фирма "1С" не рекомендуют его использовать. Рассмотрим их подробнее.
1. Падение производительности при записи.
Это главная претензия к формату на SQLite. Простая запись строки в текстовый файл — очень быстрая операция. Запись же в базу данных, даже такую легковесную, как SQLite, — более сложный и ресурсоемкий процесс. Он включает в себя обработку транзакций, обновление индексов и может вызывать блокировки. В обсуждении был верно подмечен ключевой недостаток: операция чтения журнала может блокировать запись в него. Для высоконагруженных систем, где события генерируются непрерывно, это приводит к "тормозам" при выполнении самых разных операций, так как многие серверные вызовы сопровождаются записью в ЖР.
2. Низкая надежность и риск повреждения файла.
Файлы баз данных по своей природе более уязвимы к повреждениям при сбоях, чем простые текстовые файлы. Многочисленные отзывы подтверждают, что файлы .lgd повреждаются значительно чаще. Повреждение файла журнала может привести не только к невозможности его прочитать, но и к полной остановке сервера 1С, который не сможет инициализировать работу с поврежденным логом.
3. Официальный отказ от развития.
В конечном итоге, столкнувшись с массой проблем, фирма "1С" признала формат неудачным. Начиная с платформы 8.3.5, для всех новых информационных баз по умолчанию снова стал использоваться старый, проверенный текстовый формат .lgp. Это является самым весомым аргументом против использования нового формата.
Да, чистить журнал регистрации можно и нужно. Этот процесс абсолютно безопасен для ваших основных данных.
Давайте разберемся, почему. Журнал регистрации и информационная база — это две совершенно разные, независимые сущности. В ЖР хранятся только метаданные о событиях: кто, когда и какое действие выполнил (например, "Пользователь Иванов И.И. изменил документ 'Реализация товаров и услуг №123'"). Удаление этой записи из журнала никак не затронет сам документ "Реализация товаров и услуг №123" в базе данных.
Регулярная очистка или сокращение ЖР — это стандартная процедура администрирования. Она необходима для предотвращения его неконтролируемого роста (как в примере автора темы, где он достиг 500+ Гб), что, в свою очередь, экономит дисковое пространство и ускоряет работу с самим журналом.
В ходе обсуждения были затронуты интересные технические моменты и более подходящие инструменты для разных задач логирования. Рассмотрим их.
Запись в журнал регистрации — нетривиальный процесс. Рабочие процессы сервера (rphost) не пишут в лог напрямую. Они отправляют данные для записи менеджеру кластера (rmngr) по протоколу TCP. Это взаимодействие вносит дополнительные задержки, которые, по некоторым оценкам, могут составлять до 35% от времени выполнения серверного кода. Использование базы данных SQLite поверх этой архитектуры лишь усугубляет проблему производительности.
Стандартный ЖР — это универсальный инструмент, но для решения специфических задач лучше использовать специализированные механизмы:
Версионирование объектов. Если ваша задача — отслеживать историю изменений конкретных документов или элементов справочников (кто, когда и какие реквизиты поменял), то механизм версионирования подходит для этого гораздо лучше. Он хранит историю версий самого объекта и позволяет при необходимости вернуться к предыдущему состоянию.
Технологический журнал (ТЖ). Для отладки, поиска узких мест, анализа причин блокировок и других технических проблем предназначен технологический журнал. Он предоставляет исчерпывающую информацию о внутренних процессах сервера 1С и является основным инструментом для решения проблем с производительностью.
Внешние системы сбора и анализа логов. В крупных и высоконагруженных системах для централизованного сбора логов часто применяют специализированные решения, такие как стек ELK (Elasticsearch, Logstash, Kibana) или связку с ClickHouse. Эти системы позволяют агрегировать логи с множества серверов, обеспечивают молниеносный поиск и визуализацию данных, снимая нагрузку по хранению и анализу с серверов 1С.
Подведем итог всему вышесказанному:
Не используйте новый формат журнала регистрации (SQLite). Он имеет серьезные проблемы с производительностью записи и надежностью, которые могут негативно сказаться на работе всей системы.
Придерживайтесь стандартного текстового формата (.lgp). Он проверен временем, надежен и, несмотря на медленное чтение больших объемов, не создает проблем при записи.
Регулярно очищайте и архивируйте журнал регистрации. Это безопасная и необходимая процедура для поддержания порядка и экономии места.
Используйте правильные инструменты для своих задач. Для контроля изменений данных — версионирование, для анализа производительности — технологический журнал.