Мониторинг кластера 1С: практикум по созданию собственного инструмента | infolimp.ru

Мониторинг кластера 1С: практикум по созданию собственного инструмента

30 августа 2026 · infolimp.ru

Консоль администрирования кластера 1С даёт мгновенный срез, но не позволяет увидеть динамику нагрузки, тренды и аномалии. Готовые системы мониторинга (Zabbix, PRTG) требуют настройки агентов и часто не учитывают специфику 1С. За полдня можно собрать собственный инструмент мониторинга кластера на чистом 1С, который будет собирать историю сессий, блокировок и производительности, а главное — покажет ловушку, в которую попадают 90% разработчиков: неправильная интерпретация данных о времени ожидания.

Почему стандартных средств недостаточно

Консоль администрирования кластера (RAS) показывает текущее состояние: количество сессий, занятость рабочих процессов, блокировки. Но для анализа производительности этого мало. Вы не увидите, как менялась нагрузка за последний час, какие сессии «зависали» и сколько длились пики. Журнал регистрации фиксирует события, но не даёт агрегированных метрик по кластеру в целом.

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

Готовые системы мониторинга (Zabbix, PRTG) умеют опрашивать RAS через COM или REST, но требуют установки агентов на сервер и настройки шаблонов. Для небольших и средних внедрений это избыточно. Кроме того, они не дают гибкости в анализе: вы не сможете быстро построить отчёт «Топ-10 сессий по времени ожидания» прямо из 1С.

Архитектура самописного монитора

Инструмент состоит из трёх частей:

  1. Сборщик — регламентное задание, которое через заданный интервал (например, 1 минута) опрашивает кластер и записывает данные в регистры сведений.
  2. Хранилище — набор регистров сведений (периодических) для хранения истории сессий, блокировок, производительности рабочих процессов.
  3. Отчёты — обработки для визуализации: графики, таблицы, дашборды.

Сбор данных выполняется через COM-объект V83.COMConnector (или через REST API сервера администрирования, если он доступен). Ниже приведён пример получения списка рабочих процессов кластера через COM. Обратите внимание: реальные методы могут отличаться в зависимости от версии платформы, поэтому используйте документацию ИТС.

// Псевдокод — через реальный API ИТС
Процедура СобратьДанныеКластера()
    Попытка
        Connector = Новый COMОбъект("V83.COMConnector");
        // Получение объекта кластера (адрес и порт сервера администрирования)
        Cluster = Connector.ConnectWorkingProcess("tcp://server:1540");
        // Получение списка рабочих процессов
        WorkingProcesses = Cluster.GetWorkingProcesses();
        Для Каждого WP Из WorkingProcesses Цикл
            // Чтение свойств: имя, порт, занятость, количество сессий
            ЗаписьВРегистр(WP.Name, WP.SessionsCount, WP.Load);
        КонецЦикла;
    Исключение
        ЗаписьЖурналаРегистрации("Мониторинг", УровеньЖурналаРегистрации.Ошибка,,,
            "Ошибка сбора данных: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
    КонецПопытки;
КонецПроцедуры

Ловушка: время ожидания vs время выполнения

Самая частая ошибка — путать время ожидания (когда сессия ждёт освобождения ресурса) и время выполнения (когда код реально исполняется). В RAS есть метрика «Среднее время ожидания», но она усреднена по всем сессиям. Если вы собираете только её, то не увидите, что одна «тяжёлая» сессия блокирует остальные. Правильный подход — собирать индивидуальное время ожидания для каждой сессии (если API позволяет) или хотя бы гистограмму.

Предупреждение: Не используйте среднее время ожидания как единственный показатель производительности. Оно маскирует выбросы. Собирайте также максимальное и 95-й перцентиль.

Практическая реализация: от сбора данных до визуализации

Шаг 1. Создание регистров сведений

Создайте два периодических регистра сведений (режим записи «Подчинение регистратору» не нужен, так как данные будут записываться напрямую):

Периодичность — «В пределах дня» (или «Секунда», если нужна высокая точность).

Шаг 2. Регламентное задание

Создайте регламентное задание с интервалом 60 секунд. В его процедуре вызывайте сбор данных через COM (как в примере выше) или через HTTP-запрос к REST API сервера администрирования. Если REST API недоступен, используйте COM. Добавьте обработку исключений и логирование ошибок.

// Пример записи в регистр сведений
Процедура ЗаписатьДанныеСессии(ИмяСессии, ИмяРП, ВремяОжидания, ВремяВыполнения, Состояние)
    Набор = РегистрыСведений.МониторингСессий.СоздатьНаборЗаписей();
    Запись = Набор.Добавить();
    Запись.Период = ТекущаяДата();
    Запись.Сессия = ИмяСессии;
    Запись.РабочийПроцесс = ИмяРП;
    Запись.ВремяОжидания = ВремяОжидания;
    Запись.ВремяВыполнения = ВремяВыполнения;
    Запись.Состояние = Состояние;
    Набор.Записать();
КонецПроцедуры

Шаг 3. Отчёты и дашборды

Используйте СКД для построения графиков. Например, отчёт «Динамика времени ожидания» с группировкой по часам и отбором по рабочему процессу. Для оперативного мониторинга можно вывести таблицу текущих сессий с подсветкой «красных» (время ожидания > 10 секунд).

Типичные ошибки и как их избежать

Читайте также