Где 1С хранит логи на сервере: полный разбор расположений

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

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

Каталог кластера srvinfo — главное хранилище логов сервера

Сервер 1С:Предприятия хранит служебные данные кластера в каталоге srvinfo. На Windows при установке по умолчанию это C:\Program Files\1cv8\srvinfo (для 32-битной версии — C:\Program Files (x86)\1cv8\srvinfo). Если при создании кластера администратор указал другой каталог, путь можно посмотреть в консоли управления серверами 1С: свойства кластера, поле «Каталог».

На Linux при установке пакетов с портала 1С каталог обычно создаётся в домашней папке пользователя, под которым работает агент: /home/usr1cv8/.1cv8/1C/1cv8/srvinfo. Проверить фактический путь можно командой ps aux | grep ragent — в параметрах запуска агента будет ключ -d с путём к каталогу кластера.

Внутри srvinfo находятся подкаталоги вида reg_1541 (номер соответствует порту кластера). Именно там лежат рабочие данные: файл реестра кластера 1CV8Clst.lst, список информационных баз, а также подкаталоги с журналами по каждой базе.

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

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

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

Обратите внимание на два режима хранения журнала: старый формат — один файл 1Cv8.lgd, новый формат (sqlite) — каталог с файлами базы данных журнала. Новый формат устойчивее к повреждениям и быстрее при больших объёмах. Переключение формата выполняется через конфигуратор: «Администрирование — Параметры информационной базы».

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

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

В logcfg.xml задаётся каталог вывода (элемент <log location="...">) и набор событий. Пример минимальной конфигурации для сбора ошибок и долгих запросов:

<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="0"/>
</config>

Параметр history задаёт глубину хранения в часах — старые файлы удаляются автоматически. Каждый рабочий процесс (rphost) и агент (ragent) пишут в свой подкаталог внутри указанного location. После изменения logcfg.xml перезапуск служб не требуется: платформа подхватывает конфигурацию автоматически в течение минуты.

Логи служб и процессов операционной системы

Когда агент сервера 1С не стартует или падает, журналы платформы могут быть пусты — тогда смотрят системные логи. На Windows это журнал событий: «Просмотр событий — Журналы Windows — Приложение и Система», источник — агент сервера 1С (1C:Enterprise 8.3 Server Agent). Там фиксируются ошибки запуска службы, проблемы с правами и конфликты портов.

На Linux агент обычно запускается как systemd-сервис, и его сообщения доступны через журнал: journalctl -u srv1cv8 (имя юнита зависит от версии пакета). Также полезны общесистемные журналы /var/log/messages или /var/log/syslog — туда попадают ошибки нехватки памяти и срабатывания OOM-killer, которые убивают процессы rphost.

Логи СУБД: MS SQL, PostgreSQL, IBM Db2

Значительная часть «ошибок 1С» на самом деле рождается на уровне СУБД: дедлоки, нехватка места в tempdb, обрывы соединений. В MS SQL Server журнал ошибок — это файлы ERRORLOG в каталоге ...\MSSQL\Log\ внутри каталога инстанса, а также раздел «Management — SQL Server Logs» в Management Studio. Там видны взаимоблокировки (если включён trace flag или Extended Events), ошибки ввода-вывода и авторизаций.

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

Дополнительно в SAM-инструментах самого кластера 1С полезен раздел «Счётчики» в консоли кластера и логи RAS (сервис администрирования), если он используется: его сообщения тоже пишутся в системный журнал или в каталог, заданный при запуске ras.

Практический порядок поиска нужного события

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

Если проблема в том, что база недоступна целиком или кластер не стартует, начинайте с системных журналов ОС и проверки каталога srvinfo: целостность файла 1CV8Clst.lst, свободное место на диске, права учётной записи агента.

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

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

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

Вторая группа ошибок связана с правами доступа. Служба агента работает под отдельной учётной записью (например, USR1CV8), и если администратор заходит под другим пользователем, часть каталогов может быть недоступна. Также антивирусы иногда блокируют запись в srvinfo — это проявляется как «замершие» логи при работающем кластере.

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

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