ネストされたオブジェクトの集約の場合は+1。

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

明確にするために、現在、kibana4でネストされたfilter / query / aggを実行する方法はありませんか？

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1ネストされたオブジェクトの非正規化は、マッピングの爆発的な増加につながる可能性があるため、常にオプションであるとは限りません。

マッピング：

{ 
 "timestamp":{ "type":"date"},
 "cluster_id": { "type":"string"},
 "pools":{
    "type":"nested",
    "properties":{
      "size":{
        "type":"long"
      },
      "name":{
        "type":"string",
        "index":"not_analyzed"
      }
    }
  }
}

まず、折れ線グラフで、各プール名の時間の経過に伴う平均サイズを表示できるようにしたいと思います。 名前が多すぎて非正規化するのは得策ではないと仮定すると、グラフに多くのグラフが表示される可能性があります。 このような場合に対処するには、ネストされたアグリゲーション内でフィルターアグリゲーションを使用できることも有益です。 上位の検索でネストされたフィールドをフィルタリングできることも素晴らしいことです。

物事をさらに面白くするために、次のような集計を視覚化できることは本当に素晴らしいことです。

"aggs": {
        "poolagg": {
            "nested": {
                "path": "pools"
            },
            "aggs": {
                "old": {
                    "filter": {
                        "term": {
                            "name": "some pool name"
                        }
                    },
                    "aggs": {
                        "avg_size": {
                            "avg": {
                                "field": "size"
                            }
                        },
                        "distribution": {
                            "histogram": {
                                "field": "size",
                                "interval": 5
                            },
                            "aggs": {
                                "pool_to_cluster": {
                                    "reverse_nested": {},
                                    "aggs": {
                                        "clusters": {
                                            "cardinality": {
                                                "field": "cluster_id"
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }

+1

+2

+1

+1

+1

+1

+10！

これでパワフルになります！

だから誰かがこれを明確にすることができます。 Kibana4beta1に関するこの投稿（https://www.elastic.co/blog/kibana-4-beta-1-released）には、「Kibana 4は、Elasticsearchのネストされた集計の機能をマウスをクリックするだけで実現できる」と記載されています。ネストされたオブジェクトを含むドキュメントにビジュアライゼーションを作成できません。 また、インデックステンプレート内のネストされたオブジェクトが「ネストされた」とマークされていることを確認しました。 では、Kibanaのネストされた集計のサポートは、ESのネストされたオブジェクトのサポートと同じではありませんか？ 何が足りないのですか？ ありがとう。

@ cslinuxboy-ここでは「nested」を使用して、複数のフィールドを介したグループ化を参照していると思います。たとえば、「aggregate by time nestedobjects 」のプラットフォームで使用される「nested」ではありません）

@ Alex-Ikanow-返信ありがとうございます。 残念ながら、現時点ではこれは不可能です。 彼らのベータ1投稿の誤解を招く説明を読んだとき、私は私の希望を抱きました。

視覚化集約内のネストされたオブジェクトのサポートのための+1。

+1

私は現在、問題なく機能しているように見える回避策として親子関係を使用しています。

@calvdee Kibana検索バーで機能するhas_parentまたはhas_childクエリを取得しましたか？ これは私たちにとってはうまくいきません、そしてそれは大きな問題です、あなたがこれを動かしてくれて私に知らせることができれば私は永遠に感謝します...ありがとう!!!

いいえ、私たちのユースケースでは、請求書データにインデックスを付けているため、すべての親に子があり、すべての子に必ず親がいるため、通常のクエリが機能します（画像を参照）。

@calvdee返信ありがとうございます！ 同様のデータモデルがありますが、キバナで子供たちが親を見つけられるようにしたいのですが、機能していません：0（

心配ありません、頑張ってください！

木、2015年3月26日には、午前11時36分ajrasch [email protected]は書きました：

@calvdee https://github.com/calvdee返信ありがとうござい
同様のデータモデルを持っていますが、親を見つけることができるようにしたい
キバナの子供たち、それは機能していません：0（

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/elastic/kibana/issues/1084#issuecomment-86575796 。

+1

+1

_mappingフィールドを読んだので、特定のフィールドがいつネストされているかを知っておく必要があります。そのようなフィールドがクエリまたはファセットで選択されたときに、正しいネストされたファセット/クエリを自動的に適用できないのでしょうか。

はい、：+ 1：これについて。 CLIで正しいネストされた集計を記述でき、curlを使用してデータをプルできますが、JSON編集ボックスを使用しなくても、Kibanaの[視覚化]タブでデータを機能させる方法が見つかりませんでした。 確かに、私はその機能（ボックス）を使用したことはありませんが、既存のアグリゲーションに「追加」することしかできず、新しいアグリゲーションを最初から作成するために使用することはできないようです...（修正していただければ幸いです）私がこれについて間違っているなら！）。

はい、ネストされた型の集計は重要であり、フラットデータの特定の問題を解決するため、より広く使用されるようになっています。

Kibana4がESの視覚化製品である場合、すべてのES集約をサポートする必要があります。

少なくともKibana4の

+1

+1

+1

+1

+1

＃3729から:-)

集約オプション「子ドキュメント」が欲しいのですが
（日付ヒストグラム、ヒストグラムなどの後）
子のクエリDSLのパラメータは、次のように集約されます。
「子タイプ」、「フィールド」など。

これにより、子にネストされた集計を作成できます
ドキュメント。

私はそのようなクエリを使用して作成することができないようです
高度な編集機能。 誰かができるかもしれません
私を啓発します。

ありがとう

+1

+1

+1

+1は本当にこの能力を必要とします。 回避策としてlogstashを使用してすべての親を取り除くことはできますが、何百ものフィールドがあるため、巨大な構成ファイルが必要になります。

+1誰かがこれが計画されているかどうか知っていますか？

+1

現在、「ネストされた」タイプのオブジェクトの使用を停止するようにマッピングの一部を変更することを検討しています。これらのフィールドのいずれにもKibanaビジュアライゼーションを作成できないためです。 問題が少なくともロードマップ上にあることを私が知っていれば、それはその決定を下す上で本当に大きな助けになるでしょう。

@ benjismith-私も弾丸を噛み、データの処理をネストされたドキュメントから親/子ドキュメントに切り替えました。 これまでのところうまく機能していますが、私はあなたに同意します。 これがKibanaの機能になる可能性があるかどうかを知っておくと、私たち全員がそれを待つか、先に進むことができます。

幸運を祈ります。

+1

+1

ネストされた型の集約サポートの場合は+1

+1

+1

+1

+1

+1

+1

ネストされたドキュメント内の特定のフィールド間で単純な集計（たとえば、上位の値を見つけるためのフィールドの「用語」集計）を実行しようとしている場合は、Elasticsearchマッピングに「include_in_parent」設定を追加することを検討してください。 これにより、親レベルのネストされたドキュメントにフラット化されたバージョンのフィールドが作成されます。

https://www.elastic.co/guide/en/elasticsearch/reference/1.7/mapping-nested-type.html

これらのフィールドは、左側の[検出]フィールドリストには表示されませんが、ドキュメントの詳細ビューには配列フィールドとして表示されます。 ただし、Visualizeの指標リストの個々のフィールドにアクセスでき、それらに対して集計を実行できます。

これは、ネストされたドキュメント構造に基づくウォッチ履歴を視覚化するために行っていることです（「results.actions」を参照）。

{
   ".watch_history-2015.06.12": {
      "mappings": {
         "watch_record": {
            "dynamic": "strict",
               "result": {
                  "dynamic": "true",
                  "properties": {
                     "actions": {
                        "type": "nested",
                        "include_in_parent": true,
                         …
}

+1

+1

+1

+1

+1

別の+1の代わりに...ネストされた型の集計がどこにあるかを要約すると役立つかもしれません。

私はきれいなグラフを作成する方法を学ぶために5日ですので、これのいずれかが明白であるならば私を許してください。

どうしたの？

それでもElasticSearchまたはLuceneクエリの問題ですか？

集計では解決されませんが、入力ボックスにelasticsearchJSONを入力できるようにすることで解決されます。 これは理想的ではありませんが、elasticsearchがluceneクエリ文字列構文を拡張してネストされたフィールドを指定しない限り、最善の方法です。 --rashidkpcの1年前のコメント

Kibanaの修正は可能ですか？

ES / Luceneの場合、Kibanaはその間に中間のハック/ソリューションを提供できますか？ ES6シムとベンダープレフィックスCSSを考えてみてください。

ネストされたマッピングの場合：Kibanaのパネルのエディターでネストされたものを選択する（そしてパスを構成する...）機会。 ボブマーサー

または：

_mappingフィールドを読んだので、特定のフィールドがいつネストされているかを知っておく必要があります。そのようなフィールドがクエリまたはファセットで選択されたときに、正しいネストされたファセット/クエリを自動的に適用できないのでしょうか。
アレックス-イカノウ、OP

誰かが解決策をハッキングしていますか？ ハッキングする場所のアイデア/方向性を持っている人はいますか？

回避策？

誰かがnested / include_in_parentで成功しましたか？ dynamic: static 、 dynamic: true必要ですか。 私の試みは0の結果で失敗しました。 tbragin

rashidkpcによって上記で言及されたJSON入力ボックスの例はありますか？

親/子

これが私の次のステップです。 これについてはオンラインでたくさんの参考資料があると確信していますが、この代替案の例/チュートリアルを参照しても問題はありません。

キバナの内部に関する知識が不足しているため、エラスティックとキバナの間にRESTプロキシを作成することを検討しています。 用語ベースの検索条件を指定してKibanaから特定のタイプをクエリする場合、このプロキシは最初に親タイプをクエリして、検索条件を満たす（メモリに適合する）親のセットを見つけます。 次に、これらの親のすべての子を検索し、すべての親フィールドが追加された非正規化されたkibanaにこれらを返します。 これにより、Elastic Searchに親子モデルを設定して、ストレージの爆発的な増加によってすべてが数十億の子オブジェクトに非正規化されるのを防ぎ、同時に親フィールドに基づいてデータをグラフ化できます。

理想的には、これはKibanaの一部でした。 世界はフラットではありません！

+1

+1。 以前は、関数スタックまたはurl_argsを異なるフィールドに分割していました。 ただし、これには、クラスター状態が大きすぎ、マッピング更新アクションが多すぎます。 したがって、これをネストされたオブジェクトに変更します。 さて、K4でaggsが必要です...。

+1

+1には、親子の集計の視覚化が必要です。

+1

Kibanaを使用したいすべてのElasticユーザーがログ分析にKibanaを使用しているとは思わないでください。 ネストされたオブジェクトを含む広範なデータがクラスターに入力されており、データをプルして別のシステムに変換することなく分析を実行できるようにしたいと考えています。

ネストされた集計、ネストされたクエリ、さらにはreverse_nested集計を作成できることは必須です。 Kibanaにこの機能がない時間が長いほど、Elastic / Kibanaを使用せずに代替手段を早く見つける必要があります。 この種の機能に使いやすいUIを提供することが難しい場合は、必要なデータを返すElasticの完全なjsonクエリをユーザーが提供する機能を提供することから始めます。

+1

@ppadovaniに同意し

kibana 4.1コードを見ることにしました..（マスターは2.x Elasticでしか機能しないため使用できません）..間違っている場合は修正してくださいが、何かを行うための簡単な最初のステップのように思われますこれらの行：

1）集計の「詳細」折りたたみ可能領域の下に、「ネストされたパス」などのテキストフィールドを追加します。
2）ユーザーがそのフィールドに文字列を入力すると、これが設定されている集計の前に、次のようにネストされた集計が追加されます。
"aggs"：{
"2"：{
"nested"：{"path"： "foo"}、
"aggs"：{
"3"：{
"date_histogram"：{

ネストされたオブジェクトの複数のレベルの場合を処理するために、ユーザーがネストされたパスを追加できるようにする+を追加できます。 さらに、逆ネストを処理するには、「逆」というラベルの付いたチェックボックスを追加するだけです。

これにより、少なくとも限定された「ネストされた」集約サポートが提供されます。

ネストされたクエリのサポートについて、私が短期的に考えることができる唯一の解決策は、ユーザーが手書きのエラスティック検索jsonを入力できるようにすることです。

+1

これらすべてに+1し、ユーザーがハードコードされたElastic Searchjsonを入力できるようにします

+1

+1

+1。 環境の視覚化のニーズにKibanaを使用することに非常に興奮していましたが、ネストされたオブジェクトの視覚化がサポートされていないため、Kibanaを目的に使用するのはかなり苦痛です。

+1、ちょうどこれに遭遇しました。

+1

+1

+1

+1

+1

少なくとも82人があなたの「+1」を取得しますが、これは役に立ちません。

私は強く反対します。 より多くのデータが悪いことはありません。

私のチームと私はこれに取り組んでおり、週末までに何かを見せたいと思っています。

編集： https ：

+1

+1

+1

完了し、ここでプルリクエストを作成しました：
https://github.com/elastic/kibana/pull/4806

見ている人のためのクイックアップデート... Elasticsearchcoを待っています。 CLAを確認するために、そうでなければ私は行くのは良いことだと思います。

+1

+1も

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

はい、お願いします。

+1

+1

+1

+1

4.1に対するプルリクエストはクローズされ、マスターに対するプルリクエストが優先されます。

https://github.com/elastic/kibana/pull/5411

これの4.1バージョンが必要な場合は、正しいコードでプルリクエストを再度開くことができます。

+1

+1

+1

+1

この問題で何がブロックされているのかわかりません。
https://github.com/elastic/kibana/pull/5411を待機しているプルリクエストがあり

ここには貢献する準備ができている人々がいます。 このPRをマージするには何をする必要がありますか？

間違いなくもっと+1が必要です

@ Filirom1私たちの何人かは

素晴らしい ：-）
ありがとう ！

＃5411を見てみましたが、残念ながら今の方向性ではありません。 ＃5411はストップギャップを実装しましたが、フィルタリングや検索などの重要な機能が機能しなくなりました。 また、ネストされた集計の基本的な実装を理解していない人にとっては、aggビルダー自体が壊れているように見えました。 座って深く調べた後、ネストされたドキュメントをまとまりのある方法でサポートするための作業量が膨大であることに気付きました。

それは、私たちがこれをしたくないということではなく、私たちがそれを行う場合、それを回避するだけでなく、適切にそれを行いたいということです。

多くの人がリレーショナルデータの視覚化に関心を持っていることを認識していますが、他の優先事項や懸念事項を考慮すると、現時点ではこのプロジェクトに専念するリソースがなく、近い将来にロードマップに追加することを約束できません。

参考までに、内部分析にネストされた集計を使用したkibanaを使用することを望んでいましたが、最終的には、rdbmsに直接配置される商用製品「Looker」を使用することになりました。 多くの非技術者が製品に関する日々の質問をライブデータベースで閲覧できるようになったため、Elastic開発者はリレーショナルモデルの探索を簡単にするために何をしたかを確認することを強くお勧めします。 いくつかの製品を評価したところ、Lookerがトップになりました。いつか、Kibanaで同様の機能が見られることを望んでいます。

Rashidの最新のコメントとこの機能を大いに待っていることを考えると、この問題を解決することをお勧めします。 この問題が未解決のままである場合、近い将来にこれが実装される可能性があるという誤った希望をユーザーに与えるだけです。 開発者がそれを実装する方法を理解するためのリソースを得るまで、それを閉じてアイデアをベンチに入れましょう。

プルリクエストから私の投稿をコピーする：

ここに解決策がありますが、それはかなりの量の作業を必要とし、私には時間がありません。 これをJAVAに実装したので、これが可能であることがわかります。

1）各インデックスマッピングは、ネストされたフィールドをプルして理解する必要があります。
2）Elasticsearchを使用するのではなく、簡略化されたクエリ言語を提供するカスタムASTを構築します。
3）ASTを理解し、クエリを検証して適切なJSONに変換できるクエリアダプターを構築します。
4）ネストされたフィールドの内部理解に基づいてネストされたフィールドを適切に処理するように、Kibanaの集計を更新します。

これを行うことは不可能ではなく、かなりの作業が必要です。 上記を実装する利点には、クエリの検証と簡略化された構文が含まれます。 たとえば、ASTを使用すると、次のようなクエリを作成できます。

（owner.user = "/ users / 00a0 / 18066271-29f0-40af-83ad-e5a0c8fc5944"）AND（druid = "/ druids / 0060 / 77dd14b1-b7f0-4851-9ef8-74daa18d9d4d"）AND（（owner.lastMessageReceived。挿入> = 0）OR（conversationLifecycleState = "RESERVATION_REQUEST"））AND（owner.conversationArchived = false）AND（（units.site IS NULL）OR（units.site IN {"HOMEAWAY_DE"}））AND（（inquiry.inserted > = 0）OR NOT（reservation.availabilityStatus = "DELETE"））AND NOT（owner.markedSpam = true）AND（lastMessage.inserted> = 0）

既存の言語でこのクエリをどの程度正確に行うことができますか？

IMHO-行動する前にElasticsearchからの涅槃を待つことは、採用の減少とKibanaのユーザーの喪失につながります。

私がマーケティングをしているように聞こえるのは嫌いですが、これは関係があります。 （見られた人々は他の製品に言及します。）

大量のネストを使用していた多くのpplが、実際にリレーショナルデータを検索したいと考えていたため、レコードをネストすることになりました。 （パドヴァニ、これはあなたの場合かもしれません、私は「ユーザー」「メッセージ」などを見ます。これらは別々の記録として非常にうまく保存されます）
これが、SIREn Join Elasticsearchプラグインと、このためのフィルターと機能を提供するフレンドリーなKibanaフォークを作成した理由です。

現在、すべての人の利益のために、Kibiを可能な限りKibana 4.4（別名5.0）互換のプラグインにするよう取り組んでいます。

参加プラグインは昨日リリースされ、オープンソースでもあります。

その間、利用可能なバージョンhttp://siren.solutions/kibiは率直に言って魅力のように機能し、多くのお客様がネストされたデータを必要としなくなっていました。

jccq：Kibiやjoinプラグインを知らなかった。 情報をありがとう！

+1

+1
これは必須の問題です...

@jccq私たちのユースケースは、クエリのみに参加することではなく、「joined」エンティティまたは「view」を使用して、独自のライフサイクルを持つ真のエンティティデータと呼びます。 これにより、クライアントはAPIに対して複数のGET呼び出しを行うことなく、結合されたデータをプルできます。

Kibanaでのネストされたサポートに関しては、アプローチを進化させており、リソースと時間によっては、第2四半期以前にコミュニティと共有できるものがあるかもしれません。 この新しいアプローチは、集計とクエリの両方でシームレスにネストをサポートします。 それはまだ実装の非常に初期の段階であるため、これ以上は言いません。

+1

@ppadovaniあなたが1人です！

+1

+1

+1
それは私たちにとって本当に重要です。
私たちはこの機能をほぼ1年待っています...

+1

更新：作業負荷のため、新しいブランチが少なくとも1か月間予備フィードバックまたはテストの準備ができていないようです。 しかし、私は前進するにつれてコミュニティからフィードバックを集めるために自分がしていることを提案したかったのです。

基本的な設計は、次の2つのことを中心に展開されます。

1）Kibana自由形式クエリフィールドの新しいクエリパーサー。 このパーサーは、標準のBison構文定義を使用します（私が使用しているjavascriptバージョンについては、Jisonプロジェクトを参照してください）。 私が使用しているBNFは、Elasticsearchに対するカスタムクエリ言語としてHomeawayで使用している既存のBNFに基づいています。 例については、上記の私のコメントを参照してください。 私はこのアプローチを選択して、必要に応じてコミュニティによる将来の拡張を可能にしました。

Kibanaでクエリパーサーを動作させていますが、ユーザーがKibanaで使用されている既存のクエリスタイルとこの新しいスタイルを切り替えることができるようにするための作業がまだあります。

2）mapper.jsのgetFieldMapping呼び出しをgetMappingに変更し、結果を異なる方法で処理して、フィールド上のネストされたパスがキャプチャされ、Kibanaが格納するフィールド情報に追加されるようにします。

クエリがパーサーに入力されると、フィールドに正しく名前が付けられているだけでなく、提供された値がフィールドタイプに対して有効であることが検証されます。 つまり、日付フィールドが日付を取得するか、ブール値にブール値が与えられました。 さらに、ネストされたフィールドはパーサーによって自動的に処理され、現在使用されている単純なクエリ言語の代わりに、適切なElasticsearchクエリjsonが生成されます。

最後に、集計の場合、フィールドにネストされたパスに関する手がかりが含まれるようになったため、以前のブランチに対して作業して、選択したフィールドに基づいて必要に応じてネストされた集計を自動的に挿入するのは簡単です。

マイルストーン：
1-パーサーを機能させ、クエリを生成する
2-mapper.jsを更新し、ネストされたクエリのサポートを実装します
3-ネストされた集約サポートを実装する
4-テスト/クリーンアップ

このアプローチに関するフィードバックをいただければ幸いです。 ありがとう！

上記の更新：

• パーサーが完了しました
• リバースパーサーが完了しました（elasticsearch jsonを取得し、カスタムクエリ言語に変換し直します）
• Kibanaは、nestedPathsを計算してフィールドに保存するようになりました
• パーサーはフィールド情報にアクセスできるようになりました

まだやること：

• 両方のパーサーでのネストされたパスのサポート
• 使用するクエリスタイルをユーザーが切り替えられるようにするUI構造。および、レガシークエリを保存/使用できるようにします。
• パーサーでのエラー処理を終了し、UIが解析の問題/間違いをどのように表示するか
• クエリ内のフィールド名の先行入力サポートを提供するUI構造
• バケット/メトリックのネストされたサポート
• ユニットテスト、ユニットテスト、ユニットテスト。
• ...？

+1

アップデート：

• パーサーはネストされた情報を自動的に処理/挿入します
• アグリゲーションは、ネストされた情報を自動的に処理/挿入するようになりました

TODO：

• クエリスタイル選択のUIが変更され、クエリを使用してスタイル選択がkibanaインデックスに保存されます。
• パーサーエラーのエラー処理、およびUIが解析の問題/間違いを表示する方法
• クエリの構築/書き込みのUIタイプアヘッドサポート
• ユニットテスト、ユニットテスト、ユニットテスト..

プラン：
強いスーツではなく、UIの作業で少なくともある程度の進歩を遂げたいと思っています。それから、フィードバック/貢献を可能にするために、ブランチ/フォークをHomeAwaygithubリポジトリにプッシュします。 これが終わったら、ここにもう一度投稿します。フォークを引っ張って遊んでみたいという方は、大歓迎です。 十分に磨き上げたら、公式のプルリクエストを作成します。

最後に、この作業はKibana4.3.1ブランチに対して行われています。

「include_in_parent」と「include_in_root」を使用して、ネストされたドキュメントから集計を実行する目的で選択したフィールドをトップレベルにコピーすることについての以前のコメントの続きとして、ES2.0で「copy_to」機能が導入されました。この種のもののオプション： https ：
将来のESバージョンで「copy_to」を優先して「include_in_parent」と「include_in_root」を非推奨にするという話がいくつかあります： https ：

+1

ppadovani、あなたがやろうとしていることに感謝します。 この機能は私たちにとって非常に重要です
いくつかの質問：

1. これには時間がかかると思いますか？ この機能が利用できるようになる予定の時間はありますか？
2. 誰かが別の方法を試しましたか？ ログ形式をネストされたjson（arrays）から別のものに変更するのが好きですか？ もしそうなら、ELKで動作するために、意図されたフォーマットはどうあるべきですか？
3. この機能を実現するのに役立つ他の製品が市場にありますか？ ELKはオープンソースであるため、私はすべて好きですが、そうでないまでは、Splunkよりも安いものが必要です。 Loggly、sumologic、logentries、logscape、graylogなどの多くのオプションを検討しました（splunkと同じくらい高価であるか、この機能がありません）

どうもありがとう！

1. 誰かが別の方法を試しましたか？ ログ形式をネストされたjson（arrays）から別のものに変更するのが好きですか？ もしそうなら、ELKで動作するために、意図されたフォーマットはどうあるべきですか？

スキーマをフラット化するか、ESマッピングオプション「include_in_parent」または「copy_to」を使用して、ネストされたドキュメントから親ドキュメントに一部のフィールドをコピーできます。 すべてのユースケースで機能するわけではありませんが、場合によっては、Kibanaをそのまま使用できるようになります。 Elasticでは内部的に「include_in_parent」アプローチを使用しています。

1. 「機能する」ブランチがありますが、UI作業の形でより多くのTLCが必要です。 これは私の主な仕事ではないので、時間があるときにしかそれに取り組むことができません。
2. @tbraginが示すように、データをフラット化できます。 ただし、これにより無効なクエリ結果が発生する可能性があります。
3. 現時点では、代替案を認識していません。

クエリ言語がどのように見えるかをより明確にするために、古いプルリクエストで尋ねられたので、ここにBNFの要約があります。

比較：フィールド[=、<、>、<=、> =、〜=]値
〜= ..に注意してください。これは、ワイルドカードクエリを引き起こすLIKEを示します。
IN：フィールドIN {value、value、...}集合演算
フィールドIN [value、value]包括的/排他的に応じて[]または（）を使用した範囲演算
IS：フィールドはNULLです
式：IS | IN | 比較
NOT：NOT式
AND | OR：式AND |
EXISTS：EXISTS式
存在は、ネストされたスコープが発生する方法です。 通常、EXISTSを使用せずに、互いに隣接し、同じネストされたパスを持つすべての式は、同じネストされたクエリに結合されます。 ただし、EXISTSを使用して特定のネストされたクエリを相互にスコープすることにより、ネストされたクエリブロックを分割できます。

先に述べたように、この言語はJISONと同等のJavaScript BISONを使用しており、必要に応じてわずかな労力で言語を拡張できます。

アップデート：

テストしてフィードバックを提供するために、ブランチをすべての人と共有できるようになると思います。 パーサーが機能していて、少なくとも構文フィードバックとパーサーに対する単体テストが機能しています。 いくつかのスクリーンショット：

今週中に支店の準備が整うことを願っています。 準備ができたら、ここにあるブログ投稿にリンクします。このブログ投稿には、ブランチにリンクし、構文や使用法などの詳細が記載されています。私の計画は、ブランチに関するフィードバックを収集し、問題を修正し、要求に応じて改善してからです。プルリクエストを送信します。

テストしたいと思います（K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523でネストされた集計の使用例を示します。これがないと移行されません）。

@Robitxそれが問題になるとは思わない...少なくとも2つのレベルのネストされたオブジェクトを持つドキュメントがあります...例：

A-> B-> C

単一のAドキュメントに1つ以上のBがあり、それぞれにB上にあるCのリストが含まれている場合。ネストされた各ドキュメントには、さまざまなタイプの複数のフィールドがあります。 このコードをテストして、最も内側のネストされたデータに対してヒストグラムまたは多層円グラフを作成できるようにしました。

明確にするために、マッピングはpojoから自動生成され、非常に複雑になる可能性があります。

+1

アップデート：

私の側の公式ブログ投稿が表示されるのを待つのではなく、人々が遊び始めるためにこれを出したかったのです。

フォーク/ブランチはここにあります：

https://github.com/homeaway/kibana/tree/fullNestedSupport

README：

https://github.com/homeaway/kibana/blob/fullNestedSupport/NESTED_README.md

READMEの内容は、基本的に、ある時点で表示されるブログ投稿の内容です。

必要に応じて、fullNestedSupportブランチに対して問題を開いたりリクエストをプルしたりしてください。 私は人々が見つけたどんな問題でも常に把握しようとします。

+10000

+100500

+100

こんにちはppadovani、

アドバイスをお願いします、どうすればいいですか

このフィールドはelasticsearchマッピングには存在しますが、検索結果のドキュメントには存在しません。 あなたはまだそれを視覚化または検索することができるかもしれません。

どうもありがとう！

こんにちはppadovani、

ネストされた配列としてフィールドがあります。
"abc"：[["3815222235847451"、 "131712121218083052"]]
また
"abc"：[["3815222235847451"、 "131712121218083052"、 "131712121217783052"]]
また
"abc"：[["3815222235847451"]]

値は1〜10のいずれかです。

他のネストされたフィールドの場合、このフィールドおよびこれらのような他のフィールドのフィールドにインデックスが付けられていないという警告が表示されますが（マッピングを使用する必要があると思いますか？）、各セットは個別の値として扱われますか？ さらに、フィールドタイプは数値ではなく「文字列」として表示されます。これ自体は問題ではありませんが、abcの個々の値を検索できないことを意味します。

どうもありがとう！

テストを開始するのに数分かかりました:)：|

Error: [illegal_argument_exception] Invalid format: "1457354016603" is malformed at "6603"
    at respond (http://elastic.dev:5601/bundles/kibana.bundle.js:76155:16)
    at checkRespForFailure (http://elastic.dev:5601/bundles/kibana.bundle.js:76118:8)
    at http://elastic.dev:5601/bundles/kibana.bundle.js:74736:8
    at processQueue (http://elastic.dev:5601/bundles/commons.bundle.js:42333:29)
    at http://elastic.dev:5601/bundles/commons.bundle.js:42349:28
    at Scope.$eval (http://elastic.dev:5601/bundles/commons.bundle.js:43577:29)
    at Scope.$digest (http://elastic.dev:5601/bundles/commons.bundle.js:43388:32)
    at Scope.$apply (http://elastic.dev:5601/bundles/commons.bundle.js:43685:25)
    at done (http://elastic.dev:5601/bundles/commons.bundle.js:38134:48)
    at completeRequest (http://elastic.dev:5601/bundles/commons.bundle.js:38332:8)

@BigDataEngineer
1）-それは私の変更によって生成されたメッセージではなく、以前にKibanaに存在していたものである可能性があります。
2）-そうです..値は文字列として格納されているように見えますが、これらはネストされていない可能性があります.. what / ifの問題が存在するかどうかを理解するには、インデックスのマッピングがどのように見えるかを確認する必要があります。 ここにマッピングを貼り付けてください。

@Robitx
これは日付フィールドだったと思います...エポックタイムの桁数が多すぎて13ではなく10にする必要があります。発行したクエリを更新/貼り付けできますか？

@ppadovani
設定でデフォルトのインデックスパターンを選択し、[検出]タブに戻りました

を使用しております

      "timestamp": {
        "format": "dateOptionalTime",
        "type": "date"
      }

K 4.4.1 + ES 2.2は正常に動作し、K 4.3固有の可能性があります（このバージョンはこれまで試したことがありません）

@Robitx
使用されているクエリを探しています...または、渡されたクエリはUIの標準の日付ウィンドウであり、クエリを指定しなかったと言っていますか？ 後のKibanaリリースに対して変更をリベースし、ブランチが更新されたときに再投稿します。

@ppadovaniうんちょうど*そしていくつかの時間範囲

視覚化セクションのネストされたオブジェクトの+1

@Robitx
あなたが実行したその操作は私のパーサーコードのいずれにもヒットしませんでした...それは私がしたことによるものではないかと思います...私のセットアップはK4.3.1 + ES2.1.1です-ESを2.2にアップグレードします同じ動作が得られるかどうかを確認してから、ブランチをK4.4.1にリベースします。

ES 2.2.1 w / K 4.3.1 +私のコードにアップグレードしたばかりです...再現できませんでした：

私はまだ4.4.1にリベースします-現在のリリースは、ブランチの準備ができたらこの投稿を更新します。

アップデート：

新しいブランチで4.4.1にリベース： https ：

ES2.2.0およびK4.4.1でテスト済み

こんにちはppadovani、

私の以前の質問に関しては、私はそれらを放棄します。 AWSには（マッピングとともに）Elastic Searchインスタンスがすでにあり、これをそれに接続しようとしています。 ただし、UIのkibanaサーバーのステータスには次のように表示されます。

plugin：elasticsearchこのバージョンのKibanaでは、すべてのノードでElasticsearch ^ 2.1.0が必要です。 クラスター内に次の互換性のないノードが見つかりました：Elasticsearch v1.5.2 @ undefined（undefined）

私はまだhttps://github.com/homeaway/kibana/tree/fullNestedSupportを使用しており、あなたが提供した最新のものではありません。 1.5.2と互換性を持たせることは可能ですか？
親切にアドバイス。

どうもありがとう！！

@ppadovani
後戻りしているため、これが不可能かどうかは理解できますが、Amazon Elasticsearch Serviceは、新しいバージョンへのアップグレードにあまり熱心ではありません。これは理解できることです。 だから、私は私たちが持っているものは何でも一緒に働かなければなりません。 AWSインスタンスのセットアップ（複数のノードからのログ転送、ストリーミングイベント、その他の詳細）に多くの努力を費やしてきましたが、別のプラットフォームですべてを最初から作り直すことはできません。 これを追加のフロントエンドとしてフックできると便利です。 今後、別の障害が発生するかどうかさえわかりませんか？

ありがとう！！

@BigDataEngineer
以前のバージョンのKibanaコードを確認した後、変更を適用できる最初のバージョンは4.1.6です。 ただし、コードの大幅なリライト/リファクタリング/再編成があり、そのブランチにパッチを適用することはできません。 私のコードを取り込んで機能させるには、かなりの量の作業が必要になります。

正直なところ、Kibanaチームが各リリースのように必要なエラスティックバージョンをアップする理由はわかりません。RESTインターフェイスはそれほど頻繁には変更されません。 私は、ユーザーにエラスティッククラスターのアップグレードを強制するためにそれを行っていると推測しています。

考えてみれば、src / plugins / elasticsearch /index.jsの27行目あたりのバージョンを変更してみてください。

@ppadovani
出来た。 ありがとう。

+1

@ppadovaniこんにちは、4.4.1バージョンにアップグレードしていただきありがとうございます。すぐに応答しなかったことをお詫びします（以前のコメントの1つで更新を見逃しました）。

現在は機能していますが、最初に気付いたのはパフォーマンスの問題であり、時々kibanaが完全にフリーズします（より複雑なクエリをテストできませんでした）。

この問題の原因となる可能性のあるものはほとんどありません。そのうちの1つは、日次インデックスのいくつかのフィールドです（数百のフィールドがありますhttp://pastebin.com/fktN0dR5）。

@Robitx変更なしでベース

@ppadovaniベース

この問題が修正されていない1年...

くそー、elasticsearchには「ネストされたオブジェクト」機能がかなり必要でしたが、同じ開発者のKibanaはまだこの機能をサポートしていません。

すでにこの機能を実装しているが、適切なサポートがあり、メインのソースコードにマージされていないフォークがあります。

また、「ネストされたオブジェクト」をサポートするKIbanaのプロジェクトストックバージョンではまだ使用できません。

すごいクソ!!!

@ppadovaniフォークでの作業に感謝します=）

@Robitx Kibanaがフリーズしたとき、教えていただけますか？ IndexPatternの定義？ または、新しいクエリを開始するときですか？ これが発生する可能性のある領域がありますので、絞り込みたいと思います。

検出/視覚化タブを表示するときに発生した可能性のある1つの問題を修正しました...修正をプッシュしました。再テストしてください。

@rashidkpcこの作業に基づいてプルリクエストを生成する準備ができました。 作業のベースを変更する必要があるブランチを教えてください。 私は現在、4.3.1、4.4.1、および4.xに対してそれを持っています。 （4.xは近いですが、単体テストの実行に問題があります。テストクラスターの起動に失敗します...）

やあギャング（cc @ppadovani）

https://github.com/elastic/kibana/pull/5411で述べたように、Elasticsearch自体にはいくつかの制限があります。特に、ネストされたaggs / filterは自動ではなく、luceneクエリ構文はネストされた検索をサポートしていません。 ここで採用されたアプローチは、問題を解決するための別の道筋を示しますが、それは私たちが行きたい方向ではありません。 これは狭い問題の解決策ですが、Kibanaに幅広い課題を解決してもらいたいと考えています。 この場合、それは将来の大きな勝利のために小さな勝利を犠牲にすることを意味します。

Kibanaの言語の可能性を検討している間、機能セットをどのようにするかを正確に決定しておらず、途中で、または単一の目標を念頭に置いて実行したくありません。 ElasticsearchとKibanaの両方で、いくつかの戦術と機能セットを検討していますが、まだ形成段階にあります。 時間の経過とともに、timelionのようなものに見られるように、検索、変換、視覚化を含める必要があります。ネストされたドキュメントをクエリするという考えは、その際に念頭に置いておく必要があります。

これはネストされたパスを格納することに注意しましたが、キャッシュされたマッピングhttps://github.com/elastic/kibana/pull/6648を削除し、Elasticsearchの新しいAPIに置き換えています： https ：

今のところ、 include_in_parentまたはcopy_toを使用して@tbraginのアプローチを取ることをお勧めします。 集計の90％で、このアプローチは完全に機能します。

このソリューションがinclude_in_parentまたはcopy_to使用できない人のために機能していることをうれしく思います。これは、 @ ppadovaniが達成したことに

ちょっと、チャイムを鳴らします。これについてRashidとチャットしました。ネストされたマッピングにKibanaを使用したいというユーザーの苦痛を感じますが、より一般的な方法でサポートすること（Elasticsearchレベル自体に追加機能を意味する可能性があります）が前進の道です。これにより、Kibanaに必要な柔軟性が維持されます。 この提案された変更を取得することで、ネストをサポートしないという短期的な問題を解決できる可能性がありますが、将来的には問題が発生する可能性があります。

ここでKibanaがネストをサポートする必要性を感じていますが、これは、解決する必要がある方法が明確でない場合は、自然に感じる解決策が得られるまで未解決のままにしておく方がよい場合の1つです。 間違いなく継続して調査する必要があります。さまざまな場所でチャットしたものの1つが、ES自体でネスト（ラッピングなど）を自動的にサポートしていることを確認します。

これがエレガントに解決されるのを見て、私は興奮に満ちています。

+1

+1

IMHO私はKibanaメンテナのスタンスに敬意を表して反対しなければなりません。 ただし、これらの線に沿ってKibanaにプラグインする方法を見つけることができれば、私はそれですべてです。

それまでの間、私が作成したバージョンを引き続き使用したい人のために、フォーク/ブランチのバグを維持および修正し続けます。 将来的には、これをライブBI分析ダッシュボードに幅広く使用する予定です。

牛。 ペットではありません。

+1 :)
Kibanaでネストされたオブジェクトを使用するのは素晴らしいことかもしれません!! （誰かがそのためのプラグインを持っているかどうか？...）

+1

+1

+1

@tbraginあなたが言及したアプローチは、ネストされた型では機能しません。 タイプに関係なく、すべてのデータを集約します。

+1

+1

+1

+1

この機能は、サポートされているだけでなく、開発者がこれまでサポートする予定がないことを知って、私が実際にショックを受けたのは非常に簡単です。 地獄、あなたのプロジェクトマネージャーと話して、あなたたちがそれを自分でやらないなら、プラグインを作るために@ppadovaniを雇ってください。

ネストされたオブジェクトがないため、プロジェクトが大幅に妨げられるため、+ 1

この問題を回避する方法として非正規化に関する議論を探している人のために：ネストされたオブジェクトと親/子に対するKibanaの不足しているサポートを回避する

Elasticこの問題に関してサイトに免責事項があれば、サポートされていない機能を実装しようとしてユーザーが時間を無駄にするのを防ぐことができれば素晴らしいと思います。 どうして？ Kibanaの製品ページには「ElasticSearchとのシームレスな統合」と書かれていますが、ここでは当てはまりません:)

参考までに-上記の説明で参照されているコードのブランチは古いです。現在のブランチは次のとおりです。

https://github.com/homeaway/kibana/tree/nestedSupport-4.x

社内で積極的に活用しており、今後も社内バージョンを更新していきます。 興味があれば、githubのバージョンを更新できます/更新します。

ピエール

+1

+1

+1

+1

+1

+1

1年以上前にこれを+1したことを覚えています。それ以来、Kibana開発チームはヒールインを掘り下げ、ほとんど無視されたユーザーを掘り起こし、最後に彼らの足が火にかけられたとき、彼らは多かれ少なかれ応答します。 「NO」が少なく、「自然に感じられない」と述べています。

このパターンは、次のような他の多くの要求された機能にも見られます。

• OS側のGroovyスクリプトの呼び出しのサポート。
• ES Scripted Metric Aggregationsを使用できるようにするためのサポート（特に加重平均の計算に役立ちます）。
• 等々...

これはすべて、Elastic Stack 5のビジョン全体に対するスタンスに反します。ElasticStack5のビジョンは、（Elastic）がKibanaのElasticsearchのより基本的な機能をサポートすると述べられていました。 しかし、私はこれらの主張を裏付けるものをほとんど見ていません。

その結果、キバナがサイレンのキビなどのフォークに地面を失い、このトピックなどのアイテムにトーチを取り、解決策を考え出すことにしました。

優れた視覚化ツールを提供してくれたKibanaの開発者に感謝します。 しかし、Elasticは、Kibanaが単純な視覚化ツールであり続けるか、コミュニティに耳を傾け、その有用性を拡大するかを今後決定する必要があります。 決定が前者である場合、他の人がこれらの欠点を利用することを決定したときにユーザーが去ることを期待します。

+1

@cslinuxboy

OS側のGroovyスクリプトの呼び出しのサポート。

これでカバーされるユースケースのほとんどは、 https：//github.com/elastic/kibana/pull/7700で解決され

ESスクリプトメトリックアグリゲーションを使用できるようにするためのサポート

誰もこれに反対しているとは思いません（少なくとも、https：//github.com/elastic/kibana/issues/2646で反対意見は見られません）。実際、Elasticsearchが追加したので、今が追加するときです。痛みのないスクリプト言語。 それは本当に誰かが時間を見つけることの問題です。

+1

+1

+1

私は再びフォークの作業を始めています。 コミュニティに謝罪したいのですが、フォークの問題をオンにしていないことを1か月ほど前まで知らなかったので、バグがあったことを誰も示すことができなかったでしょう。 それは修正されました。

現在のブランチ： https ：

私がそれらを実装しようとしている順序での更新：

• クエリパーサーに日付オフセットのサポートを追加します
• 結果を確認する際のネストされたフィールドの検出のサポートを追加-完了
• 親/子クエリと集計のサポートを追加します
• クエリの地理形状タイプ（ポイント、ボックスなど）のサポートを追加します。これは、内部言語に対する最近の拡張機能の移植版です。
• クエリフィールドにフィールド名の先行入力を追加します
• 私が試してみてElasticsearchから返されるいずれかのスタックトレースを引き起こし、無効なクエリの迷惑を固定するために、既存のElasticsearch単純なクエリ言語のパーサを構築する、あるいは全く結果がなぜ表示なしで返されませんされているかもしれません。 私がこれに取り組むならば、それは私が上記を完了した後になります。 これを行う場合は、ネストされた親子サポートをKibana側の言語に追加することを検討します。

Kibanaチームがコミュニティに耳を傾けていないことを示した人々に私の声を加えたいと思います。 Kibanaチームは、Kibanaを「純粋」に保つためにギャップがある場合、Elasticsearchに依存して必要な機能を提供することはできません。 市場シェアはそのようには得られず、失われます。

+1

+1
@Bargs ：この問題に関する進展はありますか？ これはいつ対処/優先されますか？
非常に長い糸....これはキバナのような製品には適していません。
私たちはあなたの努力に感謝します

これは最悪です:-(

homewayはKibana4.3.1にネストされたaggsとクエリサポートビルドを持っています。チェックしてください。このヘルプを期待してください。

https://github.com/homeaway/kibana/tree/nestedSupport-4.x

@ankitchheda私はそれについて知っていますが、メインプロジェクト（大規模な開発中）の哲学に反する少数の人々によって維持されているフォークは解決策ではなく、それが誰にも役立たないふりをします。

私はそれについて何かしたいのですが、時間がないので、今のところ私は少なくとも圧力をかけようとし、開発者がこの問題を無視するのをやめることを願っています：|

+1

参考までに-ネストされたサポートのために維持しているフォークは、次のバージョンをサポートするようになりました。

4.5.X
4.6
4.7
5.X

それは主要な開発者の「哲学」に従わないかもしれませんが、それはうまくいきます。

私はこれにぶつかったところです。 これは少し欠点であり、実行可能なソリューションがあると非常に便利です。

@ tbragin 、 @ rashidkpc-提案された回避策は要点を見逃しています-あなたは
ネストされたオブジェクトで何かが出ますが、間違った結果が得られます！ ネスト
集計によって異なる結果が得られます（少し作業例を示して、後でここに投稿します）。

@ppadovaniのフォークをテストします。

+1

：turtle :: dash：

@Bargsねえ、フォークの害から基本機能のパフォーマンスへの変更ですか？

+1

+1

+1

+10086

+1

+1

+1

include_in_parentはESとKibana5.2で引き続き機能しますか？ 代わりに使ってみましたがうまくいきませんでした。

@gustavomrうまくいくと思いますが、特定のユースケースでのみ機能します。 ネストされたクエリ/集計が提供できるすべての可能なクエリのユースケースでは機能しません。

注：Kibanaの5.1フォークでは、検索アイコンの横にあるトグルを使用して、ネイティブのエラスティックシンプルクエリ言語と、含まれているネストされたクエリ言語を切り替えます。 また、ネストされたフィールドのメトリックに関するさまざまな問題を修正しました。
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovaniこれをしてくれてありがとう。 kibanaでネストされたオブジェクトを有効にする作業を、新しいクエリ言語を作成する作業から分離することは可能ですか？ これらが別々のブランチである可能性がある場合は、両方の機能をマージする代わりに、前者を使用して、新しいkibanaリリースがリリースされたときにそれらをマージすることができます。

また、このフォーク用に作成されたDockerはすでにありますか？

フォークのDockerコンテナの場合は

@ gkozyryatskyy-フォークで問題を開いてください。それを見ていきます。

@ imranq2-これは可能ですが、単純なエラスティッククエリ言語はネストされたクエリをサポートしていないことに注意してください。 ネストされたデータがあり、それをクエリする場合は、elasticsearch json blobとしてクエリを手動で作成し、クエリボックスに貼り付ける必要があります。

+1

私のフォークはnestedSupport-5.2ブランチで5.2をサポートするようになりました。

@ppadovaniそれは素晴らしいです！ このためのDockerコンテナの作成についてサポートが必要な場合はお知らせください。

Dockerコンテナはまだ完成していませんが、[検出]タブと、ネストされたデータの表示方法を試してみる時間がありました...ネストされたサポートの問題を監視しているユーザーからのフィードバックを探しています。 テーブルは再帰的であり、ネストされたフィールドのフィルターはうまく機能しているようです。しかし、列のトグルフィールドはまだ機能していません...それがどのように/機能するかを考える必要があります。

参考までに-この作業は基本的に完了しており、サポートされているすべてのフォーク/ブランチに、nestedSupport-4.5.4からnestedSupport-5.2までの変更が加えられています。

@ Bargs-私が行ったネストされた作業のどれもあなたたちが引き込もうとしているものではないことを私は知っていますが、ディスカバリー結果にネストされたデータを表示する
https://github.com/homeaway/kibana/issues/12

これがあなたが望むものであるならば、私に知らせてください、そして、私は問題を開いて、パッチを含めます。

面白そう@ppadovani ！ あなたがPRを開きたいのなら、私は間違いなくそれをチェックすることに興味があります。 Discoverにネストされたフィールドのサポートを改善することについて少し話しましたので、具体的な議論があれば素晴らしいと思います。

@ppadovani現在、このためのhttp://staging.elastic.co/ $（VERSION_TAG）/ downloads / kibana / kibana- $ {ELASTIC_VERSION} -linux-x86_64.tar.gzのように作成されたtarボールはすでにありますか？ もしそうなら、私はそれをDockerコンテナに引き込むことができます。 それ以外の場合は、ブランチを作成してtarballを作成する必要があります。

@ imranq2フォークのディストリビューションは提供していませんので、自分で作成する必要があります。

参考までに-興味のある人のために、[検出]タブでネストされたデータをサポートするためのプルリクエストを作成しました。
https://github.com/elastic/kibana/pull/10814

+1

私のために+1
同僚は+10

+1

+1

+1

+1

+1

+1

+1。 これはELK5でサポートされていますか？

+1

ネストされたオブジェクトをサポートしないことは、プレーンAPIをより巧妙に検索するために、kibanaのインデックスとネストされたドキュメントを含む別のインデックスを作成する必要があるため、私の会社でkibanaを広く採用する上での障害となるため、これは本当に要件です。

+1
私のマッピングでは、インデックスプロパティの「爆発」の可能性を防ぎます。

+1

+1

+1

このスレッドに登録しているすべての人にのみスパムを送信している+1コメントの投稿を停止してください。 代わりに、この号の上部にある大きな黄色の「賛成」ボタンをクリックして賛成してください。

+1

Kibanaの開発者の皆さん、本当に何かしてください。 多くの場合、ネストされたオブジェクトなしでKibanaを使用しても意味がありません。 ネストされたオブジェクトなしでバージョン6.xを準備しています...

私たちのシステムは、家のテキストをスキャンして、結果をESに保存します。 したがって、ESには、家の配列を含む主要なドキュメントが含まれています。 Houseはネストされたオブジェクトです。

テキストで見つけた家の分析を含むダッシュボードを作成するために視覚化を使用することはできません。
何かしてください。 家は燃えています。

kibanaでネストされたオブジェクトを必死に使用する必要があります。 これが内蔵で利用できないのは残念です。

███████╗████████╗██╗██╗     ██╗         ██╗    ██╗ █████╗ ██╗████████╗
██╔════╝╚══██╔══╝██║██║     ██║         ██║    ██║██╔══██╗██║╚══██╔══╝
███████╗   ██║   ██║██║     ██║         ██║ █╗ ██║███████║██║   ██║   
╚════██║   ██║   ██║██║     ██║         ██║███╗██║██╔══██║██║   ██║   
███████║   ██║   ██║███████╗███████╗    ╚███╔███╔╝██║  ██║██║   ██║   
╚══════╝   ╚═╝   ╚═╝╚══════╝╚══════╝     ╚══╝╚══╝ ╚═╝  ╚═╝╚═╝   ╚═╝   

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

ここにもう1つ！

ネストされたサポートでKibanaのフォークを使用した可能性がある場合は、Kibanaリリース5.4.x以降のフォークのサポートを終了します。 代わりに、すべてではないにしてもほとんどの機能をKibanaプラグインに移動します。 年末までにプラグインを最新の5.xリリースに対応できるようにしたいと思っています。 ここで進捗状況を確認できます： https ：

作業を始めたばかりなので、数週間は重要なものが表示されるとは思わないでください。

+1

+1

+1

+1

+1

ネストされたサポートプラグインで行っている作業のスクリーンショットとステータスの更新が投稿されています。 問題を監視して、ステータスの更新を取得します。

スクリーンショットと更新

私は先に進み、Kibana5.6.5をサポートする1​​.0.0のプレリリースをリリースしました。

最初のプレリリースの内容の詳細については、この問題を参照してください：スクリーンショットと更新

V1.0.0-beta1

私のプラグインは、Kibanaのバージョン5.6.5のフィーチャーコンプリートです。 いくつかのクリーンアップタスクがあります。次に、5.6.5バージョンを切り取り、6.1.Xへのフォワードポーティングを開始します。

特徴：

• ネストされたクエリのサポート
• ネストされた集約のサポート
• 結果のネストされたサポートを見つける
• 要約フィールドの表示優先度を検出します（これは実際には新しいものです）

詳細については、 READMEを参照してください。

プラグインがリリースされました！ 5.5.3、5.6.5、および5.6.6のサポート。 今週末は6.0.Xに移植します。

この問題については、ここでステータスを更新しない可能性があります。 リリースや問題などを表示するには、GitHubページにアクセスしてください。

ありがとう！

@ ppadovani5.4.0のサポートバージョンをリリースできますか。

@ppadovani 6.0.xポートを監視します！

@ SolomonShorser-OICR
6.0.1 Beta1ビルドをリリースしました。

唯一の既知の制限は、luceneクエリ言語でのみ機能するようにハードコーディングされているため、フィルターバーが機能しないことです。 私はそれを回避する方法を模索していますが、次の週末まで解決策がないかもしれません。

6.0.1のプラグインビルドをリリースしました。次は6.1.xです。

@ppadovani
あなたの仕事と6.0.1リリースをありがとう！

kibana 6.0.1に基づいて、このプラグインをインストールした後、一部のkibana機能がうまく機能しません。

timelionをクリックすると、エラーメッセージが表示されます。

x-packがインストールされている場合、一部のx-pack機能「discover」の「Foreach」に別のエラーメッセージが表示されます

Kibanaチームさん、

@ sccds-このバグレポートを私のGitHubリポジトリに移動してください：

https://github.com/ppadovani/KibanaNestedSupportPlugin/issues/27

誰かが私のプラグインに問題がある場合は、私のリポジトリで問題を開いてください。ここで会話を開始しないでください。 この問題には、サブスクライバーが多すぎます。

@ Hronom-私はその考えに感謝しますが、私の強みはJavascriptにはありません....このプラグインを構築して

参考までに-私のプラグインはKibanaのリリースで最新になりました。 6.1.2サポートをリリースしました。

ありがとう@ppadovani 、それを続けてください！

+1

+1

+1こんにちは、Tomitribeはこの機能に非常に興味を持っています。 この機能がいつ実装されるか知っていますか？

@ppadovani機能についてどこで質問できますか？ データテーブルのネストされた集計に苦労しています。

@bumerankkkここに移動して問題を開きます： //github.com/ppadovani/KibanaNestedSupportPlugin

または、質問に一致するドキュメントページのいずれかに移動した場合は、ページの下部にコメントを追加できます。

https://ppadovani.github.io/knql_plugin/overview/

これは積極的に取り組んでいますか？ そのような機能がいつ製品リリースを経験するかについてのタイムラインはありますか？

お誕生日おめでとう🎂 'ネストされた型の集計'、🎁

今、あなたはすでに4歳です。 少し前まで、あなたはとても小さくてかわいいです。
あなたが成長し、将来的にいくつかの共通の良い年があることを願っています。

最高のマル

+1

+1

+1

+1

+1

+1

+1

なぜこれがまだ実装されていないのですか

理由は、この機能を使用すると、ホエイにはディススレッドがなく、面白​​くなく、誰もキバナのgithubにアクセスしません。これは、この種のビーコンです。

最新のelkバージョンは、ネストされたデータを正しくサポートしてくれます

ElElmié、2018年6月6日、22：08、ユージーン[email protected]
escribió：

理由は、この機能を使用すると、ホエイにはディススレッドがなく、面白​​くなく、
誰もキバナのgithubに行きません、これはある種のビーコンです

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
。

@javixeneize私はここに6.2.4バージョンで座っていますが、データネストされたオブジェクトのサポートが見つかりません。間違っている場合は修正してください

私はそのバージョンを持っており、abにアクセスできます。ここで、私の構造は{Id：xx、
a：{b：xx}}

エル・エル・三重県、2018年6月6日22時18ラス、ユージン[email protected]
escribió：

@javixeneizehttps ：//github.com/javixeneize私はここ6.2.4に座っています
バージョン、datネストされたオブジェクトのサポートが見つかりません。間違っている場合は修正してください。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
。

@javixeneize typeを使用した次のマッピングはありますか： nested ？
GET /index-nameマッピングを取得できます

{
  "document": {
    "properties": {
      "locations": {
        "type": "nested",
        "properties": {
          "name": {
            "type": "keyword"
          },
          "popularity": {
            "type": "long"
          }
        }
      }
    }
  }
}

明日チェックしますが、デフォルトの設定があります

エル・エル・三重県、2018年6月6日午前22時24ラス、ユージン[email protected]
escribió：

@javixeneizehttps ：//github.com/javixeneize次のマッピングはありますか
タイプ：ネスト？
GET / index-nameでマッピングを取得できます

{{
"資料"： {
"プロパティ"： {
「場所」：{
「タイプ」：「ネストされた」、
"プロパティ"： {
"始める"： {
「タイプ」：「長い」
}、
"終わり"： {
「タイプ」：「長い」
}、
「正規化」：{
「タイプ」：「キーワード」
}、
"オリジナル"： {
「タイプ」：「キーワード」
}
}
}
}
}
}
}

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
。

@javixeneizeよろしくお願いします！
メインドキュメントにフラット化されたサブjsonオブジェクトがある可能性がありますが、これはネストされたオブジェクトではありません。

そのフィールドのESでのマッピングを特にネストに設定しない限り、 @ javixeneizeデータが期待どおりに相関しないことに注意してください。

https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html

主な問題は、ネストされたオブジェクトの各フィールドが配列になり、プロパティ間の相関関係が失われることです。

今のところ、esにダンプする前にデータをフラット化しました。

Elasticがこれを実装するのを待つことができない場合は、私のKibanaプラグインを使用できます。

概要：
https://ppadovani.github.io/knql_plugin/overview/
インストール：
https://ppadovani.github.io/knql_plugin/installation/
クエリ言語（SQLのような）：
https://ppadovani.github.io/knql_plugin/knql/

5.5.3から6.2.4のサポート、バージョンが欠落している場合、5.5以降は問題を開いてください：
https://github.com/ppadovani/KibanaNestedSupportPlugin

寄稿、機能リクエスト、バグレポートを歓迎します。

わかりました、それでは待たなければなりません...

エル・エルJUE、2018年6月7日午後12時38分ラス、ピエールPadovani [email protected]
escribió：

Elasticがこれを実装するのを待つことができない場合は、私のKibanaを使用できます
プラグイン：

概要：
https://ppadovani.github.io/knql_plugin/overview/
インストール：
https://ppadovani.github.io/knql_plugin/installation/
クエリ言語（SQLのような）：
https://ppadovani.github.io/knql_plugin/knql/

5.5.3から6.2.4のサポート、バージョンが欠落している場合、5.5以降はお願いします
問題を開く：
https://github.com/ppadovani/KibanaNestedSupportPlugin

寄稿、機能リクエスト、バグレポートを歓迎します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
。

+1

+1

+1

+1

+1

+1

非常に便利な機能... + 1

Kibanaは、このサポートがなければ、私のユースケースにはまったく役に立ちません。 データをフラット化または再構築する必要はありません。 データを入力して、視覚化または集計を取得できるはずです。 4年後、まだネストされたオブジェクトのサポートはありませんか？

この機能が利用できる場合の見積もりはありますか？

エラスティックの誰かが、この機能がKibanaに追加されるかどうかを教えてください。 このチケットはもう5年近く開いています。

また、Kibanaで使用できない場合、このような機能をリリースする意味は何ですか？

誤解しないでください、しかしそれは少し奇妙に感じます。

+1

+1

@dayotoro @berkoaviv @yechanpark @ macckermann2 @mahnejo @bphenriques

+1コメントのようなコメントは追加しないでください。 特にあなたが本当に気にかけている問題については！ 説明させてください。通知がオンになっている人は誰でも簡単にイライラしてスレッドから退会するでしょう。 つまり、貢献者は、参加者の数だけに基づいて、これを重要な問題とは見なさないということです。 退会すると、この数は減ります。

代わりに、右上隅のボックスを介してスレッドをサブスクライブし、Githubの最初の問題に賛成を表明してサポートを示すことです。

@ bugs181これはここでは機能しません。この問題は異常であり、5年間、すべての着信波を吸収します。

科学者はこのブラックホールを探求すべきだと思います！

Kibanaの開発者は異常な力を持っているようです!!!

@ bugs181これはここでは機能しません。この問題は異常であり、5年間、すべての着信波を吸収します。

彼らが彼らにとって価値があるかもしれない情報を探し求めているたくさんの「+ 1metoo」コメントで問題全体を読みたくないと思ったことはありますか？

@ppadovaniには、使用できるオープンソースプラグインがあります（上記の彼のコメントを参照してください）

@ mika76
私はこれを使用しています。

単純な場合に非常に便利

@ mika76は、時間の制約のため、現在アクティブに維持されていないことに注意してください。

ppadovaniは28日前にコメントしました
みなさん、仕事と生活の関係で時間が厳しく制限されていることに気づきました。 さらに、部分的に問題を解決することはできましたが、KibanaチームがReactに移行する際に行った変更では、ほとんどの場合、私が行ったことの大部分を書き直す必要があります。

@ mika76はい、このプラグインは、ネストされたオブジェクトを現在機能させる唯一の方法です。
しかし、私にとって奇妙なことに、Elasticsearchはネストされたオブジェクトを公式にサポートしていますが、Kibanaはサポートしていません。

@ bugs181で述べたように、現在アクティブに保守されていないため、最新バージョンのELKスタックにアップグレードすることはできません。

したがって、公式サポートは適切な保守も意味します。 しかし、開発者がこの問題に唾を吐いているため、これに対する公式のサポートはありません。

ここで@ bugs181を2番目にする必要があります。 「+1」-この問題を送信したり、スパムを送信したりしても、この問題に対する認識を高めることはできませんが、人々にそれをミュートさせるか、ロックする必要があるポイントに近づけるだけです。私はオープンなコミュニケーションを信じているので、すべての問題を誰もが議論できるように開いたままにしておきたいので、望んでいません。

これまでのところ、私は常にそのプラグインを使用することをお勧めしました。 これがもはや積極的に維持されていないことに気づかなかったので、それを聞いて悲しいです。 また、この問題は5年間開いており、問題の分析を実行しており（Kibanaでは明らかに-添付のスクリーンショットを参照）、これが最も反応の多い問題であることもわかっています。

しかし、ご存知のとおり、（文字通り）他にも何千もの問題が発生しているため、適切な優先順位を見つけるには、機能やバグ修正などのバランスを取る必要があります。 また（だけでなく）、その機能には常にかなり堅実なコミュニティプラグインが機能していたため、これまでのところ（他の問題を克服するために）十分な優先順位が付けられていませんでした。 また、多くの場合、さまざまなものの間に技術的な関係があります。たとえば、ネストされたフィールドサポートの場合、高度にリンクされているため、これを開始する前に、視覚化レンダリングパイプライン全体（＃19813）のオーバーホールを最初に完了したいと考えています。一緒。 それでも、現在7.xのロードマップでこの問題が発生しており、他の技術的な変更によってブロックされないことを願っています。そのため、すぐにその機能をKibanaコアに移動して、コミュニティプラグインなしで利用できるようにすることができます。

ネストされたオブジェクトの視覚化をサポートするリクエストには、親子関係のサポートが含まれていますか？ 親子の視覚化について問い合わせている顧客がいます。

@MorrieAtElasticいいえ、親子は別の問題になります。

https://github.com/elastic/kibana/issues/3730
https://github.com/elastic/kibana/issues/20255

ElasticSearchはネストされたオブジェクトをサポートしているため、Kibanaで1：Mリレーションを正しく表示できないため、データをロードできても正しく表示できないため、これは非常に大きな問題です。 これはすぐに修正する必要があります。

ありがとう、
Rakesh

本日、KQLでネストされたフィールドのサポートに取り組み始めました。 Kibanaでの完全なネストされたフィールドのサポートには、KQLだけでなく多くの変更が含まれるため、追跡する別の問題を作成しました。

https://github.com/elastic/kibana/issues/44554

OMGはこれが本当ですか？ 5年後...

新しいデータ型についてはどうですか：フラット化？ 将来、その新しいタイプの視覚化のサポートはありますか？ 多くのサービスクライアントはこの新しいタイプに舵を切り、視覚化が機能するかどうか/いつ機能するかを尋ねています。

@Barrybigbuddyフラット化の計画が

親子関係をキバナで表現してもらいたいです。 したがって、この機能に優先順位を付けるように要求してください。 ありがとう。 M 'ジェイ

+1

素晴らしい！ ここに+1！ この機能には特定の時間枠がありますか？

ここで私をパーティープーパーにして、簡単に思い出させてください。この問題を購読している人はたくさんいます（228人のコミュニティの人といくつかのElasticチーム）ので、 +1を最小。 GitHubsの優れたリアクション機能のおかげで、すべてのサブスクライバーへの通知をトリガーせずに、コメントに@Bargsへの承認と愛情を追加することもできます（または不承認の場合、彼はネストされたフィールドサポートの作業を再び停止できます：wink :)。 また、特にこれは非常に大きなチケットであるため、他のフィールドタイプに関する無関係な質問には使用しないでください。

他のフィールドタイプについては、ここにいくつかの参照を残しておきます。

• flattenedフィールドタイプのサポート-現在、当面のロードマップには含まれていません
• 親/子のサポート-現在、当面のロードマップには含まれていません

この機能はいつ到着しますか？ 私たちはこれに積極的に取り組んでおり、これにはさまざまなフェーズ（KQL、フィルタリングサポート、視覚化など）があり、さまざまなバージョンで提供される可能性があります。これは、開発プロセスがどのように行われるかによって異なります。 この機能に関連するプルリクエストをコメントとしてここに投稿しますので、PRで、特定のフェーズ/サポートの一部がどのバージョンに到達するかを確認できます。

これが同じ問題であるかどうかはわかりませんが、オブジェクトのリストを含むインデックスがありますが、「ネストされた」データ型を使用していません。 ただし、「使用可能なフィールド」の下のKibanaでは、リストにあるオブジェクト内のフィールドが表示されません。 これは既知の制限ですか？

@ppadovaniはプラグインが

みなさん、こんにちは。この問題の解決策を見つけたと思います。 マッピングのソースコードを読むと、ネストされたマッピングタイプにinclude_in_parentオプションがあることがわかりました。 このオプションを使用すると、Kibanaのオブジェクトの配列を問題なく視覚化できます!!! 何らかの理由で、このオプションはESドキュメントに表示されません。 多分私は何かがおかしいのですが、どうやらすべてがうまくいきます。 フィールドオプションを使用して、キーワードとフルテキストの両方で検索できるようにします。

マッピング

PUT / test_index
`` `json
{{
「マッピング」：{
「動的」：「厳密」、
"プロパティ"： {
"州"： {
「タイプ」：「キーワード」
}、
"によって作成された"： {
「タイプ」：「ネストされた」、
"include_in_parent"：true、
"プロパティ"： {
"ファーストネーム"： {
"タイプ"： "テキスト"、
"田畑"： {
"生"： {
「タイプ」：「キーワード」
}
}
}、
"苗字"： {
"タイプ"： "テキスト"、
"田畑"： {
"生"： {
「タイプ」：「キーワード」
}
}
}
}、
「動的」：「厳密」
}、
"人"： {
「タイプ」：「ネストされた」、
"include_in_parent"：true、
"プロパティ"： {
"ファーストネーム"： {
"タイプ"： "テキスト"、
"田畑"： {
"生"： {
「タイプ」：「キーワード」
}
}
}、
"苗字"： {
"タイプ"： "テキスト"、
"田畑"： {
"生"： {
「タイプ」：「キーワード」
}
}
}
}、
「動的」：「厳密」
}
}
}
}

### Documents
POST test_index/_doc
```json
{
  "state": "done",
  "created_by": {
    "first_name": "Patricio",
    "last_name": "de Villa"
  },
  "people": [
    {
      "first_name": "Patricio",
      "last_name": "de Villa"
    },
    {
      "first_name": "Test",
      "last_name": "Test"
    }
  ]
}

@patodevilla

include_in_parentまたはcopy_toを回避策として使用することはサポートされておらず、将来のリリースで機能しなくなる可能性があります。

https://www.elastic.co/guide/en/kibana/7.x/nested-objects.html

7.6.0でリリースされたネストフィールドサポートフェーズ1

この問題の小さな更新：ネストされたフィールドの初期サポートを備えたKibanaの7.6.0を

• インデックスパターンはネストされたフィールドを正しく検出します
• Discoverでネストされたフィールドを見ることができます
• フィルタバーを介したネストされたフィールドのフィルタリングは機能します
• KQLを使用すると、ネストされたフィールドを検索できます（ネストされたフィールドのクエリに関する構文の説明については、 KQLのドキュメントを参照してください）。

現在、ビジュアライゼーションでネストされたフィールドを有効にする作業を行っており、関連情報を使用してこの問題を更新し続けます。

やあ！ NESTED機能をお待ちしております。 いつ見ることができますか？ これは、Kibanaに完全に切り替わらない唯一の瞬間です（Elasticが最適です）。 全世界があなたを見守っています。

ネストされたフィールドのクエリは、KQLでまだバグがあります。
例：
次のように定義されたインデックスマッピングを検討してください
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
このインデックスに基づいてインデックスパターンを作成し、 first.second.field : "test"をクエリしたい
[検査]タブのこのクエリは、を生成します
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
これは正しくありません。
正しいバージョンには、ネストされた構文"nested": {"path": "first.second",...}も含める必要があります

@ elastic / kibana-app-arch（Team：AppArch）にpingを実行します

@IlyaHalskyネストされたフィールドに関するKQLドキュメントを確認してください。 ネストされたフィールドは、クエリを実行する方法が複数あるため、クエリを実行するには特定の構文が必要です（この場合、実行したいのはfirst.second:{ field: "test" } ）。

また、KQLクエリでネストされたフィールドを初めて使用しようとすると、その説明にリンクするトースト通知が表示されます。

Visualizeのネストされたフィールドをサポートする新しいkibanaリリースがあるかどうかを尋ねます。
私のデータ例：
{{
"fieldX"： "x"、
"fiedY"： "Y"、
「異常」：[
{{
「カテゴリ」：「システム」、
"名前"： "cpu"、
「日付」：「2020-03-11T13：33：40.000Z」
}、
{{
「カテゴリ」：「再起動」、
"名前"： "リセット"、
「日付」：「2020-03-11T13：33：40.000Z」
}、
{{
「カテゴリ」：「システム」、
"名前"： "メモリ"、
「日付」：「2020-03-11T13：33：40.000Z」
}
]
}

キバナで円グラフを視覚化したい場合：
スライスサイズカウント=異常配列オブジェクトの総数（ドキュメント数x異常配列ごとのオブジェクト数）
最初のバケット= anomalies.category
2番目のバケット= anomalies.name

言い換えれば、異常カテゴリごとの異常名の分布を視覚化したいですか？

+1

これに関するニュースはありますか？ 7.6リリースはすでに数か月前のものであり、7.7および7.8のリリースノートにはこれについての言及がなく、7.9、7.xおよびmasterのドキュメントにもこの機能に関する新しい情報は含まれていません。

ビジュアライゼーションでネストされた集計のサポートを取得するという私たちの高い期待を表現するために、ただチャイムを鳴らします。 素晴らしいだろう！