Superviser les crédits de burst EFS avec CloudWatch

Une seule alarme de solde bas ne suffit pas pour bien superviser EFS. Elle peut signaler que la marge restante se réduit, mais pas pourquoi, à quelle vitesse les crédits s’épuisent ni si les utilisateurs en subissent déjà les effets.

Un tableau de bord EFS utile relie la capacité, la demande et l’impact sur l’application.

Cinq métriques pour comprendre la situation

BurstCreditBalance indique la réserve de crédits restante en mode Bursting Throughput.
MeteredIOBytes représente le débit comptabilisé par EFS pour son modèle de débit.
PermittedThroughput indique le débit que le système de fichiers est actuellement autorisé à utiliser.
TotalIOBytes, avec les métriques de lecture, d’écriture et de métadonnées, décrit le travail réellement effectué.
PercentIOLimit indique la proximité de la limite d’E/S du mode de performance General Purpose.

Le plus révélateur est souvent la relation entre les courbes. Si la demande comptabilisée approche régulièrement le débit autorisé tandis que le solde diminue, la charge consomme une marge temporaire.

Construire le tableau de bord par couches

Couche 1 : la marge restante

Tracez BurstCreditBalance sur au moins 30 jours. Une plage trop courte masque l’érosion lente. La statistique Minimum fait ressortir le solde le plus bas de chaque période ; ajoutez une vue plus longue pour suivre la tendance.

Couche 2 : demande et débit autorisé

Tracez MeteredIOBytes et les PermittedThroughput avec des périodes et unités compatibles. AWS précise que si le débit comptabilisé égale le débit autorisé, le système de fichiers consomme toute la capacité actuellement disponible.

Couche 3 : la composition de la charge

Séparez les lectures, les écritures et les opérations de métadonnées. Beaucoup de petites opérations de métadonnées peuvent se comporter très différemment d’un transfert séquentiel, même avec un nombre d’octets comparable.

Couche 4 : l’impact sur le service

Ajoutez la latence des requêtes, les délais dépassés, la saturation des workers et l’attente d’E/S des hôtes. Les métriques d’infrastructure deviennent utiles à l’exploitation lorsqu’on peut les relier à l’effet visible pour les utilisateurs.

Alerter sur la tendance, pas seulement sur zéro

Une alarme fixe de solde bas reste utile, mais comme dernier garde-fou. Pour détecter plus tôt, on peut combiner plusieurs seuils et un signal de consommation soutenue. Par exemple :

Prévenir lorsque le solde passe sous un seuil d’autonomie adapté à l’environnement.
Escalader si la baisse se poursuit sur plusieurs périodes d’évaluation.
Alerter si le débit comptabilisé reste proche du débit autorisé.
Corréler avec la hausse de latence ou les délais dépassés pour distinguer un risque de capacité d’un incident en cours.

Il n’y a pas de seuil universel : sa pertinence dépend de la vitesse de consommation. Un gros solde peut ne représenter que quelques heures sous forte charge ; un petit solde peut rester stable sur un système peu sollicité.

Transformer l’alarme en décision d’exploitation

La procédure doit poser les bonnes questions : la demande est-elle temporaire ? Le volume en classe Standard a-t-il diminué ? Un déploiement génère-t-il des métadonnées inhabituelles ? Elastic conviendrait-il mieux à cette charge imprévisible ? Un besoin stable et connu justifie-t-il Provisioned ?

Sans ce contexte de décision, l’alarme ne fait que transférer l’incertitude du tableau de bord à la personne d’astreinte. Une bonne observabilité rend le modèle de capacité compréhensible avant que le pager ne sonne.