Где хранятся логи 1С и как их найти

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

Расположение файлов зависит от операционной системы, версии платформы и того, как развёрнута система — в файловом или клиент-серверном варианте. Ниже разобраны все основные места хранения логов 1С в Windows и Linux, способы включения технологического журнала через logcfg.xml и практические приёмы поиска нужных событий.

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

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

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

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

Логи сервера 1С — события агента и рабочих процессов сервера предприятия: старт и остановка процессов, аварийные завершения rphost, ошибки кластера. Находятся в рабочем каталоге сервера.

Логи СУБД — журналы PostgreSQL, MS SQL Server или другой базы данных: медленные запросы, взаимоблокировки, ошибки на уровне СУБД. Их расположение определяется настройками самой СУБД, а не 1С.

Журнал регистрации: где хранится и как открыть

Журнал регистрации не требует настройки — он ведётся всегда. Открыть его можно из конфигуратора или режима «Предприятие»: меню «Администрирование» → «Журнал регистрации» (в типовых конфигурациях также «Администрирование» → «Обслуживание» → «Журнал регистрации»).

Физическое хранение зависит от варианта базы. В файловой базе журнал лежит внутри каталога базы: это файл с расширением .lgd (в новых версиях формата) или папка 1Cv8Log с файлами .lgp и .lgf в старом формате. В клиент-серверном варианте данные журнала хранятся в таблицах СУБД, отдельного файла нет.

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

Настройка уровня детализации

Через меню «Администрирование» → «Настройка журнала регистрации» можно выбрать, какие события фиксировать: только ошибки, ошибки и предупреждения или все события включая информационные. Рекомендуется периодически сокращать журнал (кнопка «Сократить»), иначе в активных базах он разрастается и замедляет отбор событий.

Технологический журнал: пути по умолчанию в Windows и Linux

Технологический журнал создаётся только если существует конфигурационный файл logcfg.xml в каталоге конфигурации платформы. Без него ТЖ не ведётся — это частая причина, почему администратор «не находит логи».

Если ТЖ включён и путь не переопределён, платформа пишет логи в стандартные каталоги:

• Windows (сервер и клиент): C:\ProgramData\1C\1cv8\logs
• Windows (пользовательский профиль, если нет прав на ProgramData): %APPDATA%\1C\1cv8\logs
• Linux: ~/.1cv8/logs для клиента или домашний каталог пользователя, под которым работает агент сервера (обычно /home/usr1cv8/.1cv8/logs)

Внутри каталога logs создаются подпапки по имени процесса (rphost, ragent, rmngr, 1cv8, 1cv8c), а в них — файлы вида YYMMDDHH.log, где имя — дата и час начала записи. Каждый час создаётся новый файл.

Как включить технологический журнал через logcfg.xml

Файл logcfg.xml нужно разместить в каталоге конфигурации платформы. В Windows это обычно C:\Program Files\1cv8\<версия>\bin\conf, в Linux — /opt/1cv8/<архитектура>/<версия>/conf (каталог conf рядом с каталогом установки). После создания файла процессы платформы подхватывают его автоматически, перезапуск службы не обязателен, но надёжнее перезапустить агент сервера.

Минимальный пример, записывающий все события с длительностью и ошибками в указанный каталог:

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

Параметр location задаёт каталог логов — укажите диск с достаточным свободным местом. Параметр history — глубина хранения в часах; по её истечении старые файлы удаляются автоматически. Для диагностики конкретной проблемы лучше ограничить события: например, только EXCP (исключения) или DBMSSQL (запросы к MS SQL) вместо записи всего подряд.

Логи СУБД и вспомогательные источники

Значительная часть ошибок «1С» на самом деле рождается на уровне базы данных. Для MS SQL Server логи лежат в каталоге экземпляра (например, ...\MSSQL\Log\ERRORLOG), а также доступны через SQL Server Management Studio: «Management» → «SQL Server Logs». Там видны взаимоблокировки, нехватка памяти, ошибки целостности.

Для PostgreSQL расположение задаётся параметром log_directory и logging_collector в postgresql.conf; типичные пути — /var/log/postgresql/ в Linux или подкаталог log в каталоге данных. Включите log_min_duration_statement, чтобы видеть медленные запросы, и log_lock_waits для диагностики блокировок.

Не забудьте про веб-сервер, если база опубликована: логи IIS (C:\inetpub\logs\LogFiles) или Apache/Nginx помогают при ошибках «Ошибка соединения с сервером» у веб-клиентов и через HTTP-сервисы.

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

Файлы ТЖ — это текстовый формат, где каждая строка начинается с метки времени и длительности события в микросекундах, затем идёт имя события (EXCP, DBMSSQL, CALL, TLOCK и т.д.) и пары «свойство=значение». Строки одного события могут быть многострочными — контекст продолжается с отступом.

Для поиска ошибок ищите события EXCP и EXCPCNTX (контекст исключения — покажет модуль и строку кода). Для блокировок — TLOCK, TDEADLOCK, TTIMEOUT. Для медленных запросов фильтруйте DBMSSQL по длительности — первое число после метки времени.

Открывать большие файлы лучше не Блокнотом, а редакторами, устойчивыми к гигабайтным файлам (Notepad++, Far, консольные утилиты grep/Select-String), либо специализированными инструментами разбора ТЖ. Ключ к успеху — точное время воспроизведения проблемы: зафиксируйте момент ошибки с точностью до секунды и ищите события в этом окне.

Частые вопросы о логах 1С