Логи сервера 1С 8.3: где лежат, как включить подробность и что в них искать

Посмотреть лог сервера 1С можно в двух местах. Журнал регистрации каждой базы лежит в каталоге кластера: на Windows по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\<ID базы>\1Cv8Log\, а открывают его из самой базы. Подробный технический лог процессов ragent, rmngr и rphost по умолчанию не пишется вовсе: его включают файлом logcfg.xml, и тогда он появляется в папке, которую вы укажете.

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

Где на диске лежат файлы логов сервера 1С

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

Число в имени reg_1541 совпадает с портом менеджера кластера. Если кластер переведён на другой порт, папка называется иначе, например reg_2541.

Как узнать фактический путь, если стандартного нет

• 🪟 Windows: откройте services.msc, найдите службу агента сервера 1С и посмотрите строку «Исполняемый файл». В ней после ключа -d указан каталог кластера.
• 🐧 Linux: посмотрите параметры запуска службы командой systemctl cat с именем службы srv1cv8… или в выводе ps aux | grep ragent. Ищите тот же ключ -d.

Как найти папку нужной базы

Папки баз названы идентификаторами (GUID), а не именами. Соответствие хранится в файле 1CV8Clst.lst в каталоге reg_1541. Это текстовый файл: найдите в нём имя базы, рядом будет её GUID.

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

Что лежит в папке 1Cv8Log

Журнал регистрации бывает двух форматов:

• 📄 последовательный (старый): файл 1Cv8.lgf со справочниками пользователей, компьютеров и событий плюс набор файлов *.lgp с самими записями, по одному на период;
• 🗄️ SQLite-формат: один файл 1Cv8.lgd.

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

У сервера 1С нет единого «уровня логирования». Подробность настраивается в двух разных местах, и путать их не стоит.

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

В окне настройки журнала регистрации есть переключатель с вариантами от «Не регистрировать» до «Регистрировать все события». Промежуточные уровни отсекают события ниже выбранной важности: например, на уровне ошибок попадут только ошибки.

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

Консоль администрирования

Консоль кластера сама логи не пишет и не настраивает. Её роль в анализе другая: она показывает «живое» состояние. В ветках «Сеансы», «Соединения» и «Рабочие процессы» видно, какой процесс занят, сколько у него памяти, кто держит сеанс. Это первое место, куда смотреть, пока проблема происходит прямо сейчас.

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

Журнал регистрации читают через клиент, а не блокнотом. Есть три способа.

1. В пользовательском режиме. В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11): Администрирование → Поддержка и обслуживание → Журнал регистрации. Нужны права администратора.
2. В конфигураторе: Администрирование → Журнал регистрации.
3. Из любой копии файлов. Скопируйте папку 1Cv8Log в каталог пустой файловой базы и откройте журнал там. Так удобно разбирать журнал с чужого сервера, не трогая рабочую базу.

Как быстро найти нужное

Без отбора журнал за месяц открывается долго и бесполезен. Сразу ставьте отбор:

• 📅 период — узкое окно вокруг времени проблемы, например 15 минут;
• 🔴 важность — «Ошибка», чтобы увидеть сбои;
• 👤 пользователь и компьютер — если жалуется конкретный человек;
• 🧩 событие — например, «Данные. Удаление» для поиска удалённых объектов или «Сеанс. Аутентификация (ошибка)» для неудачных входов.

В колонке «Данные» видна ссылка на объект, в «Комментарии» — текст ошибки. Двойной щелчок по записи открывает её целиком, вместе с представлением данных и метаданными.

Технологический журнал: включаем подробный лог процессов сервера

Технологический журнал — это и есть «лог сервера» в узком смысле. В нём видно исключения платформы, медленные запросы к СУБД, ожидания на блокировках и взаимоблокировки.

Где разместить logcfg.xml

Платформа ищет файл в каталоге conf. Два варианта:

• C:\Program Files\1cv8\conf\logcfg.xml — действует для всех установленных версий платформы;
• C:\Program Files\1cv8\<номер версии>\bin\conf\logcfg.xml — только для одной версии.

На Linux каталог conf ищите рядом с исполняемыми файлами платформы, внутри каталога установки в /opt/1cv8/.

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

Рабочий пример: только ошибки и долгие запросы

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="10000000"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
  <dump create="true" location="D:\1c_dumps" type="0"/>
</config>

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

• location — папка для логов. Выберите отдельный диск с запасом места, у учётной записи службы 1С должны быть права на запись.
• history — сколько часов хранить файлы. 24 часа хватает для расследования.
• gt property="duration" — отбор по длительности. В актуальных версиях 8.3 длительность считается в микросекундах, поэтому 10000000 — это запросы дольше 10 секунд.
• Для PostgreSQL вместо DBMSSQL укажите событие DBPOSTGRS.
• Элемент dump включает дампы при падении процессов.

Какие события включать под задачу

Собрали материал — верните файл к минимальной настройке или удалите его. Включённый «на всякий случай» подробный журнал отнимает ресурсы постоянно.

Как читать текстовые логи rphost и rmngr

Внутри папки location платформа создаёт подкаталоги по процессам: rphost_3812, rmngr_2140, ragent_1964. Число — идентификатор процесса (PID). Файлы внутри названы по часу в формате ГГММДДЧЧ.log: например, 26100714.log — это 7 октября 2026 года, 14-й час.

• rphost — рабочий процесс. Здесь выполняется код и запросы пользователей. Ошибки бизнес-логики, медленные запросы и блокировки ищите здесь.
• rmngr — менеджер кластера. Регистрирует сеансы, распределяет нагрузку, следит за лицензиями. Сюда смотрят при проблемах подключения, выдачи лицензий и рестартах рабочих процессов.
• ragent — агент сервера. Принимает первое подключение клиента и консоли.

Разбор одной строки

45:31.831006-0,EXCP,3,process=rphost,p:processName=buh_prod,OSThread=4120,t:clientID=27,t:applicationName=1CV8C,t:computerName=PC-ACC-04,Usr=Иванова,SessionID=118,Descr='Поле объекта не обнаружено (КонтрагентИНН)'

У событий СУБД вместо Descr важны свойства Sql (текст запроса), Rows (сколько строк вернулось) и Context (строка модуля, из которой запрос вызван). Именно Context показывает, какой документ или отчёт тормозит.

Если сервер не стартует

Когда служба не поднимается, технологический журнал ещё не успел заработать. Тогда смотрите журнал событий Windows: eventvwr.msc, раздел «Журналы Windows → Приложение», отбор по источникам, связанным с 1С. На Linux — journalctl -u с именем службы. Частые причины там видны сразу: занят порт 1540 или 1541, нет прав на каталог srvinfo, не найден ключ защиты.

Командная строка: rac, PowerShell и grep

Утилиты с названием chserver в поставке платформы нет. Для работы с кластером из командной строки есть пара ras (сервер администрирования) и rac (клиент к нему).

Состояние кластера через rac

Сначала запустите ras, если он не работает как служба:

ras cluster --daemon

Затем запросите данные:

rac cluster list
rac session list --cluster=<ID кластера>
rac process list --cluster=<ID кластера>
rac session list --cluster=<ID кластера> --licenses

Первая команда выдаёт идентификатор кластера, остальные — сеансы, рабочие процессы с их памятью и занятые лицензии. Полный список подкоманд и параметров для вашей версии выводит rac help.

Поиск по технологическому журналу

На Windows помогает PowerShell. Следить за свежими записями в реальном времени:

Get-Content D:\1c_techlog\rphost_3812\26100714.log -Wait -Tail 20

Найти все исключения за все процессы:

Get-ChildItem D:\1c_techlog -Recurse -Filter *.log | Select-String ",EXCP,"

На Linux то же самое делают tail -f и grep:

grep -rh ",TDEADLOCK," /var/log/1c_techlog/ | head -50
grep -rc ",EXCP," /var/log/1c_techlog/ | grep -v ":0$"

Вторая команда показывает, в каких часовых файлах были исключения и сколько. Так вы находите «горячий» час, а потом читаете уже его.

Подключаем внешние системы мониторинга

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

Что стоит отслеживать

• 📈 число событий EXCP за 5 минут — резкий рост означает новую ошибку;
• 🔒 появление TDEADLOCK и TTIMEOUT — признак конфликта блокировок;
• 🧠 память процессов rphost из rac process list — рост без снижения говорит об утечке;
• 💽 свободное место на диске с техжурналом;
• 🔁 перезапуски рабочих процессов в событиях PROC.

Сборщик логов должен учитывать многострочные события: правило склейки строк — «новая запись начинается с отметки времени». Без него каждый перенос текста запроса станет отдельным событием, и поиск сломается.

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