Cómo supervisar los créditos de ráfaga de EFS con CloudWatch

Una sola alarma de bajo saldo no basta para supervisar bien un sistema de archivos EFS. Puede avisar de que el final de la pista está cerca, pero no explica por qué la balanza cae, qué tan rápido se agotará o si los usuarios ya están sintiendo el efecto.

Un útil panel de EFS conecta la capacidad, la demanda y el impacto en las aplicaciones.

Las cinco métricas que establecen el contexto

BurstCreditBalance muestra la reserva de crédito por ráfagas restante para un sistema de archivos que utilice Bursting Throughput.
MeteredIOBytes representa el rendimiento medido utilizado para la contabilidad del rendimiento de EFS.
PermittedThroughput muestra el rendimiento que el sistema de archivos puede generar actualmente.
TotalIOBytes, junto con las métricas de lectura, escritura y metadatos, muestra el trabajo real realizado.
PercentIOLimit muestra la proximidad al límite de E/S del modo de rendimiento de uso general.

La visión más reveladora no suele ser un gráfico, sino la relación entre ellos. Cuando la demanda medida se acerca repetidamente al rendimiento permitido, mientras que los créditos reventados tienden a la baja, la carga de trabajo consume margen temporal.

Cree el panel de control en capas

Capa 1: pista restante

Gráfico BurstCreditBalance durante al menos 30 días. Un rango de tiempo corto oculta un agotamiento lento. Utilice la estadística mínima para exponer el saldo más bajo alcanzado en cada período y añadir una segunda vista con un rango más largo para analizar las tendencias.

Capa 2: demanda contra permiso

Gráfico MeteredIOBytes y PermittedThroughput con períodos y unidades compatibles. AWS señala que cuando el rendimiento medido es igual al rendimiento permitido, el sistema de archivos consume todo el rendimiento disponible actualmente.

Capa 3: composición de la carga de trabajo

Separar las operaciones de lectura, escritura de datos y metadatos. Una carga de trabajo dominada por pequeñas operaciones de metadatos puede comportarse de forma diferente a una carga de trabajo de transferencia de datos secuencial, incluso cuando el recuento total de bytes parece similar.

Capa 4: impacto en el servicio

Añada la latencia de las solicitudes de aplicaciones, la tasa de tiempo de espera, la saturación de los trabajadores y la espera de E/S del host. Las métricas de infraestructura se vuelven útiles desde el punto de vista operativo cuando se pueden alinear con el efecto visible para el usuario.

Alarma por las tendencias, no solo por cero

Una alarma fija de saldo bajo sigue siendo útil, pero debería ser la última barandilla. La detección temprana puede utilizar varios niveles de advertencia y una señal de agotamiento sostenido. Por ejemplo:

Avisar cuando la balanza caiga por debajo del umbral de pista específico del entorno.
Aumentar cuando el saldo siga cayendo a lo largo de varios períodos de evaluación.
Alerta cuando el rendimiento medido se mantiene cerca del rendimiento permitido.
Correlacione con el aumento de la latencia o los tiempos de espera para distinguir el riesgo de capacidad de un incidente activo.

No existe un umbral crediticio universal porque el valor significativo depende de la tasa de consumo. Un saldo grande solo puede representar horas con una gran carga de trabajo, mientras que un saldo pequeño puede ser estable en un sistema silencioso.

Convertir la alarma en una decisión operativa

El manual debería incluir las siguientes preguntas: ¿La demanda es temporal? ¿Se redujo el espacio de almacenamiento estándar? ¿Un despliegue genera un tráfico de metadatos inusual? ¿Elastic Throughput se adaptaría mejor a una carga de trabajo impredecible? ¿El rendimiento aprovisionado se justifica por un requisito estable y conocido?

Una alarma sin este contexto de decisión no hace más que transferir la incertidumbre del salpicadero al ingeniero de guardia. Una buena observabilidad hace que el modelo de capacidad sea visible antes de que se active el localizador.