Анализ технологического журнала 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 г.