マッピングの爆発

Elasticsearch の検索と Kibana の発見 の JavaScript レンダリングは、すべてのマッピングの深さにおける マッピングされたフィールド のバックインデックスの合計数に依存しています。この合計数が高すぎるか、指数関数的に増加している場合、これを「マッピングの爆発」と呼びます。このようにフィールド数が高くなることは珍しく、通常は このブログに示されているように、上流のドキュメントフォーマットの問題を示唆します。

マッピングの爆発は、以下のパフォーマンスの症状として現れることがあります：

  • CAT ノード がメインノードおよび/またはインデックスシャードをホストしているノードで高いヒープまたは CPU を報告します。これにより、一時的なノードの応答なしやメインの圧倒が発生する可能性があります。
  • CAT タスク がこのインデックスまたはインデックスに関連する長い検索時間を報告します。たとえ単純な検索であってもです。
  • CAT タスク がこのインデックスまたはインデックスに関連する長いインデックス時間を報告します。これは通常、保留中のタスク がコーディネーティングノードがすべての他のノードがマッピング更新リクエストに確認するのを待っていることを報告していることに関連しています。
  • Discover の ワイルドカード用フィールド ページ読み込み API コマンドまたは Dev Tools ページ更新オートコンプリート API コマンドが長時間（10 秒以上）かかるか、ブラウザの開発者ツールのネットワークタブでタイムアウトします。詳細については、Discover のトラブルシューティングに関する手順を参照してください。
  • Discover の 利用可能なフィールド がブラウザの開発者ツールのパフォーマンスタブで JavaScript をコンパイルするのに長い時間がかかります。これにより、一時的なブラウザページの応答なしが発生する可能性があります。
  • Kibana の アラート または セキュリティルール が The content length (X) is bigger than the maximum allowed string (Y) でエラーを返す場合、X は試みられたペイロードで、Y は Kibana の server-maxPayload です。
  • Elasticsearch の起動時間が長い。

防止または準備

マッピング は初期化後にフィールドを削減することはできません。Elasticsearch インデックスはデフォルトで 動的マッピング に設定されており、通常は問題を引き起こしませんが、index.mapping.total_fields.limit をオーバーライドすると問題が発生することがあります。デフォルトの 1000 制限は寛大と見なされますが、10000 にオーバーライドしても、使用ケースによっては目立った影響を与えません。ただし、悪い例を挙げると、100000 にオーバーライドし、この制限がマッピングの合計によって達成されると、通常は強いパフォーマンスへの影響があります。

インデックスのマッピングされたフィールドが大きな任意のキーのセットを含むことが予想される場合、次のことを検討できます：

nested データ型に変更しても、コアの問題は解決されません。

問題の確認

インデックスのフィールド合計を確認してマッピングの爆発をチェックするには：

  • Elasticsearch クラスターのログでエラー Limit of total fields [X] in index [Y] has been exceeded を確認します。ここで X は index.mapping.total_fields.limit の値で、Y はあなたのインデックスです。相関する取り込みソースログエラーは Limit of total fields [X] has been exceeded while adding new fields [Z] で、Z は試みられた新しいフィールドです。
  • トップレベルのフィールドについては、fields=* の [フィールド機能] をポーリングします。
  • get mapping の出力を "type" で検索します。
  • サードパーティツール JQ を使用する場合、get mapping mapping.json の出力を処理できます。
    1. $ cat mapping.json | jq -c 'to_entries[]| .key as $index| [.value.mappings| to_entries[]|select(.key=="properties") | {(.key):([.value|..|.type?|select(.!=null)]|length)}]| map(to_entries)| flatten| from_entries| ([to_entries[].value]|add)| {index: $index, field_count: .}'

インデックスのディスク使用量を分析 を使用して、ほとんどまたはまったくポピュレートされないフィールドを見つけることができます。

複雑な爆発

マッピングの爆発は、個々のインデックスフィールドの合計が制限内であっても、結合されたインデックスフィールドの合計が非常に高い場合も含まれます。症状が最初に データビュー で認識され、resolve index API を介して個々のインデックスまたはインデックスのサブセットに追跡されることは非常に一般的です。

ただし、あまり一般的ではありませんが、バックインデックスの組み合わせでのみマッピングの爆発を経験することも可能です。たとえば、データストリーム のバックインデックスがすべてフィールド合計制限に達しているが、それぞれが互いにユニークなフィールドを含んでいる場合です。

この状況は、データビュー を追加し、その フィールド タブでフィールドの合計数を確認することで最も簡単に表れます。この統計は、全体のフィールドを示し、index:true の場所だけではなく、良好なベースラインとして機能します。

問題が データビュー を介してのみ表れる場合、multi-fields を使用していない場合は、このメニューの フィールドフィルター を検討できます。あるいは、よりターゲットを絞ったインデックスパターンを検討するか、問題のあるインデックスをフィルタリングするためにネガティブパターンを使用することを検討できます。たとえば、logs-* が問題のあるバックインデックス logs-lotsOfFields-* のためにフィールド数が高すぎる場合、logs-*,-logs-lotsOfFields-* または logs-iMeantThisAnyway-* に更新することができます。

解決

マッピングの爆発は簡単には解決できないため、上記の方法で防止する方が良いです。これに遭遇することは、通常、予期しない上流データの変更や計画の失敗を示します。遭遇した場合は、データアーキテクチャを見直すことをお勧めします。以下のオプションは、このページで以前に説明したものに追加されるものであり、適用可能な最良の使用ケースとして適用する必要があります：

インデックスの分割 はコアの問題を解決しません。