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

Логов у сервера 1С не один, а три слоя, и смотрят их для разных задач. Журнал регистрации показывает, что делали пользователи и какие ошибки поймала информационная база. Консоль кластера и утилита rac показывают живое состояние: сеансы, процессы, блокировки. Технологический журнал пишет события платформы и SQL-запросы: им ищут причины зависаний и медленной работы.

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

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

Сервер 1С состоит из нескольких процессов, и каждый пишет своё:

• 🧭 ragent — агент сервера, запускается службой «Агент сервера 1С:Предприятия»;
• 🗂 rmngr — менеджер кластера, распределяет клиентов по рабочим процессам;
• ⚙️ rphost — рабочие процессы, в них выполняется весь серверный код конфигурации;
• 📋 журнал регистрации — отдельно для каждой информационной базы;
• 🔬 технологический журнал — для всего, что вы укажете в настройках.

В таблице — что где искать.

Журнал регистрации в клиент-серверной базе лежит в каталоге кластера: внутри папки reg_<порт> (обычно reg_1541) есть подпапка с идентификатором базы, а в ней каталог 1Cv8Log. В файловой базе тот же каталог 1Cv8Log лежит рядом с файлом 1Cd. Руками в эти файлы лучше не лазить: читайте через интерфейс.

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

Открыть журнал можно двумя путями. В режиме 1С:Предприятие — раздел Администрирование, дальше пункт про поддержку и обслуживание, там Журнал регистрации. В Конфигураторе — меню Администрирование → Журнал регистрации. Открывать нужно под пользователем с правом администрирования.

Как читать список событий

Каждая строка — одно событие. Смотрите на четыре колонки:

1. Уровень — «Информация», «Предупреждение», «Ошибка», «Примечание». Для поиска проблем отбирайте «Ошибка» и «Предупреждение».
2. Пользователь и Компьютер — кто и откуда.
3. Событие — например, вход в систему, запись данных, фоновое задание, ошибка выполнения.
4. Комментарий — здесь текст ошибки, часто с полным стеком вызова.

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

Что настроить, чтобы журнал не раздувался

В Конфигураторе откройте Администрирование → Журнал регистрации → Настройка. Там задают два параметра: период, за который журнал разбивается на файлы (месяц, неделя, день), и нужен ли формат хранения в виде одного файла базы данных. Если база большая, ставьте разбивку по неделе или по дню: старые файлы проще архивировать и удалять, а открывается журнал быстрее.

Сокращение журнала — отдельная команда в том же меню. Перед сокращением сохраните копию каталога 1Cv8Log: удалённые записи не вернуть.

Какие события чаще всего нужны

• ❌ ошибки фоновых и регламентных заданий (не отработал обмен, не закрылся месяц);
• 🔐 неудачные входы и смена прав — разбирать «кто что сломал»;
• ✏️ запись и удаление объектов — выяснить, кто провёл или удалил документ;
• 🔁 начало и завершение сеансов — понять, когда пользователя выкинуло.

Консоль кластера: сеансы, процессы, лицензии

Оснастка называется «Администрирование серверов 1С:Предприятия» и ставится вместе с платформой. В ней подключитесь к серверу, раскройте нужный кластер и откройте узлы:

• Информационные базы → ваша база → Сеансы — кто работает, сколько памяти занимает сеанс, что выполняет прямо сейчас, сколько времени занимают вызовы;
• Соединения — подключения к кластеру, включая фоновые задания и сторонние приложения;
• Рабочие серверы → Рабочие процессы — список rphost, их память, загрузка, число соединений;
• Блокировки — кто кого держит.

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

Что делать с зависшим сеансом

Завершить сеанс можно прямо из консоли. Пользователь потеряет всё, что не сохранил, а при завершении во время проведения документа возможен откат транзакции. Поэтому сначала позвоните сотруднику, а если сеанс явно мёртвый (пользователь давно ушёл, вызов идёт часами) — завершайте.

С завершением рабочего процесса rphost осторожнее: оборвутся сеансы всех, кто на нём работает. Делайте это в нерабочее время или когда другого выхода нет.

Диагностика через консольную утилиту rac

Когда нужно скриптовать проверки или нет доступа к графической консоли, пригодится rac. Она лежит в каталоге bin установленной платформы и общается со службой администрирования ras. Запустите службу и подключайтесь к ней:

ras cluster --port=1545 localhost:1540
rac localhost:1545 cluster list

Здесь 1540 — порт агента сервера, 1545 — порт ras. Первая команда запускает сервис, вторая показывает кластеры и их идентификаторы. Идентификатор нужен во всех дальнейших командах.

Рабочие команды, в которых можно быть уверенным:

rac cluster list
rac session list --cluster=<идентификатор_кластера>
rac process list --cluster=<идентификатор_кластера>
rac connection list --cluster=<идентификатор_кластера>
rac lock list --cluster=<идентификатор_кластера>
rac infobase summary list --cluster=<идентификатор_кластера>

Для каждой группы есть свои параметры и подкоманды; полный перечень выдаёт справка rac help, а справку по группе — rac help session и аналогичные вызовы. Сообщения об ошибке авторизации означают, что для кластера или базы задан администратор: добавьте параметры с именем и паролем, как подскажет справка.

Скрипт, который раз в пять минут пишет в файл вывод rac session list и rac lock list, даёт вам историю там, где консоль показывает только «сейчас». Для разбора вчерашних тормозов это иногда единственное, что остаётся.

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

Это главный инструмент для зависаний и медленных запросов. Он выключен, пока вы не создадите файл logcfg.xml в каталоге conf установки платформы (для Windows это обычно папка conf рядом с bin). Платформа перечитывает файл сама, перезапуск службы не нужен.

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

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

Параметр location — куда писать (каталог должен существовать, а у учётной записи службы должно быть право записи), history — сколько часов хранить файлы. Событие EXCP — исключения, property name="all" включает все свойства события.

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

Чтобы не собрать терабайты, всегда ограничивайте события условием. Для долгих вызовов используют сравнение длительности: значение в технологическом журнале хранится в микросекундах, то есть вызовы от 5 секунд отбираются порогом 5000000.

<event>
  <eq property="name" value="CALL"/>
  <ge property="duration" value="5000000"/>
</event>

Не включайте все события без отбора на рабочем сервере. Журнал растёт со скоростью гигабайт в час, забьёт диск и сам станет причиной тормозов. Включили на время расследования, собрали данные, убрали.

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

Файлы лежат в подкаталогах вида rphost_<PID>, а внутри разбиты по часам: имя файла содержит год, месяц, день и час (например, 26100714.log для 14 часов 7 октября 2026). Одна запись начинается со строки вида «время-длительность,событие,уровень», дальше идут свойства через запятую.

Читать их проще не вручную, а поиском по тексту: findstr в Windows или grep в Linux. Ищите по имени пользователя, по фрагменту текста ошибки или по идентификатору соединения, затем идите вверх и вниз по записям. Для больших объёмов используют специальные разборщики журнала, но для первого шага достаточно поиска.

Поиск причин зависаний и блокировок

Порядок действий, когда «всё встало»:

1. Откройте консоль кластера, узел Сеансы, отсортируйте по длительности текущего вызова. Найдите сеанс, который держит самый долгий вызов.
2. Откройте Блокировки и посмотрите, кто кого ждёт. Цепочка обычно заканчивается одним сеансом, который не отпускает ресурс.
3. Сопоставьте имя пользователя и время с журналом регистрации: что он делал (проведение, закрытие месяца , обмен).
4. Если причина не ясна — включите технологический журнал на TLOCK, TTIMEOUT, TDEADLOCK и дождитесь повторения.

Блокировки бывают двух видов, и разбирать их надо по-разному:

• 🔒 Управляемые — это блокировки платформы на уровне данных 1С. Их видно в консоли кластера, а в технологическом журнале — по TLOCK.
• 🧱 Блокировки СУБД — на уровне SQL Server или PostgreSQL. Консоль кластера их не покажет, нужны средства самой СУБД и событие DBMSSQL в технологическом журнале.

Таймаут ожидания блокировки из-за того, что один сеанс долго проводит документ с «тяжёлым» запросом, лечится оптимизацией запроса, а не завершением сеансов. Если же взаимоблокировки (TDEADLOCK) повторяются, смотрите на порядок захвата данных в коде: два процесса блокируют одни и те же объекты в разном порядке.

Как анализировать производительность

Когда вопрос не «что зависло», а «почему медленно в целом», картина складывается из трёх источников:

• ⏱ Замер времени выполнения: в конфигурациях с поддержкой механизма замеров можно включить регистрацию длительности ключевых операций и посмотреть оценку по времени отклика. Это даёт цифры «как было» и «как стало» после изменений.
• 🖥 Нагрузка на сервер: процессор, память и диск на машине с rphost, загрузка и память рабочих процессов в консоли. Если один rphost вырос до нескольких гигабайт и не отпускает память, это сигнал искать утечку или тяжёлую обработку.
• 🗃 Запросы к СУБД: события DBMSSQL с большой длительностью, затем разбор плана запроса средствами СУБД.

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

Чего не хватает в логах: типичные ошибки при диагностике

• 🗓 Включили технологический журнал после того, как проблема произошла, и ждёте от него вчерашних данных. Он пишет только вперёд.
• 📉 Поставили слишком короткий history. Утром пришли смотреть ночные тормоза, а файлов уже нет.
• 🚫 Каталог для журнала не существует или нет прав на запись — файлы просто не появляются, и ошибки об этом вы не увидите.
• 🧩 Смотрят только журнал регистрации и не видят причины: в нём нет ни SQL, ни блокировок, ни времени вызовов.
• 💽 Журнал пишется на тот же диск, где лежит база. Нагрузка на диск от журнала добавляется к нагрузке от базы.

Если ничего не помогло: перепроверьте, что события и условия в logcfg.xml заданы корректно (файл должен быть валидным XML в кодировке UTF-8), сравните версию платформы на сервере и у клиентов и проверьте журнал событий операционной системы на ошибки службы агента сервера.

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