Como medir o Steal Time de superprovisionamento em EC2 na nuvem pública

Meça o Steal Time de EC2 com mpstat para identificar superprovisionamento e vizinhos barulhentos

Atualizado 2026-08-13 · CloudWorth

Steal TimeSuperprovisionamento EC2Auditoria de desempenhoNitroFinOpsCloudWorthOverselling VPSBenchmark VPS

Steal Time alto não significa necessariamente superprovisionamento; é preciso avaliar em conjunto com Nitro e o mecanismo de créditos.

mpstat: medindo overselling na prática

Para medir o Steal Time em uma EC2 na nuvem pública, a maneira mais direta é usar mpstat -P ALL 1 e observar algumas rodadas de %steal. Mas não grite "overselling" só porque o número está alto — eu já caí nessa armadilha: quando os créditos de CPU de uma instância T3 se esgotam, o %steal também pode disparar para 30%+, mas isso não é vizinho tomando CPU, é o pool de créditos que esvaziou. Para realmente distinguir entre sobrecarga de agendamento normal na virtualização Nitro, créditos Burstable esgotados e apropriação indevida por um vizinho hostil, é preciso analisar em conjunto com /proc/schedstat e a métrica CPUCreditBalance do CloudWatch.

Na prática, costumo começar com sudo apt install sysstat && mpstat 1 5, observando principalmente se o %steal fica consistentemente acima de 10%. Se forem apenas picos momentâneos, normalmente é competição normal de recursos de CPU no host; se permanecer alto por um longo tempo e a proporção de tempo steal no cpustat estiver estável, aí sim suspeito de overselling. Atenção: Steal Time alto não significa overselling — pode ser que você tenha comprado uma instância pequena demais; depois de ativar o Unlimited em uma T3, uma carga alta contínua vai usar antecipadamente os créditos futuros, e o resultado é um steal maior.

E não termina aí. Aproveito para exportar a saída do mpstat como CSV e, junto com capturas de tela do CloudWatch, monto um PDF — se precisar abrir um chamado de suporte, isso é evidência concreta. A relação custo-benefício das instâncias compartilhadas da AWS parece atraente, mas ao fazer as contas de FinOps é preciso converter o risco potencial de steal em um prêmio de risco: para os mesmos 4 vCPUs, em vez de tentar a sorte disputando recursos com vizinhos, é melhor calcular a diferença de custo de longo prazo entre um Dedicated Host e uma instância compartilhada.

Para uma abordagem completa de auditoria, veja o Guia de Inspeção de StealTime em EC2, ou entre direto no Painel de Auditoria de Operações para rodar uma verificação automática.

Nitro overcommitment e créditos T3

A arquitetura Nitro da AWS EC2 é diferente do overcommitment convencional de KVM: o agendamento de CPU do Nitro possui isolamento mais rígido, mas o host compartilhado ainda sofre disputa de vizinhos. O que realmente causa confusão são as instâncias burstable como T3/T3a/T4g. Quando os créditos de CPU são esgotados e o Unlimited não está habilitado, o desempenho é forçado de volta à linha de base, e nesse momento o %steal no mpstat não é necessariamente alto; em vez disso, parece mais um "engasgo" local. Com o Unlimited habilitado, os créditos podem ser usados negativamente, mas isso gera custos adicionais.

Então, ao diagnosticar, primeiro use mpstat 1 para amostragem contínua e depois compare com a métrica CPUCreditBalance no CloudWatch. Se o steal está alto mas os créditos estão suficientes, isso é evidência de overcommitment; caso contrário, pode ser apenas a sobrecarga normal da virtualização Nitro. Em testes práticos, se o steal permanece alto, recomenda-se coletar evidências de timestamps do /proc/stat para usar em chamados ou justificar downgrade — afinal, do ponto de vista FinOps, pagar por overcommitment significa uma taxa de prêmio não vantajosa.

Ticket de investigação e prêmio FinOps

Quando você detectar steal time consistentemente alto no EC2, não se apresse em culpar a AWS por "overselling". Meu hábito é: primeiro, usar mpstat -P ALL 1 por 15 minutos contínuos, e depois puxar CPUCreditBalance e CPUCreditUsage do CloudWatch para comparação. Se o saldo de créditos da T3/T4g zerar, o steal time alto provavelmente é resultado do esgotamento dos créditos de CPU, não de um vizinho disputando a CPU. Para confirmar de verdade o "vizinho problemático", é preciso observar se o steal ultrapassa 5% na virtualização Nitro e se há elevação do irq — mas o Nitro tem uma pequena sobrecarga de agendamento, então não aplique o limite de 0,5% dos VPS de forma rígida.

Na fase de coleta de evidências, eu exporto simultaneamente as métricas CPUUtilization e StealTime do CloudWatch (o StealTime do EC2 fica em um namespace personalizado, então é preciso usar GetMetricData), e também tiro um snapshot do /proc para registrar a linha cpu. Combinando esses três elementos em um PDF com timestamps e anexando diretamente ao ticket, o AWS Support, ao ver dados com linha do tempo e capturas de tela, geralmente fica mais disposto a investigar o host subjacente — embora raramente admitam overselling, é comum trocarem a instância ou ajustarem o placement group.

Por fim, o prêmio FinOps: na mesma especificação c7i.large, rodando processamento em lote no host compartilhado, instâncias com steal time de 3% e 8% podem ter uma diferença real de throughput superior a 12%. Se você considerar a cobrança extra após o esgotamento dos créditos (T-series unlimited), o custo total pode ser maior do que o de um host dedicado. Recomendo incluir o steal time no relatório mensal de custos, converter valores acima de 5% em um "prêmio por perda de desempenho" e comparar com o preço anual do Dedicated Host — muitas vezes, migrar tarefas críticas para um host dedicado acaba saindo mais barato.