Отладка серверного кода 1С и технологический журнал: настройка с нуля

«Отладка на сервере 1С» — это два разных инструмента. Первый — пошаговая отладка серверного кода из Конфигуратора: точки останова, просмотр переменных. Второй — технологический журнал (ТЖ): текстовые логи, в которые сервер пишет события по настройке из файла logcfg.xml. Для разработчика нужен первый, для администратора, который ловит тормоза, блокировки и вылеты, — второй.

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

Что выбрать: отладка кода или технологический журнал

Если сомневаетесь, начните с ТЖ: он безопаснее. Пошаговая отладка на рабочем сервере — крайняя мера, лучше воспроизвести проблему на тестовой копии базы.

Подготовка: доступ, версии и порты

Что проверить до начала:

• 🔑 У вас есть права администратора на сервере и запись в каталог установки платформы.
• 🖥️ Версия платформы на клиенте (где работает Конфигуратор) совпадает с версией сервера, хотя бы по первым трём числам номера. Разные версии — частая причина того, что отладчик не подключается.
• 🌐 Порты. Клиент обращается к агенту сервера (по умолчанию порт 1540), дальше работает менеджер кластера (1541) и диапазон портов рабочих процессов, который задан в свойствах рабочего сервера. Файрвол между вашим компьютером и сервером должен это пропускать.
• 📁 Есть место на диске. ТЖ при подробных настройках за час разрастается на гигабайты.

Включение пошаговой отладки серверного кода

Шаг 1. Ключ запуска агента сервера

Служба «Агент сервера 1С:Предприятия» запускается программой ragent. Отладку включает параметр -debug в командной строке этой службы.

1. Откройте оснастку «Службы» (services.msc).
2. Найдите службу агента сервера 1С, откройте её свойства и посмотрите «Исполняемый файл». В нём уже есть параметры -srvc, -agent, -regport, -port, -range, -d.
3. Добавьте в конец строки -debug. Если нужен HTTP-протокол отладки, в справке платформы описан соответствующий вариант параметра; для обычной внутренней сети хватает TCP.
4. Перезапустите службу.

Править строку запуска проще через реестр (HKLM\SYSTEM\CurrentControlSet\Services\<имя службы>, значение ImagePath), но тогда сделайте копию значения: ошибка в кавычках не даст службе стартовать.

На Linux параметр добавляется в юнит службы или в скрипт запуска сервера, а смысл тот же: агент стартует с -debug.

Шаг 2. Сервер отладки

При отладке по TCP Конфигуратор и сервер обмениваются данными через сервер отладки (dbgs). Для небольшой команды он обычно поднимается автоматически на машине разработчика. Если отлаживаются несколько человек одновременно, администраторы запускают общий dbgs на отдельном узле, по умолчанию он слушает порт 1550. Адрес сервера отладки указывается в параметрах запуска клиента и в настройках Конфигуратора.

Шаг 3. Подключение из Конфигуратора

1. Запустите Конфигуратор с нужной информационной базой на сервере.
2. Поставьте точку останова (клавиша F9) в серверной процедуре или функции.
3. В меню «Отладка» выберите запуск 1С:Предприятия с отладкой или подключение к уже запущенному приложению.
4. Воспроизведите действие в клиенте. Выполнение остановится на точке.

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

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

ТЖ включается файлом, а не службой, поэтому перезапуск не нужен. Платформа перечитывает конфигурацию примерно раз в минуту.

Куда класть logcfg.xml

В каталог conf установленной платформы. На Windows это обычно C:\Program Files\1cv8\conf\, на Linux — каталог conf внутри каталога установки 1cv8. Если файла нет, создайте.

Минимальный рабочий пример

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

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

• location — каталог, куда пишутся логи. У пользователя, от имени которого работает служба (на Windows часто USR1CV8, на Linux usr1cv8), должны быть права на запись.
• history — сколько часов хранить файлы. Старые удаляются сами.
• EXCP — исключения. С этого события удобно начинать поиск ошибок.
• <property name="all"/> — писать все свойства события.

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

Для поиска долгих операций добавляйте фильтр по длительности: условие ge по свойству duration. Значение задаётся в микросекундах, то есть 1 000 000 — это одна секунда.

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

Три готовых сценария для технологического журнала

Один и тот же logcfg.xml может содержать несколько блоков <log> с разными каталогами. Так не придётся перелопачивать один гигантский файл.

Сценарий 1. Ловим ошибки сервера

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

Сценарий 2. Ищем блокировки

Для жалоб вида «Превышено время ожидания блокировки» включите три события сразу:

<log location="D:\1c_logs\locks" history="48">
  <event><eq property="name" value="TLOCK"/></event>
  <event><eq property="name" value="TTIMEOUT"/></event>
  <event><eq property="name" value="TDEADLOCK"/></event>
  <property name="all"/>
</log>

В записи TTIMEOUT видно, кто ждал и кого, а в TLOCK — какие именно данные были заблокированы. Сопоставьте время с жалобой пользователя, и круг подозреваемых сузится до одного-двух документов.

Сценарий 3. Разбираем медленную операцию

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

Чек-лист перед включением на рабочем сервере

Утилита rac: что можно сделать из командной строки

Отладку она не включает, но помогает увидеть картину на сервере. Администрирование идёт через сервер администрирования ras, а rac — это клиент к нему.

1. Запустите ras cluster с указанием адреса агента (например, localhost:1540). Порт по умолчанию для ras — 1545.
2. Узнайте идентификатор кластера: rac cluster list.
3. Посмотрите сеансы: rac session list --cluster=<идентификатор>.
4. Посмотрите рабочие процессы: rac process list --cluster=<идентификатор>.

Зачем это при отладке: по списку сеансов видно, какой из них зависший, а по списку процессов — какой rphost его обслуживает. Идентификатор процесса пригодится, потому что каталоги ТЖ называются по имени процесса и его номеру (rphost_1234). Остальные подкоманды смотрите в справке rac help.

Как читать логи

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

Практический порядок поиска:

1. Откройте самый свежий файл EXCP и найдите время ошибки.
2. Возьмите значение свойства Descr — там текст исключения.
3. Найдите в соседних логах (CALL, DBMSSQL) строки с тем же значением t:connectID, чтобы понять, из какого сеанса и по какой операции пришла ошибка.
4. Для долгих запросов отсортируйте строки DBMSSQL по длительности и посмотрите текст запроса.

Вручную читать гигабайты неудобно. Подойдёт grep на Linux, findstr или PowerShell на Windows, а при регулярной работе — специальные программы разбора ТЖ. Но они ничего не заменяют: нужно понимать, что вы ищете.

Что делать с типичными проблемами

• Точки останова не срабатывают. Сервер запущен без -debug или Конфигуратор подключился к другому серверу отладки. Проверьте ключ в службе и адрес dbgs.
• Отладчик не подключается. Проверьте версию платформы клиента и порты. Брандмауэр часто режет 1550 или диапазон рабочих процессов.
• Логи не появляются. Ошибка в XML (незакрытый тег, лишний символ в начале файла), нет прав на каталог location или файл лежит не в том conf. Подождите минуту: платформа перечитывает файл не мгновенно.
• Диск заполнился. Слишком широкий фильтр. Остановите ТЖ (см. ниже), очистите каталог и верните узкие условия.
• Сервер стал медленнее. Включённая отладка и подробный ТЖ нагружают его. Держите их только на время диагностики.

Журнал регистрации и ТЖ: в чём разница

Журнал регистрации — это внутренний журнал базы, он открывается из самой 1С и хранит действия пользователей: вход, изменение документов, ошибки. ТЖ — журнал платформы на уровне сервера, он ничего не знает о бизнес-смыслах, зато показывает вызовы, запросы и блокировки. Если нужно выяснить, кто провёл документ, смотрите журнал регистрации. Если нужно выяснить, почему проведение длилось две минуты, нужен ТЖ.

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

Как выключить отладку и не оставить мусор

Для технологического журнала достаточно убрать logcfg.xml из каталога conf или закомментировать блок <log>. Через минуту запись остановится. Уже записанные файлы удалите вручную, когда закончите анализ.

Для пошаговой отладки уберите -debug из строки запуска службы и перезапустите её. Предупредите пользователей: сеансы прервутся.

Что ещё стоит сделать после диагностики:

• сохраните копию рабочего logcfg.xml под понятным именем в другой папке, чтобы в следующий раз не писать с нуля;
• проверьте, что каталог ТЖ не растёт;
• верните права и порты в прежнее состояние, если меняли их ради отладки.

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