Skip to main content

The Forrester Wave™: XDR Platforms 2026年第2四半期

レポートにアクセス
会社概要パートナーサポート|ログイン
Elastic logo
トライアル開始お問い合わせ

トラブルシューティングガイド：Kibana［Discover］の読み込みに関する6つの一般的な問題の解決

By
Stef Nestor

Discoverは、時系列データを検索する、フィルタリング、調査するためのElastic®のコアKibana® UIです。可視化は、データのアグリゲーションや要約に使用されます。Discover UIは、大規模なElasticsearch®の対応に対して耐性がありますが、(圧縮されていない)対応サイズ、マッピングの爆発、ブラウザの制限などが原因で問題が発生する場合があります。 

以下では、読み込みの遅延、タイムアウト、エラーなど、最も一般的な履歴上の問題の概要をまとめ、それらを解決するための順を追ったトラブルシューティングの手順を説明します。注：この記事のAPIはv8.6向けに記述されていますが、一般的なトラブルシューティングの流れは、それ以前および以降のバージョンにも適用されます。

Kibanaイベントログ

ユーザーセッションの確立と読み込み後、KibanaはベースURI /アプリ/discover（または関連するKibana Space固有のURI）経由でDiscoverを読み込みます。このページを読み込むために、ブラウザページはKibanaサーバーに対して3つのAPIを順次リクエストします（必要に応じてKibanaを経由し、以下のElasticsearchサーバーに対してもリクエストが行われます）。

一般的な問題 1：読み込み時のページエラー

Kibanaページの読み込み時にエラーが発生する場合は、ブラウザのネットワークタブを開き、どのシーケンシャルリクエストが失敗しているかを確認してください。調査結果はHARログとしてエクスポートして共有できます。

1. Data viewを読み込む

ブラウザページは、Kibana の Saved Objects エンドポイントを、現在選択されている Data View に対してリクエストします（このオブジェクトは以前のバージョンでは「インデックスパターン」と呼ばれていましたが、v8.0 で明確化のために名称変更されたため、コードは依然として `type:index-pattern` をターゲットにしています）。

POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]

このKibana APIは、保存済みオブジェクトのバッキングエイリアスである .kibana を介してElasticsearch APIに検索を転送します。クエリの翻訳については確信が持てませんが、おそらく以下のようになるでしょう：

GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
 "match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}

注意：保存済みオブジェクトは、タイトルや名前ではなく、Data view の ID で検索されます。エクスポート/インポートまたはコピーを使用してKibana Spaces間や Elasticsearch クラスター間で保存済みオブジェクトを移動すると、インポート中に基盤となる ID が変更されたことによる可視化/ダッシュボード/Discover エラーが発生する可能性があります（回避方法については、保存済みオブジェクトのインポートモジュールを参照してください）。これらのフィールドの違いをデモンストレーションするには：

保存されたオブジェクト
よくある問題 2: Data viewが見つかりません

これが該当する場合、ページ読み込み時に右下に以下のような警告/エラーモジュールが表示されます： "DATA_VIEW_ID" は設定された Data view ID ではありません

このエラーは現在のKibana Spaceのコンテキストで報告されるものであり、Data viewが別のSpaceに存在するかどうかは関係ありません。

2. フィールドを読み込む

次に、Kibana UIがバッキングインデックスの関連フィールドのコンパイルを読み込みます。

API。 最初に、APIリクエストを行います：

GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score

このAPIは、ユーザーが左上でData viewを選択するたびに再トリガーされます。バックエンドでは、KibanaはElasticsearchのフィールド Caps APIからインデックスを返しています。

よくある問題3：マッピング爆発

このAPIの応答時間は、マッピングの爆発によって劇的に影響を受けます。これは、このAPIの圧縮/非圧縮の対応サイズによって部分的に診断できます。通常、これは読み込まれる インデックスマッピング の数に関連しますが、マッピング制限 を超過した結果である可能性もあります。通常、これは3秒を（大幅に）下回りますが、10秒以上かかる場合は確実に遅いと判断すべきです。

よくある問題 4：フィールドの競合

エラーは、歴史的にインデックス間のフィールド名の競合から発生してきました。根本的なインデックスマッピングを修正するのが望ましいですが、ランタイムフィールドを適用して、一時的な上書きとして不適切なインデックスのマッピングタイプを修正することもできます。

JS. APIの結果が返された後、左側のドロワー（「Selected Fields」および「Available Fields」を表示）が開いている場合、ブラウザのJavaScriptがこれらのフィールドに対して要約の分析的処理を行います。処理が遅い場合、ブラウザのNetworkタブでは、APIリクエストは終了しているものの、後続の(3)のリクエストが数秒間開始されない状態として表示されます。ユーザーが通常気づくのは10秒以上経過してからです。

フィールドのスクリーンショット

このJavaScriptのコンパイル時間は、ブラウザーのDevToolの［Performance］タブから診断されます（例：Chrome、Firefox、Edge；共有用にHAR形式と同等のものをエクスポートすることも可能です）。

3. 検索するの読み込み

最後に、ブラウザページがAPI検索リクエストを行います。このAPI検索リクエストはKibanaサーバーを経由しますが、Elasticsearch APIに直接リクエストを行う場合とほぼ同じ時間で完了する（はず）です。

API. このURIのデフォルトは以下の通りです：

POST /internal/bsearch {REQUEST_BODY_HERE}

しかし、高度な設定のcourier:batchSearchesがfalse（<v8.0）に設定されている場合、その場合、代わりに以下のAPIがリクエストされます：

POST /internal/_msearch {REQUEST_BODY_HERE}
（クイックページ検索を支援するため：#inspectViaDevTools。）この検索するための処理に時間がかかる場合は、通常、ルックバック時間を可能な限り短くします（例：1～5分）。次に、［Discover］>［Inspect］の順に移動します。（以下の緑色のボックスにある）合計読み込み時間を、［Statistics］>「Query time」と比較してクイックチェックします。
インスペクター-1

「クエリ時間」（Elasticsearchが検索するのにかかる時間）とKibanaが報告する時間の間には差が生じることが予想されますが、後者が前者から桁違いに乖離していないかを確認する必要があります。乖離がある場合は、例えばKibanaサーバーの負荷、HTTP圧縮の無効化、あるいは一般的なレンダリングの問題などが示唆されます。

Kibanaサーバーの負荷と一般的なレンダリングの問題を切り分けて、検索する内容を調査するために、さらに［Inspect］（検査）>［Request］（リクエスト）>［Open in Console］（コンソールで開く）（別名：DevTools）へと進みます。視覚的には以下の通りです。

インスペクター-2

次に、このAPI検索リクエストをDevToolsとElasticsearch APIのcURLの両方で個別に実行し、Discover、DevTools、Elasticsearch API間での全体的な応答時間の違いを確認します。

一般的な問題 5: Elasticsearch APIでクエリが遅い場合

Elasticsearch も他の2つと同様に遅い場合は、元の Discover ビューで最適化されていない検索/フィルターが原因である可能性があります。フィルターや検索が適用されていない場合（または適用せずに再現する場合）、CAT Nodes、CAT Threadpools（特に検索スレッド）、およびCAT Tasks（長時間実行されているタスク用）を通じて、Elasticsearch の一般的なパフォーマンスを確認します。クラスター全体の問題が見つからない場合は、Discover で選択された異なる Data view 間で検索の対応時間を比較し、その後、これらの検索に関連するQuery Profiling（検索リクエスト本文に profile: true を挿入した後）を比較します。

JS. APIの結果が返されると、ブラウザーのJavaScriptが実行され、1) 表示テーブルの概要（列表示のオン/オフを切り替えられる中央下の「Documents」テーブル）または 2) 「フィールド Statistics」（ベータ版、Advanced Settingsの Discover:showFieldStatisticsで切り替え可能）のいずれかが読み込まれます。

よくある問題 6: マッピング爆発によるレンダリング時間への影響

マッピングの爆発は大規模な結果セットにつながる可能性があり、過去にはブラウザーでのパフォーマンス低下の原因となってきました（例：kibana#144673）。マッピングの爆発は、Chromeの「エラー: maximum call stack size exceeded」のようなブラウザー固有のエラーを引き起こすことがあります。これはシークレットモードでも再現し、FirefoxやSafariでは発生せず、Chromeのアップグレードによってのみ解決する場合もあります。しかし、結果が返された後にエラーなしでレンダリング処理が非常に遅くなる場合は、ブラウザーのパフォーマンスプロファイルを記録して、レンダリングの遅延原因を調査する必要があります。出力の確認については、Kibana GitHub、Elastic Discuss、またはサポートケースを開いていただければ、弊社のチームが喜んでお手伝いします！

連鎖的な影響

(ページ検索を迅速化するため：#devToolsAuto。) マッピングの爆発（Mapping Explosions）の可能性をトラブルシューティングしている間、DevToolsはDiscoverよりも応答が遅くなる場合があり、URIによってリクエストが予期されていないときでも左上のアイコンが読み込まれます。

GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
これは、DevTools > Settings > 「Autocomplete」から、（少なくとも）Fieldsを無効にし、Refresh Frequencyを増やすことで制御されます。
コンソール設定

これらのリクエストは、頻度や負荷によっては、1) ページのクラッシュや「ページを待機しますか？」というバナーを表示させる原因となるローカルブラウザー、および 2) Kibanaサーバーの動作を遅くする可能性があります。この変更は、ログイン中のユーザーに固有のものです。

まとめ

Discoverは、クラスター内の複数のインデックスのデータを調査するための簡単な方法です。一部の設定や構成により、このUIの読み込みが不必要に遅くなることがあります。このガイドでは、こうしたさまざまな落とし穴の影響について説明しましたが、適切なデータ管理を行うことで、これらすべてを回避できます。データ管理のヒントについては、Elasticsearchドキュメントをご覧ください。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

Elastic Cloudの無料トライアルに登録

お好みのクラウドプロバイダーを選び、多彩な機能を組み込んでデプロイできます。Elasticsearchを開発するElasticが、クラウド向けのElasticクラスターで高度な機能とサービスを提供します。

無料トライアルを始める