Como resolver o erro “Courier fetch: n of m shards failed” (Busca de courier: n de m fragmentos falharam) no OpenSearch Dashboards do Amazon OpenSearch Service?

Última atualização: 27/09/2021

Quando tento carregar um painel no OpenSearch Dashboards em meu domínio do Amazon OpenSearch Service, ele retorna um erro de busca de courier. Como resolvo isso?

Breve descrição

Observação: o Amazon OpenSearch Service é o sucessor do Amazon Elasticsearch Service.

Quando você carrega um painel no OpenSearch Dashboards, uma solicitação de pesquisa é enviada ao domínio do OpenSearch Services. A solicitação de pesquisa é encaminhada a um nó de cluster que atua como o nó de coordenação da solicitação. O erro de “Busca de courier: n de m fragmentos falharam” ocorre quando o nó de coordenação falha ao concluir a fase de busca da solicitação de pesquisa. Existem dois tipos de problemas que geralmente causam esse erro:

  • Problemas persistentes: mapeamento de conflitos ou fragmentos não atribuídos. Se você tiver vários índices em seu padrão de índices com o mesmo nome, mas diferentes tipos de mapeamento, poderá receber um erro de busca de courier. Se o cluster estiver com o status de cluster vermelho, significa que pelo menos um fragmento não foi atribuído. Como o OpenSearch Service não pode buscar documentos de fragmentos não atribuídos, o cluster com status vermelho emite um erro de busca de courier. Se o valor de “n” na mensagem de erro de busca de Courier for o mesmo sempre que você receber o erro, provavelmente se trata de um problema persistente. Confira os logs de erros da aplicação para obter sugestões de solução de problemas.
    Observação: não é possível solucionar problemas persistentes com novas tentativas ou provisionamento de mais recursos de cluster.
  • Problemas transitórios: problemas transitórios incluem rejeições de grupo de threads, tempos limite de pesquisa e disjuntores de dados de campo disparados. Esses problemas ocorrem quando você não possui recursos computacionais suficientes no cluster. Um problema transitório é provavelmente a causa quando você recebe a mensagem de erro intermitentemente com um valor diferente de “n” a cada vez. Você também pode monitorar métricas do Amazon CloudWatch, como CPUUtilization,JVMMemoryPressure e ThreadPoolSearchRejected para determinar se um problema transitório está causando o erro de busca de courier.

Resolução

Habilite os registros de erros do aplicativo para o domínio. Os logs podem ajudar você a identificar a causa-raiz e a solução para problemas transitórios e persistentes. Para obter mais informações, consulte Visualizar logs de erros do Amazon OpenSearch Service.

Problemas persistentes

O exemplo a seguir mostra uma entrada de log para um erro de busca de courier causado por um problema persistente:

[2019-07-01T12:54:02,791][DEBUG][o.e.a.s.TransportSearchAction] [ip-xx-xx-xx-xxx] [1909731] Failed to execute fetch phase
org.elasticsearch.transport.RemoteTransportException: [ip-xx-xx-xx-xx][xx.xx.xx.xx:9300][indices:data/read/search[phase/fetch/id]]
Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default. 
Set fielddata=true on [request_departure_date] in order to load fielddata in memory by uninverting the inverted index.
Note that this can however use significant memory. Alternatively use a keyword field instead.

Neste exemplo, o problema é causado pelo campo request_departure_date. A entrada de log mostra que você pode resolver esse problema definindo fielddata=true nas configurações de índice ou usando um campo de palavra-chave.

Problemas transitórios

A maioria dos problemas transitórios pode ser resolvida provisionando mais recursos computacionais ou reduzindo a utilização de recursos para suas consultas.

Provisionamento de mais recursos computacionais

Reduzindo a utilização de recursos para suas consultas

  • Confirme se você está seguindo as práticas recomendadas para arquitetura de fragmento e cluster. Um cluster mal projetado não pode usar todos os recursos disponíveis. Alguns nós podem ficar sobrecarregados enquanto outros nós ficam ociosos. O OpenSearch Service não consegue buscar documentos em nós sobrecarregados.
  • Você também pode reduzir o escopo da consulta. Por exemplo, se você consultar por período de tempo, reduza o intervalo de datas ou filtre os resultados configurando o padrão de índice no Kibana.
  • Evite executar consultas select* em índices grandes. Em vez disso, use filtros para consultar uma parte do índice e pesquisar o menor número possível de campos. Para obter mais informações, consulte Ajuste para velocidade de pesquisa e contexto de consulta e filtro no site do Elasticsearch.
  • Reindexe e reduza o número de fragmentos. Quanto mais fragmentos houver no cluster, maior será a probabilidade de obter um erro debusca de courier. Como cada fragmento tem sua própria alocação de recursos e despesas gerais, um grande número de fragmentos sobrecarrega o cluster. Para mais informações, consulte Por que meu domínio do Amazon OpenSearch Service não sai do estado “Processing” (Processando)?

O exemplo a seguir mostra uma entrada de log para um erro de busca de courier causado por um problema transitório:

Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@26fdeb6f on QueueResizingEsThreadPoolExecutor
[name = __PATH__ queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 2.9ms, adjustment amount = 50,
org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@1968ac53[Running, pool size = 2, active threads = 2, queued tasks = 1015, completed tasks = 96587627]]

Neste exemplo, o problema é causado por rejeições de fila de threadpool de pesquisa. Para resolver esse problema, aumente na vertical a escala de seu domínio escolhendo um tipo de instância maior. Para obter mais informações, consulte grupos de threads no site do Elasticsearch.