So messen Sie Steal Time bei EC2 in der Public Cloud
Messen Sie EC2 Steal Time mit mpstat, um Überverkauf und böswillige Nachbarn zu erkennen
Hohe Steal Time bedeutet nicht unbedingt Überverkauf; eine umfassende Bewertung sollte Nitro und den Credit-Mechanismus berücksichtigen.
mpstat: Überverkauf messen
Um Steal Time auf einer Public-Cloud-EC2 zu messen, ist der direkteste Weg, mpstat -P ALL 1 laufen zu lassen und ein paar Runden %steal zu beobachten. Aber wenn die Zahl hoch ist, sollte man nicht sofort Überverkauf schreien – ich bin selbst in diese Falle getappt: Wenn die CPU-Credits einer T3-Instanz erschöpft sind, kann %steal ebenfalls auf über 30% steigen, aber das ist nicht auf Nachbarn zurückzuführen, die CPU rauben, sondern auf einen leeren Credit-Pool. Um wirklich zwischen normalem Scheduling-Overhead unter Nitro-Virtualisierung, erschöpften Burstable-Credits und bösartigen Nachbarn zu unterscheiden, muss man auch /proc/schedstat und den CloudWatch-Messwert CPUCreditBalance heranziehen.
In der Praxis lasse ich zuerst sudo apt install sysstat && mpstat 1 5 laufen und achte darauf, ob %steal dauerhaft über 10% liegt. Wenn es nur kurze Ausschläge sind, handelt es sich meist um normale CPU-Ressourcenkonkurrenz auf dem Host; erst wenn es über einen längeren Zeitraum hoch bleibt und im cpustat der Steal-Zeitanteil stabil ist, sollte man Überverkauf vermuten. Achtung: Steal Time hoch bedeutet nicht Überverkauf – es könnte auch sein, dass man selbst eine zu kleine Instanz gekauft hat: Wenn bei T3-Instanzen Unlimited aktiviert ist, werden bei dauerhaft hoher Last zukünftige Credits vorweggenommen, was sich als erhöhter Steal äußert.
Damit ist es aber noch nicht getan. Ich exportiere die mpstat-Ausgabe in eine CSV-Datei und packe sie zusammen mit CloudWatch-Screenshots in ein PDF – falls man einen Support-Ticket zur Durchsetzung von Rechten eröffnen muss, ist das ein starker Beweis. Die Kosten-Effektivität von AWS-Instanzen mit gemeinsamem Host sieht verlockend aus, aber bei der FinOps-Berechnung sollte man das potenzielle Steal-Risiko als Aufschlag einpreisen: Bei gleicher Anzahl von 4 vCPUs sollte man nicht auf gut Glück mit den Nachbarn konkurrieren, sondern besser die langfristigen Kostenunterschiede zwischen Dedicated Host und gemeinsamer Instanz durchrechnen.
Der vollständige Audit-Ansatz ist im EC2 StealTime-Inspektionsleitfaden zu finden, oder man geht direkt in die Operations-Audit-Konsole für einen automatischen Lauf.
Nitro-Überzeichnung und T3-Credits
Die Nitro-Architektur von AWS EC2 unterscheidet sich von der üblichen KVM-Überzeichnung: Die CPU-Planung von Nitro ist stärker isoliert, aber auf dem gemeinsamen Host besteht weiterhin Nachbar-Contention. Was wirklich leicht zu verwechseln ist, sind die burstable Instanzen wie T3/T3a/T4g. Wenn die CPU-Credits aufgebraucht sind und Unlimited nicht aktiviert ist, wird die Leistung zwangsweise auf die Baseline zurückgeführt. In diesem Fall steigt der %steal-Wert in mpstat nicht unbedingt an, sondern es fühlt sich eher so an, als ob die Instanz selbst 'hakt'. Wenn Unlimited hingegen aktiviert ist, können die Credits überzogen werden, was jedoch zusätzliche Kosten verursacht.
Daher sollte man bei der Fehlersuche zunächst mit mpstat 1 kontinuierlich Samples sammeln und diese dann mit dem CPUCreditBalance-Metrik in CloudWatch abgleichen. Wenn der Steal hoch ist, aber die Credits ausreichend sind, ist das ein Beweis für Überzeichnung; andernfalls handelt es sich möglicherweise um den normalen Overhead der Nitro-Virtualisierung. In Praxistests empfiehlt es sich, bei anhaltend hohem Steal Zeitstempel-Beweise aus /proc/stat zu sammeln, um sie für Ticket-Einreichungen oder eine Argumentation für die Verkleinerung der Instanz zu verwenden – schließlich bedeutet es aus FinOps-Sicht, für Überzeichnung zu zahlen, dass die Prämie nicht wirtschaftlich ist.
Forensik-Tickets und FinOps-Aufschlag
Wenn du bei EC2 anhaltend hohe Steal Time erwischt, zieh nicht voreilig AWS den „Overcommitment“-Hut auf. Meine Gewohnheit ist: erst mit mpstat -P ALL 1 15 Minuten lang kontinuierlich sampeln, dann CloudWatch CPUCreditBalance und CPUCreditUsage zum Vergleich heranziehen. Wenn das Guthaben der T3/T4g-Instanzen auf null fällt, ist hohe Steal Time meist auf erschöpfte CPU-Credits zurückzuführen, nicht auf einen lauten Nachbarn. Um wirklich einen „bösen Nachbarn“ nachzuweisen, musst du unter Nitro-Virtualisierung prüfen, ob steal über 5% liegt und gleichzeitig irq ansteigt – aber Nitro selbst hat etwas Scheduling-Overhead, also wende nicht die 0,5%-Schwelle von VPS-Szenarien stur an.
In der forensischen Phase exportiere ich parallel CloudWatch CPUUtilization und StealTime-Metriken (die StealTime von EC2 ist ein benutzerdefinierter Namespace, also mit GetMetricData abrufen) und protokolliere zusätzlich die cpu-Zeile als /proc-Snapshot. Diese drei Dinge füge ich nach Zeitstempel zu einem PDF zusammen und hänge sie direkt an das Ticket. Wenn AWS Support zeitlich aufgelöste Daten mit Screenshots sieht, ist man meist eher bereit, den zugrunde liegenden Host zu untersuchen – obwohl sie selten Overcommitment zugeben, aber sie wechseln die Instanz oder passen die Placement Group an.
Zum Schluss zum FinOps-Aufschlag: Eine c7i.large mit gleicher Spezifikation, die Batch-Verarbeitung auf einem Shared Host ausführt, kann bei 3% und 8% Steal Time einen tatsächlichen Durchsatzunterschied von über 12% aufweisen. Wenn man zusätzlich die Kosten nach erschöpften Credits einrechnet (T-Serie unlimited), können die Gesamtkosten teurer sein als ein Dedicated Host. Ich empfehle, Steal Time in den monatlichen Kostenbericht aufzunehmen und bei über 5% als „Performance-Verlust-Aufschlag“ umzurechnen, dann mit dem Jahrespreis des Dedicated Host zu vergleichen – oft ist es günstiger, für kritische Aufgaben den Host aufzurüsten.
FAQ
Wie misst man die Steal Time von EC2?
Verwenden Sie die Befehle top oder vmstat, um den CPU-Steal-Prozentsatz anzuzeigen, z.B. das Feld %st in top.
Bedeutet eine hohe Steal Time immer Überverkauf?
Nicht unbedingt. In Kombination mit der Nitro-Architektur und dem Credit-Mechanismus kann eine hohe Steal Time auf vorübergehende Ressourcenkonflikte hinweisen.
Wie erkennt man Überverkauf unter der Nitro-Architektur?
Über die AWS-API das Verhältnis von physischer CPU zu vCPU der Instanz abfragen und mit der tatsächlichen Zuweisung vergleichen.
Wie beeinflusst der Credit-Mechanismus die Steal Time?
Wenn bei T-Serie-Burst-Instanzen die Credits erschöpft sind, wird die CPU gedrosselt, was zu einer erhöhten Steal Time führen kann. Der Credit-Saldo sollte überprüft werden.
Was sind die Schritte zur umfassenden Beurteilung von Überverkauf?
Zuerst die Steal Time messen, dann die physischen Ressourcen der Nitro-Instanz prüfen und schließlich die Credit-Nutzung analysieren, um eine umfassende Schlussfolgerung zu ziehen.