So überwachen Sie EFS-Burst-Credits mit CloudWatch

Ein einziger Low-Balance-Alarm reicht nicht aus, um ein EFS-Dateisystem gut zu überwachen. Es kann warnen, dass das Ende der Landebahn nahe ist, aber es erklärt nicht, warum das Gleichgewicht sinkt, wie schnell es erschöpft sein wird oder ob die Nutzer den Effekt bereits spüren.

Ein nützliches EFS-Dashboard verbindet Kapazität, Nachfrage und Anwendungsauswirkung.

Die fünf Kennzahlen, die den Kontext bestimmen

BurstCreditBalance zeigt die verbleibende Burst-Credit-Reserve für ein Dateisystem, das Bursting Throughput verwendet.
MeteredIOBytes steht für den gemessenen Durchsatz, der für die EFS-Durchsatzabrechnung verwendet wird.
PermittedThroughput zeigt, wie viel Durchsatz das Dateisystem derzeit erreichen darf.
TotalIOBytes, zeigt zusammen mit Lese-, Schreib- und Metadatenmetriken die tatsächlich geleistete Arbeit.
PercentIOLimit zeigt die Nähe zum I/O-Limit des Allzweck-Leistungsmodus.

Die aufschlussreichste Ansicht ist oft nicht irgendein einzelnes Diagramm, sondern die Beziehung zwischen ihnen. Wenn sich der gemessene Bedarf wiederholt dem zulässigen Durchsatz nähert, während die Burst-Credits nach unten tendieren, verbraucht die Arbeitslast vorübergehend Spielraum.

Erstellen Sie das Dashboard in Ebenen

Ebene 1: Verbleibende Landebahn

Grafik BurstCreditBalance über mindestens 30 Tage. Eine kurze Zeitspanne verbirgt eine langsame Erschöpfung. Verwenden Sie die Mindeststatistik, um den niedrigsten Saldo anzuzeigen, der innerhalb jeder Periode erreicht wurde, und fügen Sie eine zweite Ansicht mit einem größeren Bereich für die Trendanalyse hinzu.

Ebene 2: Nachfrage versus Genehmigung

Grafik MeteredIOBytes und PermittedThroughput mit kompatiblen Zeiträumen und Einheiten. AWS stellt fest, dass, wenn der gemessene Durchsatz dem erlaubten Durchsatz entspricht, das Dateisystem den gesamten derzeit verfügbaren Durchsatz verbraucht.

Ebene 3: Zusammensetzung der Arbeitslast

Separate Datenlese-, Datenschreib- und Metadatenoperationen. Ein Workload, der von kleinen Metadatenoperationen dominiert wird, kann sich anders verhalten als ein Workload für sequentielle Datenübertragungen, selbst wenn die aggregierte Bytezahl ähnlich aussieht.

Ebene 4: Auswirkung auf den Service

Fügen Sie Latenz bei Anwendungsanfragen, Timeout-Rate, Workersättigung und Host-I/O-Wartezeit hinzu. Infrastrukturkennzahlen werden betrieblich nützlich, wenn sie auf den sichtbaren Effekt für den Benutzer abgestimmt werden können.

Alarm bei Trends, nicht nur bei Null

Ein fester Alarm bei niedrigem Gleichgewicht ist immer noch wertvoll, aber er sollte die letzte Leitplanke sein. Bei einer Früherkennung können mehrere Warnstufen und ein Signal für anhaltende Erschöpfung verwendet werden. Zum Beispiel:

Warnen Sie, wenn das Gleichgewicht unter einen umgebungsspezifischen Grenzwert für Start- und Landebahnen fällt.
Eskalieren Sie, wenn der Saldo über mehrere Testzeiträume hinweg weiter sinkt.
Warnung, wenn der gemessene Durchsatz in der Nähe des zulässigen Durchsatzes bleibt.
Korrelieren Sie mit erhöhter Latenz oder Timeouts, um das Kapazitätsrisiko von einem aktiven Vorfall zu unterscheiden.

Es gibt keine allgemeine Kreditschwelle, da der aussagekräftige Wert von der Konsumrate abhängt. Eine große Waage kann nur für Stunden mit hoher Arbeitslast stehen, während eine kleine Waage für ein leises System stabil sein kann.

Verwandeln Sie den Alarm in eine operative Entscheidung

Das Runbook sollte die nächsten Fragen benennen: Ist die Nachfrage vorübergehend? Ist der Platzbedarf des Standardspeichers geschrumpft? Generiert eine Bereitstellung ungewöhnlichen Metadaten-Traffic? Würde Elastic Throughput besser für eine unvorhersehbare Arbeitslast geeignet sein? Ist der bereitgestellte Durchsatz durch eine stabile, bekannte Anforderung gerechtfertigt?

Ein Alarm ohne diesen Entscheidungskontext überträgt lediglich die Unsicherheit vom Armaturenbrett auf den Bereitschaftsdienst. Gute Beobachtbarkeit macht das Kapazitätsmodell sichtbar, bevor der Pager ausgelöst wird.