EventLogService 1С: что это за служба и как её использовать

EventLogService (служба журнала регистрации 1С) — это отдельный компонент платформы «1С:Предприятие», который отвечает за запись и хранение журнала регистрации вне основного сервера 1С. До появления этой службы журнал регистрации хранился в файлах формата lgd/lgp внутри каталога информационной базы на сервере, что при больших объёмах событий создавало нагрузку и усложняло анализ. Вынос журнала в отдельную службу позволяет хранить события в базе SQLite или передавать их во внешние системы хранения, например Elasticsearch.

Служба появилась в платформе версии 8.3.22 и стала ответом на давнюю проблему администраторов: в крупных внедрениях журнал регистрации разрастался до гигабайт, замедлял работу и был неудобен для поиска. Теперь запись событий может выполняться асинхронно отдельным процессом, не блокируя работу сервера 1С и не влияя на производительность пользовательских сеансов.

Важно понимать: EventLogService — это не служба Windows «Просмотр событий» и не журнал событий операционной системы. Это именно механизм платформы 1С, который обрабатывает события журнала регистрации: входы пользователей, ошибки, изменения данных, вызовы фоновых заданий и другие действия, фиксируемые прикладным решением.

Что такое журнал регистрации и зачем его выносить из сервера

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

В классической схеме журнал писался в файлы в каталоге reg_1541 (или аналогичном) внутри служебной папки информационной базы на сервере. При десятках тысяч пользователей и активной работе фоновых заданий объём событий измерялся гигабайтами в сутки. Чтение такого журнала через конфигуратор занимало минуты, а ротация файлов усложняла ретроспективный анализ.

Вынос журнала в отдельную службу решает три задачи: разгружает рабочие процессы сервера 1С, даёт возможность хранить данные в специализированных хранилищах с быстрым поиском и позволяет централизованно собирать события с нескольких кластеров в одну точку.

Как устроена служба: компоненты и варианты хранения

Служба устанавливается вместе с дистрибутивом сервера 1С и запускается как отдельный процесс (в Windows — как служба, в Linux — как демон). Сервер 1С передаёт ей события по сетевому протоколу, поэтому службу можно размещать на отдельной машине, ближе к системе хранения логов.

Поддерживаются два основных варианта хранения. Первый — встроенная база SQLite: простой вариант, не требующий дополнительного ПО, подходящий для небольших и средних внедрений. Второй — Elasticsearch: внешнее хранилище с полнотекстовым поиском, масштабированием и интеграцией с инструментами визуализации вроде Kibana. Вариант с Elasticsearch выбирают крупные организации, где журнал анализируют регулярно и по многим измерениям.

Сравнение вариантов

Хранение в SQLite

Подходит для небольших баз и быстрого старта без дополнительного ПО. Ограничение — поиск и выборки замедляются при больших объёмах событий.

Хранение в Elasticsearch

Подходит для крупных внедрений с активным анализом журнала и интеграцией с Kibana. Ограничение — нужно разворачивать и сопровождать отдельный кластер.

Классический файловый журнал

Подходит, если платформа старше 8.3.22 или нет ресурсов на новую службу. Ограничение — нагрузка на сервер 1С и неудобный анализ больших объёмов.

Как включить и настроить службу журнала регистрации

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

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

Старый файловый журнал при этом никуда не мигрирует автоматически: исторические данные останутся в прежних файлах, а в новом хранилище появятся только события, записанные после переключения. Если история критична, предусмотрите сохранение старых файлов журнала на период, требуемый внутренними регламентами аудита.

1. 1
   Обновите платформу сервера до версии 8.3.22 или новее и убедитесь, что компонент службы журнала регистрации установлен.
2. 2
   Настройте и запустите службу: укажите каталог хранения (SQLite) или параметры подключения к Elasticsearch.
3. 3
   Откройте свойства информационной базы в консоли кластера или через утилиту rac.
4. 4
   Укажите использование службы журнала регистрации и её сетевой адрес.
5. 5
   Сохраните настройки и сгенерируйте тестовое событие (например, вход пользователя).
6. 6
   Проверьте, что событие появилось в новом хранилище и доступно для просмотра.

Просмотр и анализ событий после перехода

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

Дополнительное преимущество Elasticsearch-варианта — возможность строить дашборды в Kibana: динамика ошибок по времени, топ пользователей по числу отказов доступа, частота таймаутов фоновых заданий. Это превращает журнал регистрации из «аварийного инструмента» в источник данных для проактивного мониторинга.

Учитывайте, что при недоступности службы события могут буферизоваться на стороне сервера 1С либо теряться — поведение зависит от настроек. Для критичных систем настройте мониторинг доступности самой службы, чтобы не обнаружить «дыру» в журнале в момент расследования инцидента.

Контрольные точки

Как проверить результат

Запись новых событий

Норма

После переключения свежие события видны при просмотре журнала из конфигуратора

Тревожный признак

Журнал пуст или показывает только старые записи — служба не подключена

Доступность службы

Норма

Процесс службы запущен, порт отвечает, в логах службы нет ошибок подключения к хранилищу

Тревожный признак

Служба остановлена или перезапускается с ошибками — события могут теряться

Скорость выборки

Норма

Отбор событий за сутки выполняется за секунды

Тревожный признак

Выборка зависает на минуты — проверьте объём хранилища и индексы

Рост хранилища

Норма

Размер данных растёт предсказуемо, место на диске контролируется

Тревожный признак

Диск заполняется без контроля — не настроена ротация или retention

Ограничения, риски и типичные ошибки

Главное ограничение — версия платформы: служба доступна только начиная с 8.3.22, поэтому на старых релизах придётся либо обновляться, либо оставаться на файловом журнале. Также следует помнить, что журнал регистрации по-прежнему фиксирует только те события, которые предусмотрены платформой и настройками уровней регистрации: служба меняет способ хранения, а не состав событий.

Из рисков на практике чаще всего встречаются три. Первый — отсутствие мониторинга самой службы: она остановилась, а администраторы узнали об этом через неделю, когда понадобился журнал. Второй — неконтролируемый рост хранилища: без настройки сроков хранения (retention) данные копятся бесконечно. Третий — потеря истории при переключении: старые файлы удалили, а новые события ещё не накопились.

Когда переход оправдан, а когда лучше подождать

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

Если же у вас одна небольшая база, журнал занимает немного места и просматривается редко, переход не даст заметного эффекта, но добавит точку отказа. В таком случае разумнее остаться на классическом файловом журнале и вернуться к вопросу при росте нагрузки.

Маршрут решения

Как выбрать действие

Журнал регистрации занимает гигабайты и открывается минутамиПланируйте переход на EventLogService, для больших объёмов — с Elasticsearch

Несколько кластеров 1С и требование централизованного аудитаРазверните службу с Elasticsearch и направьте в неё события всех кластеров

Одна небольшая база, журнал просматривается редкоОстаньтесь на файловом журнале, переход отложите до роста нагрузки

Платформа старше 8.3.22 и обновление невозможноИспользуйте файловый журнал с ротацией и выгрузкой событий штатными средствами

Служба безопасности требует хранения логов в SIEMИспользуйте Elasticsearch как промежуточное хранилище с дальнейшей интеграцией

FAQ: частые вопросы о службе журнала регистрации 1С

EventLogService — это то же самое, что журнал событий Windows?

Нет. Журнал событий Windows фиксирует события операционной системы и приложений, а EventLogService — это компонент платформы 1С, работающий только с журналом регистрации информационных баз. Они не заменяют друг друга: ошибки самой службы 1С как раз можно искать в системном журнале ОС.

Перенесутся ли старые события в новое хранилище автоматически?

Нет, автоматической миграции нет. Старые события остаются в прежних файлах журнала, а в новом хранилище накапливаются только записи после переключения. Сохраните старые файлы на срок, требуемый регламентами аудита.

Можно ли использовать службу для файловых баз?

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

Что произойдёт с записями журнала, если служба остановится?

Новые события не попадут в хранилище: в зависимости от настроек они могут временно буферизоваться или теряться. Поэтому службу нужно включить в мониторинг наравне с агентом сервера 1С и СУБД.

Нужна ли отдельная лицензия на EventLogService?

Служба входит в состав дистрибутива сервера «1С:Предприятие» соответствующих версий и отдельной лицензии не требует. Лицензионные требования касаются самого сервера 1С и, при выборе внешнего хранилища, инфраструктуры Elasticsearch.

Как уменьшить объём записываемых событий?

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