Мониторинг гипервизора: какие метрики действительно важны

MAATRIX

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

Чем мониторинг гипервизора отличается от мониторинга обычного сервера

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

• сколько ресурсов реально потребляют все гостевые системы вместе, а не одна;
• своп самого хоста как индикатор переподписки памяти;
• состояние общего хранилища, от которого зависят разом десятки VM;
• кворум и синхронизация — если гипервизор работает в кластере;
• статус бэкапов на уровне всей инфраструктуры, а не одной машины.

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

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

Агрегированная нагрузка CPU и памяти: сумма всех VM против лимита хоста

Самая частая ошибка — смотреть на загрузку CPU и памяти внутри каждой VM по отдельности и не видеть общей картины. Гипервизор почти всегда работает с оверкоммитом: суммарно виртуалкам выделено больше vCPU и RAM, чем физически есть на хосте, в расчёте на то, что не все используют лимит одновременно. Это нормальная и экономически оправданная практика — подробный разбор, где проходит безопасная граница переподписки, есть в статье про оверкоммит CPU и памяти. Но именно поэтому агрегированную нагрузку нужно мониторить отдельно от нагрузки внутри отдельных гостей.

На Proxmox VE агрегированные данные хоста видно через pvesh:

# Суммарная загрузка узла: CPU, память, аптайм
pvesh get /nodes/pve1/status

В выводе интересны прежде всего поля cpu (доля загрузки хоста, 0.0-1.0), memory.used/memory.total и rootfs.used/rootfs.total. Это агрегат по всему хосту — сумма нагрузки от всех запущенных VM плюс сам гипервизор.

Для алертинга через Prometheus проще снять эти же цифры через node_exporter, установленный прямо на хосте гипервизора (не внутри VM), плюс отдельный pve-exporter для метрик уровня Proxmox API:

# prometheus.yml, фрагмент
scrape_configs:
  - job_name: 'hypervisor-node'
    static_configs:
      - targets: ['10.0.0.1:9100']   # node_exporter на хосте
  - job_name: 'pve'
    static_configs:
      - targets: ['10.0.0.1:9221']   # pve-exporter

Правило алерта, которое действительно ловит проблему на раннем этапе, — не порог "CPU хоста выше 90%" (это может быть кратковременный всплеск), а устойчивое превышение в течение нескольких минут:

# alert.rules.yml
groups:
  - name: hypervisor
    rules:
      - alert: HostCPUOverload
        expr: 1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0.90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Суммарная загрузка CPU хоста выше 90% дольше 10 минут"

      - alert: HostMemoryNearLimit
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Суммарное потребление памяти всеми VM приближается к физическому лимиту хоста"

Ориентир по порогам — 85-90% устойчивой загрузки CPU и памяти хоста как сигнал "пора планировать миграцию части VM или добавлять ресурсы". Точные цифры зависят от вашего профиля нагрузки: для равномерных фоновых сервисов можно держать выше, для всплесковых нагрузок (например, batch-задач) — закладывать запас пониже. Не берите эти пороги как строгий стандарт — откалибруйте по своей истории нагрузки за 2-4 недели.

Своп хоста — самый тревожный индикатор, который часто игнорируют

Это, пожалуй, главная метрика, которую путают с менее критичной. Своп внутри гостевой VM — обычное дело: гостевая ОС может подкачивать неактивные страницы, это чаще всего просто тюнинг vm.swappiness внутри гостя, некритично. Своп на уровне самого хоста-гипервизора — совсем другая история: он означает, что суммарное реальное потребление памяти всеми запущенными VM превысило физический объём RAM хоста, и ядро хоста вынуждено вытеснять страницы на диск, чтобы удержать все VM живыми. Это резко бьёт по latency сразу у всех гостей на этом хосте одновременно, а не у одной VM.

Отличать своп хоста от свопа гостя нужно явно — метрики физически разные счётчики:

# На хосте гипервизора — swap САМОГО ХОСТА
free -m
#              total   used   free  shared  buff/cache  available
# Mem:          64000  58000   1200     400        4800       5100
# Swap:          8192   1450   6742

Ненулевой и, тем более, растущий Swap: used на хосте — сигнал действовать, а не наблюдать. Если он появился недавно и продолжает расти при мониторинге раз в минуту — вы на грани переподписки памяти по факту (в отличие от переподписки "на бумаге" по выделенным лимитам VM). Здесь же уместно учитывать ballooning — механизм, которым гипервизор мягко забирает неиспользуемую память у гостей обратно на хост в момент нехватки; если вам интересно, как это устроено изнутри, у нас есть отдельный разбор ballooning памяти. Ballooning — это первая линия защиты хоста от нехватки RAM, а рост свопа хоста — сигнал, что этой линии обороны уже не хватает.

Метрика для Prometheus:

- alert: HostSwapGrowing
  expr: node_memory_SwapUsed_bytes > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Хост гипервизора начал использовать своп — суммарная память VM превысила физический RAM"

Практический совет: держите этот алерт с низким порогом (по факту — "любой ненулевой своп хоста дольше 5 минут"), а не с высоким процентом использования. Своп хоста в 200 МБ уже говорит о проблеме на уровне архитектуры (нужно либо снизить оверкоммит, либо добавить RAM, либо мигрировать часть VM на другой узел), даже если общая картина по свободной памяти выглядит терпимо.

Хранилище: единая точка отказа для всех VM разом

Если диски VM лежат на локальном SSD/NVMe хоста — проблема хранилища затрагивает VM именно этого узла. Но если используется общее хранилище — Ceph, NFS-стораж, ZFS через iSCSI, кластерный LVM — задержка и насыщенность хранилища одновременно бьют по каждой VM, которая на нём размещена, независимо от того, на каком физическом узле кластера эта VM запущена. Разные типы хранилищ по-разному реагируют на нагрузку и по-разному деградируют при проблемах — сравнение вариантов есть в статье про хранилища в Proxmox.

Метрики, которые важно снимать именно на уровне хранилища как общего ресурса:

# Для Ceph-кластера — общий health и латентность
ceph -s
ceph osd perf   # apply/commit latency по каждому OSD

# Для NFS-хранилища на стороне гипервизора-клиента
mount | grep nfs
nfsiostat 1     # RPC-задержки, ops/s, retransmits — раз в секунду

Ключевые пороги, за которыми нужно следить в первую очередь:

Числа в таблице — ориентир, откалиброванный под типичные конфигурации на HDD/SSD-микс; на чистом NVMe нормальная latency будет заметно ниже, и порог "требует внимания" стоит сдвигать соответственно вашему реальному базовому уровню задержки, замеренному в спокойный период.

Практический момент, который часто упускают: рост латентности хранилища на 20-30% может не выглядеть как авария ни для одной отдельной VM — просто "всё чуть медленнее". Но если это происходит одновременно у всех VM на хранилище, причина почти всегда общая (одна деградировавшая VM выжимает I/O, resync после отказа диска, забитый пул), и её нужно искать на уровне хранилища, а не гоняться за симптомами внутри гостей.

Кворум кластера и синхронизация узлов

Если гипервизоры объединены в кластер (Proxmox VE Cluster, ovirt/RHV, VMware vSphere HA) — статус кворума становится метрикой первого приоритета. Потеря кворума означает, что оставшиеся узлы не могут быть уверены, что они не в состоянии split-brain, и по умолчанию блокируют управляющие операции с VM — миграции, старты, остановки — пока кворум не восстановится. Зачем вообще нужен третий узел и как устроена логика голосования — подробно разобрано в статье про кворум в кластере.

Проверка статуса на Proxmox:

pvecm status
# Quorum information
# ------------------
# Date:             Fri Aug 28 14:02:11 2026
# Quorum provider:  corosync_votequorum
# Nodes:            3
# Node ID:          0x00000001
# Ring ID:          1.a3
# Quorate:          Yes

Поле Quorate: Yes/No — это то, что должно алертиться немедленно при переходе в No, а не раз в несколько минут при следующем опросе. Для Prometheus разумно опрашивать этот статус с малым интервалом (15-30 секунд) именно для этой метрики, отдельно от остальных, которые можно снимать раз в минуту:

- alert: ClusterQuorumLost
  expr: pve_node_quorate == 0
  for: 30s
  labels:
    severity: critical
    page: "true"
  annotations:
    summary: "Кластер потерял кворум — управляющие операции с VM заблокированы"

Отдельно стоит следить за синхронизацией между узлами — расхождением состояния Corosync-кольца (corosync-cfgtool -s) и, если используется Ceph как общее хранилище кластера, за статусом peering и recovery (ceph -s, поле pgs). Затянувшийся resync после возврата узла в строй — это период повышенной нагрузки на хранилище и сниженной отказоустойчивости, который тоже стоит явно видеть в дашборде, а не узнавать постфактум.

Мониторинг бэкапов на уровне инфраструктуры, а не "надежда"

Отдельная VM может "выглядеть здоровой" месяцами, пока не понадобится восстановление — и только тогда выяснится, что плановое задание бэкапа падало последние три недели. На уровне гипервизора статус бэкапов нужно смотреть не по одной VM, а сводно по всей инфраструктуре: сколько заданий должно было выполниться за сутки, сколько выполнилось успешно, сколько упало и почему. Если вы используете Proxmox Backup Server — там для этого есть штатный API и журнал заданий, подробности по настройке и восстановлению — в статье про Proxmox Backup Server.

Проверка последних заданий через API PBS:

# Список последних задач бэкапа со статусами
proxmox-backup-client task list --output-format json | \
  jq '.[] | select(.worker_type=="backup") | {id, status, endtime}'

Более практичный вариант для алертинга — не разбирать вывод вручную, а забирать метрики через pbs_exporter (или штатный /api2/json/status/datastore-usage для заполненности хранилища бэкапов) в Prometheus и строить правило "если хотя бы одно задание бэкапа за последние 26 часов завершилось со статусом, отличным от OK — алерт":

- alert: BackupJobFailed
  expr: increase(pbs_backup_job_failed_total[26h]) > 0
  labels:
    severity: critical
  annotations:
    summary: "Хотя бы одно задание бэкапа за последние сутки завершилось неудачно"

- alert: BackupDatastoreAlmostFull
  expr: pbs_datastore_used_bytes / pbs_datastore_total_bytes > 0.85
  labels:
    severity: warning
  annotations:
    summary: "Хранилище бэкапов заполнено более чем на 85% — новые задания могут начать падать"

Окно в 26 часов вместо 24 — намеренный запас, чтобы не ловить ложные срабатывания при небольшом дрейфе расписания или разовой задержке. Смысл в том, чтобы узнавать о неуспешном бэкапе в течение суток, а не в момент, когда бэкап реально понадобился для восстановления после инцидента — тогда узнавать об его отсутствии уже слишком поздно.

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