Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

Solução de Problemas Comuns de Falhas na Alocação de Shards do Elasticsearch

Aprenda a solucionar e resolver falhas comuns na alocação de shards do Elasticsearch. Este guia abrange a identificação de shards não atribuídos, o diagnóstico de problemas como erros de espaço em disco, indisponibilidade de nós e filtragem de alocação, e fornece soluções práticas e melhores práticas para manter um cluster Elasticsearch saudável.

28 visualizações

Solução de Problemas Comuns de Falhas na Alocação de Shards do Elasticsearch

Elasticsearch, um poderoso motor distribuído de pesquisa e análise, depende fortemente da sua capacidade de distribuir dados por vários nós usando shards. Quando esses shards falham na alocação, isso pode levar à indisponibilidade de dados, falhas de pesquisa e uma saúde degradada do cluster. Compreender as causas comuns das falhas na alocação de shards e saber como diagnosticá-las e resolvê-las é crucial para manter um ambiente Elasticsearch estável e de alto desempenho. Este artigo irá guiá-lo através dos problemas mais frequentes e fornecerá passos acionáveis para que seus shards voltem a um estado atribuído.

Este guia foca na solução de problemas prática para ambientes de produção do Elasticsearch. Abordaremos a identificação de shards não atribuídos, a compreensão das razões comuns para falhas, como espaço em disco, regras de alocação e problemas de nó, e forneceremos passos claros para resolver esses problemas de forma eficiente. Ao dominar essas técnicas, você pode minimizar o tempo de inatividade e garantir a confiabilidade do seu cluster Elasticsearch.

Identificando Shards Não Atribuídos

O primeiro passo na solução de problemas é identificar quais shards estão não atribuídos e por quê. O Elasticsearch oferece várias ferramentas para isso:

Usando a API de Saúde do Cluster

A API
_cluster/health
fornece uma visão geral de alto nível do status do seu cluster. Procure por
unassigned_shards
na resposta. Um valor diferente de zero indica um problema.

GET _cluster/health

Exemplo de Trecho de Resposta:

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

Neste exemplo,
"status": "yellow"
e
"unassigned_shards": 1
indicam que há um shard não atribuído. Um status
red
significa que um ou mais shards primários estão não atribuídos, impactando a disponibilidade dos dados. Um status
yellow
significa que os shards de réplica estão não atribuídos, mas os shards primários estão alocados, então seus dados ainda são pesquisáveis, mas não totalmente redundantes.

Usando a API de Explicação de Alocação

Para informações detalhadas sobre por que um shard específico está não atribuído, a API
_cluster/allocation/explain
é inestimável. Você pode fornecer detalhes do shard ou deixar que ela analise o estado do cluster.

Para obter uma explicação para qualquer shard não atribuído:

GET _cluster/allocation/explain

Para obter uma explicação para um shard específico (substitua
index_name
e
shard_id
):

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

Causas Comuns e Soluções

Vários fatores podem levar à não atribuição de shards. Aqui estão os mais comuns e como abordá-los:

1. Espaço em Disco Insuficiente

Esta é, sem dúvida, a causa mais frequente de falhas na alocação de shards. Quando um nó fica sem espaço em disco, o Elasticsearch impede que novos shards sejam alocados a ele para evitar corrupção de dados e garantir a estabilidade. Ele também pode despejar shards existentes.

  • Sintoma: A
    Allocation Explain API
    frequentemente reportará mensagens como
    "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" (não é possível alocar porque o uso do disco [X%] excede a marca d'água baixa [Y%])
    ou
    "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]" (não é possível alocar porque o uso do disco [X%] excede a marca d'água alta [Y%])
    .
  • Diagnóstico: Verifique o uso do disco nos seus nós de dados. Você pode usar a API
    _cat/allocation
    para uma visão geral rápida:
    bash GET _cat/allocation?v
    Procure por nós com altas porcentagens de uso de disco.
  • Soluções:
    • Adicione Mais Espaço em Disco: A solução mais direta é adicionar mais armazenamento aos nós afetados ou substituir os discos existentes por outros maiores.
    • Exclua Índices Não Usados: Identifique e exclua índices antigos ou desnecessários que estão consumindo espaço em disco.
    • Ajuste os Watermarks (Marcas d'água): Você pode ajustar os watermarks de uso de disco (
      cluster.routing.allocation.disk.watermark.low
      ,
      cluster.routing.allocation.disk.watermark.high
      ,
      cluster.routing.allocation.disk.watermark.flood_stage
      ) na sua configuração
      elasticsearch.yml
      ou dinamicamente via API de configurações do cluster. No entanto, aconselha-se cautela ao ajustá-los, pois eles são projetados para proteger seu cluster. Diminuí-los sem adicionar capacidade pode levar a problemas adicionais.
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • Adicione Mais Nós: Escale seu cluster adicionando mais nós de dados. Isso distribui os dados e reduz a carga sobre os nós individuais.
    • Force Merge (Mesclagem Forçada) ou Exclua Dados Antigos: Se você tiver dados de séries temporais, considere usar a API
      _forcemerge
      em índices mais antigos para reduzir o número de segmentos (o que pode liberar espaço em disco) ou use o gerenciamento do ciclo de vida do índice (ILM) para excluir dados antigos automaticamente.

2. Nó Não Disponível ou Reiniciando

Se um nó estiver inativo, reiniciando ou experimentando problemas de rede, quaisquer shards que residam nesse nó se tornarão não atribuídos. Se for um shard primário, o status do cluster ficará vermelho.

  • Sintoma: A
    Allocation Explain API
    indicará que o shard não pode ser alocado porque o nó não está disponível ou está marcado como
    (excluded)
    devido à sua inatividade.
  • Diagnóstico: Use a API
    _cat/nodes
    para verificar o status dos seus nós. Certifique-se de que todos os nós esperados estejam listados e saudáveis.
    bash GET _cat/nodes?v
    Verifique os logs do Elasticsearch no nó afetado em busca de erros ou sinais de desligamento.
  • Soluções:
    • Reinicie o Nó: Se o nó estiver inativo, tente reiniciar o serviço Elasticsearch.
    • Resolva Problemas de Rede: Certifique-se de que o nó pode se comunicar com outros nós no cluster.
    • Verifique os Logs: Examine os logs do Elasticsearch para o nó específico a fim de identificar a causa raiz da falha (por exemplo, falta de memória, erros de disco, problemas de JVM).
    • Aumente
      index.unassigned.node_left.delayed_timeout
      : Se os nós estiverem frequentemente entrando e saindo do cluster (por exemplo, durante reinícios contínuos), você poderá ver shards de réplica se tornarem não atribuídos temporariamente. A configuração
      index.unassigned.node_left.delayed_timeout
      (padrão de 1 minuto) permite que o Elasticsearch espere antes de marcar os shards em um nó que saiu como não atribuídos, dando tempo para o nó se reintegrar. Aumente este valor se necessário, mas esteja atento ao impacto no tempo de recuperação.

3. Regras de Filtragem e Conscientização de Alocação

O Elasticsearch permite controlar onde os shards são alocados usando várias regras de alocação, como atributos de nó e anti-afinidades. Se essas regras impedirem a alocação, os shards podem se tornar não atribuídos.

  • Sintoma: A
    Allocation Explain API
    reportará que a alocação está desativada para atributos específicos ou que nenhum nó adequado está disponível de acordo com as regras configuradas.
  • Diagnóstico:
    • Verifique as configurações do seu índice para
      index.routing.allocation.require.*
      ,
      index.routing.allocation.include.*
      ,
      index.routing.allocation.exclude.*
      e
      index.routing.allocation.total_shards_per_node
      .
    • Verifique as configurações em nível de cluster para
      cluster.routing.allocation.enable
      (por exemplo,
      all
      ,
      primaries
      ,
      new_primaries
      ,
      none
      ).
    • Verifique os atributos do nó usando
      GET _cat/nodeattrs?v
      .
  • Soluções:
    • Atualize as Configurações do Índice: Remova ou ajuste as regras restritivas de roteamento de índice. Por exemplo, para permitir a alocação para qualquer nó:
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • Atualize as Configurações do Cluster: Habilite temporariamente a alocação se ela estiver desabilitada:
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      Lembre-se de reverter esta configuração se ela for apenas temporária.
    • Atualize os Atributos do Nó: Certifique-se de que seus nós tenham os atributos esperados definidos em
      elasticsearch.yml
      (por exemplo,
      node.attr.zone: us-east-1
      ) e que esses atributos se alinhem com suas regras de alocação. Depois de alterar
      elasticsearch.yml
      , os nós precisam ser reiniciados para que as alterações entrem em vigor.

4. Dados de Shard Corrompidos (Raro)

Em casos raros, os dados do shard podem ser corrompidos, impedindo que o Elasticsearch inicie ou aloque o shard. Isso é mais comum com problemas de disco subjacentes.

  • Sintoma: Os logs podem mostrar erros relacionados à leitura de dados do shard ou corrupção do índice. A
    Allocation Explain API
    pode não fornecer um motivo claro ou pode apontar para um erro de leitura.
  • Diagnóstico: Examine os logs do Elasticsearch de perto no nó onde o shard deve estar localizado. Procure por erros de I/O ou mensagens de corrupção de dados.
  • Soluções:
    • Restaurar de Snapshot: A solução mais confiável é restaurar o índice afetado (ou o cluster inteiro) a partir de um snapshot conhecido e bom. É por isso que backups regulares são críticos.
    • Excluir Shard Forçadamente (Último Recurso): Se você não conseguir restaurar de um snapshot e os dados não forem críticos ou puderem ser reindexados, talvez seja necessário excluir forçadamente o shard corrompido. Esta é uma operação avançada e só deve ser realizada quando você entender as implicações. Normalmente, você precisa parar o nó afetado, remover o diretório de dados do shard manualmente e, em seguida, reiniciar o nó. Isso resultará em perda de dados para esse shard. Consulte a documentação do Elasticsearch para o procedimento exato para sua versão.

5. Capacidade de Relocação Insuficiente

Quando um nó sai do cluster ou surgem problemas de espaço em disco, o Elasticsearch tenta realocar shards para outros nós. Se não houver nós adequados suficientes ou se o cluster já estiver sob carga pesada, a realocação de shards pode parar, levando a
initializing_shards
ou
unassigned_shards
.

  • Sintoma: Os shards permanecem em estado de
    initializing
    (inicializando) ou
    relocating
    (realocando) por períodos prolongados, ou novos shards falham na alocação.
  • Diagnóstico: Verifique
    _cat/shards
    e
    _cat/allocation
    para ver os status dos shards e o uso do disco. Monitore a saúde do cluster e a utilização de CPU/IO dos nós.
  • Soluções:
    • Adicione Mais Nós: Aumente a capacidade do seu cluster adicionando mais nós de dados.
    • Libere Recursos: Resolva quaisquer gargalos de desempenho nos nós existentes (por exemplo, alta CPU, I/O de disco lento).
    • Ajuste as Configurações de Alocação de Shard: Você pode ajustar configurações como
      cluster.routing.allocation.node_concurrent_recoveries
      (número de shards que podem ser recuperados concomitantemente em um nó) e
      cluster.routing.allocation.node_concurrent_incoming_recoveries
      (número de shards que podem ser recuperados concomitantemente de outro nó). No entanto, seja cauteloso, pois aumentar esses valores pode sobrecarregar ainda mais o cluster.

Melhores Práticas para Prevenção

  • Monitore o Espaço em Disco: Monitore proativamente o uso do disco em todos os nós de dados. Configure alertas para quando o uso do disco ultrapassar limites predefinidos (por exemplo, 80% ou 85%).
  • Implemente o Gerenciamento do Ciclo de Vida do Índice (ILM): Automatize o gerenciamento de dados de séries temporais, incluindo a rolagem, redução e exclusão de índices antigos. Isso ajuda a controlar o uso do espaço em disco.
  • Snapshots Regulares: Garanta que você tenha uma estratégia de backup robusta com snapshots automatizados e regulares dos seus dados. Teste seu processo de restauração periodicamente.
  • Compreenda as Regras de Alocação: Planeje e configure cuidadosamente as regras de alocação de shards com base nos seus requisitos de hardware, dados e disponibilidade.
  • Hardware Adequado: Certifique-se de que seus nós tenham capacidade de CPU, RAM e I/O suficientes para lidar com a carga de trabalho e os processos de recuperação de shards.
  • Monitoramento da Saúde do Cluster: Verifique regularmente a saúde do seu cluster usando a API
    _cluster/health
    e visualize-a com ferramentas como o Stack Monitoring do Kibana.

Conclusão

Falhas na alocação de shards no Elasticsearch podem ser um problema assustador, mas ao diagnosticar sistematicamente o problema usando ferramentas como a Cluster Health API e a Allocation Explain API, e compreendendo causas comuns como espaço em disco, disponibilidade de nós e regras de alocação, você pode resolvê-las efetivamente. O monitoramento proativo e a adesão às melhores práticas, como backups regulares e ILM, são fundamentais para prevenir esses problemas em primeiro lugar e garantir um cluster Elasticsearch estável e saudável.