Resolvendo o Status do Cluster Vermelho: Um Guia Passo a Passo de Troubleshooting no Elasticsearch

O status vermelho do cluster Elasticsearch significa que pelo menos um shard primário não está alocado. Isso é o que importa. Alguns dados podem estar indisponíveis, buscas em índices afetados podem retornar resultados parciais ou com falhas, e gravações nesses shards não podem prosseguir normalmente.

Amarelo é diferente: os primários estão alocados, mas uma ou mais réplicas não estão. Amarelo ainda merece atenção porque você tem menos redundância, mas vermelho é o incidente. Não comece excluindo dados ou redirecionando shards manualmente. Primeiro, descubra qual primário não está atribuído e por que o Elasticsearch se recusa a alocá-lo.

Entendendo a Saúde do Cluster Elasticsearch

O Elasticsearch fornece uma API de Saúde do Cluster que oferece um instantâneo do status do cluster e da alocação de shards. Esta API é sua ferramenta principal para diagnosticar problemas de saúde.

GET _cluster/health

A saída deste comando incluirá um campo status, que pode ser green, yellow ou red. Também fornece informações sobre o número de shards ativos e não atribuídos.

• Green: Todos os shards primários e de réplica estão alocados e funcionando corretamente.
• Yellow: Todos os shards primários estão alocados, mas alguns shards de réplica não estão atribuídos.
• Red: Um ou mais shards primários não estão atribuídos, levando à indisponibilidade de dados para esses shards.

Use uma chamada de saúde mais detalhada quando estiver em um incidente:

GET _cluster/health?level=indices

Em seguida, liste os shards não atribuídos:

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Causas Comuns e Etapas de Troubleshooting para Status Vermelho/Amarelo

Quando seu cluster não está green, é hora de investigar. Aqui estão as razões mais comuns para shards não atribuídos e como resolvê-las:

1. Espaço em Disco Insuficiente

O Elasticsearch possui salvaguardas para evitar corrupção de dados devido a discos cheios. Se um nó ficar sem espaço em disco, ele impedirá que novos shards sejam alocados ou que os existentes sejam recuperados.

Diagnóstico:

• Verifique o uso de disco em cada nó.
• Use a API de Explicação de Alocação do Cluster para entender por que os shards não estão atribuídos.

GET _cluster/allocation/explain

Esta API fornecerá uma justificativa detalhada, muitas vezes apontando para limites de disco.

Resolução:

• Libere espaço em disco: Exclua índices antigos, mova dados para outro nível ou adicione capacidade. Forçar merge de índices ativos não é uma correção rápida de espaço em disco e pode adicionar I/O pesado durante um incidente.
• Adicione mais espaço em disco: Aumente a capacidade de armazenamento de seus nós.
• Configure limites de disco: Ajuste cluster.routing.allocation.disk.watermark.low, high e flood_stage apenas quando os valores atuais estiverem errados para seu ambiente. Aumentar os limites pode ganhar tempo, mas também pode esconder um problema real de capacidade.

2. Nó Saiu do Cluster (Remoção de Nó)

Nós podem sair de um cluster devido a problemas de rede, falhas ou remoção intencional. Se um nó que contém shards (especialmente shards primários) sair, esses shards se tornam não atribuídos.

Diagnóstico:

• Verifique os logs do cluster para nós que saíram recentemente.
• Monitore a conectividade de rede entre os nós.
• Garanta que todos os nós sejam detectáveis entre si. Verifique discovery.seed_hosts, conectividade de transporte e logs do cluster. Não reintroduza cluster.initial_master_nodes em um cluster já formado como uma correção genérica.

Resolução:

• Reinicie o nó: Se o nó falhou ou ficou sem resposta, tente reiniciá-lo.
• Resolva problemas de rede: Resolva quaisquer problemas de conectividade de rede entre os nós.
• Re-adicione o nó: Se o nó foi removido intencionalmente, certifique-se de que está configurado corretamente antes de se juntar novamente ao cluster.

3. Filtragem e Consciência de Alocação de Shards

Regras de alocação de shards configuradas incorretamente podem impedir que shards sejam atribuídos a nós disponíveis.

Diagnóstico:

• Revise suas configurações cluster.routing.allocation.*, particularmente os filtros cluster.routing.allocation.include, exclude e require.
• Verifique cluster.routing.allocation.awareness.attributes se você estiver usando consciência de zona ou rack.

Resolução:

• Ajuste os filtros de alocação: Modifique os filtros para permitir que shards sejam alocados nos nós apropriados.
• Corrija os atributos de consciência: Garanta que os nós estejam corretamente marcados com atributos de consciência, se usados, e que suas regras de alocação respeitem isso.

4. Espaço em Disco Insuficiente para Alocação (Pós-Criação de Índice)

Mesmo que um disco não esteja cheio, o Elasticsearch pode impedir a alocação de shards se prever que o disco excederá os limites altos após a alocação. Isso está relacionado aos limites de disco, mas afeta especificamente novas alocações.

Diagnóstico:

• A API _cluster/allocation/explain é inestimável aqui.
• Verifique o espaço livre disponível versus o tamanho esperado dos shards.

Resolução:

• Semelhante ao problema geral de espaço em disco: libere espaço, adicione mais armazenamento ou ajuste os limites com cautela.

5. Tamanho do Shard e Capacidade do Nó

Shards muito grandes ou um grande número de shards podem sobrecarregar os recursos do nó (CPU, memória) e afetar a alocação. Além disso, se um nó atingiu seu limite de shards (cluster.routing.allocation.total_shards_per_node), novos shards não serão alocados a ele.

Diagnóstico:

• Verifique os tamanhos dos shards (GET _cat/shards?v).
• Monitore a utilização de recursos do nó (CPU, memória).
• Revise a configuração cluster.routing.allocation.total_shards_per_node.

Resolução:

• Reduza a pressão dos shards: Para índices futuros, ajuste o rollover e a contagem de shards para que os shards fiquem em um intervalo de tamanho gerenciável. Para índices existentes, use reindex, shrink ou split somente após o cluster estar estável o suficiente para lidar com o trabalho.
• Aumente a capacidade do nó: Adicione nós mais poderosos ou nós com mais memória/CPU.
• Ajuste o limite de shards: Se necessário e você tiver recursos suficientes, aumente cluster.routing.allocation.total_shards_per_node.

6. Problemas no Nó Mestre

Um nó mestre instável pode levar a problemas de alocação de shards. Se o mestre estiver indisponível ou incapaz de realizar suas funções, os shards podem se tornar não atribuídos.

Diagnóstico:

• Verifique os logs do cluster para erros ou avisos relacionados ao mestre.
• Garanta que você tenha um número ímpar de nós elegíveis a mestre (tipicamente 3 ou 5) para evitar cenários de split-brain.
• Verifique se os nós elegíveis a mestre podem eleger um mestre.

Resolução:

• Estabilize o mestre: Garanta que os nós elegíveis a mestre estejam saudáveis, tenham recursos suficientes e estejam bem conectados.
• Verifique o histórico de bootstrap: cluster.initial_master_nodes é apenas para a primeira formação do cluster. Após o bootstrap, remova-o das configurações do nó e solucione a instabilidade do mestre através de logs, rede de transporte e configuração de votação.

Troubleshooting Avançado com _cluster/allocation/explain

A API _cluster/allocation/explain é sua ferramenta mais poderosa para entender por que um shard específico não está atribuído.

Exemplo:

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Isso retornará uma saída JSON detalhada explicando por que o shard primário 0 de my-index não pode ser alocado. Procure por campos como deciders que listam as razões para a não atribuição (por exemplo, DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Resolvendo o Status Amarelo do Cluster

Um status amarelo significa que os shards primários estão alocados, mas as réplicas não. Isso impacta principalmente a redundância de dados e a tolerância a falhas.

Causas Comuns:

• Nós insuficientes: Você não tem nós suficientes para acomodar o número necessário de réplicas para seus índices.
• Filtragem de alocação de shards: Semelhante ao status vermelho, filtros podem estar impedindo que réplicas sejam alocadas.
• Restrições de espaço em disco: Os nós podem ter espaço suficiente para shards primários, mas não para réplicas, especialmente se os limites de disco estiverem ativos.

Resolução:

• Adicione mais nós: Aumente o número de nós em seu cluster.
• Ajuste a contagem de réplicas: Reduza o número de réplicas por índice (index.number_of_replicas) se a tolerância a falhas não for crítica para todos os índices.
• Verifique as configurações de alocação: Garanta que shards de réplica possam ser alocados nos nós disponíveis.

Melhores Práticas para Manter a Saúde do Cluster

• Monitore o Uso de Disco: Monitore proativamente o espaço em disco em todos os nós e configure alertas.
• Dimensione Corretamente seu Cluster: Garanta que você tenha nós e recursos suficientes para seu volume de dados e carga de consultas.
• Gerenciamento de Shards: Mantenha os tamanhos dos shards dentro das faixas recomendadas e evite o excesso de shards.
• Revise Regularmente a Saúde do Cluster: Use GET _cluster/health e GET _cluster/allocation/explain como parte de seu monitoramento de rotina.
• Teste Mudanças: Antes de fazer mudanças significativas nas configurações de alocação ou limites de disco, teste-as em um ambiente de staging.

Depois que você conhece o decisor de alocação, o caminho geralmente é claro. Limite de disco significa capacidade. NODE_LEFT significa recuperar ou substituir o nó ausente. NO_VALID_SHARD_COPY significa que você pode precisar de uma restauração de snapshot ou uma decisão deliberada de perda de dados usando os procedimentos documentados de recuperação insegura do Elasticsearch. Esse último caso deve ser tratado lentamente, com backups verificados primeiro, porque o comando que tira o cluster do vermelho também pode confirmar a perda permanente dos dados mais recentes do primário ausente.