Журналы сервера 1С Предприятия 8.3: путь, настройка, разбор

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

Быстрый ответ. События пользователей и обмены смотрите в журнале регистрации (Конфигуратор → Администрирование → Журнал регистрации). Сбои сервера, rphost, блокировки и тяжёлые запросы лежат в технологическом журнале. Он по умолчанию выключен и включается файлом logcfg.xml в каталоге conf платформы.

Какие журналы есть у сервера 1С

Сначала определитесь, что именно вы ищете. От этого зависит и место, и инструмент.

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

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

Для серверной базы он хранится в каталоге кластера, в подпапке с идентификатором информационной базы. Внутри есть каталог 1Cv8Log, а в нём файлы 1Cv8.lgf (справочники: пользователи, компьютеры, события) и *.lgp (сами записи, по периодам).

Типичный путь в Windows выглядит так: C:\Program Files\1cv8\srvinfo\reg_1541\<идентификатор базы>\1Cv8Log. Число 1541 — порт кластера, у вас оно может быть другим.

Не открывайте эти файлы текстовым редактором и не правьте их. Формат внутренний, а любая правка ломает журнал. Читайте его только средствами 1С.

Каталог srvinfo и реестр кластера

В srvinfo лежат подкаталоги вида reg_<порт>. Там файл 1CV8Clst.lst со списком баз кластера и служебные файлы сеансов. Для поиска причин сбоя он нужен редко, но именно отсюда видно, какой идентификатор у какой базы. Это пригодится, когда нужная папка журнала названа только GUID-ом.

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

Каталог вы задаёте сами в logcfg.xml. Внутри платформа создаёт подпапки по именам процессов с номером PID, например rphost_4212, rmngr_1980, ragent_1204. В каждой подпапке лежат текстовые файлы .log, по одному на час, имя вида 26100714.log (год, месяц, день, час).

Пока ТЖ не включён, этих папок нет. Не ищите их по умолчанию.

Особенности Linux

Логика та же, отличаются пути и права. Каталог для ТЖ создайте заранее и отдайте его пользователю usr1cv8, от имени которого работает сервер. Если этого не сделать, файлы не появятся, а ошибки вы не увидите.

Служебные сообщения агента сервера смотрите через journalctl -u с именем вашей службы. Имя зависит от версии платформы и способа установки, уточните его командой systemctl list-units | grep srv1cv8.

Проверить, что процессы кластера живы и слушают порты, можно так:

ps aux | grep -E "ragent|rmngr|rphost"
ss -ltnp | grep -E "1540|1541|1545"

Порты по умолчанию: 1540 у агента, 1541 у менеджера кластера, 1545 у сервера администрирования. Диапазон 1560-1591 занимают рабочие процессы. Если ваша схема отличается, подставьте свои значения.

Чем отличаются логи rphost, rmngr и ragent

В кластере работают три основных типа процессов. Их записи в ТЖ различаются по смыслу.

• ⚙️ ragent — агент сервера. Запускает остальные процессы и принимает подключения. Его записи нужны, если кластер не поднимается или не видны процессы.
• 🧭 rmngr — менеджер кластера. Распределяет сеансы по рабочим процессам, ведёт реестр, управляет блокировками. Здесь ищите проблемы подключения клиентов и управляемых блокировок.
• 🛠 rphost — рабочий процесс. Именно в нём выполняется код 1С и идут запросы к СУБД. Почти все прикладные ошибки и тяжёлые запросы видны в его папках.
• 🔌 ras — сервер администрирования, через который работают консоль и утилита rac. Это не рабочий процесс кластера: он нужен для управления, и свои записи у него скромные.

Практическое правило. Ошибка «у одного пользователя при определённом действии» — смотрите rphost. Ошибка «никто не может подключиться» — ragent и rmngr. Ошибка «консоль не видит кластер» — ras и порты.

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

Всё управление идёт через файл logcfg.xml. Создайте его в каталоге conf вашей версии платформы. В Windows это обычно C:\Program Files\1cv8\conf\, в Linux — подкаталог conf в каталоге установки /opt/1cv8/. Перезапускать службу не нужно: платформа перечитывает файл сама, обычно в течение минуты.

Минимальная конфигурация: только ошибки

Этого достаточно для первого шага. Журнал собирает исключения и не создаёт большой нагрузки.

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

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

1. location — каталог для файлов. Выберите отдельный диск, не системный. У пользователя, от имени которого работает служба, должны быть права на запись.
2. history — сколько часов хранить файлы. 48 значит двое суток, потом старые файлы удаляются сами.
3. EXCP — событие «исключение». Это ошибки, которые платформа поймала в работе.
4. property name="all" — писать все свойства события. Для диагностики это удобно.

Уровень детализации: что добавлять по задаче

Чем больше событий, тем быстрее растёт каталог. Включайте только то, что нужно сейчас.

Пример: записывать запросы к СУБД дольше 3 секунд. Длительность в ТЖ хранится в микросекундах, поэтому 3 секунды это 3000000.

<log location="D:\1CLogs\slowsql" history="24">
  <event>
    <eq property="name" value="DBMSSQL"/>
    <ge property="duration" value="3000000"/>
  </event>
  <property name="all"/>
</log>

Дампы падений

Если процесс падает без внятной ошибки, в logcfg.xml добавляют секцию dump. Платформа сохранит дамп памяти в указанный каталог, и его можно передать на анализ.

<dump location="D:\1CLogs\dumps" create="1" type="3"/>

Дампы большие. Проверьте свободное место заранее.

Как читать записи и искать ошибки

Каждая запись ТЖ — одна строка (иногда с продолжением), и начинается она с времени и длительности.

12:41:07.532001-1204,EXCP,2,process=rphost,OSThread=5120,Exception=DataBase,Descr='Ошибка при выполнении запроса POST к ресурсу...'

Разбор по частям:

• 12:41:07.532001 — время события до микросекунд, а число после дефиса (1204) — длительность;
• EXCP — тип события;
• process=rphost — какой процесс записал событие;
• Descr — текст ошибки. Именно он нужен для поиска.

Приёмы поиска

1. Возьмите время жалобы пользователя и откройте файл за этот час. Имя файла содержит час, так что искать по всему каталогу не нужно.
2. В Windows ищите по тексту через PowerShell: Select-String -Path D:\1CLogs\errors\rphost_*\*.log -Pattern "EXCP".
3. В Linux используйте grep -r "EXCP" /var/1clogs/errors/.
4. Найдя исключение, смотрите соседние записи выше и ниже по времени. Причина часто в предыдущем событии, а не в самом EXCP.
5. Сверьте время с журналом регистрации. Он покажет, какой пользователь и какая база были в этот момент.

Для блокировок смотрите пары TLOCK и TTIMEOUT. По событию TTIMEOUT видно, что ожидание истекло, а в соседних TLOCK найдётся тот, кто держал ресурс.

Читать журнал регистрации

Откройте Конфигуратор, меню «Администрирование», пункт «Журнал регистрации». Задайте отбор:

• период — сужайте до часа-двух;
• уровень «Ошибка» и «Предупреждение» — так уходит шум;
• пользователь или событие — для конкретной жалобы.

В обычном приложении тот же журнал открывается в разделе администрирования.

Чем разбирать журналы автоматически

Вручную читать гигабайты ТЖ тяжело. Три рабочих подхода.

• 🔎 Скрипты и утилиты. Для разовых задач хватает grep, PowerShell и распределения по событиям. Сгруппируйте записи по Descr и посчитайте частоту, это сразу покажет главную ошибку.
• 📊 Системы сбора логов. ТЖ можно складывать в ELK, Seq или аналогичные системы и строить поиск и графики. Нужен парсер для формата 1С, готовые решения есть у сообщества.
• 📈 Штатные средства 1С. Для постоянного контроля производительности применяют «Центр управления производительностью» (ЦУП), он собирает замеры и показывает узкие места без ручного разбора файлов.

Для мониторинга доступности подойдёт Zabbix или любой другой сервис с проверкой службы и портов кластера. Он не заменит ТЖ, но оповестит раньше пользователей.

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

Вот что мешает чаще всего.

• ❌ Лог не появляется. Проверьте путь location и права службы. Если каталога нет, платформа часто молча ничего не пишет.
• ❌ Файл logcfg.xml лежит не там. Он должен находиться в conf той версии платформы, под которой запущен сервер. На сервере с несколькими версиями легко положить его в соседнюю.
• ❌ XML с ошибкой разметки. Незакрытый тег — и вся конфигурация игнорируется. Проверьте файл любым XML-валидатором.
• ❌ Диск забит. Включили all без фильтра, и через сутки свободное место закончилось. Это уже само по себе приводит к падению сервера.
• ❌ Ищут не в том процессе. Пользователь жалуется на медленный отчёт, а админ смотрит ragent. Нужен rphost.

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