Hoe meet je StealTime voor EC2-overboeking in de publieke cloud?
Meet EC2 Steal Time met mpstat om overboeking en lawaaierige buren te identificeren
Een hoge Steal Time betekent niet altijd overboeking; combineer Nitro en het tegoedmechanisme voor een volledige beoordeling.
mpstat: overboeking in de praktijk
Op public cloud EC2 is de meest directe manier om Steal Time te meten door mpstat -P ALL 1 te gebruiken en een paar rondes naar %steal te kijken. Maar roep niet meteen overboeking als je hoge cijfers ziet—ik ben in een valkuil getrapt: wanneer de CPU-credits van een T3-instantie uitgeput zijn, kan %steal ook oplopen tot 30%+, maar dat is helemaal geen buurman-preemptie; het is dat de creditpool leeg is. Om echt onderscheid te maken tussen normale planningsoverhead onder Nitro-virtualisatie, uitputting van burstable credits en preemptie door een luidruchtige buurman, moet je /proc/schedstat en de CloudWatch-metric CPUCreditBalance samen bekijken.
In de praktijk draai ik eerst sudo apt install sysstat && mpstat 1 5 en let ik vooral op of %steal continu >10% is. Als het slechts kortstondige schommelingen zijn, is er meestal sprake van normale CPU-resourceconcurrentie op de host; blijft het lang hoog en is het aandeel steal-tijd in cpustat stabiel, dan vermoed je overboeking. Let op: Hoge Steal Time betekent niet automatisch overboeking; het kan ook zijn dat je zelf te klein hebt ingekocht—na het inschakelen van Unlimited op een T3-instantie worden bij aanhoudend hoge belasting eerst toekomstige credits verbruikt, wat zich uit in een hogere steal.
Daarmee is het nog niet klaar. Ik exporteer de mpstat-output ook even naar CSV en bundel dat met CloudWatch-screenshots tot een PDF—mocht je een klacht willen indienen, dan is dit hard bewijs. De prijs-kwaliteitverhouding van AWS gedeelde instanties ziet er aantrekkelijk uit, maar bij de FinOps-berekening moet je het potentiële steal-risico omrekenen naar een opslagpercentage: in plaats van te gokken op de buren, kun je beter het langetermijnkostenverschil tussen Dedicated Host en gedeelde instanties uitrekenen.
De volledige audit-aanpak vind je in EC2 StealTime-auditgids, of ga direct naar Operationeel auditplatform om het automatisch te laten draaien.
Nitro-overcommitment en T3-tegoed
De Nitro-architectuur van AWS EC2 verschilt van reguliere KVM-overcommitment: de CPU-planning van Nitro is sterker geïsoleerd, maar op een gedeelde host is er nog steeds concurrentie van buren. Wat echt verwarrend kan zijn, zijn de burstable instanties zoals T3/T3a/T4g. Wanneer het CPU-tegoed is uitgeput en Unlimited niet is ingeschakeld, worden de prestaties teruggebracht naar de basislijn. In dat geval hoeft %steal in mpstat niet per se hoog op te lopen, maar lijkt het eerder alsof de machine zelf 'hapert'. Na het inschakelen van Unlimited kan het tegoed worden overschreden, maar dit brengt extra kosten met zich mee.
Dus bij het debuggen: gebruik eerst mpstat 1 voor continue sampling, en vergelijk dit met de CPUCreditBalance-metriek van CloudWatch. Als de steal hoog is maar het tegoed voldoende, dan is dat bewijs van overcommitment; anders is het waarschijnlijk normale overhead van Nitro-virtualisatie. In de praktijk, bij aanhoudend hoge steal, raden we aan om tijdstempelbewijs van /proc/stat te verzamelen, voor het indienen van een ticket of voor een downgrade-onderbouwing – vanuit FinOps-perspectief is het betalen voor overcommitment namelijk de premie niet waard.
Forensische tickets en FinOps-premie
Wanneer je op EC2 een aanhoudend hoge steal time opmerkt, haast je dan niet om AWS het label 'oververkocht' op te plakken. Mijn gewoonte: gebruik mpstat -P ALL 1 om 15 minuten lang continu te samplen, en trek daarna CloudWatch's CPUCreditBalance en CPUCreditUsage erbij ter vergelijking. Als het credit-saldo van T3/T4g op nul staat, is hoge steal time meestal te wijten aan uitputting van CPU-credits, niet aan buurman-CPU-concurrentie. Om een echte 'slechte buurman' te bevestigen, moet je onder Nitro-virtualisatie zien of steal boven de 5% uitkomt en gepaard gaat met een stijging van irq—maar Nitro heeft zelf een beetje scheduling-overhead, dus pas de VPS-drempel van 0,5% niet rigide toe.
In de forensische fase exporteer ik tegelijkertijd CloudWatch's CPUUtilization- en StealTime-metrics (de StealTime van EC2 is een aangepaste namespace, dus je moet GetMetricData gebruiken om het op te halen), en gebruik daarna een /proc-snapshot om de cpu-regel vast te leggen. Plak deze drie op basis van tijdstempel in een PDF en voeg die direct toe aan de ticket. AWS Support, die gegevens met tijdlijn en screenshots ziet, is meestal eerder bereid om de onderliggende host te onderzoeken—hoewel ze zelden toegeven dat er oververkocht is, maar ze zullen je een andere instantie geven of de placement group aanpassen.
Tot slot, de FinOps-premie: een c7i.large met dezelfde specificaties, draaiend op een gedeelde host voor batchverwerking, instanties met een steal time van 3% en 8% kunnen in werkelijke doorvoer meer dan 12% verschillen. Als je de extra kosten na uitputting van credits (T-serie unlimited) meerekent, kunnen de totale kosten hoger zijn dan die van een dedicated host. Het advies is om steal time op te nemen in het maandelijkse kostenrapport, en alles boven de 5% om te rekenen als 'prestatieverlies-premie', en dat te vergelijken met de jaarlijkse prijs van een Dedicated Host—in veel gevallen is het voor kritieke taken juist voordeliger om over te stappen naar een dedicated host.
FAQ
Hoe meet je StealTime bij EC2?
Gebruik de opdrachten top of vmstat om het CPU-stealpercentage te bekijken, bijvoorbeeld het %st-veld in top.
Betekent een hoge StealTime altijd overboeking?
Niet noodzakelijk. Het is noodzakelijk om de Nitro-architectuur en het tegoedmechanisme te overwegen; een hoge StealTime kan te wijten zijn aan tijdelijke resourcecontentie.
Hoe bepaal je overboeking onder de Nitro-architectuur?
Gebruik de AWS API om de verhouding tussen fysieke CPU en vCPU van de instantie op te vragen en vergelijk dit met de werkelijke toewijzing.
Hoe beïnvloedt het tegoedmechanisme de StealTime?
Wanneer de tegoeden van T-serie burst-instanties zijn uitgeput, wordt de CPU beperkt, wat kan leiden tot een hogere StealTime; controleer het tegoedsaldo.
Wat zijn de stappen om overboeking uitgebreid te beoordelen?
Meet eerst de StealTime, controleer vervolgens de fysieke bronnen van de Nitro-instantie en analyseer ten slotte het tegoedverbruik om tot een conclusie te komen.