Бухгалтер проводит документ и ждёт. Внутри виртуальной машины процессор свободен, памяти хватает, ошибок 1С нет. Перезапускать кластер рано: задержка может возникнуть на физическом хосте, которого гостевая Windows не видит.
Чтобы найти причину до перезапуска 1С, проверяйте систему по маршруту: виртуальная машина, гипервизор, физический хост, компоненты 1С и СУБД. Один график загрузки процессора этот маршрут не заменит.
Почему внутри виртуальной машины всё выглядит исправным
Гостевая ОС не обращается к диску и сетевой карте напрямую. По описанию архитектуры Hyper-V в Microsoft Learn, дочерняя секция работает с виртуальными устройствами.
Запрос ввода-вывода принимает клиент службы виртуализации VSC. Затем VMBus передаёт его поставщику VSP в родительской секции. Только после этого запрос попадает к физическому устройству.
Для гостевой ОС этот путь прозрачен. Она видит свой виртуальный диск, но не обязательно видит очередь на общем хранилище. По той же причине свободный виртуальный процессор ещё не говорит, что физические ядра хоста справляются с нагрузкой остальных машин.
На одном хосте могут работать сервер 1С, СУБД, терминальный сервер и вспомогательные службы. Гипервизор изолирует их операционные системы, но оборудование остаётся общим. Несколько ВМ конкурируют за процессорное время, память и дисковый ввод-вывод.
| Что видит администратор | Где может возникнуть задержка | Где проверять |
|---|---|---|
| CPU гостевой ОС загружен слабо | Физические ядра заняты другими ВМ | Счётчики процессора хоста и распределение нагрузки между ВМ |
| В гостевой ОС хватает свободной памяти | Хост испытывает нехватку памяти или меняет её распределение | Память хоста, Assigned Memory и параметры динамической памяти |
| Виртуальный диск отвечает нестабильно | Очередь возникла на физическом накопителе или общем хранилище | Задержки чтения и записи на хосте, состояние VHD или VHDX |
| Одна ВМ перестала отвечать | Сбой затронул её рабочий процесс VMWP или канал интеграции | Состояние ВМ, VMWP и службы интеграции Hyper-V |
| Несколько ВМ остановились одновременно | Нарушена работа хоста или службы управления ВМ | Состояние VMMS, хоста и общей дисковой подсистемы |
Проверка одной гостевой ОС не отделяет сбой 1С от конкуренции нескольких ВМ за общее оборудование.
Один сбой хоста даёт разные жалобы в 1С
Задержка физического диска блокирует обращения к базам внутри ВМ. Пользователь при этом видит зависший документ, медленный отчёт или долгий вход. Эти симптомы похожи на сбой платформы, хотя очередь появилась до запроса к СУБД.
При нехватке памяти картина меняется. В одной ВМ растёт подкачка, другая получает меньше динамической памяти, а третья продолжает работать без заметных отклонений. Жалобы приходят от одного отдела, хотя причина общая для хоста.
Перегруженный процессор тоже не обязан замедлять все ВМ одинаково. Результат зависит от распределения виртуальных процессоров и соседней нагрузки. Поэтому среднее значение CPU по хосту скрывает перекос между машинами.
Отдельная область проверки — службы Hyper-V. Microsoft Learn указывает, что VMMS управляет состоянием дочерних ВМ. Для каждой работающей машины служба создаёт отдельный процесс VMWP.
Если проблема затронула один VMWP, сбой остаётся локальным. Если остановилась VMMS, под угрозой оказываются все машины хоста. Сторонние списки идентификаторов Event Log здесь не помогут: без документа Microsoft для нужной версии нельзя считать диапазон событий точной расшифровкой.
Канал интеграции тоже влияет на диагностику. Через него Hyper-V получает сведения от гостевой ОС, включая пульс и время работы. Сбой канала не доказывает остановку 1С, но объясняет, почему хост перестал получать состояние машины.
Собирайте данные с хоста и из гостевой ОС
Первый слой мониторинга охватывает физический хост и гипервизор. Здесь нужны загрузка процессора, распределение памяти, дисковые операции, состояние ВМ и служб управления.
Второй слой работает внутри каждой ВМ. Он показывает нагрузку конкретной гостевой ОС, процессы сервера 1С, состояние СУБД, блокировки и фоновые задания.
Эти слои отвечают на разные вопросы. Хост показывает, получил ли сервер 1С обещанные ресурсы. Гостевая ОС показывает, как ими распорядились платформа и СУБД.
Если 1С работает на Linux с PostgreSQL, маршрут можно продолжить через iowait, память, процессы 1С и состояние PostgreSQL. Для Windows те же уровни остаются, но инструменты сбора будут другими.
| Уровень | Метрика или событие | Какой сбой помогает отделить | Действие администратора |
|---|---|---|---|
| Физический хост | Загрузка CPU и распределение по ядрам | Перегрузку одной ВМ от общей нехватки процессорного времени | Сопоставить нагрузку хоста с нагрузкой всех активных ВМ |
| Физический хост | Память хоста | Нехватку памяти хоста от утечки внутри одной гостевой ОС | Проверить распределение памяти и параметры активных машин |
| Хранилище | Операции чтения и записи, задержка диска | Медленную СУБД от очереди на физическом накопителе | Найти ВМ, которая создаёт нагрузку, и проверить состояние хранилища |
| Гипервизор | Состояние Running, Off, Saved, Paused, Starting или Stopping | Остановку ВМ от зависания приложения внутри неё | Зафиксировать состояние до перезапуска и проверить события хоста |
| Виртуальная машина | CPU, RAM, диск и сеть | Общий сбой хоста от проблемы одной гостевой ОС | Сравнить показатели с соседними ВМ за тот же период |
| Hyper-V | VMMS, VMWP и службы интеграции | Сбой управления ВМ от остановки 1С | Проверить область отказа: одна машина или весь хост |
| Сервер 1С | Рабочие процессы, сеансы и блокировки | Проблему платформы от нехватки ресурсов ниже неё | Перейти к контролю через консоль кластера |
| СУБД | Активные запросы, блокировки и фоновые операции | Ожидание базы от задержки гипервизора | Сопоставить время события с показателями диска и памяти |
Уведомление должно называть не только симптом, но и хост либо ВМ, где он появился.
Не копируйте пороги из чужой инфраструктуры
Универсального порога CPU, памяти или дисковой задержки для сервера 1С нет в представленных данных. Допустимое значение зависит от конфигурации, числа ВМ, СУБД и обычной нагрузки компании.
Сначала соберите историю своей системы. Отметьте периоды закрытия месяца, обменов, резервного копирования и фоновых заданий. Затем сравнивайте новые отклонения с этим режимом, а не со случайным числом из чужой статьи.
Порог без контекста создаёт две ошибки. Слишком высокий пропускает постепенное ухудшение. Слишком низкий засыпает администратора уведомлениями, после чего тот перестаёт их читать.
Полезный алерт содержит четыре элемента: метрику, объект, время начала и текущее состояние. Сообщение «высокая нагрузка» не помогает. Запись «узел HV-02, ВМ SQL-01, выросла задержка записи» сразу задаёт следующий шаг проверки.
Отдельные правила нужны для событий. Остановка ВМ, повреждение её состояния, ошибка миграции или резервного копирования требуют уведомления независимо от средней нагрузки CPU.
Что смотреть в Hyper-V
Для Hyper-V начинайте со штатных средств. Hyper-V Manager показывает состояние ВМ и выделенную память. Perfmon раскрывает счётчики хоста и гостевых машин. WMI подходит для централизованного сбора и автоматических проверок.
Проверяйте Assigned Memory вместе с режимом выделения памяти. При статической настройке объём фиксирован. При динамической действуют параметры Startup, Minimum и Maximum RAM. Одного текущего значения мало без понимания этих границ.
Загрузку виртуального процессора сопоставляйте с процессором хоста. Если одна ВМ показывает рост, а соседние работают в прежнем режиме, переходите внутрь гостевой ОС. Если нагрузка меняется у нескольких машин, сначала проверяйте хост.
С дисками действует тот же принцип. Размер VHD или VHDX не описывает скорость хранилища. Нужны операции чтения и записи, задержка и связь с нагрузкой других ВМ.
Перед перезапуском сохраните исходную картину: состояние ВМ, показатели хоста и время жалобы. Иначе после запуска вы увидите исправную систему, но потеряете данные о причине.
Что смотреть в KVM и VMmanager
Для KVM и LXC набор метрик остаётся тем же, хотя названия инструментов меняются. По описанию мониторинга VMmanager от ISPsystem, платформа собирает CPU, RAM, STORAGE, IOPS и сетевой трафик на уровне гипервизора.
VMmanager хранит историю по ВМ и физическим узлам. В карточке машины видны её состояние и статистика. Карточка узла связывает нагрузку с размещёнными на нём ВМ.
Уведомления можно отправлять в интерфейс, по электронной почте или через Telegram. Правила охватывают пороги ресурсов и события: недоступность сервера, повреждение ВМ, ошибки миграции и резервного копирования.
Если в компании уже работает единая система наблюдения, данные VMmanager можно передать в Zabbix или Grafana. API пригодится для собственного сборщика. Отдельный дашборд имеет смысл только тогда, когда он сокращает маршрут от сигнала до объекта сбоя.
Саму виртуальную среду нужно подготовить до настройки уведомлений. Для KVM можно свериться с порядком настройки Proxmox VE под сервер 1С. Числа производительности из соседнего материала переносить нельзя: другая конфигурация даст другой результат.
Как выбрать инструмент мониторинга
Не сравнивайте Hyper-V и VMmanager как продукты одного класса. Первый случай опирается на штатные средства Windows и архитектуру Hyper-V. Второй относится к управлению средой KVM и LXC.
Выбирайте место сбора данных по своей платформе. Для Hyper-V берите Perfmon, WMI и состояние ВМ из средств Microsoft. Для VMmanager используйте его метрики узлов и машин, а общую визуализацию отдавайте существующей системе.
| Среда | Откуда брать данные | Что вынести в уведомление | Когда нужна внешняя система |
|---|---|---|---|
| Hyper-V | Hyper-V Manager, Perfmon, WMI | Хост, ВМ, состояние, CPU, память и диск | Когда несколько хостов нужно видеть в одном окне |
| VMmanager | Дашборды ВМ и узлов, события платформы | Узел, ВМ, ресурс или ошибка задания | Когда данные уже собирает Zabbix либо Grafana |
| Смешанная среда | Сборщики каждой платформы | Единые имена объектов и уровень сбоя | Когда дежурный не должен переключаться между консолями |
| Одна ВМ с 1С | Средства гипервизора и гостевой ОС | Состояние ВМ и отклонение ресурса | Когда уведомления нужны вне рабочего времени |
Инструмент подходит, если по его уведомлению вы находите нужный хост и ВМ без ручного обхода всех консолей.
Вопрос о самой схеме размещения нужно решать отдельно. Материал о физическом сервере и виртуальной машине поможет выбрать платформу, но не заменит мониторинг уже работающей среды.
Маршрут проверки при следующем торможении 1С
Зафиксируйте время жалобы и состояние нужной ВМ. Не начинайте с перезапуска рабочих процессов: он стирает часть диагностической картины и может временно скрыть причину.
Дальше пройдите один маршрут:
- Проверьте CPU, память, диск и сеть внутри гостевой ОС.
- Сопоставьте их с процессором, памятью и дисковыми операциями хоста.
- Посмотрите, изменились ли показатели соседних ВМ.
- Для Hyper-V проверьте VMMS, VMWP нужной машины и службы интеграции.
- Затем переходите к рабочим процессам 1С, сеансам, блокировкам и СУБД.
Если симптом остался внутри одной ВМ, ищите причину в гостевой ОС, 1С или СУБД. Если одновременно изменились несколько машин, начинайте с хоста, хранилища и служб гипервизора.
Готовый мониторинг отвечает на три вопроса ещё до звонка бухгалтера: на каком уровне начался сбой, какой объект затронут и какая метрика отклонилась. Числовые пороги настройте по истории своей нагрузки — чужие значения здесь только маскируют причину.