Comment puis-je résoudre l'erreur « Récupération de la messagerie : n partitions sur m ont échoué » dans les tableaux de bord OpenSearch sur Amazon OpenSearch Service ?

Brève description

Lorsque vous chargez un tableau de bord dans OpenSearch Dashboards, une demande de recherche est envoyée au domaine OpenSearch Service. La requête de recherche est acheminée vers un nœud de cluster qui agit en tant que nœud de coordination de 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 la messagerie. Si votre cluster a un statut de cluster rouge, cela signifie qu'au moins une partition n'est pas attribuée. Étant donné qu'OpenSearch Service ne peut pas récupérer de documents à partir de partitions non attribuées, un cluster dont le statut est rouge génère un message d'erreur de récupération de la messagerie. Si la valeur de « n » dans le message d'erreur de récupération de la messagerie est la même chaque fois, 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, veuillez consulter Affichage des journaux d'erreurs Amazon OpenSearch Service (langue Français non garantie).

Problèmes persistants

Voici un exemple d'entrée de journal pour une erreur de récupération de la 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

• Augmentez votre domaine en basculant vers un type d'instance plus important, ou montez en puissance en ajoutant des nœuds au cluster. Pour plus d'informations, veuillez consulter Création et gestion des domaines Amazon OpenSearch Service.
• Vérifiez que vous utilisez bien un type d'instance adapté à votre cas d'utilisation. Pour plus d'informations, veuillez consulter la rubrique 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 restent inactifs. OpenSearch Service 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 contient de partitions, plus vous avez de chances de recevoir un message d'erreur de récupération de la messagerie. Dans la mesure où chaque partition a sa propre allocation de ressources et ses propres frais, un trop grand nombre de partitions impose trop de pression sur votre cluster. Pour plus d'informations, consultez Pourquoi mon domaine Amazon OpenSearch Service est-il bloqué à l'état « Traitement en cours » ?

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.

Informations connexes

Bonnes pratiques Amazon OpenSearch Service

Dépannage d'Amazon OpenSearch Service