Сбор служебной информации в 1С: что это и зачем нужно

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

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

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

Что входит в состав служебной информации

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

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

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

В каких ситуациях требуется сбор

Типовой сценарий — обращение в службу поддержки по инциденту. Оператор просит прислать служебную информацию, чтобы локализовать проблему: воспроизводится ли ошибка на конкретной версии платформы, связана ли она с запросом к СУБД или с обрывом соединения.

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

Как настроить технологический журнал

Технологический журнал включается созданием конфигурационного файла logcfg.xml в каталоге conf платформы. В файле задаются каталог размещения логов, перечень событий и условия отбора. После сохранения файла платформа начинает запись без перезапуска — настройки подхватываются автоматически.

Ключевой принцип — собирать только нужные события. Полное логирование всех событий на рабочем сервере быстро генерирует гигабайты данных и снижает производительность. Для диагностики ошибок достаточно событий EXCP и EXCPCNTXT, для анализа запросов — событий конкретной СУБД с указанием минимальной длительности.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_logs" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

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

Как выгрузить журнал регистрации и сведения о системе

Журнал регистрации выгружается из конфигуратора: меню «Администрирование» — «Журнал регистрации», затем «Выгрузить журнал». Перед выгрузкой установите отбор по периоду, пользователю и уровню событий (например, только ошибки), чтобы не передавать лишние данные. Формат выгрузки — XML или табличный документ.

Сведения о версиях доступны в разделе «О программе» толстого или тонкого клиента: там указаны версия платформы, конфигурации и режим работы. Параметры сервера смотрят в консоли кластера серверов 1С: состав рабочих процессов, сеансы, соединения. Эти данные обычно прикладывают к обращению в виде снимков экрана или текстового описания.

1. 1
   Зафиксируйте точное время возникновения ошибки и шаги воспроизведения
2. 2
   Включите технологический журнал с фильтром по нужным событиям
3. 3
   Воспроизведите ошибку и дождитесь записи событий в лог
4. 4
   Выгрузите журнал регистрации с отбором по периоду и пользователю
5. 5
   Соберите сведения о версиях платформы, конфигурации и СУБД
6. 6
   Упакуйте логи и описание в архив, проверьте отсутствие конфиденциальных данных

Проверка результата и типичные ошибки

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

Ограничения и безопасность

Технологический журнал фиксирует события только с момента включения — восстановить историю до настройки невозможно. Поэтому для плавающих ошибок лог держат включённым с узким фильтром и ограниченным сроком хранения. В файловых базах часть событий СУБД недоступна, поскольку нет отдельного сервера баз данных.

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

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