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

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

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

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

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

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

В файловом режиме журнал регистрации находится в каталоге базы — это файл 1Cv8.lgd (в старых версиях формата — каталог 1Cv8Log с файлами .lgp и .lgx). Путь к каталогу базы можно посмотреть в списке информационных баз стартера 1С: выделите базу, и путь отобразится внизу окна либо откройте его через кнопку настройки.

В клиент-серверном режиме журнал регистрации хранится на сервере 1С в служебном каталоге конкретной базы внутри srvinfo: обычно это srvinfo\reg_1541\<GUID базы>\1Cv8Log. Напрямую редактировать или удалять эти файлы нельзя — это приведёт к повреждению журнала или всей базы.

Как открыть журнал регистрации

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

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

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

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

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

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

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

<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="CLSTR"/>
    </event>
    <property name="all"/>
  </log>
  <dump location="D:\1clogs\dumps" create="1" type="3"/>
</config>

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

Логи сервера 1С и агента кластера

Агент сервера 1С пишет собственные события в системный журнал операционной системы. В Windows это «Просмотр событий» (eventvwr.msc), раздел «Журналы Windows» → «Приложение» — источник обычно содержит «1C:Enterprise». Здесь фиксируются старт и остановка службы, ошибки кластера, проблемы с лицензиями и критические сбои процессов.

В Linux аналогичные сообщения попадают в syslog/journald: смотрите journalctl -u srv1cv8 (имя службы зависит от способа установки) или файлы /var/log/syslog, /var/log/messages. Дополнительно рабочие процессы могут оставлять файлы в каталоге srvinfo сервера.

Каталог srvinfo по умолчанию расположен: в Windows — C:\Program Files\1cv8\srvinfo (или в профиле пользователя службы, если порт реестра нестандартный), в Linux — /home/usr1cv8/.1cv8/1C/1cv8. Внутри, помимо журналов регистрации баз, лежат файлы реестра кластера (1CV8Clst.lst) — их тоже нельзя править вручную при запущенной службе.

Логи СУБД: что смотреть при клиент-серверной работе

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

Для Microsoft SQL Server основной источник — журнал ошибок SQL Server (доступен в Management Studio: «Management» → «SQL Server Logs») и системные представления динамического управления. Для PostgreSQL — файлы в каталоге log кластера (путь задаётся параметром log_directory в postgresql.conf), в Linux часто это /var/log/postgresql. Для IBM Db2 и Oracle свои журналы диагностики.

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

Дампы аварийных завершений и дополнительные файлы

При аварийном завершении процессов платформа может создавать дампы памяти. Их расположение задаётся секцией dump в logcfg.xml. Если дампы не настроены, Windows может сохранять их через механизм WER: каталог %LOCALAPPDATA%\CrashDumps либо C:\ProgramData\Microsoft\Windows\WER. Для клиентского приложения также полезен каталог %APPDATA%\1C\1cv8\logs и %APPDATA%\1C\1cv8\dumps, куда платформа пишет часть диагностической информации по умолчанию.

Отдельно стоит упомянуть логи обновления конфигурации и загрузки/выгрузки: при обновлении через конфигуратор ход выполнения виден в окне сообщений, но для автоматизированных сценариев (пакетный режим конфигуратора) вывод перенаправляется в файл через параметр /Out. Если обновление «молча» упало — первым делом проверьте, задан ли этот файл и что в нём записано.

1. 1
   Зафиксируйте точное время ошибки и имя пользователя, у которого она возникла
2. 2
   Откройте журнал регистрации и отфильтруйте события с уровнем «Ошибка» за нужный период
3. 3
   Если информации мало — проверьте Просмотр событий Windows / journalctl на сервере
4. 4
   При необходимости включите технологический журнал через logcfg.xml (события EXCP, TLOCK, DBMSSQL) и воспроизведите ошибку
5. 5
   Сопоставьте события по времени с логами СУБД, если работа идёт в клиент-серверном режиме
6. 6
   После диагностики отключите или сузьте сбор технологического журнала

Типичные ошибки при работе с логами 1С

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

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

Как проверить, что логирование работает

После настройки технологического журнала убедитесь, что файлы реально появляются. Достаточно перезапустить службу сервера 1С (или клиентское приложение) и подождать минуту: в каталоге, указанном в location, должны появиться подкаталоги с именами процессов (rphost_*, ragent_*) и файлами .log внутри. Если каталог пуст — проверяйте права и синтаксис XML: ошибка в logcfg.xml приводит к тому, что конфигурация молча игнорируется.

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

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