1 октября 2026 года «ИТ-Экспертиза» представила «Умный мониторинг» 1.6. Журнал теперь показывает время с точностью до микросекунд, а раздел анализа 1С умеет работать с дампами и замерами производительности.

Для ИТ-руководителя смысл обновления не в ещё одном дашборде. Версия 1.6 помогает отделить нехватку процессора, памяти или дисков от проблем платформы 1С и СУБД. Сам сервер она не ускоряет и готовую конфигурацию для закупки не выбирает.

Коридор аномалий отделяет новый режим работы от разового всплеска

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

Инженер сопоставляет показатели серверов

В версии 1.6 механизм анализа первопричин строит коридор поведения объектов с помощью регрессионного анализа. Система ищет связи между метриками и позволяет исключать отдельные периоды из обучения модели. Например, из базовой линии можно убрать аварию, тест миграции или регламентную обработку.

Дальше нужен инженерный разбор. Рост времени вызова сопоставляют с загрузкой rphost, очередями к рабочим процессам, памятью, дисковым вводом-выводом СУБД и задержками сети. Такой набор показателей приводит к проверяемому выводу:

процессор долго держится у предела одновременно с ростом очередей — проверяй частоту и число ядер;
время отклика дисков растёт вместе с запросами СУБД — проверяй массив, контроллер и накопители;
ресурсов хватает, но задерживается один вызов 1С — покупка нового сервера может ничего не изменить;
выброс пришёлся на исключительное событие и больше не повторился — закладывать его в конфигурацию рано.

Перечень метрик основан на методике специалиста «Кодерлайн» Евгения Романюка: на уровне 1С он предлагает смотреть CPU, память, соединения, вызовы и очереди, на уровне СУБД — дисковую активность, блокировки и время запросов, на уровне ОС и сети — общую загрузку ресурсов, задержки и потери пакетов.

Дамп и трассировка отделяют ошибку платформы от нехватки железа

«Умный мониторинг» 1.6 загружает, разбирает и экспортирует дампы платформы 1С. Трассировка показывает время событий с точностью до микросекунд, а отдельный монитор собирает счётчики производительности 1С. Эти функции перечислены в описании релиза «ИТ-Экспертизы».

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

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

Один алерт ничего не доказывает. Для закупки нужна повторяемая связь: одна и та же нагрузка, один и тот же дефицит ресурса, сопоставимый результат в нескольких прогонах.

Лицензии и расписания убирают ложные аппаратные диагнозы

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

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

Перед расширением кластера проверь, действительно ли пользователям не хватает CPU или памяти. Если новые сеансы не открываются, сначала исключи проблему с пулом: вот способы проверить доступные лицензии 1С.

Версия 1.6 не заменяет нагрузочный тест

«ИТ-Экспертиза» не приводит в описании релиза системные требования версии 1.6, её расход CPU и памяти, объём служебных данных и нагрузку на диски. По перечню новых функций нельзя рассчитать сервер ни для самого комплекса, ни для 1С.

Кандидата на замену проверяют отдельным воспроизводимым сценарием. В опубликованном на Infostart испытании стенд моделировал 100, 1 000 и 10 000 пользователей. Сценарий на 1 000 пользователей включал 30 минут нагрузки и показывал в среднем 12 000 операций в минуту — 360 000 операций за один прогон. Полный цикл занимал 7 часов.

Эти цифры описывают тот стенд и ту методику. Они не характеризуют «Умный мониторинг» 1.6 и не доказывают, что любой сервер выдержит 1 000 пользователей.

Спецификация под задачу

Здесь нужна не выдуманная модель процессора, а проверяемая спецификация испытания. Считаем для контура на 1 000 пользователей с целевой нагрузкой 12 000 операций в минуту — это исходные данные опубликованного сценария Infostart.

Сервер-кандидат: та же модель CPU, объём ECC RDIMM, дисковый массив и сетевые адаптеры, которые поставщик предлагает для продуктивного контура. Иначе тест проверит другое железо.
Нагрузка: 1 000 сеансов, 30 минут, 12 000 операций в минуту. Расчёт: 12 000 × 30 = 360 000 операций за прогон.
Диски: рабочая база и журналы СУБД размещены так же, как в проектной конфигурации. Если в закупке указан RAID10 из четырёх NVMe, стенд должен повторять RAID10 из четырёх NVMe, а не один локальный SSD.
Память: объём равен проектному. Сокращать его на стенде нельзя: изменятся кэш СУБД и профиль дисковой нагрузки.
Сеть: та же скорость соединения между сервером приложений и СУБД, что заложена в проекте.
Контроль: время операций 1С, загрузка и очередь CPU, занятая память, задержка и очередь дисков, блокировки СУБД, задержки сети.

При двух прогонах сервер должен выполнить 360 000 × 2 = 720 000 операций без смены сценария. Если второй прогон заметно медленнее, ищи накопительный эффект: рост очередей, вытеснение данных из памяти, блокировки или фоновые операции. Процент допустимого отклонения назначает команда по требованиям бизнеса — в материалах исследования такого порога нет.

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

Компромисс — время. В опубликованном примере полный цикл испытаний занимал 7 часов. Зато результат показывает пропускную способность выбранной конфигурации, а не цвет индикатора на дашборде.

Что обновление меняет для закупки

Переходить на версию 1.6 имеет смысл, если команде не хватает цепочки «аномалия → связанные метрики → вызов или дамп 1С». Именно её расширяет релиз: коридор поведения, корреляция показателей, дампы, трассировка и счётчики производительности.

Если задача — заменить сервер, действуй по другой развилке:

Зафиксируй повторяемую задержку под одинаковой нагрузкой.
Свяжи её с CPU, памятью, дисками или сетью.
Исключи ошибку платформы, СУБД и исчерпание лицензий.
Повтори нагрузку на конфигурации поставщика.
Покупай сервер, если кандидат устраняет измеренное ограничение.

Версия 1.6 даёт больше данных для диагноза, но не добавляет производительности. Сервер меняют по устойчивому дефициту ресурса под воспроизводимой нагрузкой. Требования самого комплекса стоит включать в расчёт только после публикации системных требований или собственных замеров на пилотном контуре.