Журнал регистрации 1С на 35 миллиардов событий: как заставить его открываться за 0,11 секунды

Журнал регистрации — первое, куда лезешь при разборе инцидента: кто изменил документ, почему упало фоновое задание, что было перед сбоем. Пока база небольшая, это работает. На нагруженной — перестаёт: файловый журнал разрастается на гигабайты в день, просмотр через конфигуратор виснет на любом отборе, а история глубже пары недель просто недоступна.

Расскажу, как мы вынесли журнал регистрации трёх продуктивных баз в ClickHouse и что из этого вышло: 35 миллиардов событий онлайн-истории, поиск всех ошибок за сутки — 0,11 секунды, привычная форма журнала для пользователей и падение числа ошибок в проде в 23 раза за полгода. Решение работает в промышленной эксплуатации больше двух лет. Все цифры — реальные, сняты прямыми запросами к боевому серверу.

Почему штатный журнал не тянет

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

Дальше — арифметика. Основная база этого внедрения пишет 150–194 млн событий в сутки, в пике — до 11 300 событий в секунду. Это гигабайты прироста в день на дисках боевого сервера. Просмотр «за неделю» превращается в чтение десятков гигабайт последовательного формата — отсюда зависания и знаменитое «журнал не открывается вообще».

Это не баг и не кривая настройка. Формат ЖР спроектирован под дешёвую запись, а не под аналитику. Штатные меры (периодичность файлов, отбор событий, регламентное сокращение) проблему отсрочивают, но фундаментальный конфликт «формат для записи против запросов на чтение» не убирают. Если журнал нужен как рабочий инструмент — данные надо унести туда, где чтение стоит дёшево.

Архитектура: три части и один принцип

Принцип — разделить запись и чтение. Боевой сервер пишет журнал как писал; рядом работает конвейер, который в реальном времени переливает события во внешнее аналитическое хранилище.

Кластер 1С (файлы .lgp/.lgf)
        ^74; tail-чтение хвоста файлов в реальном времени
        `60;
Служба-экспортёр (.NET, Windows)
  • читает реестр кластера, по маске имени поднимает экспортёр на каждую базу
  • парсит .lgp, батчи по 10 000 событий каждые 3–5 секунд
  • хранит позицию в файле → докатка после любого рестарта
        ^74; HTTP :8123, батч-вставка
        `60;
ClickHouse (отдельный сервер)
  • таблица EventLogItems на каждую базу 1С
  • MergeTree, партиции по месяцам, сжатие 6,7–9,2×
        ^74; внешний источник данных (ODBC)
        `60;
1С:Предприятие
  • обработка-интерфейс: привычный журнал со всеми отборами
  • мониторинг живости конвейера + Telegram-алерты
  • метод анализа ошибок для AI-ассистента

1. Экспортёр

Служба Windows на .NET (за основу взят открытый проект OneSTools.EventLog). Три свойства, которые делают её пригодной для прода:

• Автообнаружение баз. Служба читает реестр кластера и по regex-маске имени (^PROD$ → база prod_el) сама поднимает экспортёр на каждую нужную базу. Добавили базу в кластер — выгрузка началась без ручной настройки.
• Потоковое чтение. Парсер читает .lgp «хвостом», как tail -f: событие попадает в ClickHouse через секунды после записи в файл.
• Гарантия доставки. В каждой строке хранится имя файла и позиция чтения. После рестарта службы или сервера выгрузка продолжается ровно с того места, где остановилась, — без потерь и дублей. За два года эксплуатации потеряно 0 событий.

2. ClickHouse: почему именно он и как настроена таблица

ClickHouse — колоночная СУБД, созданная ровно под логовый профиль: массовая вставка, редкие точечные обновления, быстрые агрегаты. Ключевые решения по схеме (одна таблица EventLogItems на базу):

• Ключ сортировки (DateTime, EndPosition) — запросы «за период» (99 % сценариев журнала) читают только нужные гранулы индекса, а не всю таблицу.
• Партиции по месяцам (PARTITION BY toYYYYMM) — ретеншн реализуется удалением партиции целиком, мгновенно, без тяжёлых DELETE.
• Кодеки под тип данных. LowCardinality на словарных полях (пользователь, компьютер, событие, метаданные — значения повторяются), DoubleDelta на монотонных счётчиках, ZSTD на текстах. Итог — 2,5 ТБ сырых журналов лежат в 380 ГБ (сжатие 6,7×, на складских базах до 9,2×).

3. Интерфейс в 1С

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

Цифры с продуктива

Скорость сканирования — около 500 млн строк в секунду. За типовые сутки система принимает 163 млн событий от 602 пользователей и 186 компьютеров, 1,3 млн сеансов, 75 видов событий. Разрез по приложениям показателен: 98,3 % потока — фоновые задания, и именно они в файловом журнале тонут первыми.

Главный эффект — не скорость, а поведение системы

Самая важная таблица проекта — не про миллисекунды, а про качество. Динамика ошибок уровня «Ошибка» в основной базе по месяцам:

С 1,4 млн ошибок в январе до 60 тысяч в июле — в 23 раза меньше за полгода (на пятимиллиардном месячном потоке это 0,001 %). Это прямое следствие наблюдаемости: когда каждая ошибка видна, считается, попадает в тренды и алерты — их начинают системно чинить, а не «замечать, когда пользователи пожалуются». Журнал перестал быть архивом «на всякий случай» и стал метрикой качества.

Самообслуживание конвейера

Отдельный инженерный слой — чтобы всё это жило без ручного присмотра. Регламентные задания в 1С следят за самим конвейером:

• Контроль актуальности. Задание запрашивает дату последнего события в ClickHouse; если поток остановился — алерт в Telegram и автоматический перезапуск службы экспортёра удалённо.
• Фикс полуночного бага платформы. После смены суток 1С иногда не обновляет отметку времени нового файла журнала, и экспортёр его «не видит». Мониторинг сам «трогает» файл на всех рабочих серверах кластера, чтобы платформа обновила метаданные.
• Очистка. Локальные файлы старше периода хранения удаляются со всех серверов — но только после проверки, что их содержимое уже в ClickHouse. Диск боевого сервера перестаёт расти.

Три неочевидные проблемы интеграции 1С ↔ ClickHouse

Если будете повторять — вот три места, на которых уходит время:

1. CONVERT() в агрегатах. 1С транслирует КОЛИЧЕСТВО(*) к внешнему источнику как CONVERT(COUNT(*), SQL_NUMERIC) — ClickHouse такой синтаксис не понимает. Решение: лёгкие выборки строк делаются запросом 1С, а тяжёлые агрегаты — нативным SQL ClickHouse; счётчики при необходимости собираются в BSL по выборке.

2. Перестановка GUID. В журнале 1С хранит идентификатор объекта в переставленном формате — не как Строка(УникальныйИдентификатор). Обработка преобразует ссылку в формат журнала на лету (перестановка частей GUID), поэтому отбор «Данные = конкретный документ» работает так же, как в штатном журнале, включая префикс вида ссылки.

3. UTC против местного времени. ClickHouse хранит время в UTC; во всех пользовательских выборках применяется сдвиг в местную зону. Мелочь, которая при пропуске даёт «события из будущего» и часовые расхождения в отборах.

Почему ClickHouse, а не Elasticsearch или PostgreSQL

Вопрос закономерный — выгружать журнал можно в разные хранилища, и у популярных экспортёров (тот же OneSTools) есть режим Elasticsearch. Почему в итоге ClickHouse:

• Против Elasticsearch. ES отлично ищет полнотекстово, но журнал регистрации — это не полнотекстовый поиск, а аналитика по структурированным полям с отборами и агрегатами. На тех же объёмах ES требует кратно больше памяти и диска (инвертированные индексы против колоночного сжатия), а агрегаты по миллиардам строк отдаёт медленнее. Для «посчитай ошибки по месяцам за всю историю» ClickHouse выигрывает и по скорости, и по железу.
• Против PostgreSQL. Postgres — прекрасная строчная СУБД, но 35 млрд строк логов — это не её профиль: вставка такого потока упрётся в WAL, а аналитические сканы без колоночного хранения будут читать всю таблицу. Партиционирование помогает, но не заменяет колоночный движок.
• За ClickHouse. Массовая batch-вставка «из коробки», колоночное сжатие 7–9×, гранулярный индекс по времени, удаление истории партициями за миллисекунды и агрегаты со скоростью сотен миллионов строк в секунду. Это ровно тот профиль нагрузки, что даёт журнал регистрации: пишем много, обновляем никогда, читаем аналитикой по периоду.

Оговорка: если у вас уже развёрнут и обслуживается ES-кластер под другие задачи — тащить в него журнал разумно, чтобы не плодить технологии. Но с нуля под эту задачу ClickHouse дешевле и по железу, и по сопровождению.

Поверх — слой для AI

Раз журнал стал быстрым, на нём заработал метод анализа ошибок для ИИ-ассистента: счётчики, тренд к предыдущему периоду, топ событий и метаданных, распределение по часам, последние ошибки. Вопрос «что сломалось за ночь?» получает ответ за секунды, без ручного копания. Это и есть разница между «архивом на всякий случай» и живым инструментом наблюдаемости.

Стоимость и когда это оправдано

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

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

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

А нагрузка на боевой сервер от чтения журнала не вырастет? Наоборот, падает. Экспортёр читает файлы последовательно, «хвостом» — это дешёвая операция, несравнимая с тем, как штатный просмотрщик гоняет весь журнал при каждом отборе. Плюс локальные файлы после выгрузки удаляются, и диск боевого сервера перестаёт расти. Аналитическая нагрузка целиком уходит на отдельный сервер ClickHouse.

Что с задержкой — данные «онлайн» или с лагом? Практически онлайн: батч в 10 000 событий уходит каждые 3–5 секунд, так что событие доступно для запроса через секунды после записи в файл. Для расследований и алертов этого более чем достаточно.

Отбор по конкретному документу работает? Да, это принципиально важный сценарий («кто и когда трогал вот эту накладную»). Работает благодаря преобразованию GUID в формат журнала на лету — см. раздел про перестановку GUID выше.

Что с правами доступа к журналу? Права разграничиваются на стороне обработки-интерфейса и учётной записи ODBC-подключения так же, как вы разграничили бы доступ к любому внешнему источнику данных. Сам ClickHouse при этом не торчит наружу — только на сервер 1С.

Сколько времени на внедрение? Базовый конвейер (экспортёр + ClickHouse + форма журнала) поднимается за несколько дней. Больше времени уходит на «взрослую» обвязку: мониторинг живости, автоперезапуск, очистку файлов, разграничение прав, тонкую настройку кодеков под ваши данные.

А если у вас, как у нас, сотни миллионов событий в сутки — вопрос не «нужно ли», а «почему ещё не сделали». Поделитесь в комментариях, как вы держите журнал регистрации на нагруженных базах: сокращаете, отключаете события, выносите во внешнее хранилище — интересно собрать реальные практики, а не советы из справки.

Про окна хранения. Здесь журнал регистрации складывается в отдельное хранилище и живёт там годами. В интеграционном слое всё наоборот: у шины сообщения доступны около шести часов, у приёмника две недели, и через сутки после сбоя расследовать уже не по чему. Как это выглядит на живом контуре - Год с 1С:Шиной в проде: что ломается на длинном аптайме.

Другие наши инструменты диагностики 1С:

• Карта объёмов базы 1С - из чего состоит база: журнал регистрации не единственное, что растёт незаметно.
• Чек-ап СУБД под 1С - 40+ проверок настроек SQL Server под платформу.
• Трансформатор SQL в запрос 1С - что делает конкретный медленный запрос.
• Оптимизатор временных таблиц - как переписать то, что нашли.