Comment mesurer le Steal Time de la survente EC2 dans le cloud public

Mesurez le Steal Time EC2 avec mpstat, identifiez la survente et les voisins bruyants

Mis à jour 2026-08-13 · CloudWorth

Steal TimeSurvente EC2Audit de performanceNitroFinOpsCloudWorthSurvente VPSBenchmark VPS

Un Steal Time élevé ne signifie pas nécessairement une survente, il faut combiner Nitro et le mécanisme de crédits pour un jugement global.

Test de sur-allocation avec mpstat

Pour mesurer le Steal Time sur EC2 dans le cloud public, la méthode la plus directe est d'utiliser mpstat -P ALL 1 et de surveiller %steal pendant quelques cycles. Mais ne criez pas à la sur-allocation dès que vous voyez un chiffre élevé — je suis tombé dans ce piège : lorsque les crédits CPU d'une instance T3 sont épuisés, %steal peut aussi monter à 30%+, mais ce n'est pas du tout de la concurrence entre voisins, c'est que le pool de crédits est vide. Pour vraiment distinguer la surcharge de planification normale sous la virtualisation Nitro, l'épuisement des crédits Burstable et la concurrence agressive des voisins, il faut examiner conjointement /proc/schedstat et la métrique CPUCreditBalance de CloudWatch.

En pratique, j'ai l'habitude de lancer d'abord sudo apt install sysstat && mpstat 1 5, et de vérifier si %steal reste continuellement >10%. Si ce n'est qu'une fluctuation transitoire, il s'agit généralement d'une concurrence normale des ressources CPU de l'hôte ; si le niveau reste élevé pendant longtemps et que la proportion du temps steal dans cpustat est stable, alors seulement on peut suspecter une sur-allocation. Notez : Un Steal Time élevé ne signifie pas sur-allocation ; il se peut aussi que vous ayez choisi une instance trop petite — après avoir activé Unlimited sur une instance T3, une charge élevée continue consomme d'abord les crédits futurs, et le steal augmente alors.

Mais ce n'est pas tout. Je prends aussi le soin d'exporter la sortie de mpstat en CSV, puis de la regrouper avec des captures d'écran CloudWatch dans un PDF — si jamais vous devez ouvrir un ticket de litige, c'est une preuve solide. Le rapport qualité-prix des instances mutualisées AWS semble attrayant, mais lors du calcul FinOps, il faut convertir le risque de steal en prime : pour 4 vCPU, plutôt que de tenter votre chance avec les voisins, il vaut mieux calculer clairement la différence de coût à long terme entre Dedicated Host et instance mutualisée.

Pour une approche complète de l'audit, consultez le Guide d'inspection EC2 StealTime, ou lancez directement un cycle automatique dans la Console d'audit des opérations.

Nitro sur-vente et crédits T3

L'architecture Nitro d'AWS EC2 diffère de la sur-vente KVM classique : la planification CPU de Nitro est plus strictement isolée, mais les hôtes partagés subissent toujours des conflits de voisinage. Ce qui prête vraiment à confusion, ce sont les instances burstables comme T3/T3a/T4g. Lorsque les crédits CPU sont épuisés et que Unlimited n'est pas activé, les performances sont forcées de revenir à la ligne de base, et à ce moment-là, le %steal dans mpstat n'augmente pas forcément ; au contraire, cela ressemble plus à un « lag » personnel. Et une fois Unlimited activé, les crédits peuvent être dépassés, mais cela engendre des frais supplémentaires.

Donc, lors du dépannage, commencez par échantillonner continuellement avec mpstat 1, puis comparez avec la métrique CPUCreditBalance de CloudWatch. Si le steal est élevé mais que les crédits sont suffisants, c'est une preuve de sur-vente ; sinon, il peut s'agir d'un surcoût normal de la virtualisation Nitro. En pratique, si le steal reste élevé, il est recommandé de collecter les preuves d'horodatage de /proc/stat, à soumettre pour un ticket ou pour justifier une réduction de configuration — après tout, d'un point de vue FinOps, payer pour la sur-vente signifie un taux de prime non rentable.

Tickets d'investigation et prime FinOps

Lorsque vous observez un steal time constamment élevé sur EC2, ne vous précipitez pas pour attribuer le chapeau de « sur-vente » à AWS. Mon habitude est la suivante : d'abord, utilisez mpstat -P ALL 1 pour un échantillonnage continu de 15 minutes, puis récupérez CPUCreditBalance et CPUCreditUsage de CloudWatch pour comparaison. Si le solde de crédits des T3/T4g tombe à zéro, alors un steal time élevé est probablement dû à l'épuisement des crédits CPU, et non au vol de CPU par un voisin. Pour vraiment confirmer un « mauvais voisin », il faut voir, sous la virtualisation Nitro, si steal dépasse 5 % et s'accompagne d'une hausse de irq—mais Nitro lui-même a un léger overhead de planification, donc ne réappliquez pas directement le seuil de 0,5 % du monde VPS.

Au stade de l'investigation, j'exporte simultanément les métriques CPUUtilization et StealTime de CloudWatch (le StealTime d'EC2 est un espace de noms personnalisé, il faut utiliser GetMetricData pour le récupérer), puis j'utilise un instantané /proc pour enregistrer la ligne cpu. Je combine ces trois éléments par horodatage dans un PDF et je le joins directement au ticket. Lorsque le support AWS voit des données avec une chronologie et des captures d'écran, il est généralement plus disposé à vérifier l'hôte sous-jacent—bien qu'ils admettent rarement la sur-vente, ils vous donneront une nouvelle instance ou ajusteront le placement group.

Enfin, parlons de la prime FinOps : la même spécification c7i.large, exécutant un traitement par lots sur un hôte partagé, les instances avec un steal time de 3 % et de 8 % peuvent avoir une différence de débit réel de plus de 12 %. Si l'on tient également compte des frais supplémentaires après l'épuisement des crédits (série T unlimited), le coût global peut être plus élevé que celui d'un hôte dédié. Il est recommandé d'inclure le steal time dans le rapport de coûts mensuel, et pour ceux dépassant 5 %, de le convertir en « prime de perte de performance », puis de comparer avec le prix annuel de Dedicated Host—souvent, passer à un hôte supérieur pour les tâches clés est en réalité plus rentable.