EFS-burstcredits bewaken met CloudWatch

Eén alarm voor een laag saldo is niet genoeg om een EFS-bestandssysteem goed te bewaken. Het kan waarschuwen dat de reserve bijna op is, maar verklaart niet waarom het saldo daalt, hoe snel het opraakt of of gebruikers het effect al merken.

Een bruikbaar EFS-dashboard verbindt capaciteit, vraag en gevolgen voor de applicatie.

De vijf meetwaarden die context geven

BurstCreditBalance toont de resterende burstcreditreserve van een bestandssysteem dat Bursting Throughput gebruikt.
MeteredIOBytes staat voor de gemeten doorvoer die voor de EFS-doorvoerberekening wordt gebruikt.
PermittedThroughput toont hoeveel doorvoer het bestandssysteem momenteel mag leveren.
TotalIOBytes, samen met lees-, schrijf- en metadatameetwaarden, toont het werkelijk uitgevoerde werk.
PercentIOLimit toont hoe dicht de I/O-limiet van de prestatiemodus General Purpose wordt genaderd.

Het meest verhelderend is vaak niet één losse grafiek, maar het verband ertussen. Wanneer de gemeten vraag herhaaldelijk de toegestane doorvoer nadert terwijl burstcredits afnemen, verbruikt de werklast tijdelijke speelruimte.

Bouw het dashboard in lagen op

Laag 1: resterende speelruimte

Grafiek BurstCreditBalance voor minstens 30 dagen. Een korte periode verbergt langzaam verbruik. Gebruik de minimumstatistiek om het laagste saldo per periode zichtbaar te maken en voeg een tweede, langer overzicht toe voor trendanalyse.

Laag 2: vraag tegenover toegestane doorvoer

Grafiek MeteredIOBytes en PermittedThroughput met verenigbare perioden en eenheden. AWS merkt op dat wanneer de gemeten doorvoer gelijk is aan de toegestane doorvoer, het bestandssysteem alle momenteel beschikbare doorvoer gebruikt.

Laag 3: samenstelling van de werklast

Scheid lees-, schrijf- en metadatabewerkingen. Een workload met vooral kleine metadatabewerkingen kan zich anders gedragen dan opeenvolgende gegevensoverdracht, ook als het totale aantal bytes vergelijkbaar lijkt.

Laag 4: gevolgen voor de dienstverlening

Voeg applicatielatentie, het aandeel time-outs, workerverzadiging en I/O-wachttijd van de host toe. Infrastructuurmetingen worden operationeel bruikbaar wanneer ze naast het voor gebruikers zichtbare effect kunnen worden gelegd.

Alarmeer op trends, niet alleen op nul

Een vast alarm voor een laag saldo blijft waardevol, maar moet de laatste vangrail zijn. Vroegere detectie kan gebruikmaken van meerdere waarschuwingsniveaus en een signaal voor aanhoudende uitputting. Bijvoorbeeld:

Waarschuw wanneer het saldo onder een omgevingsspecifieke grens voor de resterende reserve daalt.
Schaal op in de incidentafhandeling als het saldo meerdere beoordelingsperioden blijft dalen.
Waarschuw wanneer de gemeten doorvoer dicht bij de toegestane doorvoer blijft.
Leg een verband met verhoogde latentie of time-outs om capaciteitsrisico te onderscheiden van een actief incident.

Er is geen universele creditdrempel, omdat de betekenis afhangt van het verbruikstempo. Een groot saldo kan bij een zware workload maar enkele uren meegaan, terwijl een klein saldo bij een rustig systeem stabiel kan zijn.

Maak van het alarm een operationele beslissing

Het draaiboek moet de volgende vragen benoemen: is de vraag tijdelijk? Is de hoeveelheid Standard-opslag afgenomen? Veroorzaakt een deployment ongebruikelijk veel metadataverkeer? Past Elastic Throughput beter bij een onvoorspelbare werklast? Rechtvaardigt een stabiele, bekende behoefte Provisioned Throughput?

Een alarm zonder deze besliscontext verplaatst onzekerheid alleen van het dashboard naar de storingsdienst. Goede observability maakt het capaciteitsmodel zichtbaar voordat de pieper afgaat.