Проблема: журнал есть - пользоваться нельзя
Журнал регистрации - главный инструмент расследований в 1С: кто изменил документ, почему упало фоновое задание, откуда ошибка. Но на нагруженной базе штатный механизм ломается о собственный объём. Основная база этого внедрения генерирует 150-194 млн событий в сутки - файловый журнал разрастается на десятки гигабайт в день, просмотр через конфигуратор открывается минутами и виснет на любом отборе, а держать историю глубже пары недель значит забить диски боевого сервера терабайтами.
В результате журнал превращается в формальность: он вроде бы есть, но ответить “что делал этот пользователь месяц назад” или “как менялось число ошибок после релиза” - практически невозможно.
Решение: конвейер из трёх частей
- Экспортёр - служба Windows на .NET (открытый проект OneSTools.EventLog),
читает файлы журнала кластера “хвостом”, как
tail -f, и батчами по 10 000 событий каждые 3-5 секунд отправляет их в хранилище. Базы кластера подхватываются автоматически по маске имени: добавили базу - выгрузка началась без настройки. В каждой строке хранится позиция исходного файла, поэтому рестарт службы или сервера не теряет и не дублирует события. - ClickHouse - колоночная СУБД на отдельном сервере, созданная ровно для таких нагрузок: партиции по месяцам, словарные кодеки для повторяющихся полей. Итог - 2,5 ТБ сырых журналов основной базы лежат в 380 ГБ (сжатие 6,7×, на складских базах - до 9,2×), а скорость сканирования достигает ~500 млн строк в секунду.
- Интерфейс в 1С - обработка, повторяющая штатный журнал регистрации: те же отборы (период, пользователь, событие, уровень, метаданные и даже отбор по конкретной ссылке), только под капотом - внешний источник данных поверх ClickHouse. Пользователи и саппорт работают в привычной форме и не знают, что листают миллиарды строк; обучение не потребовалось.
Отдельный инженерный слой - самообслуживание конвейера: регламентное задание следит за свежестью данных, при остановке потока шлёт алерт в Telegram и автоматически перезапускает службу экспортёра; локальные файлы журнала на боевых серверах удаляются только после проверки, что их содержимое уже в ClickHouse. За два года эксплуатации конвейер живёт без ручного присмотра.
Цифры с продуктива
Все значения сняты прямыми запросами к боевому серверу ClickHouse (04.08.2026), методика замеров воспроизводима:
- 35,2 млрд событий онлайн-истории по трём базам; основная - 30,5 млрд.
- Поток: в среднем 170 млн событий в сутки, зафиксированный пик - 11 300 событий в секунду. За типовые сутки: 163 млн событий, 602 пользователя, 1,3 млн сеансов.
- Поиск всех ошибок за последние 24 часа - 0,11 секунды (просканировано 158,5 млн строк). Агрегация по месяцам за всю историю - 61 секунда.
- Хранение: 2,97 ТБ сырых журналов → 440 ГБ в ClickHouse.
Главный эффект - не скорость, а поведение системы
Самая важная таблица кейса - динамика ошибок уровня “Ошибка” в основной базе:
с 1 403 721 в январе до 60 097 в июле - в 23 раза меньше за полгода (на пятимиллиардном месячном потоке событий это 0,001 %).
Это прямое следствие наблюдаемости: когда каждая ошибка видна, считается, попадает в тренды и алерты - их начинают системно чинить, а не “замечать, когда пользователи пожалуются”. Журнал перестал быть архивом и стал метрикой качества, по которой видно работу команды.
Поверх хранилища работает и AI-слой: метод анализа ошибок для ИИ-ассистента (счётчики, тренды, топы событий и метаданных, распределение по часам) - вопрос “что сломалось за ночь?” получает ответ за секунды, без ручного копания в журнале.
Технические детали, которые пришлось решить
- GUID в “переставленном” формате. 1С хранит идентификатор объекта в журнале с переставленными частями GUID - обработка на лету преобразует ссылку, поэтому отбор “Данные = конкретный документ” работает как в штатном журнале.
- Полуночный баг платформы. После смены суток 1С иногда не обновляет отметку времени нового файла журнала, и экспортёр его “не видит” - мониторинг сам “трогает” файл на всех рабочих серверах кластера.
- Ограничения SQL-трансляции. Запросы 1С к внешнему источнику генерируют конструкции, которые ClickHouse не поддерживает, - тяжёлые агрегаты выполняются нативными запросами ClickHouse, лёгкая сборка - на стороне 1С.
Стек полностью открытый: ClickHouse, открытый экспортёр, обработки 1С. Из затрат - один сервер под хранилище.
Кому это нужно
- Саппорту и администраторам: “почему вчера в 14:32 не провёлся документ” - ответ за секунды, история не затёрта.
- Разработчикам: тренд ошибок после релиза, топ падающих фоновых заданий.
- Безопасности: полная история действий пользователя по каждому объекту за месяцы, с отбором по ссылке.
- Руководству: стабильность системы в цифрах по месяцам.
Как это устроено внутри - схема хранения, движки таблиц, экспортёр и запросы, которыми сняты все приведённые здесь цифры, - разобрано в статье на Инфостарте: “Журнал регистрации 1С на 35 миллиардов событий”.
Если ваша база пишет десятки миллионов событий в сутки, а журнал регистрации при этом бесполезен - мы разворачиваем такой конвейер под ключ: услуга журнал регистрации 1С в ClickHouse, от осмотра парка баз до дашбордов и алертов. Отдельно про метрики серверов и СУБД - в услуге мониторинга 1С. Посмотреть, что творится в вашей базе прямо сейчас, можно с бесплатного экспресс-аудита.