Серверная отладка 1С 8.3: флаг -debug, конфигуратор и технологический журнал

Чтобы включить отладку на сервере 1С, добавьте ключ -debug (лучше -debug -http) в строку запуска службы агента ragent.exe и перезапустите службу. Затем в конфигураторе выберите тот же протокол отладки и включите автоподключение к предмету «Сервер». Без этого ключа точки останова в серверных процедурах в клиент-серверной базе не срабатывают.

Для файловой базы ничего настраивать не нужно: серверный код там выполняется в процессе клиента, и отладчик видит его сразу. Всё, что ниже, касается клиент-серверного варианта: кластера 1С на Windows или Linux.

Как устроена серверная отладка и что подготовить

Отладчик конфигуратора не «залезает» в рабочий процесс сам. Рабочий процесс rphost должен быть запущен в режиме отладки и уметь отдавать отладчику информацию о выполняемом коде. Этот режим задаёт агент сервера ragent при старте.

Есть два протокола:

Перед началом проверьте:

• 🔑 у вас есть права локального администратора на сервере (нужно менять параметры службы);
• 👥 есть окно, когда можно перезапустить службу 1С;
• 🧩 у пользователя конфигуратора есть право «Отладка» в роли (обычно у «Полных прав» оно есть);
• 🔌 между сервером и машиной разработчика открыты порты: 1540, 1541, диапазон рабочих процессов (по умолчанию 1560–1591) и порт отладки 1550 для HTTP.

Включаем отладку на сервере 1С: ключ -debug у службы агента

Windows

Служба агента обычно называется 1C:Enterprise 8.3 Server Agent (x86-64). Сначала посмотрите текущую строку запуска:

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

В поле BINARY_PATH_NAME будет примерно такая строка:

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

Добавьте ключи отладки после -agent. Удобнее всего через реестр:

1. Откройте regedit от имени администратора.
2. Перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ и найдите раздел службы агента 1С.
3. Откройте параметр ImagePath.
4. Допишите -debug -http после -agent, остальные ключи не трогайте.
5. Перезапустите службу в services.msc (или командами net stop / net start).

Итоговая строка:

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

💡 После перезапуска откройте Диспетчер задач, вкладку «Подробности», и включите столбец «Командная строка». У процесса ragent.exe должен быть виден -debug. Если ключа нет — правили не ту службу (на сервере бывает несколько версий платформы).

Linux

На Linux порядок зависит от того, как запущен сервер:

• 📄 Старый скрипт /etc/init.d/srv1cv83 читает файл настроек (/etc/sysconfig/srv1cv83 или /etc/default/srv1cv83). Там раскомментируйте строку SRV1CV8_DEBUG=1 и перезапустите службу.
• ⚙️ Unit systemd в новых платформах передаёт ключи прямо в ExecStart. Выполните systemctl edit для юнита сервера 1С, переопределите ExecStart, добавив -debug -http, затем systemctl daemon-reload и systemctl restart.

Проверка та же: ps aux | grep ragent должен показать ключ -debug.

Почему не через консоль и ras

Переключателя «включить отладку» в консоли администрирования кластера нет. Утилиты ras и rac управляют кластером, базами и сеансами, но режим отладки задаётся только при старте агента. rac при этом полезна для контроля: rac cluster list покажет кластеры, rac session list — сеансы, где видно, какой пользователь и с какого приложения сидит в базе. Остальные подкоманды смотрите в rac help.

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

Сервер запущен с -debug, теперь настраиваем сторону разработчика.

1. В конфигураторе откройте Сервис → Параметры, вкладку «Отладка».
2. В блоке отладки для данной информационной базы выберите тот же протокол, что у агента: HTTP или TCP/IP.
3. Нажмите F5 (Отладка → Начать отладку) или запустите пользовательский режим обычным способом.
4. Откройте Отладка → Подключение. В HTTP-режиме здесь виден список предметов отладки: клиенты, серверные сеансы, фоновые задания.
5. Нажмите «Автоматическое подключение» и отметьте нужные типы: «Сервер», «Фоновое задание», «HTTP-сервис», «Веб-сервис».

Теперь точка останова в модуле с директивой &НаСервере или в общем модуле с флагом «Сервер» остановит выполнение.

Отладка чужого сеанса

Если ошибка воспроизводится только у конкретного пользователя, запустите его клиент с ключами отладки:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "srv1c\buh" /Debug -http -attach /DebuggerURL "http://dev-pc:1550"

Сеанс сам появится в списке предметов отладки. Учтите, что пока выполнение стоит на точке останова, пользователь видит «зависшую» программу.

Уровни детализации: отладчик, замер и технологический журнал

Под словом «отладка» на сервере понимают три разных инструмента. Они отвечают на разные вопросы:

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

• 🟢 Минимум — только EXCP (исключения) и QERR (ошибки компиляции запросов). Можно держать постоянно.
• 🟡 Производительность — CALL, SCALL, DBMSSQL или DBPOSTGRS с фильтром по длительности. Включать на часы, не на недели.
• 🔴 Блокировки — TLOCK, TTIMEOUT, TDEADLOCK. Самый тяжёлый вариант, только на время разбора конкретной проблемы.

Настройка технологического журнала (logcfg.xml)

Журнал управляется файлом logcfg.xml. Он лежит в каталоге conf платформы: на Windows обычно C:\Program Files\1cv8\conf\, на Linux — /opt/1cv8/conf/ (или в каталоге conf конкретной версии). Создайте файл, если его нет.

Пример для поиска ошибок:

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

Пример для медленных запросов (дольше одной секунды):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog\slow" history="12">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="CALL"/>
      <gt property="duration" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Пояснения к параметрам:

• ⏱ duration в 8.3 пишется в микросекундах: 1 секунда = 1000000.
• 🗂 history — сколько часов хранить файлы. Старше — платформа удалит сама.
• 📁 location — отдельный каталог на диске с запасом места, не системный C:.

💡 Перезапускать службу после правки logcfg.xml не нужно. Платформа перечитывает файл примерно раз в минуту. Включили, подождали, воспроизвели проблему.

Диагностика производительности на сервере 1С

Начинайте с замера, а не с журнала. Это быстрее и точнее показывает виновную строку.

1. Убедитесь, что агент запущен с -debug. Без него замер покажет только клиентский код, а серверные процедуры будут пустыми.
2. В конфигураторе запустите отладку и подключитесь к серверу.
3. Включите Отладка → Замер производительности.
4. В пользовательском режиме выполните медленную операцию: проведите документ, сформируйте отчёт.
5. Выключите замер. Отсортируйте результат по колонке времени.

Обычно наверху оказывается одна из трёх вещей:

• 🐢 запрос внутри цикла — сотни одинаковых обращений к базе вместо одного;
• 🔒 ожидание блокировки — строка проста, а время огромное;
• 📦 обращение через точку к реквизитам ссылки в цикле (Документ.Контрагент.ИНН), которое каждый раз читает объект из базы.

Если замер не воспроизводит тормоза (у разработчика всё быстро, у бухгалтеров медленно), включайте журнал с событиями CALL и DBMSSQL из примера выше. Он покажет реальные сеансы, реальных пользователей и реальное время.

Для запросов дополнительно можно включить запись планов: элемент <plansql/> внутри <config>. Это заметно нагружает сервер — включайте на 15–30 минут.

Анализ логов и поиск ошибок

Журнал раскладывается по папкам процессов: rphost_4120, ragent_2280, rmngr_3304. Внутри — файлы вида 26100714.log: год, месяц, день, час.

Каждая запись начинается с минут, секунд и длительности:

14:07.512003-2350112,DBMSSQL,5,process=rphost,p:processName=buh,Usr=Иванова,Sql='SELECT ...',Rows=18240,Context='Документ.РеализацияТоваровУслуг.МодульОбъекта : 245 : ...'

Здесь видно: запрос шёл 2,35 секунды, пользователь Иванова, база buh, вызван из модуля объекта реализации, строка 245. Поле Context — самое ценное: оно ведёт прямо к строке кода.

Быстрый поиск без специальных программ:

# Все исключения за сегодня по всем процессам
Get-ChildItem D:\techlog\errors -Recurse -Filter *.log |
  Select-String -Pattern ",EXCP," |
  Select-Object -First 50

На Linux то же делает grep -r ",EXCP," /var/log/1c/techlog/errors | head -50.

Что искать в первую очередь:

• ❌ EXCP с Descr= — текст ошибки, который пользователь видел в окне или не видел вовсе (ошибки фоновых заданий);
• ⏳ TTIMEOUT — превышено время ожидания на блокировке, в записи есть список сеансов, которые держали ресурс;
• 💥 TDEADLOCK — взаимоблокировка, в записи видна пара конфликтующих сеансов;
• 🔁 одинаковый Context у сотен событий подряд — запрос в цикле.

Для больших журналов (гигабайты за час) удобнее отдельные анализаторы технологического журнала. Принцип тот же: группировка по Context и сумма duration.

Безопасность и очистка после отладки

Режим отладки на рабочем сервере не стоит оставлять включённым «на всякий случай»:

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

Порядок после завершения работ:

1. Удалите -debug -http из ImagePath (или верните SRV1CV8_DEBUG=0 на Linux).
2. Перезапустите службу в технологическое окно — снова оборвутся сеансы.
3. В logcfg.xml оставьте только минимальный журнал ошибок или удалите файл совсем.
4. Удалите каталоги журнала. В них лежат тексты запросов и имена пользователей, а при включённом <property name="all"/> — и значения параметров.
5. Закройте порт 1550 в брандмауэре, если открывали его только для отладки.

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