Métricas de virtualização: o que medir em VMs e hosts

As métricas de virtualização respondem a uma pergunta operacional que servidores físicos nunca enfrentaram: como o hypervisor divide o hardware entre dezenas de cargas que disputam o mesmo socket, banco de memória e array de storage. Sem essa visibilidade, a operação fica cega à degradação silenciosa que precede o ticket.

Ambientes virtualizados modernos rodam VMware vSphere, Microsoft Hyper-V, KVM e Proxmox em paralelo, muitas vezes no mesmo data center. Cada hypervisor expõe métricas com nomes diferentes, ainda que meçam o mesmo fenômeno. Sem um catálogo claro do que olhar em cada camada, alertas falham e ajustes de capacidade viram chute baseado em suposições.

Este guia organiza as métricas de virtualização por camada (host físico, hypervisor, VM/guest, storage compartilhado e rede virtual), explica os thresholds que sinalizam contenção real e mapeia os nomes equivalentes entre VMware, Hyper-V e KVM. Em seguida, percorre os erros comuns que tornam dashboards bonitos mas inúteis na prática operacional diária.

O que são métricas de virtualização e por que diferem de servidores físicos

Métricas de virtualização medem como o hypervisor compartilha recursos físicos entre múltiplas máquinas virtuais. No servidor físico tradicional, basta acompanhar CPU, memória, IOPS e rede. No ambiente virtualizado, esses números precisam de cruzamento entre host e guest, porque o sistema operacional dentro da VM enxerga apenas uma fatia do hardware real.

Por isso, há sinais que só aparecem na camada do hypervisor. CPU ready time, balloon driver, swap activity, transparent page sharing e queue depth de datastore não existem fora da virtualização. Quando o monitoramento se limita aos contadores do guest OS, falhas como contenção de scheduler ou pressão de memória física passam batidas até o usuário reclamar da lentidão.

Em síntese, monitorar virtualização exige olhar duas coisas ao mesmo tempo: como o host distribui o hardware e como cada VM consome a sua parte. Máquinas virtuais compartilham o substrato físico de formas que mudam com o vendor, mas todas geram métricas próprias da camada de orquestração.

As quatro camadas onde as métricas vivem

Métricas de virtualização se distribuem em quatro camadas, cada uma com instrumentação própria. O host físico expõe sensores de hardware (temperatura, ventilação, integridade de discos) e contadores de CPU e memória física. O hypervisor agrega esses dados e adiciona métricas de scheduling, alocação e overcommit.

Acima do hypervisor, cada VM expõe métricas de utilização que o guest OS percebe, geralmente subestimando contenção, porque o sistema dentro da VM não enxerga as filas de scheduler do host. Por outro lado, storage compartilhado (datastore VMware, CSV Hyper-V, pool Proxmox) e rede virtual (vSwitch, NIC team) têm métricas próprias que cruzam todas as camadas anteriores.

Cada camada tem ferramentas e cadência de coleta distintas. O monitoramento de servidores tradicional cobre apenas as camadas física e do guest OS. Ambientes virtualizados exigem instrumentação adicional no hypervisor para correlacionar um pico de CPU ready com a latência de datastore observada no storage compartilhado.

Métricas de CPU em ambientes virtualizados

A utilização de CPU física e a contagem de vCPUs alocadas formam apenas a superfície. A métrica decisiva em virtualização é o CPU ready time, que mede quanto tempo uma VM ficou na fila do scheduler esperando ciclos disponíveis no host físico.

Em VMware esse contador aparece como cpu.ready.summation; em Hyper-V, como CPU Wait Time per Dispatch; em KVM, como steal time exposto pelo guest. Valores acima de 5% indicam contenção persistente e pedem revisão do dimensionamento ou redistribuição de carga entre hosts do cluster.

CPU Ready e Steal time não são exatamente a mesma métrica. Ambos refletem contenção de CPU no host, mas o CPU Ready (%RDY, em ms) é medido pelo hypervisor e o Steal time (%st) é medido dentro do sistema operacional convidado. São duas perspectivas, host e guest, do mesmo overcommit.

Por outro lado, o overcommit ratio (vCPUs alocadas divididas pelas pCPUs do host) mostra quanta concorrência existe no scheduler. Ratios de 4:1 funcionam bem em workloads leves e travam em bancos de dados. O monitoramento de CPU em virtualização precisa cruzar utilização do guest com ready time do host para diferenciar carga real de fila.

Vale destacar três contadores adicionais: CPU costop (quando uma vCPU é segurada porque outras vCPUs da mesma VM não estão prontas), CPU swap wait e %RUN vs %WAIT em esxtop. Esses três sinais mostram fadiga de SMP e ajudam a justificar reduzir vCPUs em vez de adicioná-las.

Métricas de memória: ballooning, swap e overcommit

Memória em virtualização raramente respeita a aritmética simples de RAM física dividida por VMs. O hypervisor usa três técnicas para multiplicar a capacidade aparente: ballooning, transparent page sharing e swap host-level. Cada técnica gera métricas próprias que indicam pressão de memória antes do guest OS reportar falta de RAM.

O balloon driver reivindica memória do guest quando o host enfrenta escassez. Em VMware, a métrica mem.vmmemctl.average sinaliza quanta memória o balloon recolheu; em Hyper-V, o contador Dynamic Memory Balancer reporta o mesmo fenômeno. Valores persistentes acima de zero significam que o host está sob pressão e a VM perderá RAM se a situação piorar.

O swap host-level acontece quando ballooning não basta e o hypervisor escreve páginas de memória em disco. A métrica mem.swapped em VMware e o uso ativo do pagefile.sys no servidor Hyper-V revelam degradação severa, porque latência de RAM cai de nanossegundos para milissegundos. Em síntese, swap host é sintoma de overcommit mal calibrado.

Para diagnosticar pressão real, compare memória consumed (o que o host efetivamente alocou) com memória active (o que a VM realmente acessa). Quando active sobe enquanto consumed estagna, balloon ou swap já estão atuando. Ferramentas modernas correlacionam esses contadores automaticamente; outras exigem cruzamento manual via esxtop ou PowerShell.

A documentação oficial da Microsoft mostra exemplos práticos de dashboards de performance de VMs no Azure Monitor e oferece referência cruzada para deployments Hyper-V on-premises.

Métricas de storage e IOPS em datastores compartilhados

Storage é o gargalo mais frequente em ambientes virtualizados, especialmente quando vários workloads compartilham o mesmo datastore. As três métricas-pilares de storage são latência, throughput e IOPS. Cada uma revela um aspecto diferente da saúde do array.

Latência mede o tempo entre o pedido de I/O e a resposta do datastore. Valores acima de 20 ms em workloads OLTP indicam saturação; abaixo de 5 ms é o esperado em arrays SSD. Throughput, medido em MB/s, mostra a banda total consumida e ajuda a diferenciar leitura sequencial de escrita aleatória.

IOPS, ou operações de I/O por segundo, captura quantos pedidos discretos o storage atende. Combinado com latência, IOPS revela se o array está saturado: alto IOPS com latência crescente significa fila no controlador. Por isso, queue depth complementa o trio: depths acima de 32 sustentadas indicam que aplicações esperam o array.

Provisionamento thin vs thick gera outra dimensão de métricas. Thin growth rate por datastore mostra quanto espaço lógico vira espaço real ao longo do tempo. Em ambientes com thin provisioning agressivo, esquecer essa métrica resulta em datastore lotado em produção, com todas as VMs do datastore travando ao mesmo tempo.

O Computer Weekly publicou um guia técnico que aprofunda essas três grandezas com exemplos de arrays modernos e comparativos entre flash e disco mecânico.

Métricas de rede virtual e vSwitches

Rede virtual adiciona uma camada de roteamento dentro do host que não existe no servidor físico. O vSwitch (ou Hyper-V Virtual Switch ou Open vSwitch em KVM) move pacotes entre VMs sem tocar a NIC física quando o destino é local. Isso introduz métricas próprias: pacotes intra-host, drops por porta e saturação de uplink.

Throughput por vSwitch indica quanto a rede virtual movimenta de dados. Drops por porta sinalizam buffer overflow no switch, geralmente por VMs ruidosas ou uplinks subdimensionados. esxtop com a tecla n exibe essas estatísticas em VMware; Get-VMSwitch e contadores de PerfMon cumprem o mesmo papel em Hyper-V.

Em Proxmox VE e outras distribuições KVM, Open vSwitch expõe métricas via ovs-vsctl e ovs-ofctl. Cabe ressaltar que ambientes com VLANs virtuais separando tenants exigem monitoramento por VLAN, não apenas por porta física, porque um único uplink saturado afeta múltiplos clientes ao mesmo tempo.

Tabela cruzada: nomes equivalentes em VMware, Hyper-V e KVM/Proxmox

Cada hypervisor batiza a mesma métrica de um jeito diferente. Dashboards multi-vendor frequentemente perdem sinal porque comparam nomes em vez de fenômenos. A tabela abaixo aproxima as métricas equivalentes para que VMware, Hyper-V e KVM apareçam lado a lado no mesmo painel operacional.

Vale destacar que monitoramento de VMware e monitoramento de Hyper-V oferecem contadores nativos detalhados, mas exigem ferramentas externas para correlacionar com KVM. Plataformas que consolidam essas métricas em um único painel eliminam a comparação manual entre nomes e reduzem o tempo de diagnóstico em incidentes multi-vendor.

A documentação técnica oficial da VMware lista centenas de contadores adicionais para quem precisa de granularidade extra na investigação de incidentes.

Thresholds operacionais e correlação multi-camada

Thresholds servem para transformar números em alertas acionáveis. Em virtualização, os valores variam por hardware e workload, mas existem faixas consensuais que servem como ponto de partida para qualquer baseline. A tabela abaixo resume três níveis operacionais e o que cada um indica.

Esses valores funcionam como ponto de partida. Antes de tudo, baselines do ambiente refinam os thresholds, porque workloads de banco de dados toleram menos CPU ready que servidores de arquivo. O monitoramento em tempo real 24×7 ajuda a coletar dados durante semanas e calibrar limites realistas em vez de adotar valores padronizados.

Correlacionar métricas entre camadas costuma resolver mais do que ajustar um threshold isolado. CPU ready de 8% sozinho pode indicar overcommit; combinado com latência de datastore acima de 15 ms, sugere que o storage está atrasando I/O e segurando a VM. Em síntese, os melhores diagnósticos vêm de cruzamentos, não de contadores isolados em silos.

Cinco erros comuns ao monitorar virtualização

Equipes de operação repetem alguns padrões de erro ao instrumentar ambientes virtualizados. Conhecer esses erros economiza meses de tentativa e erro com dashboards inúteis. A lista abaixo resume os cinco mais frequentes em ambientes corporativos brasileiros que a OpServices acompanha.

1. Confiar apenas em métricas do guest OS

O guest enxerga a fatia de CPU e memória que o hypervisor entrega, não a contenção real. Monitoramento que se limita a agentes Windows ou Linux dentro da VM perde CPU ready, balloon e queue depth. Por isso, instrumente sempre as duas camadas em paralelo: hypervisor para contenção, guest para impacto na aplicação.

2. Adotar thresholds genéricos sem baseline

Adotar 5% de CPU ready como crítico em qualquer workload é heurística, não engenharia. Bancos de dados sentem 3%; servidores de aplicação aguentam 8%. Em contrapartida, baselines coletados durante 30 dias calibram thresholds que reduzem significativamente os falsos positivos (sem percentual verificado) segundo dados operacionais consolidados de ambientes em produção.

3. Esquecer thin provisioning crescente

Thin provisioning permite alocar mais espaço lógico do que existe fisicamente. Sem monitorar o crescimento real por datastore, o array enche silenciosamente até o dia em que uma VM pede I/O e descobre que não há espaço. Por isso, métricas de thin growth rate por LUN são tão importantes quanto IOPS e latência.

4. Amostrar com intervalos longos demais

Coletar métricas a cada 5 minutos suaviza picos que duraram 30 segundos mas paralisaram a aplicação. O intervalo recomendado pela VMware para métricas real-time é 20 segundos; em produção, 60 segundos costuma equilibrar precisão e volume de dados. Intervalos acima de 5 minutos só servem para análise histórica de tendência.

5. Não correlacionar host, VM e storage

Dashboards separados por camada escondem a relação causal entre fenômenos. Quando o operador vê CPU ready alto numa aba e latência de storage alta em outra, não percebe que são o mesmo incidente. Plataformas modernas correlacionam essas métricas no mesmo timestamp e mostram a causa raiz em vez de uma sopa de gráficos.

Conclusão

Métricas de virtualização não são contadores de servidor adaptados ao mundo virtual. São instrumentos próprios da camada de orquestração que revelam contenção, overcommit e fadiga de scheduler invisíveis no guest OS. Estruturar o monitoramento por camadas (host, hypervisor, VM, storage, rede) e cruzar nomes entre VMware, Hyper-V e KVM transforma alertas em diagnósticos acionáveis.

Por fim, thresholds eficientes nascem de baselines, não de valores tabulados. Cada workload, cada hypervisor e cada array tem assinatura própria que só aparece após semanas de coleta consistente. Para implantar ou auditar sua estratégia de monitoramento com apoio especializado, fale com um especialista da OpServices e estruture um plano concreto.