Como monitorar créditos de burst do EFS com CloudWatch

Um único alarme de saldo baixo não basta para monitorar bem o EFS. Ele avisa que a reserva está perto do fim, mas não explica por que cai, quanto tempo resta ou se os usuários já sentem o efeito.

Um dashboard útil de EFS conecta capacidade, demanda e impacto na aplicação.

As cinco métricas que dão contexto

BurstCreditBalance mostra a reserva de créditos restante de um sistema de arquivos em Bursting Throughput.
MeteredIOBytes representa o throughput contabilizado pelo EFS.
PermittedThroughput mostra quanto throughput o sistema de arquivos pode usar naquele momento.
TotalIOBytes, junto com as métricas de leitura, gravação e metadados, mostra o trabalho efetivamente realizado.
PercentIOLimit mostra a proximidade do limite de I/O do modo de desempenho General Purpose.

Muitas vezes, o mais revelador não é um gráfico isolado, mas a relação entre eles. Quando a demanda medida se aproxima repetidamente do throughput permitido e o saldo cai, a carga está consumindo uma folga temporária.

Monte o dashboard em camadas

Camada 1: reserva restante

Mostre BurstCreditBalance por pelo menos 30 dias. Um intervalo curto esconde o consumo lento. Use a estatística de mínimo para revelar o menor saldo em cada período e adicione uma visão mais longa para analisar tendências.

Camada 2: demanda e capacidade permitida

Mostre MeteredIOBytes e nas PermittedThroughput com períodos e unidades compatíveis. A AWS informa que, quando o throughput medido iguala o permitido, o sistema usa toda a capacidade disponível naquele momento.

Camada 3: composição da carga

Separe leitura, gravação e operações de metadados. Uma carga dominada por pequenas operações de metadados pode se comportar de forma diferente de uma transferência sequencial, mesmo com volumes totais parecidos.

Camada 4: impacto no serviço

Acrescente latência das requisições, taxa de timeout, saturação de workers e espera por I/O no host. Métricas de infraestrutura ganham utilidade operacional quando se conectam ao efeito percebido pelo usuário.

Crie alarmes para a tendência, não só para o zero

Um alarme de saldo baixo continua valioso, mas deve ser a última barreira. Para detectar antes, use níveis de aviso e um sinal de consumo contínuo. Por exemplo:

Avise quando o saldo ficar abaixo de um limite de reserva definido para o ambiente.
Escale quando o saldo continuar caindo por vários períodos de avaliação.
Alerte quando o throughput medido permanecer perto do permitido.
Correlacione com aumento de latência ou timeouts para separar risco de capacidade de um incidente ativo.

Não há um limite universal de créditos: o valor útil depende da taxa de consumo. Um saldo grande pode durar apenas horas sob carga intensa, enquanto um pequeno pode permanecer estável em um sistema tranquilo.

Transforme o alarme em uma decisão operacional

O procedimento deve indicar as próximas perguntas: a demanda é temporária? O volume em Standard diminuiu? Um deploy gera tráfego incomum de metadados? Elastic Throughput combina melhor com a imprevisibilidade? Uma necessidade estável justifica Provisioned Throughput?

Sem esse contexto, o alarme só transfere a incerteza do dashboard para quem está de plantão. Boa observabilidade torna o modelo de capacidade visível antes de o pager tocar.