Troubleshooting de Low Disk no Amazon OpenSearch Service
Alertas de Low Disk são comuns em ambientes Amazon OpenSearch Service que recebem grandes volumes de logs, métricas e eventos.
Em um primeiro momento, o impulso pode ser aumentar o EBS. Mas antes de escalar o cluster, é necessário entendermos por que o armazenamento chegou ao limite e se existe outro fator pressionando o cluster.
Este artigo apresenta um processo simples e prático para investigar esse cenário.
Vamos ao troubleshooting.
O que é o OpenSearch Service?
O Amazon OpenSearch Service é um serviço gerenciado da AWS, baseado no OpenSearch, que facilita a implantação, operação e escalabilidade, um mecanismo de busca e análise de código aberto. Ele permite que você armazene, pesquise e analise grandes volumes de dados em tempo real, oferecendo recursos como monitoramento de logs, análise de métricas e visualização de dados.
Ele é bastante utilizado em cenários como:
- Centralização e análise de logs de aplicações e infraestrutura;
- Observabilidade e troubleshooting de sistemas;
- Análise de métricas e eventos;
- SIEM e análise de segurança;
- Busca textual e aplicações de pesquisa;
- Monitoramento de ambientes distribuídos;
- Análise de dados de aplicações.
Um cenário muito comum é a centralização de logs:
Aplicações / Containers / Infraestrutura
↓
Pipeline de ingestão
↓
Amazon OpenSearch
↓
OpenSearch Dashboards
↓
Busca / Métricas / Análise
Como esses ambientes podem receber milhões ou bilhões de documentos, a capacidade de storage, quantidade de shards, retenção e dimensionamento dos nodes precisam ser acompanhados continuamente.
É nesse contexto que alertas de Low Disk podem se tornar um grande gargalo operacional.
Troubleshooting de Low Disk
1. Entenda o domínio
Antes de alterar qualquer coisa, levante as informações sobre:
- A versão do OpenSearch;
- O tipo das instâncias (se é serverless ou provisionado);
- A quantidade de data nodes;
- Tamanho e tipo do EBS por node;
- Availability Zones;
- UltraWarm/Cold, se utilizados.
Isso define a capacidade atual e ajuda a avaliar se o cluster está dimensionado corretamente para o workload.
2. Olhe a tendência, não apenas o valor atual
No CloudWatch da AWS, comece a procurar por métricas como:
FreeStorageSpaceClusterUsedSpaceClusterIndexWritesBlockedJVMMemoryPressureCPUUtilization
O FreeStorageSpace é especialmente importante, mas o valor atual sozinho não conta a história.
Pergunte:
Quanto espaço estamos consumindo por dia?
Se o cluster tem 200 GiB livres, mas perde 50 GiB por dia, o problema não está resolvido. Existe uma tendência de crescimento que precisa ser corrigida. Também observe o mínimo por node, porque um único node pode estar muito mais cheio que os demais.
No OpenSearch Service, ClusterIndexWritesBlocked = 1 indica que o cluster está bloqueando operações de escrita. Entre as causas comuns estão pouco espaço de armazenamento e alta pressão de JVM. A AWS recomenda acompanhar essas métricas pelo CloudWatch.
3. Verifique o estado do cluster
Se o OpenSearch Dashboards estiver disponível, alguns endpoints são úteis para a verificação do estado do cluster. Para isso, vá em Dev Tools e rode os seguintes comandos:
GET /_cluster/health
GET /_cat/allocation?v
GET /_cat/indices?v
GET /_cat/shards?v
GET /_cluster/stats
O _cat/allocation ajuda a identificar a distribuição de shards e armazenamento entre os nodes. O _cat/indices ajuda a encontrar os maiores índices.
Se o Dashboards estiver indisponível e você não tiver acesso via API, não pare o troubleshooting: faça primeiro a análise pelo AWS Console/CLI e CloudWatch.
4. Procure a causa raiz
Algumas perguntas nos ajudam a separar as hipóteses mais plausíveis:
4.1. Retenção
Existem índices antigos que deveriam ter sido removidos?
4.2. Crescimento de ingestão
A quantidade de dados aumentou recentemente?
4.3. Shards
Existem shards muito grandes ou distribuição desequilibrada?
4.4. JVM
Existe histórico de High JVM Usage ou Insufficient GC?
4.5. Capacidade
O volume de dados cresceu além da capacidade atual do cluster?
Em incidentes reais, o alerta de Low Disk pode aparecer junto com eventos de alta pressão de JVM. Por isso, olhar apenas para o disco pode levar a uma conclusão incompleta.
5. Não ignore os shards
Verifique a alocação de shards:
GET /_cat/allocation?v
e:
GET /_cat/shards?v
Procure por:
- nodes com utilização muito diferente;
- shards muito grandes;
- muitos shards por node;
- shards
UNASSIGNED; - shards em
INITIALIZINGouRELOCATING.
É importante validar o status do cluster, pois um cluster com status Yellow significa que os primaries estão alocados, mas existem replicas não alocadas. Falta de espaço também pode impedir a alocação de replicas. Já um cluster Red significa que existem primaries não alocados, o que é ainda mais crítico.
Por isso, Low Disk + status do cluster + muitos shards unassigned merece investigação antes de qualquer alteração.
6. Verifique o ISM
Para índices temporais, como logs, o Index State Management (ISM) é uma das primeiras coisas a verificar.
Pergunte:
- Existem policies?
- Os índices estão associados às policies?
- Existem ações falhando?
- O rollover está funcionando?
- A transição para
deleteestá funcionando? - Existem índices muito mais antigos que a retenção esperada?
Um fluxo comum pode ser:
Hot
↓
Warm
↓
Delete
Se a transição para Delete não acontece, os índices continuam consumindo storage.
O ISM permite automatizar operações como rollover, migração entre tiers e exclusão de índices conforme idade, tamanho e outras condições.
7. Valide backup antes de apagar dados
Antes de remover qualquer índice:
- Existe snapshot válido?
- Qual foi o último snapshot bem-sucedido?
- Qual é a retenção?
- O dado pode realmente ser descartado?
Low Disk não é motivo para apagar índices às cegas
A exclusão de um índice é uma operação destrutiva. Primeiro valide retenção, requisito de negócio e recuperação.
8. Escolha a remediação somente depois do diagnóstico
Dependendo da causa encontrada, a remediação pode ser diferente:
Retenção incorreta
Corrija o ISM ou a retenção.
Crescimento anormal
Investigue a origem da ingestão antes de simplesmente aumentar capacidade.
Storage insuficiente
Aumente o armazenamento EBS quando o crescimento for legítimo.
Falta de capacidade de processamento
Avalie mais nodes ou instâncias maiores.
Problema de shards
Revise quantidade, tamanho e distribuição dos shards.
JVM pressure
Investigue shards, consultas, mappings, carga e dimensionamento das instâncias.
A AWS recomenda considerar instâncias maiores, mais instâncias ou mais armazenamento EBS para problemas de capacidade, dependendo da causa.
9. O principal aprendizado para esses casos
Um alerta de Low Disk não significa automaticamente:
"Aumente o disco."
O fluxo deve ser:
Alerta
↓
Entender o domínio
↓
Analisar FreeStorageSpace
↓
Analisar tendência de crescimento
↓
Verificar write block e JVM
↓
Identificar índices e shards
↓
Verificar retenção e ISM
↓
Validar snapshots
↓
Identificar a causa
↓
Escolher a remediação
Em ambientes OpenSearch, diferentes sinais podem aparecer ao mesmo tempo: Low Disk, pressão de JVM, shards não alocados, write blocks e problemas de configuração.
O principal aprendizado é simples:
Use o Low Disk como ponto de partida para a sua investigação, não como diagnóstico final.
Checklist rápido
[ ] Versão / instance type
[ ] Data nodes / EBS / AZ / UltraWarm
[ ] FreeStorageSpace
[ ] FreeStorageSpace por node
[ ] Tendência de 24h / 7d
[ ] ClusterUsedSpace
[ ] ClusterIndexWritesBlocked
[ ] JVMMemoryPressure
[ ] CPUUtilization
[ ] Cluster health
[ ] Shard allocation
[ ] Maiores índices
[ ] Shards UNASSIGNED
[ ] Shards muito grandes
[ ] Retenção
[ ] ISM
[ ] Snapshots
[ ] Configuration change em andamento?
[ ] Identificar causa
[ ] Remediar com segurança
[ ] Escalar quando necessário
Considerações finais
TO troubleshooting de Low Disk no Amazon OpenSearch Service vai além de acompanhar o espaço livre, pois é importante entender a relação entre storage, ingestão, shards, retenção, ISM, JVM e capacidade do cluster antes de tomar uma ação. Uma abordagem estruturada reduz o risco de resolver apenas o sintoma e ajuda a construir ambientes OpenSearch mais previsíveis, resilientes e fáceis de operar.