Amazon OpenSearch Service の OpenSearch Dashboards で発生する「クーリエ取得: m 個のうち n 個のシャードが失敗しました」エラーを解決するにはどうすればよいですか?

最終更新日: 2021 年 9 月 27 日

Amazon OpenSearch Service ドメインの OpenSearch Dashboards でダッシュボードをロードしようとすると、クーリエ取得エラーが返されます。これを解決するにはどうすればよいですか?

簡単な説明

注: Amazon OpenSearch Service は、Amazon Elasticsearch Service の後継サービスです。

OpenSearch Dashboards でダッシュボードをロードすると、検索リクエストが OpenSearch Services ドメインに送信されます。この検索リクエストは、コーディネーティングノードとして機能するクラスターノードにルーティングされます。「Courier fetch: n of m shards failed」エラーは、 コーディネーティングノードが検索リクエストのフェッチフェーズを完了できない場合に発生します 。通常、このエラーを引き起こす原因としては 2 つが考えられます。

  • 持続的な問題: マッピングが競合しているか、シャードが未割り当て。インデックスパターンの中に、同じ名前だが異なるマッピングタイプを使用する複数のインデックスが存在する場合、クーリエ取得エラーが発生することがあります。クラスターのクラスターステータスが赤になっている場合は、割り当てられていないシャードが少なくとも 1 つ存在します。OpenSearch Service は未割り当てのシャードからドキュメントを取得できないため、ステータスが赤になっているクラスターは、クーリエ取得エラーをスローします。クーリエ取得エラーメッセージの「n」の値が、エラーを受け取るたびに同じである場合は、持続的な問題である可能性があります。アプリケーションエラーログで、トラブルシューティングに関する提案を確認します。
    注: 持続的な問題は、クラスターリソースを再試行したり、さらにプロビジョニングしたりしても解決できません。
  • 一時的な問題: 一時的な問題には、スレッドプールの拒否、検索タイムアウト、およびフィールドデータサーキットブレーカーの失敗が含まれます。これらの問題は、クラスターに十分なコンピューティングリソースがない場合に発生します。毎回「n」値が異なるエラーメッセージを断続的に受け取っている場合、一時的な問題が原因である可能性があります。CPUUtilizationJVMMemoryPressureThreadpoolSearchRejected などの Amazon CloudWatch メトリクスを監視することで、クーリエフェッチエラーの原因が一時的な問題なのかを確認することもできます。

解決方法

ドメインのアプリケーションエラーログを有効にします 。ログは、根本原因の特定と、一時的な問題および持続的な問題の両方に対する解決策を見つけるのに役立ちます。詳細については、Viewing Amazon OpenSearch Service error logs を参照してください。

持続的な問題

次に示すのは、持続的な問題が原因のクーリエ取得エラーのログエントリの一例です。

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

この例は、問題が request_departure_date フィールドにより引き起こされたことを示しています。このログエントリからは、インデックス設定に fielddata=true を設定するか、キーワードフィールドを使用することで、問題を解決できることが読み取れます。

一時的な問題

一時的な問題のほとんどは、より多くのコンピューティングリソースをプロビジョニングするか、クエリのリソース使用率を下げることによって解決できます。

より多くのコンピューティングリソースをプロビジョニングする

クエリのリソース使用率を下げる

  • シャードとクラスターのアーキテクチャに関するベストプラクティスに従っていることを確認します 。クラスターの設計に不備がある場合など、可能なすべてのリソースを使用できないことがあります。一部のノードがアイドル状態になってしまうと、他のノードが過負荷になり得ます。OpenSearch Service は、過負荷になったノードからドキュメントを取得できません。
  • また、クエリの範囲を縮小することもできます。例えば、フレームに関してクエリする場合は、Kibana でインデックスパターンを設定して、日付範囲を狭めるか結果をフィルタリングします。
  • 大きいインデックスで選択 * クエリを実行しないようにします。代わりに、フィルターを使用してインデックスの一部をクエリし、できる限り少ないフィールドを検索します。詳細については、Elasticsearch ウェブサイトの「検索速度を調整する」と「クエリとフィルターのコンテキスト」を参照してください。
  • インデックスを再作成し、シャードの数を減らします。クラスター内のシャードが多いほど、クーリエ取得エラーが発生する可能性が高くなります。各シャードにリソース割り当てとオーバーヘッドがあるため、多数のシャードはクラスターに過剰な負荷をかけます。詳細については、Amazon OpenSearch Service ドメインが「処理中」状態のまま変わらないのはなぜですか? を参照してください。

次に示すのは、一時的な問題が原因のクーリエ取得エラーのログエントリの一例です。

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

この例では、問題の原因はスレッドプールの検索キューが拒否されたことにあります。この問題を解決するには、より大きいインスタンスタイプを選択してドメインのスケールアップを行います。詳細については、Elasticsearch ウェブサイトの「スレッドプール」を参照してください。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?