Cómo medir el Steal Time en EC2 de nubes públicas
Mida el Steal Time de EC2 con mpstat, identifique sobresuscripción y vecinos ruidosos
Un Steal Time alto no equivale a sobresuscripción; hay que juzgar combinando Nitro y el mecanismo de créditos.
Medición real de sobreventa con mpstat
Para medir el Steal Time en un EC2 de nube pública, la forma más directa es ejecutar mpstat -P ALL 1 y observar %steal durante varias rondas. Pero no digas "sobreventa" solo porque veas números altos: he caído en esa trampa. Cuando los créditos de CPU de una instancia T3 se agotan, %steal también puede dispararse por encima del 30%, y eso no es por la apropiación del vecino, sino porque el pool de créditos está vacío. Para distinguir realmente entre la sobrecarga de programación normal en la virtualización Nitro, el agotamiento de los créditos burstables y la apropiación de un vecino hostil, hay que revisar /proc/schedstat y la métrica CPUCreditBalance de CloudWatch.
En la práctica, suelo ejecutar primero sudo apt install sysstat && mpstat 1 5 y prestar especial atención a si %steal se mantiene por encima del 10% de forma sostenida. Si es solo una fluctuación momentánea, lo más probable es que sea una competencia normal por los recursos de CPU del host; si se mantiene alto durante mucho tiempo y la proporción de tiempo steal en cpustat es estable, entonces sí se puede sospechar de sobreventa. Ojo: Que el Steal Time sea alto no implica sobreventa, puede ser que tú mismo hayas comprado una instancia demasiado pequeña: cuando una instancia T3 tiene Unlimited habilitado, una carga alta sostenida consume por adelantado los créditos futuros, y eso se manifiesta como un aumento del steal.
Y con esto no termina. De paso, exporto la salida de mpstat a CSV, y junto con capturas de pantalla de CloudWatch lo empaqueto en un PDF; si algún día tengo que abrir un ticket de reclamación, esto es una prueba contundente. El precio de las instancias compartidas de AWS parece atractivo, pero al hacer cuentas FinOps hay que convertir el riesgo potencial de steal en una prima de sobreprecio: si hablamos de 4 vCPU, en lugar de apostar a la suerte compitiendo con los vecinos, es mejor calcular bien la diferencia de coste a largo plazo entre un Dedicated Host y una instancia compartida.
Para ver el enfoque completo de auditoría, consulta la Guía de inspección de StealTime en EC2, o entra directamente en la Plataforma de auditoría de operaciones para ejecutar un ciclo automático.
Sobreventa de Nitro y créditos T3
La arquitectura Nitro de AWS EC2 difiere de la sobreventa habitual de KVM: la programación de CPU de Nitro tiene un aislamiento más rígido, pero el host compartido sigue teniendo contención entre vecinos. Lo que realmente confunde son las instancias de ráfaga como T3/T3a/T4g. Cuando los créditos de CPU se agotan y no se ha habilitado Unlimited, el rendimiento se ve forzado a volver a la referencia; en este momento, el %steal en mpstat no necesariamente se dispara, sino que parece más un 'lag' propio. Y al habilitar Unlimited, los créditos pueden sobregirarse, pero se generan costos adicionales.
Por lo tanto, al investigar, primero muestree continuamente con mpstat 1 y luego contraste con la métrica CPUCreditBalance de CloudWatch. Si el steal es alto pero los créditos son suficientes, entonces es evidencia de sobreventa; de lo contrario, podría ser la sobrecarga normal de la virtualización Nitro. En la práctica, si el steal alto persiste, se recomienda recopilar evidencia de marcas de tiempo de /proc/stat para presentar un ticket o argumentar una reducción de instancia; después de todo, desde la perspectiva de FinOps, pagar por sobreventa significa que la prima no es rentable.
Ticket de investigación y prima FinOps
Cuando detectes un steal time persistentemente alto en EC2, no te apresures a culpar a AWS de "sobreventa". Mi costumbre es: primero muestrear con mpstat -P ALL 1 durante 15 minutos, y luego obtener CPUCreditBalance y CPUCreditUsage de CloudWatch para comparar. Si el saldo de créditos de T3/T4g llega a cero, el steal time alto se debe probablemente al agotamiento de créditos de CPU, no a que un vecino esté robando CPU. Para confirmar realmente un "mal vecino", hay que ver si bajo virtualización Nitro el steal supera el 5% y va acompañado de un aumento de irq — pero Nitro tiene una pequeña sobrecarga de planificación, así que no apliques el umbral del 0.5% típico de los VPS.
En la fase de recopilación de evidencia, exporto simultáneamente las métricas CPUUtilization y StealTime de CloudWatch (el StealTime de EC2 es un espacio de nombres personalizado, hay que extraerlo con GetMetricData), y luego uso una instantánea de /proc para registrar la línea cpu. Reúno estas tres cosas con marcas de tiempo en un PDF y lo adjunto directamente al ticket. Cuando AWS Support ve datos con línea de tiempo y capturas de pantalla, normalmente está más dispuesto a investigar el host subyacente — aunque rara vez admiten sobreventa, te cambiarán de instancia o ajustarán el placement group.
Por último, hablemos de la prima FinOps: en un c7i.large de la misma especificación, ejecutando procesamiento por lotes en un host compartido, las instancias con un steal time del 3% y del 8% pueden tener una diferencia de rendimiento real de más del 12%. Si además se considera el cargo adicional después del agotamiento de créditos (unlimited en la serie T), el costo total puede ser más alto que el de un host dedicado. Recomiendo incluir el steal time en el informe de costos mensual y, cuando supere el 5%, convertirlo en una "prima por pérdida de rendimiento" para compararla con el precio anual del Dedicated Host — en muchos casos, subir las tareas críticas a un host dedicado resulta más rentable.
FAQ
¿Cómo medir el Steal Time de EC2?
Use los comandos top o vmstat, mire el porcentaje de steal de CPU, por ejemplo, el campo %st en top.
¿Un Steal Time alto significa necesariamente sobresuscripción?
No necesariamente. Hay que combinar la arquitectura Nitro y el mecanismo de créditos; un Steal Time alto puede ser una disputa temporal de recursos.
¿Cómo juzgar la sobresuscripción bajo la arquitectura Nitro?
Consulte a través de la API de AWS la proporción entre CPU física subyacente y vCPU de la instancia, compare la asignación real.
¿Cómo afecta el mecanismo de créditos al Steal Time?
Cuando las instancias de ráfaga de la serie T agotan los créditos, la CPU se restringe, lo que puede provocar un aumento del Steal Time; hay que revisar el saldo de créditos.
¿Cuáles son los pasos para juzgar de forma integral la sobresuscripción?
Primero mida el Steal Time, luego revise los recursos físicos de la instancia Nitro, y finalmente analice el uso de créditos, para llegar a una conclusión integral.