Как настроить контроль доступности 1С и отслеживать зависания базы?

В распределенных компаниях с филиальной сетью нередко возникает ситуация, когда пользователи жалуются на то, что программа «зависла», а системные службы и стандартные средства мониторинга фиксируют штатную работу серверов. При этом сетевой пинг проходит без потерь, рабочие процессы rphost присутствуют в диспетчере задач, процессор не загружен, но информационная база перестает отвечать на запросы клиентов. Рассмотрим причины такого поведения платформы и подробно разберем практические способы организации сквозного мониторинга доступности 1С.

Выясним причины «скрытых» зависаний платформы 1С

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

1. Блокировки службы лицензирования. Процессы rphost периодически проверяют наличие лицензий. При кратковременных сбоях сети, задержках DNS или исчерпании пула лицензий рабочие процессы встают в режим синхронного ожидания ответа от сервера лицензирования, не потребляя ресурсы процессора.
2. Задержки аутентификации в домене. При использовании Windows-аутентификации (Active Directory/NTLM) задержки ответов контроллера домена приводят к зависанию новых сеансов на этапе первоначального подключения.
3. Исчерпание динамических портов (TCP Port Exhaustion). При большом числе кратковременных подключений между кластером 1С, веб-сервером и СУБД заканчиваются свободные исходящие TCP-порты, из-за чего кластер не может открыть новые сокетные соединения.
4. Ожидание блокировок на уровне СУБД. Долгие системные транзакции или скрытые дедлоки на системных таблицах базы данных могут блокировать дальнейшее обслуживание пользовательских сеансов.
5. Некорректный перезапуск рабочих процессов кластера. Если настроен автоматический перезапуск процессов по объему памяти или времени жизни, процесс может зависнуть в переходном состоянии завершения, если внутри него остался сеанс с открытой транзакцией или блокировкой.

Способ 1. Использование встроенных веб-сервисов и легковесных HTTP-сервисов

Разберем вариант проверки отклика приложения с помощью сервисов, опубликованных на веб-сервере (IIS или Apache). Это позволяет внешней системе мониторинга (например, Zabbix) с заданным интервалом запрашивать состояние базы данных.

В конфигурациях на базе «Библиотеки стандартных подсистем» (включая «1С:Управление торговлей», начиная с редакций 11.3) присутствует встроенный SOAP-веб-сервис RemoteControl с методом GetCurrentState. Этот метод выполняет элементарную операцию проверки работоспособности сеанса и возвращает значение Истина. Данный сервис разрабатывался для интеграции с подсистемами ЦКК (Центр контроля качества), но его можно опрашивать любым внешним HTTP-клиентом.

Однако стандартные SOAP-сервисы требуют формирования и парсинга XML-пакетов, что создает лишнюю нагрузку при частом опросе. Более эффективное решение — создание собственного легковесного HTTP-сервиса, возвращающего статус без сложного контекста. Рассмотрим пример реализации простого обработчика для точки доступа /hs/healthcheck:

Функция ПроверитьДоступность(Запрос)
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "text/plain; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки("OK");
    Возврат Ответ;
КонецФункции

На стороне системы мониторинга Zabbix настраивается элемент данных типа «Веб-проверка» (Web Monitoring) или запуск скрипта через утилиту curl. Если в течение заданного таймаута (например, 3–5 секунд) сервер не возвращает код 200, система фиксирует инцидент и отправляет оповещение администратору.

Способ 2. Сквозной синтетический мониторинг (робот-клиент)

Опрос HTTP-сервиса показывает только доступность веб-сервера и способность платформы выделить сеанс. Он не позволяет проверить работу пользовательского интерфейса, получение клиентских лицензий и прохождение полной сквозной авторизации. Для детальной проверки разберем запуск синтетического теста с помощью тонкого клиента 1С.

По расписанию (например, каждые 3–5 минут) из планировщика задач запускается отдельный процесс тонкого клиента под специальным технологическим пользователем. Запуск осуществляется через командную строку с ключами автоматизации:

1cv8c.exe ENTERPRISE /S "Server1C\TradeBase" /N "MonitoringRobot" /P "SecurePass123" /Execute "C:\Monitoring\HealthCheck.epf" /DisableStartupMessages

Внутри внешней обработки HealthCheck.epf в модуле формы или объекта реализуем проверку базовых операций информационной базы:

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

Если процесс не успел завершиться в течение контрольного времени (например, 30–60 секунд), внешний скрипт принудительно убивает зависший процесс тонкого клиента и передает в Zabbix статус ошибки. Это дает стопроцентное подтверждение реальной недоступности базы со стороны пользовательских рабочих мест.

Способ 3. Мониторинг кластера серверов через RAS и RAC

Чтобы понять, что именно происходит внутри зависшего кластера, подключим мониторинг служебных процессов без входа в саму информационную базу. Для этого используется служба удаленного администрирования ras и консольная утилита rac.

С помощью утилиты rac периодически запрашиваются ключевые метрики кластера:

1. Доступность менеджера кластера rmngr: опрос списка кластеров и рабочих процессов подтверждает, что служба кластера не заблокирована внутренними ошибками.
2. Состояние рабочих процессов rphost: анализ показателей потребления памяти и количества соединений на каждый процесс.
3. Список активных и спящих сеансов: выявление зависших фоновых заданий и соединений, находящихся в состоянии сна дольше порогового значения.

Параллельно в Zabbix рекомендуется снимать системные счетчики производительности (Performance Counters) операционной системы: число дескрипторов (handles) и потоков (threads) в процессах rphost.exe, а также счетчики дисковой очереди и сетевых подключений TCP Established.

Рекомендации по настройке кластера для предотвращения зависаний

Для минимизации риска зависаний настроим параметры кластера в консоли администрирования 1С:

1. Изоляция информационных баз: в свойствах кластера рекомендуется задать параметр Количество ИБ на один рабочий процесс = 1. Это гарантирует, что сбой или зависание одной базы данных не повлияет на работу соседних систем.
2. Ограничение времени жизни спящих сессий: установим параметры Время засыпания пассивных сеансов (например, 1200 секунд) и Время завершения спящих сеансов (120 секунд), чтобы разорванные филиальные соединения не удерживали лицензии и блокировки.
3. Автоматический перезапуск процессов: укажем корректный Допустимый объем памяти рабочих процессов и Интервал превышения допустимого объема памяти, чтобы исключить утечки оперативной памяти при интенсивной работе.
4. Контроль через технологический журнал: настроим минимальный сбор технологического журнала на события EXCP (исключительные ситуации) и SDBL/TLOCK (длительные ожидания на блокировках) с порогом более 20–30 секунд для оперативного анализа причин зависания.

Комбинация легкого HTTP-сервиса для частых проверок отклика и синтетического теста через тонкий клиент обеспечивает точный контроль доступности 1С и позволяет накапливать объективную статистику по филиалам без опоры на субъективные отзывы пользователей.