Журнал регистрации и технологический журнал на сервере 1С: что где лежит и как этим пользоваться

На Windows логи сервера 1С по умолчанию хранятся в C:\Program Files\1cv8\srvinfo\reg_1541\<GUID базы>\1Cv8Log, на Linux — в /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/<GUID базы>/1Cv8Log. Это журнал регистрации: отдельная папка на каждую информационную базу кластера.

Технологический журнал (подробный лог рабочих процессов rphost, rmngr, ragent) по умолчанию выключен. Он пишется туда, куда укажете в файле logcfg.xml. Журнал регистрации отвечает на вопрос «кто и что сделал в базе», технологический — «почему сервер тормозит или падает». Для анализа ошибок производительности обычно нужен второй.

Где физически лежат журналы регистрации на сервере

Все данные кластера живут в каталоге, который передаётся службе агента сервера параметром -d. Если при установке путь не меняли, он такой:

Внутри лежит папка reg_<порт менеджера кластера>. Стандартный порт менеджера — 1541, поэтому почти всегда это reg_1541. Если на сервере поднято несколько кластеров на разных портах, папок будет несколько: reg_1541, reg_2541 и так далее.

Как проверить реальный путь

Администратор мог перенести srvinfo на другой диск. Не гадайте — посмотрите командную строку службы.

Windows. Откройте services.msc, найдите службу «1C:Enterprise 8.3 Server Agent», откройте свойства и скопируйте поле «Исполняемый файл». Там будет что-то вроде:

"C:\Program Files\1cv8\8.3.24.1691\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\1C\srvinfo" -debug

Нужный каталог стоит после -d. То же самое из консоли:

sc qc "1C:Enterprise 8.3 Server Agent (x86-64)"

Имя службы зависит от разрядности и способа установки, поэтому сначала уточните его в services.msc.

Linux. Посмотрите параметры запущенного процесса:

ps -ef | grep ragent

В выводе ищите тот же ключ -d. Если его нет, используется каталог по умолчанию в домашней папке пользователя usr1cv8.

Журнал файловой базы

У файловой базы сервера нет. Журнал лежит рядом с базой: <папка с 1Cv8.1CD>\1Cv8Log. Схема та же, только без srvinfo.

Что лежит в srvinfo и как опознать папку нужной базы

Структура каталога данных кластера выглядит так:

srvinfo\
  1cv8wsrv.lst              — список кластеров этого агента
  reg_1541\
    1CV8Clst.lst            — реестр кластера: базы, рабочие серверы, настройки
    3f6a1c2e-...-9b10\      — папка информационной базы (имя = GUID)
      1Cv8Log\              — журнал регистрации
    snccntx3f6a1c2e-...\    — сеансовые данные и кэш этой базы

Папки баз названы GUID-ами, а не именами. Найти нужную можно двумя способами:

1. 🔎 Открыть 1CV8Clst.lst в текстовом редакторе (копию, не оригинал) и найти имя базы. Рядом с ним стоит её GUID.
2. 🖥️ Выполнить в консоли rac infobase summary list --cluster=<GUID кластера> (подробнее о rac — ниже). В выводе есть пары «infobase — name».

Два формата журнала регистрации

Внутри 1Cv8Log вы увидите один из двух вариантов:

У последовательного формата каждый .lgp начинается с даты в имени. Это удобно: сразу видно, какой файл за какой период и сколько он весит.

Настройка журналов: уровень записи и технологический журнал

Говоря о «настройке логов кластера», смешивают три разных механизма. Разведём их.

Уровень журнала регистрации

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

Если журнал вдруг пустой, первым делом загляните сюда. Уровень «Не регистрировать» — частая причина «пропавших» логов после переноса базы.

Технологический журнал: logcfg.xml

Платформа ищет logcfg.xml в каталоге conf. На Windows это C:\Program Files\1cv8\conf\ (действует на все версии платформы) или C:\Program Files\1cv8\<версия>\bin\conf\ (только для этой версии). На Linux — /opt/1cv8/conf/ или каталог conf внутри папки конкретной версии в /opt/1cv8/x86_64/.

Рабочий пример для поиска ошибок и взаимоблокировок:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="false"/>
  <log location="D:\1c_techlog\errors" history="48">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что здесь важно:

• 📁 location — каталог для логов. Папку создайте заранее и дайте права на запись пользователю, от имени которого работает служба (на Linux — usr1cv8).
• ⏳ history — сколько часов хранить файлы. 48 — двое суток.
• 🎯 event — фильтр событий. Без фильтров журнал пишет всё подряд.
• 🧾 property name="all" — писать все свойства события, включая контекст встроенного языка.

Перезапуск службы не нужен: сервер перечитывает logcfg.xml примерно раз в минуту. Удалили файл — запись остановилась.

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

Как читать логи и находить причины торможений

Структура файлов техжурнала

В каталоге из location появятся папки по процессам: rphost_4120, rmngr_3876, ragent_2204. Число после подчёркивания — PID процесса. Внутри — файлы по часам с именем вида 26100714.log: год, месяц, день, час.

Строка события начинается так:

32:15.704011-1250032,TDEADLOCK,4,process=rphost,p:processName=buh,...

• 32:15.704011 — минуты, секунды и микросекунды внутри часа из имени файла;
• 1250032 — длительность в микросекундах (здесь ≈1,25 с);
• TDEADLOCK — имя события;
• p:processName — имя информационной базы.

Быстрый поиск без внешних инструментов

Найти все исключения за час на Linux:

grep -h ",EXCP," /var/1c_techlog/errors/rphost_*/26100714.log | less

То же на Windows в PowerShell:

Select-String -Path "D:\1c_techlog\errors\rphost_*\*.log" -Pattern ",TDEADLOCK," | Select-Object -First 50

Посчитать, в каких базах больше всего исключений:

grep -ho ",EXCP,.*p:processName=[^,]*" /var/1c_techlog/errors/*/*.log \
  | grep -o "p:processName=[^,]*" | sort | uniq -c | sort -rn

Какие события что означают

Для медленных запросов не пишите все запросы подряд — фильтруйте по длительности. В фильтрах logcfg.xml свойство duration задаётся в десятитысячных долях секунды, поэтому значение 30000 — это 3 секунды:

<event>
  <eq property="name" value="DBMSSQL"/>
  <ge property="duration" value="30000"/>
</event>

Журнал регистрации: фильтр по важности

Для разбора пользовательских ошибок откройте журнал регистрации самой базы. В БП 3.0, ЗУП 3.1 и УТ 11 он находится в Администрирование → Обслуживание → Протоколы работы → Журнал регистрации. Поставьте отбор по уровню «Ошибка» и периоду — сразу видно, у кого и в каком модуле упало.

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

Ротация и очистка старых записей

Технологический журнал

Ротация встроена: файлы старше значения history (в часах) сервер удаляет сам. Ставить для этого задания планировщика не нужно. Типичные значения:

• ⏱️ 4–24 часа — для тяжёлых событий вроде DBMSSQL и TLOCK;
• 📅 48–168 часов — для EXCP и TDEADLOCK, если хотите видеть историю за неделю.

Закончили расследование — удалите logcfg.xml или уберите из него лишние блоки log.

Журнал регистрации

Сам по себе журнал регистрации не чистится. На нагруженной базе он вырастает до десятков гигабайт, и тогда медленно открывается даже окно журнала.

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

Удалять старые .lgp вручную технически можно, но только при остановленной службе и с копией каталога. Остановка службы агента обрывает сеансы всех пользователей всех баз кластера — предупредите их и выберите нерабочее время. Файл 1Cv8.lgf не трогайте никогда: без него оставшиеся .lgp не прочитать.

Кэш сеансовых данных

Папки snccntx<GUID> в reg_1541 — не логи, а сеансовые данные и кэш. Их очистка — известный приём при странных ошибках после обновления конфигурации или платформы. Порядок:

1. Предупредите пользователей: работа всех баз кластера прервётся.
2. Остановите службу агента сервера 1С.
3. Перенесите (не удаляйте сразу) папки snccntx* во временный каталог.
4. Запустите службу и проверьте вход в базы.
5. Через пару дней без проблем удалите перенесённые папки.

Файлы 1CV8Clst.lst и 1cv8wsrv.lst при этом не трогайте — это реестр кластера.

Диагностика кластера через ras и rac

Консольная утилита rac даёт ту же информацию, что и оснастка «Администрирование серверов 1С Предприятия», но её удобно запускать по SSH и в скриптах. Работает она через сервер администрирования ras.

Запуск ras

На сервере 1С запустите ras в режиме кластера. По умолчанию он подключается к агенту на localhost:1540 и слушает порт 1545:

/opt/1cv8/x86_64/8.3.24.1691/ras cluster --daemon

На Windows ras.exe лежит в папке bin версии платформы. Для постоянной работы его регистрируют службой, для разовой диагностики достаточно запустить из командной строки:

"C:\Program Files\1cv8\8.3.24.1691\bin\ras.exe" cluster

Команды для разбора проблем

Сначала узнайте GUID кластера:

rac cluster list

Дальше подставляйте его в ключ --cluster:

rac infobase summary list --cluster=<GUID кластера>
rac process list --cluster=<GUID кластера>
rac session list --cluster=<GUID кластера>
rac session list --cluster=<GUID кластера> --licenses
rac connection list --cluster=<GUID кластера>

Если у кластера заданы администраторы, добавьте --cluster-user= и --cluster-pwd=.

Что смотреть:

• 🧠 process list — сколько рабочих процессов, их PID и потребление памяти. PID сразу ведёт к папке rphost_<PID> в техжурнале.
• 👥 session list — кто сидит в базе, с какого компьютера, когда начал. Помогает найти сеанс, который держит блокировку из TDEADLOCK.
• 🔑 session list --licenses — какие лицензии заняты сеансами.
• 🗂️ infobase summary list — соответствие GUID и имён баз для поиска папки в reg_1541.

Полный список параметров для каждого режима выводит rac help process, rac help session и так далее. Сверяйтесь с ним для своей версии платформы.

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