AdminClusterMonitor: чему учит зависший кластер 1С в 9 утра

AdminClusterMonitor — учебный скрипт для администрирования кластера 1С:Предприятие через утилиты rac и ras: он собирает вывод консольных команд в понятные таблицы сессий, блокировок и памяти рабочих процессов. Инструмент годится, чтобы разобраться в устройстве кластера на практике, но не заменяет промышленный мониторинг с историей событий и алертами на рабочей базе.

что показывает AdminClusterMonitor: rac и ras без десяти консольных команд

В обычной работе администратор кластера 1С получает данные через две консольные утилиты: rac подключается к агенту сервера (ragent) и к серверу администрирования (ras), возвращая список кластеров, рабочих серверов и информационных баз. Чтобы увидеть, кто сейчас работает в базе, нужна отдельная команда rac session list, для блокировок объектов — rac lock list, для памяти каждого рабочего процесса rphost — ещё одна команда rac process list. Каждая возвращает набор технических полей и GUID-идентификаторов, которые нужно сопоставлять вручную: чтобы понять, какая сессия держит конкретную блокировку, приходится сверять два разных вывода по номеру процесса.

AdminClusterMonitor — учебный проект, который обычно пишут начинающие 1С-администраторы или студенты курсов по администрированию, чтобы закрепить работу с RAS API на практике. Скрипт подключается к ras, опрашивает кластер и собирает три связанные таблицы: сессии с именами пользователей и базами, блокировки с указанием заблокированного объекта и держащей его сессии, память рабочих процессов сервера. Для человека, который только осваивает администрирование кластера, разница ощутимая: вместо того чтобы помнить синтаксис трёх-четырёх команд rac, достаточно запустить один скрипт и увидеть картину целиком в одном окне.

закрытие месяца на 40 пользователях: как выглядит первое реальное применение

В компании на 40 пользователей 1С:Бухгалтерии в Москве администратор до этого работал с кластером только через AdminClusterMonitor на тестовом стенде — проходил курс и разбирался, как выглядят сессии и блокировки на учебных примерах, где всё заранее понятно. В девять утра бухгалтерия садится закрывать месяц, и база начинает подвисать: документы проводятся по минуте вместо секунд, форма закрытия месяца зависает на шаге «выполнение операции», а через десять минут звонит главный бухгалтер с вопросом, почему всё встало.

Администратор открывает знакомый скрипт уже не на тестовом стенде, а на рабочем сервере — и видит не учебный пример, а сессию одного из бухгалтеров, которая 12 минут держит блокировку на регистре накопления партий товаров. Опыт с пет-проектом помогает быстро прочитать таблицу сессий и понять, где искать проблему, но сам AdminClusterMonitor не умеет ничего, кроме показа текущего среза: он не запомнил, что происходило в 8:45, не прислал уведомление, когда блокировка превысила разумное время, и не подсказал, безопасно ли завершать сеанс принудительно.

Если бы главный бухгалтер не позвонила и не пожаловалась на зависшую базу, администратор заметил бы проблему только когда вся бухгалтерия дошла бы до него лично. Регламентированный отчёт, который нужно было отправить в этот же день, рисковал уйти с опозданием, а менеджеры не могли закрыть отгрузки, пока висела блокировка на общем регистре — обычный рабочий день компании встал на час дольше, чем нужно.

⚠️ три вещи, которые учебный скрипт не умеет — и почему это нормально

AdminClusterMonitor задуман как тренажёр, а не как система эксплуатации, поэтому у него нет функций, без которых не обходится ни один промышленный мониторинг кластера.

• ✓История событий: скрипт показывает срез состояния на момент запуска и ничего не сохраняет — через час нельзя посмотреть, что происходило с кластером в 8:45, когда всё только начало тормозить.
• ✓Оповещения: если блокировка держится 20 минут, а память рабочего процесса приближается к пределу, никто не узнает об этом, пока вручную не запустит скрипт и не посмотрит на экран.
• ✓Работа с несколькими серверами и резервированием: инструмент писался под один тестовый кластер на одной машине, а не под связку основного и резервного сервера с балансировкой нагрузки между рабочими процессами.
• ✓Автоматические действия: увидеть зависший рабочий процесс скрипт может, а корректно завершить его или перезапустить — нет, это остаётся ручной операцией администратора через ту же консоль rac.

Для обучения такие ограничения не мешают — наоборот, простой вывод без лишней автоматизации легче читать, когда структура кластера изучается впервые. Проблема начинается, когда тот же скрипт становится единственным инструментом контроля рабочей базы, на которой считают зарплату и отгружают товар.

📊 AdminClusterMonitor против штатной консоли и мониторинга на аутсорсе

Вот как выглядит разница в трёх вариантах мониторинга кластера 1С — с чем реально сталкивается администратор в каждом случае.

Разница не в том, что штатная консоль или AdminClusterMonitor «плохие» — оба показывают правильные данные. Разница в том, кто и когда на эти данные смотрит: пока это делает человек вручную раз в день, зависание в 9 утра находят по звонку из бухгалтерии, а не по автоматическому оповещению.

цена простоя: что теряет бизнес, пока кластер висит

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

Если причина не в разовой блокировке, а в устаревшем железе, ситуация повторяется каждый месяц в одно и то же время — обычно как раз в дни закрытия периода или сдачи отчётности, когда нагрузка на кластер выше обычной. Проверить, тянет ли сервер текущее число пользователей, можно тестом Гилёва — он показывает производительность именно для 1С, а не общие бенчмарки процессора. Дальше стоит свериться с официальными системными требованиями 1С: нередко кластер держат на конфигурации сервера, которая по документации рассчитана на меньшее число одновременных пользователей, чем реально работает в базе сейчас.

как перейти от пет-проекта к рабочему мониторингу кластера

Опыт с AdminClusterMonitor — хорошая точка старта, но дальше есть конкретные шаги.

1. ✓Зафиксировать, сколько сессий, памяти рабочих процессов и активных блокировок кластер держит в обычный рабочий день — это будет базой для сравнения при следующем зависании.
2. ✓Настроить постоянный мониторинг с оповещениями вместо ручного запуска скрипта раз в день — тревога должна приходить администратору, а не бухгалтерии, которая первой замечает тормоза.
3. ✓Обновлять платформу 1С регулярно: часть известных проблем с зависанием рабочих процессов закрывается именно в новых релизах платформы, и обновление 1С снимает их без доработки кластера вручную.
4. ✓Если нужен нестандартный скрипт под конкретный кластер — например, автоматический перезапуск зависшего рабочего процесса или интеграция мониторинга с внутренним чатом — это задача для доработки 1С, а не для развития учебного проекта.
5. ✓Если кластер растёт вместе с проектом — переход на 1С:ERP или 1С:Управление торговлей увеличивает число одновременных сессий кратно, и стоит заранее закладывать мониторинг в план внедрения 1С:ERP или 1С:Управление торговлей.

Мы в UKVED берём администрирование кластера на сопровождение: подключаем мониторинг, реагируем на инциденты и донастраиваем кластер под реальную нагрузку компании. Работы сисадмина и сопровождение 1С стоят от 3800 ₽/час, а если параллельно нужно понять, тянет ли текущий сервер нагрузку, начинаем с внедрения 1С — с аудита кластера, а не с продажи часов.

❓ Частые вопросы

Что такое AdminClusterMonitor и для чего он нужен 1С-администратору?

AdminClusterMonitor — учебный скрипт, который оборачивает консольные команды rac и ras в понятные таблицы сессий, блокировок и памяти рабочих процессов кластера 1С. Он помогает разобраться в структуре кластера на практике, без заучивания синтаксиса консольных утилит, но не хранит историю и не отправляет оповещения об инцидентах.

Можно ли использовать AdminClusterMonitor на рабочей базе компании?

Технически да — скрипт просто читает данные через ras и ничего не меняет в кластере. Но как единственный инструмент контроля он не подходит: нет истории событий, нет автоматических оповещений о зависших сессиях, и администратор узнаёт о проблеме только когда сам вспомнит проверить кластер вручную.

Чем штатная консоль администрирования кластера отличается от полноценного мониторинга?

Штатная консоль показывает те же сессии, блокировки и процессы, но требует, чтобы администратор зашёл и посмотрел вручную. Полноценный мониторинг сам следит за кластером и присылает оповещение при отклонении, а также хранит журнал инцидентов — что и когда произошло, кто держал блокировку и сколько длился простой.

Сколько стоит сопровождение кластера 1С у внешнего администратора?

Работы сисадмина и сопровождение 1С в UKVED стоят от 3800 ₽/час — сюда входит настройка мониторинга, реакция на инциденты и донастройка кластера под реальную нагрузку. Стоимость зависит от объёма задач: разовая диагностика зависания обходится дешевле регулярного дежурства по кластеру.

Как понять, что кластер тормозит из-за блокировок, а не из-за слабого сервера?

Если в AdminClusterMonitor или консоли видна конкретная сессия, которая держит блокировку объекта несколько минут подряд — дело в блокировке, и решение в бизнес-логике или параллельности операций. Если блокировок нет, а память рабочих процессов и очередь сессий стабильно высокие — проверьте сервер тестом Гилёва и сверьте с системными требованиями 1С.