Анализ технологического журнала 1С
Сегодня я покажу на примере, как использовать технологический журнал для расследования проблем.
У клиента возникла следующая проблема: терминалы сбора данных иногда начинали долго выполнять соединение с 1C. Предполагали, что тормозит сервер.
Проблема у клиента возникла давно, и он попробовал решить её покупкой нового оборудования — более мощного сервера. Новый сервер запустили, все прекрасно работало до обеда того же дня, после чего проблема вернулась.
Я решил не копать в сторону железа сервера, так как сервер уже поменяли, и это не дало прирост производительности. Теория с проблемами в сети так же была временно отброшена. Я решил собрать технологический журнал (ТЖ).
Сначала я собрал все EXCP (исключительные ситуации). Запустил ТЖ — он начал расти довольно быстро. События с описанием «Сеанс отсутствует или удален» сыпались постоянно, независимо от того работали пользователи с системой или нет.
Рисунок 1. События EXCP в технологическом журнале.
Я проанализировал параметр ConnectID — идентификатор соединения с информационной базой и обнаружил, что вызывает данные исключения Модуль расширения веб-сервера. Запомним в уме ConnectID = 127964.
Рисунок 2. Анализ параметров ConnectID.
Изучив информацию по проблемам с веб-сервисом на портале ИТС, я начал с помощью ТЖ собирать события:
- VRSREQUEST — запрос к серверу за некоторым ресурсом;
- VRSRESPONSE — ответ сервера.

Рисунок 3. События VRSREQUEST, VRSRESPONSE в технологическом журнале.
В собранном ТЖ я увидел постоянные запросы 1c к веб-серверу. Как я это понял: ConnectID = 127964 совпадал как у событий EXCP, так у VSRESPONSE. Причем EXCP возникали, когда веб-сервер возвращал ошибку 401 (проблема с авторизацией). Я задался вопросом, зачем 1с постоянно слать запросы на авторизацию к веб-серверу? Немного изучив баг-трекер платформы 1с, я наткнулся на интересную ошибку, которая в моей версии платформы уже была исправлена.
Рисунок 4. Ошибка при публикации базы 1С.
Я проверил настройки публикации web-сервиса. Конфигурационный файл не представлял ничего особенного. Однако сравнив его с шаблоном на портале ИТС, я обнаружил, что время жизни сеанса, которое описывалось в ошибке выше, здесь было не установлено.
Файл клиента:
<?xml version="1.0″ encoding="UTF-8″?>
<point>
<standardOdata enable="true"
reuseSessions="autouse"
sessionMaxAge="20″
poolSize="10″
poolTimeout="5″/
</ws>
//Некие настройки, которые не важны
</ws>
/point>
Структура default.vrd на ИТС выглядит так:
</point...>
<ws...>
<point.../point>
<zones>
<zone.../zone>
<zone.../zone>
</zones>
<point.../point>
</ws>
<httpServices>
<service...service/>
</httpServices>
<pool.../>
<debug.../>
<openid>
<rely... />
<provider>
<lifetime.../lifetime>
</provider>
<openid>
<openidconnect>
<exitURL>
...
</exitURL>
<standardOData.../>
</point>
Из описания на портале ИТС — элемент lifetime, указывает время жизни признака аутентификационных данных в секундах. В нашем файле публикации его не было. Я задал время жизни сеанса равное 24 часам или 86400 секунд.
<?xml version="1.0″ encoding="UTF-8″?>
<point>
<standardOdata enable="true"
reuseSessions="autouse"
sessionMaxAge="20″
poolSize="10″
poolTimeout="5″/>
<ws>
//Некие настройки, которые не важны
<ws...>
<openid>
<provider>
<lifetime>86400</lifetime>
</provider>
</openid>
</point>
Терминалы сбора данных перестали долго искать соединения, тормоза пропали — проблема была решена.
Надеюсь данный пример поможет расследовать и анализировать различные проблемы в работе платформы 1С:Предприятие.
Предлагаю также ознакомиться со статьей: «Как ИТ-руководителю выстроить службу поддержки 1С».
_______________________________________
Автор статьи: Ведущий специалист отдела разработки Мерзляков Андрей. Дата обновления статьи 31.01.2019 г.