Comment résoudre l'erreur « Courier fetch : n of m shards failed » (Récupération de la messagerie : n partitions sur m ont échoué) dans Kibana sur Amazon Elasticsearch Service ?

Date de la dernière mise à jour : 16/12/2020

Lorsque j'essaie de charger un tableau de bord dans Kibana sur mon domaine Amazon Elasticsearch Service (Amazon ES), il renvoie l'erreur de récupération de la messagerie. Comment puis-je résoudre ce problème?

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 » (Récupération de la messagerie : n partitions sur m ont échoué) 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 votre modèle d'index comporte plusieurs index qui utilisent le même nom, mais des types de mappage différents, vous pouvez obtenir une erreur de récupération de messagerie. Si votre cluster a un état de cluster 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 l'état est rouge génère une erreur de récupération de messagerie. Si la valeur de « n » dans le message d'erreur de récupération de la messagerie est la même chaque fois que vous recevez l'erreur, il s'agit probablement d'un problème persistant. Consultez les journaux des erreurs d'application pour des suggestions de dépannage.
    Remarque : les problèmes persistants ne peuvent pas être résolus via de nouvelles tentatives ou l'allocation de ressources de cluster supplémentaires.
  • Problèmes transitoires : les problèmes transitoires incluent les rejets de groupes de threads , les dépassements de délais de recherche et les disjoncteurs de circuits de données de champs déclenchés. Ces problèmes se produisent lorsque vous n'avez pas suffisamment de ressources de calcul sur le cluster. Un problème transitoire est probablement la cause lorsque vous recevez le message d'erreur par intermittence avec une valeur de « n » différente à chaque fois. Vous pouvez également surveiller les métriques Amazon CloudWatch telles que CPUUtilization, JVMMemoryPressure et ThreadpoolSearchRejected pour déterminer si un problème transitoire est à l'origine de l'erreur de récupération de messagerie.

Résolution

Activez les journaux d'erreurs d'application pour le domaine. Les journaux peuvent vous aider à identifier la cause racine et la solution aux problèmes transitoires et persistants. Pour plus d'informations, consultez Affichage des journaux d'erreurs Amazon Elasticsearch Service.

Problèmes persistants

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

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

La plupart des problèmes transitoires peuvent être résolus en allouant plus de ressources de calcul ou en réduisant l'utilisation des ressources pour vos demandes.

Allocation de ressources de calcul supplémentaires

  • Mettez votre domaine à l'échelle en basculant vers un type d'instance plus grand, ou procédez à une mise à l'échelle horizontale en ajoutant plus de nœuds au cluster. Pour plus d'informations, consultez Création et gestion de domaines Amazon ES.
  • Vérifiez que vous utilisez bien un type d'instance adapté à votre cas d'utilisation. Pour plus d'informations, consultez Choix des types d'instances et tests.

Réduire l'utilisation des ressources pour vos demandes

  • 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 récupérer de documents à partir de nœuds surchargés.
  • Vous pouvez également réduire la portée de votre requête. Par exemple, si vous effectuez une requête basée sur l'intervalle de temps, réduisez la fourchette de dates ou filtrez les résultats en configurant le modèle d'index dans Kibana.
  • Évitez d'exécuter les requêtes select * sur les index de grande taille. Utilisez plutôt des filtres pour interroger une partie de l'index et rechercher le moins de champs possible. Pour plus d'informations, consultez Réglage de la vitesse de recherche et Contexte de requête et de filtre sur le site Web Elasticsearch.
  • 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 de la messagerie. Étant donné que chaque partition a sa propre allocation de ressources et ses propres frais, un grand nombre de partitions impose trop de pression sur votre cluster Elasticsearch. Pour plus d'informations, voir Pourquoi mon domaine Amazon Elasticsearch Service (Amazon ES) est-il bloqué à l'état « En cours de traitement » ?

Voici un exemple d'entrée de journal pour une erreur de récupération de la messagerie causée par un problème transitoire :

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 de files d'attente des groupes de threads de recherche. Pour résoudre ce problème, mettez à l'échelle votre domaine en choisissant un type d'instance plus grand. Pour plus d'informations, consultez Groupes de threads sur le site Web Elasticsearch.


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


Besoin d'aide pour une question technique ou de facturation ?