В практике администрирования серверов 1С часто возникает ситуация, когда системные службы ragent, rmngr, rphost и сервер СУБД запущены и потребляют стандартный объем ресурсов, но пользователи не могут зайти в конкретную базу. Причиной могут быть монопольные блокировки метаданных, зависания сеансов, исчерпание лицензий или установленная блокировка начала сеансов. Разберем основные подходы к организации надежного мониторинга доступности баз.
Один из классических способов проверить возможность авторизации — попытка создания подключения через внешний COM-коннектор. Выясним, как правильно реализовать данный механизм, чтобы не тратить лишние ресурсы.
Посмотрим на пример базового скрипта проверки:
Попытка
V8 = Новый COMОбъект("V83.COMConnector");
СтрокаПодключения = "Srvr=""Server1C"";Ref=""Trade"";Usr=""MonitorUser"";Pwd=""SecretPass"";";
Соединение = V8.Connect(СтрокаПодключения);
// Выполняем тестовый минимальный запрос к данным
Запрос = Соединение.NewObject("Запрос");
Запрос.Текст = "ВЫБРАТЬ 1 КАК Тест";
Выборка = Запрос.Выполнить().Выбрать();
Соединение = Неопределено;
Исключение
ОписаниеОшибки = ОписаниеОшибки();
// Обрабатываем ошибку и отправляем алерт
КонецПопытки;
Проанализируем тонкости использования этого метода:
V83.COMConnector занимает клиентскую лицензию на время своей работы.Подъем полноценного клиента или COM-интерфейса при проверке десятков баз создает существенную нагрузку на сервер. Более производительный и современный подход — публикация базы на веб-сервере с отдельным сервисом проверки состояния.
Разберем по шагам реализацию проверки через HTTP-сервис:
/health).GET выполняем чтение одной константы или простой запрос к базе данных, чтобы убедиться в отзывчивости СУБД.200 OK при успешном выполнении и 500 Internal Server Error в случае ошибки.Если разработка собственного сервиса невозможна, можно задействовать стандартный интерфейс OData, опубликовав базу и выполняя периодический опрос адреса /odata/standard.odata/$metadata или таблицы с лимитом $top=1.
Чтобы исключить зависимость от прав пользователей и расход клиентских лицензий, рассмотрим опрос состояния кластера через сервис администрирования ras и консольную утилиту rac. Данный метод является кроссплатформенным и одинаково эффективно работает как на Windows, так и на Linux.
Разберем последовательность действий при мониторинге через консоль:
ras для целевого кластера 1С.rac infobase --ib=<ИдентификаторБазы> info.sessions-denied (блокировка сеансов включена) и scheduled-jobs-denied (блокировка регламентных заданий).Рассмотрим вариант архитектуры мониторинга, когда не сервер мониторинга опрашивает базы, а сами информационные базы отправляют отчет о своем состоянии наружу. Для этого в базу добавляется регламентное задание, выполняющееся каждые 2–5 минут.
Задание обращается к внешнему веб-сервису или передает метрику в систему мониторинга (например, через утилиту zabbix_sender). Если внешний сервис не получает подтверждение активности («heartbeat») в течение заданного окна времени, генерируется алерт о недоступности базы.
Важное ограничение: учитывайте, что при установке флага «Блокировка регламентных заданий» (например, во время регламентных процедур) фоновые задачи перестают запускаться. В этом случае мониторинг выдаст ложное срабатывание, даже если интерактивный вход в базу для пользователей остается доступным.
Для комплексного мониторинга крупных инфраструктур с десятками баз оптимально использовать инструмент «1С:Центр контроля производительности» из состава «1С:Корпоративный инструментальный пакет» (1С:КИП). Он позволяет из единого центра отслеживать не только доступность базы, но и расход оперативной памяти процессами rphost, количество активных сеансов, взаимные блокировки в СУБД и счетчики производительности без необходимости ручной поддержки скриптов.