Куда 1С пишет логи: полный разбор мест хранения и настройки

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

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

Журнал регистрации: главный лог внутри базы

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

Место хранения зависит от режима работы. В файловой базе журнал лежит в каталоге базы — это файл 1Cv8.lgd (в старых форматах — папка 1Cv8Log с файлами .lgp и .lgf). В клиент-серверном варианте журнал хранится на сервере 1С в каталоге конкретной базы внутри srvinfo: reg_1541 (или другой порт кластера) → каталог с GUID базы → файлы журнала регистрации.

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

Технологический журнал: куда 1С пишет диагностику ошибок

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

Включается ТЖ файлом logcfg.xml, который нужно положить в каталог conf установки платформы (например, C:\Program Files\1cv8\<версия>\bin\conf) или в каталог conf в профиле пользователя. Каталог для самих логов задаётся прямо в этом файле атрибутом location. Если каталог не указать, платформа будет писать в подкаталог logs рядом с srvinfo на сервере или в профиле пользователя на клиенте.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="DBMSSQL"/></event>
    <property name="all"/>
  </log>
  <dump create="true" location="D:\1clogs\dumps" type="3"/>
</config>

Параметр history задаёт глубину хранения в часах — без него логи будут копиться бесконечно и заполнят диск. Внутри каталога location платформа создаёт папки по именам процессов (rphost, ragent, 1cv8 и т.д.), а внутри — файлы вида YYMMDDHH.log по часам.

1. 1
   Создайте на диске каталог для логов, например D:\1clogs, и дайте на него права записи учётной записи агента сервера 1С (по умолчанию USR1CV8)
2. 2
   Создайте файл logcfg.xml с нужными событиями и положите его в каталог conf установки платформы на сервере и/или клиенте
3. 3
   Перезапустите службу агента сервера 1С (или клиентское приложение), чтобы конфигурация подхватилась
4. 4
   Проверьте, что в каталоге логов появились подкаталоги процессов и файлы .log
5. 5
   После сбора диагностики отключите ТЖ или уменьшите состав событий — полный лог сильно нагружает диск

Логи клиентского приложения и дампы аварийных завершений

Когда «падает» тонкий или толстый клиент, следы ищите в профиле пользователя. Типовые пути в Windows: %APPDATA%\1C\1cv8\logs (если ТЖ настроен без явного location), %LOCALAPPDATA%\1C\1cv8\dumps — дампы аварийных завершений, а также каталог %APPDATA%\1C\1cv8\conf для пользовательских настроек. В Linux клиент пишет в ~/.1cv8/.

Дампы создаются только если включён элемент dump в logcfg.xml либо настроен системный сборщик дампов Windows (WerFault, папка %LOCALAPPDATA%\CrashDumps при соответствующей настройке реестра). Дамп полного размера может занимать гигабайты — следите за свободным местом.

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

Логи сервера 1С и СУБД

Агент сервера 1С ведёт собственный журнал в каталоге srvinfo (Windows: C:\Program Files\1cv8\srvinfo или профиль службы; Linux: /home/usr1cv8/.1cv8/1C/1cv8). Здесь лежит реестр кластера 1CV8Clst.lst, каталоги баз reg_1541 и служебные файлы. События самой службы также попадают в системный журнал Windows (Просмотр событий → Журналы Windows → Приложение, источник «1C:Enterprise»).

Не забывайте про СУБД: в клиент-серверном режиме половина проблем видна только там. MS SQL Server пишет ERRORLOG в каталоге Log своего экземпляра, PostgreSQL — в каталог, заданный параметром log_directory в postgresql.conf. Если в ТЖ видны ошибки DBMSSQL или DBPG, следующий шаг — именно логи СУБД.

Как организовать хранение и не заполнить диск

Главная ошибка эксплуатации — включить полный технологический журнал «на всякий случай» и забыть. События вида DBMSSQL со всеми свойствами на активной базе генерируют десятки гигабайт в сутки. Практичный подход: держать ТЖ выключенным, а включать точечно под конкретную проблему — только нужные события и с ограничением history.

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

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

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