Что такое логи в 1С и как с ними работать

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

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

Материал рассчитан на администраторов и внедренцев, которые работают с файловыми и клиент-серверными базами 1С:Предприятие 8. Разберём виды логов, способы их включения и чтения, типичные сценарии диагностики и ограничения, о которых часто забывают.

Какие виды логов существуют в 1С

Под словом «логи» в контексте 1С обычно понимают три разных механизма. Их путаница — частая причина того, что администратор ищет ошибку «не там» и теряет время.

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

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

Логи СУБД — журналы Microsoft SQL Server, PostgreSQL или другой используемой СУБД: медленные запросы, deadlock-графы, ошибки подключений. Они ведутся средствами самой СУБД и не зависят от настроек 1С.

Журнал регистрации: как открыть и что он показывает

Журнал регистрации доступен из конфигуратора: меню «Администрирование» → «Журнал регистрации». В пользовательском режиме многих типовых конфигураций есть аналогичный раздел, например «Администрирование» → «Обслуживание» → «Журнал регистрации».

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

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

1. 1
   Откройте конфигуратор и перейдите: Администрирование → Журнал регистрации.
2. 2
   Нажмите «Отбор» и задайте период — чем уже, тем быстрее откроется выборка.
3. 3
   Укажите пользователя или тип события, например «Данные. Ошибка» или «Доступ. Отказ в доступе».
4. 4
   Примените отбор и изучите колонки «Событие», «Комментарий» и «Представление данных».
5. 5
   Двойным щелчком по записи о данных откройте сам объект, если он ещё существует.

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

Технологический журнал: когда и как включать

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

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

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

В примере выше настроена запись исключений (EXCP) и запросов к MS SQL Server (DBMSSQL) в каталог C:\1clogs с хранением файлов 24 часа. Параметр history задаёт срок хранения в часах — без него логи будут копиться бесконечно.

Файлы ТЖ — текстовые, но читать их вручную тяжело: события многострочные, с множеством свойств. Для разбора используют специализированные инструменты (например, решения на базе стека мониторинга или парсеры логов), а также штатную консоль кластера для сопутствующего анализа. Начинающему администратору разумно собирать ТЖ по конкретному событию: например, только взаимоблокировки (TDEADLOCK) или только исключения.

Логи СУБД и журналы операционной системы

Когда проблема проявляется как «тормоза» или ошибки соединения с базой, источник истины — СУБД. В MS SQL Server полезны журнал ошибок (Error Log), расширенные события и динамические административные представления для поиска активных запросов и блокировок. В PostgreSQL — журнал сервера с настраиваемой записью медленных запросов через параметр log_min_duration_statement.

Дополнительный источник — журналы Windows (Просмотр событий) или syslog/journald в Linux. Туда попадают аварийные завершения процессов rphost и ragent, ошибки дисковой подсистемы, сбои сети. Если платформа «падает» без сообщений в журнале регистрации, ответ почти всегда лежит именно в системном журнале.

Как читать логи и находить причину ошибки

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

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

Хранение, ротация и безопасность логов

Логи — это не только диагностика, но и нагрузка на диск, а иногда и источник утечек. В журнале регистрации и технологическом журнале могут присутствовать имена пользователей, представления документов, а в запросах к СУБД — значения параметров. Доступ к каталогам с логами стоит ограничивать администраторами.

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

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

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

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

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