+1 untuk agregasi objek bersarang.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

untuk menjadi jelas, tidak ada cara untuk melakukan filter/query/agg bersarang di kibana 4 sekarang, bukan?

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1 Karena denormalisasi objek bersarang tidak selalu merupakan pilihan karena ini dapat menyebabkan ledakan pemetaan.

Pemetaan:

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

Pertama-tama saya ingin bagan garis untuk dapat menunjukkan ukuran rata-rata dari waktu ke waktu untuk setiap nama kumpulan. Dengan asumsi bahwa ada banyak nama sehingga denormalisasi bukanlah ide yang baik, ini dapat menyebabkan banyak grafik dalam bagan. Untuk menangani kasus seperti itu, akan bermanfaat juga untuk dapat menggunakan agregasi filter di dalam agregasi bersarang. Mampu memfilter bidang bersarang di pencarian teratas juga akan bagus.

Untuk membuat segalanya lebih menarik, akan sangat bagus untuk dapat memvisualisasikan agregasi seperti ini:

"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!

Ini akan menjadi kuat dengan ini!

Jadi bisakah seseorang mengklarifikasi ini; Dalam posting ini (https://www.elastic.co/blog/kibana-4-beta-1-released) untuk Kibana4beta1 menyatakan bahwa "Kibana 4 membawa kekuatan agregasi bersarang Elasticsearch ke klik mouse. " Namun Saya tidak dapat membuat visualisasi apa pun pada dokumen dengan objek bersarang. Saya juga memastikan objek bersarang di templat indeks saya ditandai sebagai "bersarang". Jadi, apakah dukungan Kibana untuk agregasi bersarang tidak sama dengan dukungan ES untuk objek bersarang? Apa yang saya lewatkan? Terima kasih.

@cslinuxboy - Saya pikir mereka menggunakan "bersarang" di sini untuk merujuk ke pengelompokan melalui beberapa bidang, misalnya "agregat berdasarkan waktu lalu geo" (bukan "bersarang" seperti dalam penggunaannya di platform untuk "objek bersarang")

@Alex-Ikanow - Terima kasih atas jawabannya. Sayang sekali ini tidak mungkin saat ini. Saya mendapatkan harapan saya ketika membaca deskripsi menyesatkan pada posting beta-1 mereka.

+1 untuk mendukung objek bersarang dalam agregasi visualisasi.

+1

Saat ini saya menggunakan hubungan orang tua/anak sebagai solusi yang tampaknya berfungsi dengan baik.

@calvdee Apakah Anda memiliki kueri has_parent atau has_child untuk bekerja di bilah pencarian Kibana? Ini tidak berhasil untuk kami dan ini adalah masalah besar, saya akan sangat berterima kasih jika Anda memiliki ini bekerja dan dapat memberi tahu saya ... terima kasih!!!

Tidak, untuk kasus penggunaan kami semua orang tua memiliki anak dan semua anak harus memiliki orang tua karena kami mengindeks data faktur sehingga kueri biasa hanya berfungsi (lihat gambar).

@calvdee Terima kasih banyak atas jawabannya! Kami memiliki model data yang serupa tetapi ingin dapat menemukan orang tua oleh anak-anak mereka di Kibana, itu tidak berhasil :0(

Jangan khawatir, semoga berhasil!

Pada Kamis, 26 Maret 2015, 11:36 ajrasch [email protected] menulis:

@calvdee https://github.com/calvdee Terima kasih banyak atas jawabannya! Kita
memiliki model data yang serupa tetapi ingin dapat menemukan orang tua dengan cara mereka
anak-anak di Kibana, itu tidak berfungsi :0(

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment -86575796.

+1

+1

Anda membaca bidang _mapping, jadi Anda harus tahu kapan bidang tertentu disarangkan, jadi tidak bisakah itu secara otomatis menerapkan faset/kueri bersarang yang benar saat bidang tersebut dipilih dalam kueri atau faset?

Ya, :+1: yang ini. Meskipun saya berhasil menulis agregasi bersarang yang benar pada CLI, dan dapat menarik data dengan curl, saya belum menemukan cara untuk membuatnya bekerja di tab "Visualise" Kibana, bahkan tidak menggunakan kotak edit JSON. Memang, saya tidak pernah menggunakan fitur itu (kotak), tetapi tampaknya hanya mungkin untuk "menambahkan" hal-hal ke agregasi yang ada, tidak menggunakannya untuk membuat agregasi baru dari awal... (akan menghargai untuk dikoreksi jika saya salah dalam hal ini!).

Ya, agregasi tipe bersarang adalah kunci dan menjadi lebih banyak digunakan karena mereka memecahkan masalah tertentu dengan data datar.

Jika Kibana4 adalah produk visualisasi untuk ES, itu harus mendukung semua agregasi ES.

Akan menyenangkan untuk setidaknya melihat ini di peta jalan untuk Kibana4 .

+1

+1

+1

+1

+1

Dari #3729 :-)

Saya ingin melihat opsi agregat "dokumen anak"
(setelah histogram tanggal, histogram, dll.) yang membuka
parameter untuk kueri DSL untuk agregat anak-anak, seperti
"tipe anak", "bidang", dll.

Ini akan memungkinkan seseorang untuk membuat agregat bersarang pada anak
dokumen.

Sepertinya saya tidak bisa membuat kueri seperti itu menggunakan
fitur pengeditan lanjutan. Mungkin ada yang bisa
mencerahkan saya.

Terima kasih

+1

+1

+1

+1 sangat membutuhkan kemampuan ini. Saya dapat menghapus semua orang tua dengan logstash sebagai solusi, tetapi itu akan membutuhkan file konfigurasi yang besar karena saya memiliki ratusan bidang.

+1 ada yang tahu apakah ini direncanakan?

+1

Saat ini, saya sedang mempertimbangkan untuk mengubah beberapa pemetaan saya untuk berhenti menggunakan objek tipe "bersarang", karena saya tidak dapat membuat visualisasi Kibana di salah satu bidang tersebut. Jika saya tahu masalahnya setidaknya ada di peta jalan, itu akan sangat membantu dalam membuat keputusan itu.

@benjismith - Saya juga menggigit peluru dan mengalihkan pemrosesan data saya dari bersarang ke dokumen induk/anak. Sejauh ini bekerja dengan baik, tapi saya setuju dengan Anda; akan menyenangkan mengetahui apakah ada kemungkinan fitur ini akan menjadi fitur di Kibana sehingga kita semua dapat menunggu atau melanjutkan.

Semoga berhasil.

+1

+1

+1 untuk dukungan agregasi tipe bersarang

+1

+1

+1

+1

+1

+1

Bagi mereka yang ingin melakukan agregasi sederhana di seluruh bidang tertentu dalam dokumen bersarang (misalnya agregasi "istilah" pada bidang untuk menemukan nilai teratas), Anda dapat mempertimbangkan untuk menambahkan setelan "include_in_parent" ke pemetaan Elasticsearch Anda. Ini membuat versi bidang yang diratakan di dokumen bersarang di tingkat induk.

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

Bidang ini tidak akan muncul di daftar bidang Temukan di sisi kiri, meskipun Anda akan melihatnya di tampilan detail dokumen sebagai bidang larik. Namun, Anda akan memiliki akses ke masing-masing bidang dalam daftar metrik di Visualisasikan, dan Anda dapat menjalankan agregasi pada bidang tersebut.

Inilah yang kami lakukan untuk memvisualisasikan Riwayat Tontonan, yang didasarkan pada struktur dokumen bersarang (lihat "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

Alih-alih +1 lain... Mungkin ringkasan tentang tempat Agregasi Tipe Bersarang akan membantu.

Saya 5 hari belajar cara membuat grafik cantik jadi maafkan saya jika ada yang jelas.

Apa masalahnya?

Apakah ini masih merupakan masalah kueri ElasticSearch atau Lucene?

Ini tidak diselesaikan dengan agregasi, tetapi diselesaikan dengan fakta bahwa kami mengizinkan Anda mengetik elasticsearch JSON di kotak input. Itu tidak ideal, tetapi kecuali elasticsearch memperluas sintaks string kueri lucene untuk menentukan bidang bersarang, ini yang terbaik yang bisa kami lakukan. -- komentar lama rashidkpc

Perbaikan Kibana Mungkinkah?

Jika ES/Lucene, dapatkah Kibana memberikan peretasan/solusi perantara untuk sementara? Pikirkan shims ES6 dan CSS awalan vendor.

Untuk pemetaan bersarang : kesempatan untuk memilih bersarang di editor (dan mengonfigurasi jalur...) untuk panel Kibana. tukang bobmer

Atau:

Anda membaca bidang _mapping, jadi Anda harus tahu kapan bidang tertentu disarangkan, jadi tidak bisakah itu secara otomatis menerapkan faset/kueri bersarang yang benar saat bidang tersebut dipilih dalam kueri atau faset?
Alex-Ikanow, OP

Apakah ada yang meretas solusi? Adakah yang punya ide/arah ke mana harus meretas?

Bekerja di sekitar?

Adakah yang berhasil dengan nested/include_in_parent? Apakah itu memerlukan dynamic: static , dynamic: true . Upaya saya gagal dengan 0 hasil. tbragin

Adakah yang punya contoh untuk kotak input JSON yang disinggung di atas oleh rashidkpc?

Orang tua/Anak

Ini adalah langkah saya selanjutnya. Saya yakin ada banyak bahan referensi online untuk ini, tetapi tidak ada salahnya untuk merujuk contoh/tutorial untuk alternatif ini.

Kurang pengetahuan tentang internal kibana, saya sedang mempertimbangkan untuk menulis proxy REST yang berada di antara elastis dan kibana. Saat menanyakan dari Kibana untuk tipe tertentu yang diberikan beberapa kriteria pencarian berbasis istilah, proxy ini pertama-tama menanyakan tipe induk untuk menemukan kumpulan orang tua yang memenuhi kriteria pencarian (mereka sesuai dengan memori). Kemudian ia menemukan semua anak untuk orang tua ini dan mengembalikannya ke kibana yang didenormalisasi dengan semua bidang induk ditambahkan. Ini akan memungkinkan kita untuk memiliki model induk-anak dalam Pencarian Elastis yang menghindari ledakan penyimpanan dari denormalisasi segalanya menjadi miliaran objek anak, dan pada saat yang sama membuat grafik data berdasarkan bidang induk.

Idealnya ini adalah bagian dari Kibana. Dunia tidak datar!

+1

+1. Kami biasa membagi tumpukan fungsi atau url_args ke dalam bidang yang berbeda. Tapi ini datang dengan status cluster yang terlalu besar dan terlalu banyak tindakan refresh pemetaan. Jadi kita ubah ini menjadi objek bersarang. Sekarang, kita membutuhkan aggs di K4....

+1

+1 membutuhkan visualisasi agregasi induk -anak.

+1

Harap jangan percaya bahwa semua pengguna Elastic yang ingin menggunakan Kibana menggunakannya untuk analisis log. Kami memiliki data yang luas, dengan objek bersarang, yang terisi di klaster kami yang kami ingin dapat melakukan analitik terhadapnya tanpa harus menarik dan mengubah data menjadi sistem lain.

Mampu membuat agregasi bersarang, kueri bersarang, dan bahkan agregasi bersarang terbalik adalah suatu keharusan. Semakin lama Kibana tanpa fitur ini sama dengan semakin cepat kita harus menemukan alternatif tanpa menggunakan Elastic/Kibana. Jika menyediakan UI yang mudah digunakan untuk fitur semacam ini adalah bagian yang sulit, mulailah dengan menyediakan kemampuan bagi pengguna Anda untuk menyediakan kueri json lengkap untuk elastic yang mengembalikan data yang diperlukan.

+1

Setuju dengan @ppadovani . Kami sedang mengevaluasi alat BI dan akan senang menggunakan Kibana, tetapi tidak mendukung hubungan di entitas bisnis kami yang perlu kami laporkan, dan tidak cukup ramah pengguna untuk dijelajahi oleh pengguna non-teknologi. Kami akhirnya menggunakan Looker (pada dasarnya GUI untuk SQL). Melihat looker mungkin menawarkan beberapa ide tentang bagaimana kibana dapat diperluas untuk melayani kasus penggunaan yang lebih beragam di masa depan.

Saya memutuskan untuk melihat kode kibana 4.1 .. (Saya tidak dapat menggunakan master karena hanya berfungsi dengan 2.x elastic) .. Mohon koreksi saya jika saya salah tetapi tampaknya langkah pertama yang mudah untuk melakukan sesuatu bersama garis-garis ini:

1) Di bawah area agregasi 'lanjutan' yang dapat dilipat, tambahkan bidang teks yang disebut sesuatu seperti 'jalur bersarang'.
2) Jika pengguna menempatkan string di bidang itu, maka agregasi ini diatur, akan memiliki agregasi bersarang yang ditambahkan seperti ini:
"aggs":{
"2":{
"bersarang":{ "jalur":"foo" },
"aggs":{
"3":{
"date_histogram":{

Untuk menangani kasus beberapa level objek bersarang, Anda bisa menambahkan + yang memungkinkan pengguna menambahkan jalur bersarang tambahan. Selain itu, untuk menangani reverse nested, cukup tambahkan kotak centang berlabel 'reverse'.

Ini setidaknya akan memberikan dukungan agregasi 'bersarang' terbatas.

Untuk dukungan kueri bersarang, satu-satunya solusi yang dapat saya pikirkan untuk jangka pendek, adalah mengizinkan pengguna memasukkan json pencarian elastis kode tangan.

+1

+1 pada semua ini dan memungkinkan pengguna untuk memasukkan json pencarian elastis kode keras

+1

+1

+1. Saya sangat senang menggunakan Kibana untuk kebutuhan visualisasi lingkungan kami, tetapi tanpa dukungan untuk visualisasi objek bersarang, cukup menyakitkan menggunakan Kibana untuk tujuan kami di sana.

+1, baru saja mengalami ini.

+1

+1

+1

+1

+1

Setidaknya 82 orang mendapatkan "+1" Anda dan ini TIDAK membantu.

Saya sangat tidak setuju. Lebih banyak data tidak pernah buruk.

Tim saya dan saya sedang mengerjakan ini dan berharap mungkin memiliki sesuatu untuk ditunjukkan pada akhir minggu.

EDIT: Silakan lihat komentar saya di: https://github.com/elastic/kibana/pull/4645#issuecomment -132908544

+1

+1

+1

Selesai dan permintaan tarik dibuat di sini:
https://github.com/elastic/kibana/pull/4806

Pembaruan cepat bagi mereka yang menonton ... menunggu di Elasticsearch co. untuk ack CLA, kalau tidak saya pikir itu baik untuk pergi.

+1

+1 juga

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

Ya silahkan.

+1

+1

+1

+1

Permintaan tarik terhadap 4.1 ditutup mendukung yang ini melawan master.

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

Jika ada permintaan untuk versi 4.1 ini, saya dapat membuka kembali permintaan tarik dengan kode yang benar.

+1

+1

+1

+1

Saya tidak mengerti apa yang menghalangi masalah ini.
Ada permintaan tarik yang menunggu https://github.com/elastic/kibana/pull/5411

Ada orang-orang di sini yang siap berkontribusi. Apa yang perlu dilakukan untuk menggabungkan PR ini?

Pasti lebih banyak +1 dibutuhkan

@Filirom1 Beberapa dari kami telah berada di jalan, jadi kami belum memiliki kesempatan untuk meninjau PR :( Kami akan mencoba melakukannya minggu ini. Ini jelas merupakan peningkatan yang sangat dibutuhkan dan kami sangat bersemangat tentang kontribusi komunitas di sini!

Besar :-)
Terima kasih !

Saya melihat #5411 dan sayangnya itu bukan arah yang ingin kita tuju saat ini. #5411 menerapkan jeda penghentian, tetapi menyebabkan fitur penting, seperti pemfilteran dan penelusuran terputus. Itu juga menyebabkan pembuat agg itu sendiri tampak rusak bagi mereka yang tidak memahami implementasi yang mendasari agregasi bersarang. Setelah kami duduk dan melihat lebih dalam, kami menyadari bahwa jumlah pekerjaan untuk mendukung dokumen bersarang secara kohesif sangat luas.

Bukannya kami tidak ingin melakukan ini, tetapi jika kami melakukannya, kami ingin melakukannya dengan benar, bukan hanya menyiasatinya.

Kami menyadari bahwa banyak yang tertarik untuk memvisualisasikan data relasional, namun mengingat prioritas dan kekhawatiran lain, kami tidak memiliki sumber daya untuk didedikasikan untuk proyek ini saat ini dan tidak dapat berkomitmen untuk menambahkannya ke peta jalan di masa mendatang.

FYI kami berharap untuk menggunakan kibana dengan agregasi bersarang untuk analitik internal tetapi akhirnya menggunakan produk komersial, 'Looker', yang berada langsung di rdbms kami. Saya akan sangat menyarankan agar pengembang Elastic melihat apa yang telah mereka lakukan untuk membuat penjelajahan model relasional menjadi sederhana, karena banyak orang non-teknologi sekarang dapat menelusuri db langsung kami untuk pertanyaan sehari-hari mereka tentang produk. Saya mengevaluasi sejumlah produk dan Looker menjadi yang teratas, dan saya ingin melihat fungsionalitas serupa di Kibana suatu hari nanti.

Mengingat komentar terbaru Rashid dan penantian panjang untuk fitur ini, saya sarankan agar masalah ini ditutup. Jika masalah ini tetap terbuka maka itu hanya memberi harapan palsu kepada pengguna bahwa akan ada kemungkinan penerapan ini dalam waktu dekat. Mari kita tutup dan simpan idenya sampai pengembang memiliki sumber daya untuk mengetahui cara mengimplementasikannya.

Menyalin posting saya dari permintaan tarik:

Ada solusi di sini, tetapi itu akan membutuhkan banyak pekerjaan dan saya tidak punya waktu. Kami menerapkan ini di JAVA jadi saya tahu ini mungkin.

1) Setiap pemetaan indeks perlu menarik dan memahami bidang bersarang.
2) Bangun AST khusus yang menyediakan bahasa kueri yang disederhanakan alih-alih mencoba hanya menggunakan Elasticsearch.
3) Buat adaptor kueri yang memahami AST dan dapat memvalidasi serta mengonversi kueri ke JSON yang tepat.
4) Perbarui agregasi di Kibana untuk menangani bidang bersarang dengan benar berdasarkan pemahaman internal tentang bidang bersarang.

Ini bukan tidak mungkin untuk dilakukan, hanya membutuhkan kerja yang signifikan. Manfaat penerapan di atas termasuk validasi kueri dan sintaks yang disederhanakan. Misalnya AST kami memungkinkan kami untuk membuat kueri seperti ini:

(owner.user = "/users/00a0/18066271-29f0-40af-83ad-e5a0c8fc5944") AND (druid = "/druids/0060/77dd14b1-b7f0-4851-9ef8-74daa18d9d4d") DAN ((owner.lastMessageReceived. dimasukkan >= 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)

Bagaimana tepatnya saya bisa membuat kueri ini dengan bahasa yang ada?

IMHO - menunggu nirwana dari Elasticsearch sebelum bertindak akan menyebabkan penurunan adopsi dan hilangnya pengguna Kibana.

Benci terdengar seperti saya melakukan pemasaran tetapi ini relevan. (terlihat orang menyebutkan produk lain..)

Kami menemukan banyak ppl yang menggunakan sangat bersarang ingin benar-benar mencari data relasional dan akhirnya bersarang catatan yang seharusnya hanya "bergabung" terlambat. (Padovani, ini mungkin kasus Anda, saya melihat "pengguna" "pesan" dll. ini akan disimpan dengan sangat baik sebagai catatan terpisah)
Inilah alasan kami membuat plugin SIREn Join elasticsearch dan Kibi kami - fork Kibana yang menawarkan filter dan fungsionalitas untuk ini.

Kami sekarang bekerja untuk membuat sebanyak mungkin Kibi menjadi plugin yang kompatibel dengan Kibana 4.4 (alias 5.0) untuk manfaat semua.

Plugin Join telah dirilis kemarin dan juga open source.

Sementara itu, versi yang tersedia http://siren.solutions/kibi terus terang berfungsi seperti pesona dan membuat banyak pelanggan kami tidak memerlukan data bersarang lagi.

jccq: Tidak pernah tahu tentang Kibi atau plugin join. Terimakasih atas infonya!

+1

+1
ini adalah masalah yang harus dimiliki ...

@jccq Kasus penggunaan kami bukan tentang bergabung hanya untuk kueri, kami menggunakan entitas 'bergabung' atau 'tampilan' seperti yang kami sebut sebagai data entitas sejati dengan siklus hidupnya sendiri. Ini memungkinkan klien untuk menarik data yang digabungkan tanpa harus melakukan beberapa panggilan GET ke API kami.

Dalam hal dukungan bersarang di Kibana, kami mengembangkan pendekatan kami dan mungkin memiliki sesuatu untuk dibagikan dengan komunitas di Q2 atau lebih awal tergantung pada sumber daya dan waktu. Pendekatan baru ini akan mendukung bersarang dengan mulus di agregasi DAN kueri. Saya tidak akan mengatakan lebih banyak, karena masih dalam tahap implementasi yang sangat awal.

+1

@ppadovani kamu

+1

+1

+1
Ini sangat penting bagi kami.
Kami menunggu hampir satu tahun untuk fitur ini...

+1

Pembaruan: Saya tidak melihat cabang baru saya siap untuk umpan balik atau pengujian awal selama setidaknya satu bulan karena beban kerja saya. Namun saya ingin mengemukakan apa yang saya lakukan untuk mengumpulkan umpan balik dari komunitas saat saya bergerak maju.

Desain dasar berkisar pada dua hal:

1) Pengurai kueri baru untuk bidang kueri formulir bebas Kibana. Parser ini menggunakan definisi sintaksis Bison standar (lihat proyek Jison untuk versi javascript yang saya gunakan). BNF yang saya gunakan didasarkan pada BNF yang ada yang kami gunakan di Homeaway untuk bahasa kueri khusus kami terhadap Elasticsearch. Lihat komentar saya di atas untuk contoh. Saya memilih pendekatan ini untuk memungkinkan peningkatan masa depan oleh komunitas sesuai kebutuhan.

Saya memiliki parser kueri yang berfungsi di Kibana, tetapi masih ada pekerjaan yang harus dilakukan untuk memungkinkan pengguna beralih antara gaya kueri yang ada yang digunakan oleh Kibana dan gaya baru ini.:

2) Ubah panggilan getFieldMapping di mapper.js menjadi getMapping dan proses hasilnya secara berbeda sehingga jalur bersarang pada bidang ditangkap dan ditambahkan ke informasi bidang yang disimpan Kibana.

Saat kueri diketik di parser akan memvalidasi bahwa tidak hanya bidang yang diberi nama dengan benar, tetapi nilai yang diberikan juga valid untuk jenis bidang. Yaitu bidang tanggal mendapat tanggal, atau boolean diberi boolean. Selain itu, bidang bersarang akan ditangani secara otomatis oleh parser dan kueri Elasticsearch json yang tepat akan dihasilkan alih-alih bahasa kueri sederhana yang digunakan sekarang.

Akhirnya untuk agregasi, karena bidang sekarang berisi petunjuk tentang jalur bersarang, akan mudah untuk bekerja melawan cabang saya sebelumnya untuk secara otomatis menyuntikkan agregasi bersarang sesuai kebutuhan berdasarkan bidang yang dipilih.

Tonggak sejarah:
1 - Dapatkan fungsi parser, dan buat kueri
2 - Perbarui mapper.js, dan terapkan dukungan kueri bersarang
3 - Menerapkan dukungan agregasi bersarang
4 - Pengujian/pembersihan

Setiap umpan balik tentang pendekatan ini akan sangat dihargai. Terima kasih!

Pembaruan di atas:

• Pengurai selesai
• Pengurai terbalik selesai (mengambil json elasticsearch dan mengonversinya kembali ke bahasa kueri khusus)
• Kibana sekarang mencari tahu dan menyimpan NestedPaths di bidang
• Parser sekarang memiliki akses ke informasi lapangan

Masih harus:

• dukungan jalur bersarang di kedua parser
• Konstruksi UI untuk memungkinkan pengguna mengganti gaya kueri mana yang harus digunakan, dan memungkinkan kueri lama disimpan/digunakan.
• menyelesaikan penanganan kesalahan di parser, dan bagaimana UI menampilkan masalah/kesalahan penguraian
• Konstruksi UI untuk memberikan dukungan tipe-depan untuk nama bidang dalam kueri
• dukungan bersarang di bucket/metrik
• tes unit, tes unit, tes unit.
• ... ?

+1

Memperbarui:

• Parser secara otomatis menangani/menyuntikkan informasi bersarang
• Agregasi sekarang secara otomatis menangani/menyuntikkan informasi bersarang

MELAKUKAN:

• Perubahan UI untuk pemilihan gaya kueri, dan menyimpan pemilihan gaya dengan kueri dalam indeks kibana.
• penanganan kesalahan untuk kesalahan pengurai, dan bagaimana UI menampilkan masalah/kesalahan penguraian
• Dukungan tipe UI di depan untuk pembuatan/penulisan kueri
• tes unit, tes unit, tes unit ...

Rencana:
Saya ingin mendapatkan setidaknya beberapa kemajuan pada pekerjaan UI, bukan setelan kuat saya, maka kami akan mendorong cabang/garpu ke repo github HomeAway untuk memungkinkan umpan balik/kontribusi. Saya akan memposting di sini lagi ketika ini selesai sehingga siapa pun di antara Anda yang ingin menarik garpu dan bermain dengannya dipersilakan. Setelah cukup dipoles, saya akan membuat permintaan tarik resmi.

Satu catatan terakhir: Pekerjaan ini sedang dilakukan terhadap cabang Kibana 4.3.1.

Sebagai tindak lanjut dari komentar saya https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html
Ada beberapa pembicaraan tentang mencela "include_in_parent" dan "include_in_root" demi "copy_to" di versi ES mendatang: https://github.com/elastic/elasticsearch/issues/12461 Jika Anda memiliki pengalaman dengan keduanya, silakan Menimbang.

+1

ppadovani, hargai apa yang Anda coba lakukan. Fitur ini sangat penting bagi kami
Beberapa pertanyaan:

1. Saya mengerti ini akan memakan waktu? Apakah ada perkiraan waktu fitur ini akan tersedia?
2. Apakah ada yang mencoba alternatif? Suka mengubah format log dari json (array) bersarang ke yang lain? Jika demikian, apa format yang dimaksud, untuk bekerja dengan ELK ?
3. Apakah ada produk lain di pasar yang dapat membantu mencapai fungsi ini? Saya mendukung ELK karena ini open source, tetapi sampai tidak, kami menginginkan sesuatu yang lebih murah daripada Splunk. Kami menjelajahi banyak opsi, seperti Loggly, sumologic, logentries, logscape, greylog (baik semahal splunk atau mereka tidak memiliki fungsi ini)

Terimakasih banyak!

1. Apakah ada yang mencoba alternatif? Suka mengubah format log dari json (array) bersarang ke yang lain? Jika demikian, apa format yang dimaksud, untuk bekerja dengan ELK ?

Anda dapat meratakan skema atau menggunakan opsi pemetaan ES "include_in_parent" atau "copy_to" untuk menyalin beberapa bidang dari dokumen bersarang ke dokumen induk. Tidak bekerja untuk semua kasus penggunaan, tetapi dalam beberapa kasus ini akan memungkinkan Anda untuk menggunakan Kibana di luar kotak. Kami menggunakan pendekatan "include_in_parent" secara internal di Elastic.

1. Saya memiliki cabang yang 'berfungsi', tetapi membutuhkan lebih banyak TLC dalam bentuk pekerjaan UI. Ini bukan pekerjaan utama saya jadi saya hanya bisa mengerjakannya jika saya punya waktu.
2. Seperti yang ditunjukkan oleh @tbragin , Anda dapat meratakan data. Namun ini dapat menyebabkan hasil kueri yang tidak valid.
3. Saya tidak mengetahui adanya alternatif pada saat ini.

Untuk lebih jelas seperti apa bahasa kueri itu, karena saya telah ditanyai permintaan tarik lama saya, berikut adalah ringkasan BNF:

Perbandingan: bidang [=,<,>,<=,>=,~=] nilai
Perhatikan ~= .. ini menunjukkan LIKE yang pada gilirannya akan menyebabkan kueri wildcard
IN: field IN {nilai,nilai,...} Setel operasi
bidang IN [nilai,nilai] Operasi rentang menggunakan [ ] atau ( ) tergantung pada inklusif/eksklusif
IS: bidang IS NULL
ekspresi: IS | DI | Perbandingan
BUKAN: BUKAN ekspresi
DAN | ATAU: ekspresi DAN |
EXISTS: ekspresi EXISTS
Ada adalah cara pelingkupan bersarang terjadi. Biasanya tanpa menggunakan EXISTS semua ekspresi yang bersebelahan dan memiliki jalur bersarang yang sama akan digabungkan ke dalam kueri bersarang yang sama. Namun, Anda dapat memecah blok kueri bertingkat dengan menggunakan EXISTS untuk mencakup kueri bersarang tertentu dari satu sama lain.

Seperti yang dinyatakan sebelumnya, bahasa ini menggunakan JISON yang setara dengan javascript BISON, dan akan memungkinkan kita untuk memperluas bahasa sesuai kebutuhan dengan sedikit usaha.

MEMPERBARUI:

Saya yakin saya hampir dapat berbagi cabang dengan semua orang untuk menguji dan memberikan umpan balik. Saya memiliki parser yang berfungsi dan setidaknya umpan balik sintaks berfungsi serta tes unit terhadap parser. Beberapa tangkapan layar:

Saya berharap bahwa saya akan memiliki cabang siap akhir minggu ini. Ketika saya sudah siap, saya akan menautkan ke posting blog di sini yang akan menautkan ke cabang dan memiliki ikhtisar lengkap tentang sintaks, penggunaan, dll. Rencana saya adalah mengumpulkan umpan balik di cabang, memperbaiki masalah, meningkatkan seperti yang diminta dan kemudian mendapatkan permintaan tarik yang diajukan.

Saya ingin mengujinya (berikut adalah contoh penggunaan agregasi bersarang kami di K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523, tidak akan bermigrasi tanpanya).

@Robitx Saya tidak berpikir itu akan menjadi masalah... kami memiliki dokumen yang memiliki setidaknya dua tingkat objek bersarang... misalnya:

A->B->C

Di mana satu dokumen A mungkin memiliki satu atau lebih B, dan masing-masing berisi daftar C yang ada di B. Setiap dokumen bersarang memiliki beberapa bidang dari berbagai jenis. Saya telah menguji kode ini sedemikian rupa sehingga saya dapat membuat histogram atau diagram lingkaran multi-lapisan terhadap data bersarang terdalam.

Untuk lebih jelasnya, pemetaan kami dibuat secara otomatis dari pojo kami dan bisa menjadi sangat kompleks.

+1

MEMPERBARUI:

Saya ingin mengeluarkan ini agar orang-orang mulai bermain daripada menunggu posting blog resmi di pihak saya muncul.

Fork/Cabang dapat ditemukan di sini:

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

BACA AKU:

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

Isi README pada dasarnya adalah isi dari posting blog yang akan muncul di beberapa titik.

Jangan ragu untuk membuka masalah/menarik permintaan terhadap cabang fullNestedSupport jika Anda mau. Saya akan mencoba dan tetap di atas masalah apa pun yang ditemukan orang.

+10000

+100500

+100

Hi ppadovani,

Bisakah Anda memberi saran, apa yang harus saya lakukan?

Bidang ini ada di pemetaan elasticsearch Anda tetapi tidak ada di dokumen apa pun di hasil pencarian. Anda mungkin masih dapat memvisualisasikan atau menelusurinya.

Terimakasih banyak!

Hi ppadovani,

Kami memiliki bidang sebagai array bersarang.
"abc":[["3815222235847451","131712121218083052"]]
ATAU
"abc":[["3815222235847451",,"131712121218083052",,"131712121217783052"]]
ATAU
"abc":[["3815222235847451"]]

Nilainya bisa berupa 1-10

Sementara untuk bidang bersarang lainnya saya melihat peringatan bahwa bidang tersebut tidak diindeks (yang saya kira saya perlu menggunakan pemetaan?) untuk bidang ini dan lainnya seperti ini, setiap set diperlakukan sebagai nilai terpisah? Selain itu, jenis bidang ditampilkan sebagai "string" alih-alih angka, yang bukan merupakan masalah tersendiri, tetapi apa artinya saya tidak dapat mencari nilai individual abc..?

Terimakasih banyak!

Ditemukan beberapa menit untuk memulai pengujian :) :|

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) - Saya tidak percaya itu adalah pesan yang dihasilkan oleh perubahan saya, dan mungkin sesuatu yang ada di Kibana sebelumnya.
2) - Jadi ya .. sepertinya nilai disimpan sebagai string, tetapi ini mungkin tidak bersarang .. Saya harus melihat seperti apa pemetaan pada indeks untuk memahami masalah apa/jika ada. Silakan tempel pemetaan di sini.

@Robitx
Saya berasumsi ini adalah bidang tanggal ... waktu zaman memiliki terlalu banyak digit seharusnya 10 bukan 13 .. dapatkah Anda memperbarui/menempelkan kueri yang Anda keluarkan?

@ppadovani
Saya baru saja memilih pola indeks default dalam pengaturan dan kembali untuk menemukan tab

Kita gunakan

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

K 4.4.1+ES 2.2 berfungsi dengan baik, mungkin khusus K 4.3 (Saya belum pernah mencoba versi ini sebelumnya)

@Robitx
Saya mencari kueri yang digunakan ... atau apakah Anda mengatakan bahwa kueri yang diteruskan hanyalah jendela tanggal standar dari UI dan Anda tidak menentukan kueri? Saya akan mengubah basis perubahan saya terhadap rilis Kibana selanjutnya dan memposting ulang ketika cabang diperbarui.

@ppadovani ya hanya * dan beberapa rentang waktu

+1 untuk objek bersarang di bagian visualisasi

@Robitx
Operasi yang Anda jalankan tidak pernah mencapai salah satu kode parser saya ... jadi saya ragu itu karena sesuatu yang saya lakukan ... Pengaturan saya adalah K 4.3.1 + ES 2.1.1 - Saya akan meningkatkan ES saya ke 2.2 dan lihat apakah saya mendapatkan perilaku yang sama, maka saya akan rebase cabang ke K 4.4.1

Baru saja ditingkatkan ke ES 2.2.1 w/ K 4.3.1 + kode saya... tidak dapat mereproduksi:

Saya masih akan rebase ke 4.4.1 - rilis saat ini, akan memperbarui posting ini ketika cabang sudah siap.

MEMPERBARUI:

Diubah menjadi 4.4.1 di cabang baru: https://github.com/homeaway/kibana/tree/nestedSupport-4.4.1

Diuji pada ES 2.2.0 dan K 4.4.1

Hi ppadovani,

Mengenai pertanyaan saya sebelumnya, saya akan melupakan itu. Saya sudah memiliki instance pencarian elastis di AWS (bersama dengan pemetaan) dan saya mencoba menghubungkan ini dengan itu. Namun status server kibana di UI mengatakan:

plugin:elasticsearch Versi Kibana ini membutuhkan Elasticsearch ^2.1.0 di semua node. Saya menemukan node yang tidak kompatibel berikut di cluster Anda: Elasticsearch v1.5.2 @ undefined (undefined)

Saya masih menggunakan https://github.com/homeaway/kibana/tree/fullNestedSupport dan bukan yang terbaru yang disediakan oleh Anda. Apakah mungkin bagi Anda untuk membuatnya kompatibel untuk 1.5.2?
Mohon saran.

Terimakasih banyak!!

@ppadovani
Saya dapat mengerti jika ini tidak mungkin, karena kita akan mundur, namun, Amazon Elasticsearch Service tidak terlalu tertarik untuk meningkatkan ke versi yang lebih baru, yang dapat dimengerti. Jadi, saya harus bekerja dengan apa pun yang kami miliki. Kami telah menginvestasikan banyak upaya dalam menyiapkan instans AWS (bersama dengan penerusan log dari beberapa node, acara streaming, dan detail menit lainnya) dan menemukan kembali semuanya di platform terpisah dari awal bukanlah pilihan bagi kami. Akan lebih baik jika dapat mengaitkan ini sebagai Frontend tambahan. Saya bahkan tidak yakin apakah akan ada penghalang jalan lain di masa depan?

Terima kasih!!

@BigDataEngineer
Setelah melihat kode Kibana di versi sebelumnya, versi pertama yang bisa saya coba dan terapkan perubahannya adalah 4.1.6. Namun, ada penulisan ulang/refactor/reorganisasi kode yang signifikan dan saya tidak bisa begitu saja menambal cabang itu. Ini akan membutuhkan banyak pekerjaan untuk mencoba dan memasukkan kode saya dan berfungsi.

Sejujurnya saya tidak tahu mengapa tim Kibana meningkatkan versi elastis yang diperlukan seperti yang mereka lakukan dengan setiap rilis .. antarmuka REST tidak sering berubah. Saya berspekulasi bahwa mereka melakukannya untuk memaksa pengguna meningkatkan klaster elastis mereka.

Satu pemikiran, Anda dapat mencoba mengubah versi di src/plugins/elasticsearch/index.js di sekitar baris 27

@ppadovani
itu berhasil. Terima kasih.

+1

@ppadovani Hai, terima kasih telah meningkatkan ke versi 4.4.1, maaf karena tidak merespons lebih cepat (saya melewatkan pembaruan Anda di salah satu komentar sebelumnya).

Ini berfungsi sekarang, tetapi hal pertama yang saya perhatikan adalah masalah kinerja dan kadang-kadang kibana membeku sepenuhnya (saya tidak dapat menguji kueri yang lebih rumit).

Ada beberapa hal yang mungkin berkontribusi terhadap masalah ini, salah satunya adalah sejumlah kolom dalam indeks harian kami (ada ratusan di antaranya http://Pastebin.com/fktN0dR5).

@Robitx Apakah Anda memiliki masalah yang sama dengan kode dasar 4.4.1 K tanpa perubahan saya? Atau hanya dengan perubahan saya? Saya tahu bahwa pola indeks yang sangat besar menyebabkan masalah kinerja yang signifikan untuk K. Jika hanya dengan kode saya, maka saya pikir saya tahu apa itu. Saya akan melihatnya ketika saya mencari udara dalam satu atau dua hari.

@ppadovani basis K 4.4.1 tidak memiliki masalah ini

Setahun sejak masalah ini tidak diperbaiki ...

Sial, elasticsearch memiliki fitur "Nested Objects" yang cukup dibutuhkan, dan Kibana dari pengembang yang sama masih belum mendukung fitur ini.

Anda memiliki fork yang sudah mengimplementasikan fitur ini dan masih belum bergabung dalam kode sumber utama, dengan dukungan yang tepat.

Dan kami masih tidak dapat menggunakan KIbana versi stok proyek kami dengan dukungan "Objek Bersarang".

F * cking luar biasa !!!

@ppadovani terima kasih banyak atas pekerjaan Anda di fork=)

@Robitx Bisakah Anda memberi tahu saya kapan Kibana membeku untuk Anda? Definisi IndexPattern? Atau saat Anda memulai kueri baru? Ada kemungkinan area di mana ini mungkin terjadi, dan saya ingin mempersempitnya.

Saya memperbaiki satu masalah yang mungkin berkontribusi saat memunculkan tab penemuan/visualisasikan... Saya telah mendorong perbaikan, harap uji ulang.

@rashidkpc Saya siap membuat permintaan tarik berdasarkan pekerjaan ini. Bisakah Anda memberi tahu saya cabang mana yang harus saya rebase untuk pekerjaan saya? Saat ini saya memilikinya terhadap 4.3.1, 4.4.1, dan 4.x. (4.x sudah dekat, tetapi saya mengalami masalah dalam menjalankan pengujian unit. Cluster pengujian gagal untuk memulai...)

Hai geng (cc @ppadovani)

Seperti yang saya sebutkan di https://github.com/elastic/kibana/pull/5411 ada sejumlah batasan dalam Elasticsearch itu sendiri, terutama bahwa aggs/filter bersarang tidak otomatis dan sintaks kueri lucene tidak mendukung pencarian bersarang. Sementara pendekatan yang diambil di sini akan memetakan jalan yang berbeda untuk memecahkan masalah, itu bukan arah yang ingin kita tuju. Ini adalah solusi untuk masalah yang sempit, tetapi kami ingin Kibana menyelesaikan banyak tantangan. Dalam hal ini itu berarti mengorbankan kemenangan yang lebih kecil untuk kemenangan yang lebih besar di kemudian hari.

Sementara kami mempertimbangkan kemungkinan bahasa untuk Kibana, kami belum memutuskan persis seperti apa fitur yang kami inginkan dan tidak ingin melakukannya setengah jalan, atau dengan satu tujuan dalam pikiran. Kami sedang mempertimbangkan beberapa taktik dan set fitur, baik di Elasticsearch maupun di Kibana, tetapi kami masih dalam tahap pembentukan. Seiring waktu kami ingin ini menyertakan pencarian, transformasi, dan visualisasi, seperti yang Anda lihat di sesuatu seperti timelion, dan kami pasti akan mengingat gagasan untuk menanyakan dokumen bersarang saat kami melakukannya

Saya mencatat bahwa ini menyimpan jalur bersarang, namun kami menghapus pemetaan yang di-cache https://github.com/elastic/kibana/pull/6648 dan menggantinya dengan API baru di Elasticsearch: https://github.com/elastic /elasticsearch/issues/15728. Tolong pertimbangkan masalah itu, akan lebih bagus jika Kibana tidak perlu menguraikan jalur bersarang. Ini sangat penting untuk tujuan kami membuat dokumen yang sangat besar dapat diakses di Kibana

Untuk saat ini kami sarankan untuk mengambil pendekatan @tbragin menggunakan include_in_parent atau copy_to . Untuk 90% agregasi, pendekatan ini akan bekerja dengan sempurna.

Saya senang solusi ini berfungsi untuk mereka yang tidak dapat menggunakan include_in_parent atau copy_to , sangat terkesan dengan apa yang telah dicapai @ppadovani . Saya ingin melihat sesuatu seperti ini diimplementasikan sebagai plugin. Saat ini input kueri pada dasarnya membutuhkan 2 jenis kueri, kami mungkin dapat menemukan cara untuk membuatnya dapat dicolokkan.

hei, ikut campur. Saya mengobrol dengan Rashid tentang ini, dan sementara saya merasakan sakitnya pengguna yang ingin menggunakan Kibana untuk pemetaan bersarang, mendukungnya secara lebih umum (yang mungkin menyiratkan fitur tambahan di level Elasticsearch itu sendiri) adalah jalan ke depan yang mempertahankan fleksibilitas yang kita butuhkan di Kibana. Sementara mendapatkan perubahan yang disarankan ini mungkin memecahkan masalah jangka pendek karena tidak mendukung bersarang, itu akan terbukti menjadi masalah di kemudian hari.

Saya menuju dan merasa perlunya Kibana di sini untuk mendukung bersarang, tetapi ini adalah salah satu kasus di mana jika tidak jelas bagaimana hal itu perlu diselesaikan, lebih baik membiarkannya tidak terpecahkan sampai kita memiliki solusi yang terasa alami. Kita pasti perlu melanjutkan dan mendalami itu, salah satunya, yang kita ngobrol di tempat yang berbeda, secara otomatis mendukung nested (wrapping dan sebagainya) di ES itu sendiri.

Saya sangat bersemangat untuk melihat ini diselesaikan dengan elegan.

+1

+1

IMHO Saya harus dengan hormat tidak setuju dengan sikap pengelola Kibana. Namun, jika kita dapat menemukan cara untuk membuat sesuatu di sepanjang garis ini terhubung ke Kibana, saya akan setuju.

Sementara itu, saya akan terus memelihara dan memperbaiki bug di fork/cabang saya bagi mereka yang ingin terus menggunakan versi yang telah saya buat. Saya tahu bahwa kami akan menggunakan ini secara ekstensif untuk dasbor analitik BI langsung di masa mendatang.

Ternak. Bukan hewan peliharaan.

+1 :)
Akan sangat bagus untuk menggunakan objek Bersarang di Kibana !! (Seseorang memiliki plugin untuk itu atau tidak?...)

+1

+1

+1

@tbragin Pendekatan yang Anda sebutkan tidak berfungsi pada tipe bersarang. Ini akan mengumpulkan semua data terlepas dari jenisnya.

+1

+1

+1

+1

Fitur ini sangat mudah, saya benar-benar terkejut mengetahui bahwa itu tidak hanya tidak didukung, tetapi pengembang tampaknya tidak memiliki rencana untuk mendukungnya. Sial, bicaralah dengan manajer proyek Anda dan rekrut @ppadovani untuk membuat plugin jika Anda tidak mau melakukannya sendiri.

+1 karena kurangnya objek bersarang menghambat proyek saya secara substansial

Bagi siapa pun yang mencari diskusi tentang denormalisasi sebagai cara untuk menghindari masalah ini: Mengatasi hilangnya dukungan Kibana untuk Objek Bersarang & Orang Tua/Anak

Elastis akan sangat bagus jika ada penafian di situs mengenai masalah ini untuk menghindari pengguna membuang waktu di sana untuk mencoba menerapkan fitur yang tidak didukung. Mengapa? Halaman produk Kibana mengatakan "Integrasi Seamless dengan ElasticSearch" yang tidak benar di sini :)

FYI - Cabang kode saya yang dirujuk dalam diskusi di atas sudah tua .. cabang saat ini adalah:

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

Kami secara aktif menggunakannya secara internal, dan terus memperbarui versi internal kami. Saya dapat/akan memperbarui versi github jika ada minat.

Pierre

+1

+1

+1

+1

+1

+1

Saya ingat memberi ini +1 lebih dari setahun yang lalu, dan sejak itu tim pengembangan Kibana tidak melakukan apa-apa selain menggali penyembuhan mereka dan sebagian besar mengabaikan pengguna dan akhirnya ketika kaki mereka dibakar, mereka merespons dengan lebih-atau- less "TIDAK", yang menyatakan bahwa "tidak terasa alami".

Saya juga melihat pola ini pada banyak fitur lain yang diminta seperti:

• Dukungan untuk memanggil skrip groovy sisi OS.
• Dukungan untuk dapat menggunakan ES Scripted Metric Aggregations (terutama berguna untuk menghitung rata-rata tertimbang).
• Dan seterusnya...

Ini semua bertentangan dengan pendirian pada seluruh visi Elastic Stack 5 yang menyatakan bahwa mereka (Elastis) akan mendukung lebih banyak fitur mendasar dari Elasticsearch di Kibana. Tapi saya telah melihat sangat sedikit untuk mendukung klaim ini.

Akibatnya saya melihat Kibana kehilangan tempat untuk garpu seperti Kibi Siren, yang memutuskan untuk mengambil obor pada item seperti topik ini dan datang dengan solusi.

Saya berterima kasih kepada pengembang Kibana karena memberi kami alat visualisasi yang hebat. Tetapi Elastic perlu memutuskan ke depan apakah Kibana akan tetap menjadi alat visualisasi sederhana atau mendengarkan komunitas dan memperluas kegunaannya. Jika keputusannya adalah yang pertama, maka harapkan pengguna untuk pergi ketika orang lain memutuskan untuk mengambil keuntungan dari kekurangan ini.

+1

@cslinuxboy

Dukungan untuk memanggil skrip groovy sisi OS.

Sebagian besar kasus penggunaan yang dicakup oleh ini akan diselesaikan dengan https://github.com/elastic/kibana/pull/7700.

Dukungan untuk dapat menggunakan ES Scripted Metric Aggregations

Saya tidak berpikir ada yang menentang ini (setidaknya, tidak melihat oposisi di sini https://github.com/elastic/kibana/issues/2646), sebenarnya sekarang adalah waktu untuk menambahkannya sejak Elasticsearch telah menambahkan bahasa scripting tanpa rasa sakit. Ini benar-benar hanya masalah seseorang menemukan waktu.

+1

+1

+1

Saya mulai mengerjakan garpu saya lagi. Saya ingin meminta maaf kepada komunitas, saya tidak tahu sampai sekitar sebulan yang lalu bahwa saya belum mengaktifkan masalah untuk garpu, jadi tidak ada yang bisa menunjukkan bahwa ada bug. Itu telah diperbaiki.

Cabang saat ini: https://github.com/homeaway/kibana/tree/nestedSupport-4.5.4

Pembaruan dalam urutan yang ingin saya implementasikan:

• Tambahkan dukungan untuk offset tanggal ke parser kueri
• Tambahkan dukungan ke penemuan untuk bidang bersarang saat melihat hasil - SELESAI
• Tambahkan dukungan untuk kueri dan agregasi orang tua/anak
• Tambahkan dukungan untuk jenis bentuk geo untuk kueri (yaitu titik, kotak, dll.) Ini adalah port peningkatan terbaru untuk bahasa internal kami.
• Tambahkan ketik di depan untuk nama bidang di bidang kueri
• Saya mungkin mencoba dan membangun parser untuk bahasa kueri sederhana Elasticsearch yang ada untuk memperbaiki gangguan kueri yang tidak valid baik yang menyebabkan jejak tumpukan dikembalikan dari Elasticsearch, atau tidak ada hasil yang dikembalikan tanpa indikasi mengapa. Jika saya mengerjakan ini, itu akan terjadi setelah saya menyelesaikan hal di atas. Jika saya melakukan ini, saya akan melihat menambahkan dukungan bersarang dan orang tua/anak ke bahasa di sisi Kibana.

Saya ingin menambahkan suara saya kepada mereka yang mengindikasikan bahwa tim Kibana tidak mendengarkan komunitas. Tim Kibana TIDAK BISA hanya mengandalkan Elasticsearch untuk menyediakan fungsionalitas yang dibutuhkan jika ada celah untuk menjaga Kibana "murni". Pangsa pasar tidak diperoleh dengan cara itu, ia hilang.

+1

+1
@Bargs : Ada kemajuan dalam masalah ini? Kapan ini akan ditangani/diprioritaskan?
Benang yang sangat panjang .... Ini tidak baik untuk produk seperti kibana..
Kami menghargai upaya Anda

Ini menyebalkan :-(

homeway memiliki aggs & query suport build di Kibana 4.3.1, periksa.. semoga membantu..

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

@ankitchheda Saya tahu tentang itu, tetapi garpu yang dikelola oleh beberapa orang yang bertentangan dengan filosofi proyek utama (yang sedang dalam pengembangan berat) bukanlah solusi, berpura-pura itu tidak akan membantu siapa pun ..

Saya ingin melakukan sesuatu tentang itu, tetapi saya tidak punya waktu, jadi untuk saat ini setidaknya saya mencoba untuk memberikan tekanan dan berharap para pengembang akan berhenti mengabaikan masalah ini :|

+1

FYI - Garpu yang saya pertahankan untuk dukungan bersarang, sekarang memiliki dukungan untuk versi berikut:

4.5.X
4.6
4.7
5.X

Ini mungkin tidak mengikuti 'filosofi' dari pengembang utama, tetapi itu berhasil dan bekerja dengan baik.

Saya baru saja menghadapi ini. Ini sedikit kelemahan dan akan sangat berguna untuk memiliki solusi yang bisa diterapkan.

@tbragin , @rashidkpc - solusi yang diusulkan tidak tepat - Anda mengerti
sesuatu dengan objek bersarang - tetapi Anda mendapatkan hasil yang salah! Bersarang
agregasi memberikan hasil yang berbeda (saya akan melakukan sedikit contoh yang berhasil dan mempostingnya di sini nanti).

Saya akan menguji garpu @ppadovani.

+1

:kura-kura::lari:

@Bargs Hei apakah perubahan dari fork membahayakan kinerja fungsionalitas dasar?

+1

+1

+1

+10086

+1

+1

+1

include_in_parent masih berfungsi di ES dan Kibana 5.2? Saya mencoba menggunakan sebagai alternatif tanpa hasil.

@gustavomr Saya percaya ini akan berhasil, tetapi hanya untuk kasus penggunaan tertentu. Ini tidak akan berfungsi untuk semua kemungkinan kasus penggunaan kueri yang dapat disediakan oleh kueri/agregasi bersarang.

CATATAN: Garpu 5.1 Kibana saya sekarang menggunakan sakelar di sebelah ikon pencarian untuk beralih antara bahasa kueri sederhana elastis asli dan bahasa kueri bersarang yang telah saya sertakan. Saya juga telah memperbaiki berbagai masalah seputar metrik untuk bidang bersarang.
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovani terima kasih banyak telah melakukan ini. Apakah mungkin untuk memisahkan pekerjaan Anda yang memungkinkan objek bersarang di kibana dari pekerjaan Anda membuat bahasa kueri baru? Jika ini bisa menjadi cabang yang terpisah daripada kita bisa menggunakan yang pertama dan menggabungkannya dengan rilis kibana yang lebih baru saat mereka keluar daripada harus menggabungkan kedua fitur.

Juga apakah Anda sudah memiliki buruh pelabuhan yang dibuat untuk garpu ini?

@ppadovani +1 untuk wadah buruh pelabuhan untuk garpu Anda.

@gkozyryatskyy - Silakan buka masalah di garpu, dan saya akan melihatnya.

@ imranq2 - Saya bisa melakukan ini, namun harap perhatikan bahwa bahasa kueri elastis sederhana tidak mendukung kueri bersarang. Jika Anda memiliki data bersarang dan ingin membuat kueri, Anda harus membuat kueri sebagai gumpalan json elasticsearch, dan menempelkannya ke dalam kotak kueri.

+1

Garpu saya sekarang mendukung 5.2 di cabang nestedSupport-5.2.

@ppadovani Bagus sekali! Beri tahu saya jika Anda memerlukan bantuan untuk membuat wadah buruh pelabuhan untuk ini.

Wadah buruh pelabuhan belum selesai, tetapi punya waktu untuk bermain dengan tab penemuan dan cara menampilkan data bersarang... mencari umpan balik dari mereka yang memantau masalah dukungan bersarang. Tabelnya rekursif dan filter untuk bidang bersarang tampaknya berfungsi dengan baik .. tetapi bidang sakelar di kolom belum berfungsi ... Saya masih perlu memikirkan bagaimana/jika itu harus bekerja.

FYI - Pekerjaan ini pada dasarnya selesai dan semua cabang/cabang yang didukung memiliki perubahan dimulai dengan nestedSupport-4.5.4 hingga nestedSupport-5.2

@Bargs - Saya tahu tidak ada pekerjaan bersarang yang telah saya lakukan adalah sesuatu yang kalian ingin lakukan, tetapi saya ingin tahu apakah pekerjaan di sekitar menampilkan data bersarang dalam hasil penemuan adalah sesuatu yang mungkin Anda inginkan. Itu tidak tergantung pada pekerjaan saya sebelumnya. Lihat masalah ini untuk tangkapan layar yang diperbarui:
https://github.com/homeaway/kibana/issues/12

Jika ini adalah sesuatu yang kalian inginkan, beri tahu saya dan saya akan membuka masalah dan menyertakan tambalan.

Terlihat menarik @ppadovani ! Jika Anda ingin membuka PR, saya pasti tertarik untuk memeriksanya. Kami telah berbicara sedikit tentang menambahkan dukungan yang lebih baik untuk bidang bersarang ke Discover sehingga akan sangat bagus untuk memiliki sesuatu yang konkret untuk didiskusikan.

@ppadovani Saya sedang membuat wadah buruh pelabuhan untuk ini sekarang sehingga saya dapat menggunakannya. Apakah Anda sudah membuat bola tar seperti http://staging.elastic.co/ $(VERSION_TAG)/downloads/kibana/kibana-${ELASTIC_VERSION}-linux-x86_64.tar.gz? Jika demikian saya bisa menariknya ke dalam wadah buruh pelabuhan saya. Kalau tidak, saya harus membangun cabang Anda dan membuat tarball.

@imranq2 Saya tidak menyediakan distribusi garpu saya, jadi Anda harus membuatnya sendiri.

FYI - Saya telah membuat permintaan tarik untuk mendukung data bersarang di tab penemuan bagi mereka yang tertarik:
https://github.com/elastic/kibana/pull/10814

+1

+1 untuk saya
+10 untuk kolega saya

+1

+1

+1

+1

+1

+1

+1. Apakah ini didukung di ELK5?

+1

ini benar-benar persyaratan karena tidak mendukung objek bersarang benar-benar merupakan hambatan untuk adopsi kibana secara luas di perusahaan saya karena Anda harus membuat indeks untuk kibana dan yang lain dengan dokumen bersarang untuk pencarian yang lebih pintar melalui API biasa

+1
Dalam pemetaan saya itu akan mencegah kemungkinan "ledakan" properti indeks.

+1

+1

+1

Tolong, berhenti memposting komentar +1 yang hanya mengirim spam ke semua orang yang berlangganan utas ini. Sebagai gantinya, klik tombol kuning besar "jempol ke atas" di bagian atas edisi ini untuk memilihnya.

+1

Pengembang Kibana, tolong lakukan sesuatu, kawan. Penggunaan Kibana tanpa objek bersarang dalam banyak kasus tidak berguna. Anda menyiapkan versi 6.x tanpa objek bersarang...

Sistem kami memindai teks untuk rumah dan kemudian menyimpan hasilnya ke ES. Jadi ES berisi dokumen utama dengan susunan rumah. Rumah adalah objek bersarang.

Saya tidak dapat menggunakan visualisasi untuk membuat dasbor dengan analisis rumah yang kami temukan dalam teks.
Tolong lakukan sesuatu. Rumah-rumah terbakar.

Sangat perlu menggunakan objek bersarang di kibana. Terasa buruk bahwa ini tidak tersedia built-in.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

satu lagi di sini!

Bagi mereka yang mungkin telah menggunakan garpu Kibana saya dengan dukungan bersarang, saya menghentikan dukungan untuk garpu itu setelah rilis Kibana 5.4.x. Sebaliknya saya akan memindahkan sebagian besar jika tidak semua fungsi ke dalam plugin Kibana. Saya berharap plugin sudah siap untuk rilis 5.x terbaru pada akhir tahun. Anda dapat mengikuti perkembangannya di sini: https://github.com/ppadovani/KibanaNestedSupportPlugin

Saya baru saja memulai pekerjaan, jadi jangan berharap sesuatu yang signifikan akan muncul selama beberapa minggu.

+1

+1

+1

+1

+1

Saya memiliki tangkapan layar dan pembaruan status yang diposting untuk pekerjaan yang saya lakukan di plugin dukungan bersarang. Tonton edisi untuk mendapatkan pembaruan status.

Tangkapan layar dan pembaruan

Saya telah melanjutkan dan merilis pra-rilis 1.0.0 dengan dukungan untuk Kibana 5.6.5.

Lihat masalah ini untuk detail tentang apa yang ada di pra-rilis awal: Tangkapan layar dan pembaruan

V1.0.0-beta1

Plugin saya adalah fitur lengkap untuk versi 5.6.5 dari Kibana. Saya memiliki beberapa tugas pembersihan, kemudian saya akan memotong versi 5.6.5 dan mulai meneruskan porting ke 6.1.X.

Fitur:

• Dukungan kueri bersarang
• Dukungan agregasi bersarang
• Temukan hasil dukungan bersarang
• Temukan prioritas tampilan bidang ringkasan (ini sebenarnya sesuatu yang baru)

Lihat README untuk detailnya.

Plugin saya sekarang dirilis! Dukungan untuk 5.5.3, 5.6.5, dan 5.6.6. Saya akan porting ke 6.0.X akhir pekan ini.

Saya mungkin tidak akan memperbarui status di sini tentang masalah ini lagi. Silakan kunjungi halaman GitHub saya untuk melihat rilis, masalah, dll.

Terima kasih!

@ppadovani dapatkah Anda merilis versi dukungan untuk 5.4.0 terima kasih.

@ppadovani Saya akan mengawasi port 6.0.x!

@SolomonShorser-OICR
Saya telah merilis build 6.0.1 Beta 1.

Satu-satunya batasan yang diketahui adalah bahwa bilah filter tidak beroperasi karena kode keras hanya berfungsi dengan bahasa kueri lucene. Saya sedang mencari cara untuk mengatasinya, tetapi mungkin tidak memiliki solusi sampai akhir pekan depan.

Saya sekarang telah merilis plugin build untuk 6.0.1, 6.1.x berikutnya.

@ppadovani
Terima kasih atas pekerjaan Anda dan rilis 6.0.1!

berdasarkan kibana 6.0.1, setelah menginstal plugin ini, beberapa fitur kibana tidak berfungsi dengan baik.

saat klik timelion, itu menunjukkan pesan kesalahan:

jika x-pack diinstal, beberapa fitur x-pack "discover" memiliki pesan kesalahan lain di "Foreach"

Hei tim Kibana, mengapa Anda belum merekrut @ppadovani ?

@sccds - Harap pindahkan laporan bug ini ke repo GitHub saya:

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

Jika seseorang memiliki masalah dengan plugin saya, silakan buka masalah di repo saya dan jangan memulai percakapan di sini. Masalah ini memiliki terlalu banyak pelanggan.

@Hronom - Saya menghargai pemikiran itu, tetapi kekuatan saya tidak dalam Javascript .... meskipun membangun plugin ini dan meretas Kibana tentu saja membantu kemampuan saya di bidang itu.

FYI - Plugin saya sekarang diperbarui dengan rilis Kibana. Saya telah merilis dukungan 6.1.2.

Terima kasih @ppadovani ,

+1

+1

+1 Halo, Tomitribe sangat tertarik dengan fitur ini. Sudah tahu kapan fitur ini akan diimplementasikan?

@ppadovani di mana saya bisa bertanya tentang fungsionalitas? Saya berjuang dengan agregasi bersarang di tabel data.

@bumerankkk Buka di sini dan buka masalah: https://github.com/ppadovani/KibanaNestedSupportPlugin

Atau, jika Anda membuka salah satu halaman dokumentasi yang sesuai dengan pertanyaan Anda, Anda dapat menambahkan komentar di bagian bawah halaman.

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

Apakah ini sedang aktif dikerjakan? Apakah kami memiliki jadwal kapan fitur tersebut akan mengalami rilis produksi?

Selamat Ulang Tahun 'Agregasi tipe bersarang',

Sekarang Anda sudah berusia empat tahun. Belum lama ini kamu begitu kecil dan imut.
Semoga Anda akan tumbuh dewasa dan kita akan memiliki tahun-tahun yang baik bersama di masa depan.

Malu terbaik

+1

+1

+1

+1

+1

+1

+1

Mengapa ini belum diterapkan

karena alasan, dengan fitur ini whey tidak akan memiliki dis thread, tidak menyenangkan dan tidak ada yang akan pergi ke github dari kibana, ini semacam suar

Versi rusa terbaru mendukung data bersarang dengan benar untuk saya

El El mié, 6 Juni 2018 hingga 22:08, Eugene [email protected]
deskripsi:

karena alasan, dengan fitur ini whey tidak akan memiliki dis thread, tidak menyenangkan dan
tidak ada yang akan pergi ke github dari kibana, ini semacam suar

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
.

@javixeneize Saya duduk di sini pada versi 6.2.4 , tidak dapat menemukan dukungan objek bersarang itu, perbaiki saya jika saya salah

Saya memiliki versi itu dan saya dapat mengakses ab, di mana struktur saya adalah {Id:xx,
a: {b:xx}}

El El mié, 6 Juni 2018 hingga 22:18, Eugene [email protected]
deskripsi:

@javixeneize https://github.com/javixeneize Saya duduk di sini di 6.2.4
versi, tidak dapat menemukan dukungan objek bersarang itu, perbaiki saya jika saya salah.

—
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung, lihat di GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
.

@javixeneize apakah Anda memiliki pemetaan berikutnya dengan type : nested ?
Anda bisa mendapatkan pemetaan dengan GET /index-name

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

Saya akan memeriksa besok tetapi saya memiliki konfigurasi default

El El mié, 6 Juni 2018 22:24 terakhir, pemberitahuan [email protected]
deskripsi:

@javixeneize https://github.com/javixeneize apakah Anda memiliki pemetaan berikutnya?
dengan tipe: bersarang?
Anda bisa mendapatkan pemetaan dengan GET /index-name

{
"dokumen": {
"properti": {
"lokasi": {
"tipe": "bersarang",
"properti": {
"mulai": {
"tipe": "panjang"
},
"akhir": {
"tipe": "panjang"
},
"dinormalisasi": {
"ketik": "kata kunci"
},
"asli": {
"ketik": "kata kunci"
}
}
}
}
}
}
}

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
.

@javixeneize terima kasih sebelumnya!
Anda mungkin memiliki objek sub json yang diratakan ke dokumen utama, tetapi ini bukan objek bersarang.

Ya hati-hati @javixeneize data Anda tidak akan berkorelasi seperti yang diharapkan kecuali Anda secara khusus mengatur pemetaan di ES untuk bidang itu menjadi bersarang

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

Masalah utama setiap bidang di objek bersarang hanya menjadi array dan Anda kehilangan korelasi antara properti.

Saya baru saja meratakan data saya sebelum membuang ke es untuk saat ini.

Jika Anda tidak sabar menunggu Elastic menerapkan ini, Anda dapat menggunakan plugin Kibana saya:

Gambaran:
https://ppadovani.github.io/knql_plugin/overview/
Instalasi:
https://ppadovani.github.io/knql_plugin/installation/
Bahasa kueri (seperti SQL):
https://ppadovani.github.io/knql_plugin/knql/

Dukungan untuk 5.5.3 hingga 6.2.4, jika ada versi yang hilang, setelah 5.5 silakan buka masalah:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Kontribusi, permintaan fitur, dan laporan bug diterima.

Oke, saya harus menunggu kalau begitu ...

El El jue, 7 Juni 2018 terakhir 0:38, Pierre Padovani [email protected]
deskripsi:

Jika Anda tidak sabar menunggu Elastis untuk menerapkan ini, Anda dapat menggunakan Kibana saya
pengaya:

Gambaran:
https://ppadovani.github.io/knql_plugin/overview/
Instalasi:
https://ppadovani.github.io/knql_plugin/installation/
Bahasa kueri (seperti SQL):
https://ppadovani.github.io/knql_plugin/knql/

Dukungan untuk 5.5.3 hingga 6.2.4, jika ada versi yang hilang, setelah 5.5 silakan
membuka masalah:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Kontribusi, permintaan fitur, dan laporan bug diterima.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
.

+1

+1

+1

+1

+1

+1

fitur yang sangat berguna... +1

Kibana sama sekali tidak berguna untuk kasus penggunaan saya tanpa dukungan ini. Saya tidak perlu meratakan atau merestrukturisasi data saya. Saya seharusnya bisa memasukkan data dan mengeluarkan visualisasi atau agregasi. Empat tahun kemudian dan masih belum ada dukungan objek bersarang?

Adakah perkiraan kapan fitur ini tersedia?

Bisakah seseorang dari elastic memberi tahu kami apakah fitur ini ditambahkan ke Kibana? Tiket ini terbuka selama hampir 5 tahun sekarang.

Juga, apa gunanya merilis fitur seperti itu jika tidak dapat digunakan di Kibana?

Jangan salah paham tapi rasanya agak aneh.

+1

+1

@dayotoro @berkoaviv @yechanpark @mackermann2 @mahnejo @bphenriques

Tolong jangan tambahkan komentar seperti +1 komentar. Terutama untuk masalah yang benar-benar Anda pedulikan! Izinkan saya menjelaskan, siapa pun yang mengaktifkan notifikasi akan dengan mudah merasa terganggu dan berhenti berlangganan dari utas tersebut. Itu berarti kontributor tidak akan melihat ini sebagai masalah penting semata-mata berdasarkan berapa banyak peserta yang terlibat. Ketika orang berhenti berlangganan, jumlah ini turun.

Sebagai gantinya, yang harus ANDA lakukan adalah berlangganan utas melalui kotak di sudut kanan atas dan berikan jempol ke edisi Github awal untuk menunjukkan dukungan Anda.

@ bugs181 ini tidak berfungsi di sini, masalah ini anomali dan menyerap semua gelombang yang masuk, selama lima tahun sekarang!

Saya pikir para ilmuwan harus menjelajahi lubang hitam ini!

Pengembang Kibana tampaknya memiliki kekuatan yang tidak normal!!!

@ bugs181 ini tidak berfungsi di sini, masalah ini anomali dan menyerap semua gelombang yang masuk, selama lima tahun sekarang!

Pernahkah Anda berpikir mereka tidak ingin membaca seluruh masalah dengan banyak komentar "+1 saya juga" yang memancing informasi yang bisa berharga bagi mereka?

@ppadovani memiliki plugin open source yang dapat digunakan (lihat komentarnya di atas)

@mika76
saya menggunakan ini.

sangat berguna dalam kasus sederhana

@mika76 perlu diketahui, bahwa karena keterbatasan waktu saat ini tidak dipertahankan secara aktif.

ppadovani berkomentar 28 hari yang lalu
Hai teman-teman... Saya merasa waktu saya sangat terbatas karena pekerjaan dan kehidupan. Selain itu, meskipun saya bisa menyelesaikan sebagian, perubahan yang dilakukan tim Kibana saat pindah ke React akan membutuhkan sebagian besar penulisan ulang sebagian besar dari apa yang telah saya lakukan.

@mika76 ya plugin ini adalah satu-satunya cara agar objek bersarang berfungsi sekarang.
Tapi yang aneh bagi saya, Elasticsearch memiliki dukungan resmi untuk objek bersarang, tetapi Kibana tidak.

Seperti yang disebutkan @ bugs181 saat ini tidak dipelihara secara aktif dan ini berarti Anda tidak dapat memutakhirkan ke versi terbaru dari tumpukan ELK.

Jadi dukungan resmi berarti pemeliharaan yang tepat juga. Tetapi karena dev meludahi masalah ini, kami tidak memiliki dukungan resmi untuk ini.

Saya harus kedua @ bugs181 di sini. '+1'-ing masalah ini dan jika tidak mengirim spam, tidak banyak membantu meningkatkan kesadaran untuk ini, tetapi hanya akan membuat orang membungkamnya atau membawa kita lebih dekat ke titik di mana saya harus menguncinya, yang sebenarnya tidak saya lakukan 't ingin, karena saya ingin menjaga setiap masalah terbuka untuk diskusi untuk semua orang, karena saya percaya pada komunikasi terbuka.

Selama ini saya juga selalu merekomendasikan menggunakan plugin itu. Saya tidak sadar bahwa ini tidak lagi dipertahankan secara aktif dan saya sedih mendengarnya. Kami juga tahu bahwa masalah ini telah terbuka selama 5 tahun, dan kami menjalankan analisis tentang masalah (jelas di Kibana - lihat tangkapan layar terlampir) dan tahu bahwa ini adalah masalah yang paling banyak ditanggapi:

Tetapi seperti yang Anda ketahui ada (secara harfiah) ribuan masalah lain terbuka, jadi kami selalu perlu menyeimbangkan antara fitur, perbaikan bug, dll. untuk menemukan prioritas yang baik. Juga (tetapi tidak hanya) karena fitur itu selalu memiliki plugin komunitas kerja yang cukup solid, itu belum mendapatkan prioritas yang cukup (untuk mengalahkan masalah lain) sejauh ini. Juga sering ada hubungan teknis antara hal-hal yang berbeda, dan misalnya untuk dukungan bidang bersarang, kami saat ini pertama-tama ingin menyelesaikan perombakan seluruh pipa rendering visualisasi (#19813), sebelum kami memulai ini, karena sangat terkait bersama. Namun demikian, saat ini kami mengalami masalah ini pada peta jalan kami untuk 7.x dan semoga tidak terhalang oleh perubahan teknis lainnya, jadi kami dapat segera memindahkan fitur tersebut ke inti Kibana agar tersedia tanpa plugin komunitas.

Apakah permintaan untuk mendukung visualisasi objek bersarang menyertakan dukungan untuk hubungan induk-anak? Saya memiliki pelanggan yang bertanya tentang visualisasi orang tua-anak.

@MorrieAtElastic tidak, orang tua-anak akan menjadi masalah yang terpisah.

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

Ini adalah masalah yang sangat besar karena kami tidak dapat menampilkan hubungan 1:M dengan benar di Kibana karena ElasticSearch mendukung Objek Bersarang sehingga kami dapat memuat data tetapi tidak dapat melihat dengan benar. Ini harus segera diperbaiki.

Terima kasih,
Rakesh

Mulai bekerja pada dukungan lapangan bersarang di KQL hari ini. Membuat masalah terpisah untuk dilacak karena dukungan lapangan bersarang penuh di Kibana melibatkan banyak perubahan di luar KQL saja.

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

ini beneran om? Setelah 5 tahun...

Bagaimana dengan tipe data baru: diratakan? Apakah akan ada dukungan untuk visualisasi untuk tipe baru itu di masa mendatang? Banyak klien layanan diarahkan ke tipe baru ini dan mereka menanyakan apakah/kapan visualisasi mungkin ikut bermain.

@Barrybigbuddy Saya tidak yakin apa rencananya untuk diratakan, dapatkah Anda membuat tiket terpisah untuk itu?

Saya ingin hubungan orang tua dan anak terwakili di Kibana. Jadi minta Anda untuk memprioritaskan fitur ini. Terima kasih. M'Jay

+1

Luar biasa! +1 di sini! Apakah ada jangka waktu khusus untuk fitur ini?

Biarkan saya menjadi pengganggu pesta di sini dan memberikan pengingat singkat: Ada banyak orang yang berlangganan masalah ini (228 orang komunitas + beberapa tim Elastis), jadi alangkah baiknya jika kita menyimpan +1 untuk minimal. Berkat fitur reaksi bagus GitHubs Anda juga dapat menambahkan persetujuan dan cinta Anda untuk @Bargs ke komentarnya tanpa memicu pemberitahuan ke semua pelanggan (atau ketidaksetujuan Anda, maka ia dapat berhenti mengerjakan dukungan lapangan bersarang lagi :wink :). Juga terutama karena ini adalah tiket yang sangat besar, tolong jangan menggunakannya untuk pertanyaan yang tidak terkait tentang jenis bidang lainnya.

Saya akan meninggalkan beberapa referensi di sini untuk jenis bidang lainnya:

• Dukungan untuk jenis bidang flattened - saat ini tidak ada dalam peta jalan jangka pendek kami
• Dukungan orang tua/anak - saat ini tidak ada dalam peta jalan jangka pendek kami

Kapan fitur ini akan tiba? Kami secara aktif mengerjakan ini dan akan ada fase yang berbeda untuk ini (KQL, dukungan penyaringan, visualisasi, dll.) yang dapat tiba dalam versi yang berbeda, dan itu akan tergantung pada bagaimana proses pengembangan akan berlangsung. Kami akan memposting permintaan tarik terkait fitur ini sebagai komentar di sini, sehingga Anda dapat melihat di PR versi mana fase/bagian dukungan tertentu akan masuk.

Saya tidak yakin apakah ini masalah yang sama, tetapi saya memiliki indeks dengan daftar objek, tetapi tidak menggunakan tipe data "bersarang". Namun di Kibana di bawah "Bidang yang tersedia", saya tidak melihat bidang di dalam objek yang ada dalam daftar. Apakah ini batasan yang diketahui?

@ppadovani apakah plugin tersedia untuk kibana-7.3.1?

Hai semuanya, saya pikir saya menemukan semacam solusi untuk masalah ini. Membaca kode sumber pemetaan saya menemukan bahwa ada opsi include_in_parent untuk tipe pemetaan bersarang. Saat menggunakan opsi ini, saya dapat memvisualisasikan array objek di Kibana tanpa masalah!!! Untuk beberapa alasan opsi ini TIDAK muncul dalam dokumentasi ES. Mungkin saya mendapatkan sesuatu yang salah tetapi tampaknya semuanya berfungsi. Saya menggunakan opsi bidang sehingga saya dapat mencari baik sebagai kata kunci maupun sebagai teks lengkap.

Pemetaan

PUT /test_index
```json
{
"pemetaan": {
"dinamis": "ketat",
"properti": {
"negara": {
"ketik": "kata kunci"
},
"dibuat oleh": {
"tipe": "bersarang",
"include_in_parent": benar,
"properti": {
"nama depan": {
"ketik": "teks",
"bidang": {
"mentah": {
"ketik": "kata kunci"
}
}
},
"nama keluarga": {
"ketik": "teks",
"bidang": {
"mentah": {
"ketik": "kata kunci"
}
}
}
},
"dinamis": "ketat"
},
"rakyat": {
"tipe": "bersarang",
"include_in_parent": benar,
"properti": {
"nama depan": {
"ketik": "teks",
"bidang": {
"mentah": {
"ketik": "kata kunci"
}
}
},
"nama keluarga": {
"ketik": "teks",
"bidang": {
"mentah": {
"ketik": "kata kunci"
}
}
}
},
"dinamis": "ketat"
}
}
}
}

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

Menggunakan include_in_parent atau copy_to sebagai solusi tidak didukung dan dapat berhenti berfungsi di rilis mendatang.

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

Dukungan Lapangan Bersarang Fase 1 dirilis pada 7.6.0

Pembaruan kecil untuk masalah ini: Kami baru saja merilis 7.6.0 Kibana, yang memiliki dukungan awal untuk bidang bersarang di dalamnya. Anda sekarang dapat menggunakan bidang bersarang di tempat-tempat berikut di Kibana:

• Pola Indeks akan mendeteksi Bidang Bersarang dengan benar
• Anda akan dapat menonton Nested Fields di Discover
• Memfilter di Bidang Bersarang melalui bilah filter berfungsi
• KQL memungkinkan pencarian untuk bidang bersarang (lihat dokumentasi KQL untuk penjelasan sintaks pada kueri bidang bersarang)

Saat ini kami sedang berupaya mengaktifkan bidang bersarang dalam visualisasi dan kami akan terus memperbarui masalah ini dengan informasi yang relevan.

Hai! Kami sedang menunggu fungsi NESTED. Kapan kita bisa melihatnya? Ini adalah satu-satunya momen yang tidak sepenuhnya beralih ke Kibana (Elastis adalah yang terbaik). Seluruh dunia memperhatikanmu.

Kueri bidang bersarang masih disadap dengan KQL.
Contoh:
Pertimbangkan pemetaan indeks yang didefinisikan sebagai
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
Saya telah membuat pola Indeks berdasarkan indeks ini dan ingin menanyakan first.second.field : "test"
Kueri ini di tab periksa akan menghasilkan
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
yang tidak benar.
Versi yang benar juga harus menyertakan sintaks bersarang "nested": {"path": "first.second",...}

Ping @elastic/kibana-app-arch (Tim:AppArch)

@IlyaHalsky Silakan periksa dokumentasi KQL di bidang bersarang. Bidang bersarang memerlukan sintaks khusus untuk kueri, karena Anda memiliki banyak cara untuk menanyakannya (dalam kasus Anda, kemungkinan besar Anda hanya ingin melakukannya: first.second:{ field: "test" } ).

Anda juga akan melihat pemberitahuan toast saat Anda mencoba menggunakan bidang bersarang untuk pertama kalinya dalam kueri KQL yang akan menautkan Anda ke penjelasan itu.

Saya bertanya apakah ada rilis kibana baru yang mendukung bidang bersarang dalam visualisasi:
contoh data saya:
{
"bidangX": "x",
"fiedY": "Y",
"anomali": [
{
"kategori": "sistem",
"nama": "cpu",
"tanggal": "2020-03-11T13:33:40.000Z"
},
{
"kategori": "boot ulang",
"nama": "setel ulang",
"tanggal": "2020-03-11T13:33:40.000Z"
},
{
"kategori": "sistem",
"nama": "memori",
"tanggal": "2020-03-11T13:33:40.000Z"
}
]
}

Saya ingin memvisualisasikan diagram lingkaran di kibana di mana:
jumlah ukuran irisan = Jumlah total objek larik anomali (jumlah dokumen x jumlah objek menurut larik anomali)
ember pertama = anomalies.category
ember kedua = anomalies.name

dengan kata lain saya ingin memvisualisasikan distribusi nama anomali berdasarkan kategori anomali?

+1

Ada berita tentang ini? Rilis 7.6 sudah berumur beberapa bulan, 7.7 dan 7.8 tidak menyebutkan ini dalam catatan Rilis dan dokumen untuk 7.9, 7.x dan master juga tidak berisi info baru tentang fungsi ini.

Hanya menimpali untuk juga mengungkapkan harapan besar kami untuk mendapatkan dukungan agregasi bersarang di Visualisasi. Akan luar biasa!