Comment résoudre l'erreur « Courier fetch : n of m shards failed » dans Kibana sur Amazon Elasticsearch Service ?

Date de la dernière mise à jour : 23/08/2019

Lorsque j'essaie de charger un tableau de bord dans Kibana sur mon domaine Amazon Elasticsearch Service (Amazon ES), il renvoie une erreur similaire à celle-ci : « Error : Courier Fetch : 5 of 60 shards failed » (Erreur : récupération du transporteur : 5 des 60 partitions ont échoué).

Remarque : il existe de nombreuses causes possibles de cette erreur. Cet article couvre certaines des causes et solutions courantes.

Brève description

Lorsque vous chargez un tableau de bord dans Kibana, Kibana envoie une demande de recherche au domaine Amazon ES. La demande de recherche est acheminée vers un nœud de cluster qui agit en tant que nœud de coordination pour la demande. L'erreur « Courier fetch : n of m shards failed » se produit lorsque le nœud de coordination ne parvient pas à terminer la phase de récupération de la demande de recherche. En règle générale, cette erreur est due à deux types de problèmes :

  • Problèmes persistants: conflits de mappage ou partitions non attribuées. Si vous avez plusieurs index dans votre modèle d'index, et que certains de ces index ont des champs avec le même nom, mais des types de mappage, différents, vous pouvez obtenir une erreur de récupération du transporteur. Si votre cluster est en statut rouge, cela signifie qu'au moins une partition n'est pas attribuée. Étant donné qu'Elasticsearch ne peut pas récupérer des documents à partir de partitions non attribuées, un cluster dont le statut est rouge génère des erreurs de récupération du transporteur. Si vous continuez à recevoir des erreurs de récupération du transporteur et que la valeur de « n » dans le message d'erreur (« Courier fetch : n of m shards failed ») est toujours la même, un problème persistant en est probablement la cause. Une nouvelle tentative ou la mise en service de plus de ressources de cluster ne résout pas les problèmes persistants. Consultez les journaux des erreurs d'application pour trouver des suggestions de dépannage.
  • Problèmes passagers: rejets du groupe de threads, dépassements du délai de recherche, disjoncteurs de circuit de données de champ déclenchés, etc. Ces problèmes se produisent lorsque vous n'avez pas suffisamment de ressources de calcul sur le cluster. Si les erreurs se produisent par intermittence et que la valeur de « n » dans le message d'erreur est différente chaque fois que l'erreur se produit, un problème passager en est probablement la cause. Vous pouvez également surveiller les métriques d'Amazon Cloudwatch telles que CPUUtilization, JVMMemoryPressure et ThreadpoolSearchRejected pour déterminer si un problème passager est à l'origine de l'erreur d'extraction du transporteur.

Résolution

Activez les journaux d'erreurs d'application pour le domaine. Les journaux peuvent vous aider à identifier la cause profonde et la solution aux problèmes passagers et persistants.

Problèmes persistants

Voici un exemple d'entrée de journal pour une erreur de récupération du transporteur provoquée par un problème persistant.

Remarque : les entrées de journal ne ressemblent pas toujours à ceci : les vôtres peuvent être différentes.

[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.

Dans cet exemple, le problème est provoqué par le champ request_departure_date . L'entrée de journal montre que vous pouvez résoudre ce problème en définissant fielddata = true dans les paramètres d'index ou en utilisant un champ de mot-clé.

Problèmes passagers

Voici un exemple d'entrée de journal pour une erreur d'extraction de messagerie qui est provoquée par un problème passager.

Remarque : les entrées de journal ne ressemblent pas toujours à ceci : les vôtres peuvent être différentes.

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]]

Dans cet exemple, le problème est provoqué par les rejets des files d'attente du groupe de threads de recherche . Pour résoudre ce problème, mettez à l'échelle votre domaine en choisissant un type d'instance plus grand.

La plupart des problèmes passagers peuvent être résolus avec l'une des méthodes suivantes :

Allouer des ressources de calcul supplémentaires

  • Augmentation de votre domaine en basculant vers un type d'instance plus grand, ou augmentation de la taille en ajoutant plus de nœuds au cluster. Pour plus d'informations, consultez Configuration de domaines Amazon ES.
  • Vérifiez que vous utilisez bien un type d'instance adapté à votre cas d'utilisation. Pour plus d'informations, consultez la page Choix des types d'instances et test.

Réduire l'utilisation des ressources pour vos requêtes

  • Confirmez que vous suivez les bonnes pratiques pour l'architecture de partition et de cluster. Un cluster mal conçu ne peut pas utiliser toutes les ressources disponibles. Certains nœuds peuvent être surchargés tandis que d'autres nœuds restent inactifs. Elasticsearch ne peut pas extraire de documents à partir de nœuds surchargés.
  • Réduisez la portée de votre requête. Par exemple, si vous interrogez sur la période, réduisez la plage de dates ou filtrez les résultats en configurant le modèle d'index dans Kibana.
  • Évitez d'exécuter des requêtes select* sur des index volumineux. Utilisez plutôt des filtres pour interroger une partie de l'index et rechercher le moins de champs possible.
  • Réindexez et réduisez le nombre de partitions. Plus votre cluster Elasticsearch contient de partitions, plus vous risquez d'obtenir une erreur de récupération du transporteur. Étant donné que chaque partition a sa propre allocation de ressources et ses propres frais généraux, un grand nombre de partitions exerce une pression excessive sur le cluster. Pour réduire le nombre de partitions dans votre cluster, consultez Mon domaine Amazon Elasticsearch Service est bloqué à l'état de traitement depuis longtemps.

Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?