+1 pour l'agrégation d'objets imbriqués.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

pour être clair, il n'y a aucun moyen de faire un filtre/requête/agg imbriqué dans kibana 4 pour le moment, n'est-ce pas ?

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1 Parce que la dénormalisation des objets imbriqués n'est pas toujours une option car cela peut conduire à une explosion de mappage.

Cartographie :

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

Tout d'abord, je voudrais que le graphique linéaire puisse montrer la taille moyenne au fil du temps pour chaque nom de piscine. En supposant qu'il y ait autant de noms que la dénormalisation n'est pas une bonne idée, cela peut conduire à de nombreux graphiques dans le graphique. Afin de travailler avec de tels cas, il serait également avantageux de pouvoir utiliser l'agrégation de filtres à l'intérieur d'une agrégation imbriquée. Pouvoir filtrer sur les champs imbriqués dans la recherche supérieure serait également formidable.

Pour rendre les choses encore plus intéressantes, ce serait vraiment génial de pouvoir visualiser une agrégation comme celle-ci :

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

Ce serait puissant avec ça !

Quelqu'un peut-il donc clarifier cela; Dans cet article (https://www.elastic.co/blog/kibana-4-beta-1-released) pour Kibana4beta1, il est indiqué que "Kibana 4 apporte la puissance des agrégations imbriquées d'Elasticsearch à un clic de souris. " Cependant Je ne parviens pas à créer de visualisations sur des documents avec des objets imbriqués. J'ai également veillé à ce que les objets imbriqués dans mon modèle d'index soient marqués comme "imbriqués". La prise en charge par Kibana des agrégations imbriquées n'est-elle pas la même que la prise en charge par ES des objets imbriqués ? Qu'est-ce que je rate? Merci.

@cslinuxboy - Je pense qu'ils utilisent ici "imbriqué" pour faire référence au regroupement via plusieurs champs, par exemple "agréger par heure puis géo" (pas "imbriqué" comme dans son utilisation dans la plate-forme pour "objets imbriqués")

@Alex-Ikanow - Merci pour la réponse. Dommage que ce ne soit pas possible pour le moment. J'ai eu de l'espoir en lisant la description trompeuse de leur publication bêta-1.

+1 pour la prise en charge des objets imbriqués dans l'agrégation de visualisation.

+1

J'utilise actuellement les relations parent/enfant comme solution de contournement qui semble bien fonctionner.

@calvdee Avez-vous des requêtes has_parent ou has_child pour travailler dans la barre de recherche Kibana ? Cela ne fonctionne pas pour nous et c'est un énorme problème, je vous serais ÉTERNELLEMENT reconnaissant si cela fonctionne et pouvez me le faire savoir... merci !!!

Non, pour notre cas d'utilisation, tous les parents ont des enfants et tous les enfants ont nécessairement des parents puisque nous indexons les données de facturation, donc les requêtes régulières fonctionnent (voir image).

@calvdee Merci beaucoup pour la réponse ! Nous avons un modèle de données similaire mais voulons pouvoir trouver des parents par leurs enfants à Kibana, ça ne marche pas :0(

Pas de soucis, bonne chance !

Le jeu. 26 mars 2015, 11:36 ajrasch [email protected] a écrit :

@calvdee https://github.com/calvdee Merci beaucoup pour la réponse ! Nous
ont un modèle de données similaire mais veulent pouvoir trouver les parents par leur
enfants à Kibana, ça ne marche pas :0(

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment -86575796.

+1

+1

Vous lisez le champ _mapping, vous devez donc savoir quand un champ particulier est imbriqué. Il ne peut donc pas appliquer automatiquement la facette/requête imbriquée correcte lorsqu'un tel champ est sélectionné dans des requêtes ou des facettes ?

Oui, :+1: sur celui-ci. Bien que j'aie réussi à écrire l'agrégation imbriquée correcte sur CLI et que je puisse extraire des données avec curl, je n'ai pas trouvé de moyen de le faire fonctionner dans l'onglet "Visualiser" de Kibana, pas même en utilisant la zone d'édition JSON. Certes, je n'utilise jamais cette fonctionnalité (la box), mais il semble qu'il soit possible uniquement de "rajouter" des trucs à une agrégation existante, pas de l'utiliser pour créer une nouvelle agrégation de toutes pièces... (appréciera d'être corrigé si je me trompe !).

Oui, les agrégations de types imbriquées sont essentielles et deviennent de plus en plus utilisées car elles résolvent un problème spécifique avec des données plates.

Si Kibana4 est le produit de visualisation pour ES, il doit prendre en charge toutes les agrégations ES.

Ce serait bien de voir au moins cela sur la feuille de route de Kibana4 .

+1

+1

+1

+1

+1

Du #3729 :-)

J'aimerais voir une option globale "documents enfants"
(histogramme après date, histogramme, etc.) qui ouvre le
paramètres pour un agrégat de requête DSL pour les enfants, comme
"type enfant", "champs", etc.

Cela permettra de créer des agrégats imbriqués sur l'enfant
documents.

Je ne semble pas être en mesure de créer une telle requête en utilisant
la fonction d'édition avancée. Peut-être que quelqu'un peut
éclaire-moi.

Merci

+1

+1

+1

+1 vraiment besoin de cette capacité. Je pourrais supprimer tous les parents avec logstash comme solution de contournement, mais cela nécessiterait un énorme fichier de configuration car j'ai des centaines de champs.

+1 quelqu'un sait si c'est prévu ?

+1

À l'heure actuelle, j'envisage de modifier certains de mes mappages pour arrêter d'utiliser des objets de type "imbriqué", car je ne peux pas créer de visualisations Kibana sur aucun de ces champs. Si je savais que le problème était au moins sur la feuille de route, ce serait une très grande aide pour prendre cette décision.

@benjismith - J'ai également mordu la balle et changé le traitement de mes données des documents imbriqués aux documents parents/enfants. Jusqu'à présent, cela fonctionne bien, mais je suis d'accord avec vous; ce serait bien de savoir s'il y a une chance que cela devienne un jour une fonctionnalité à Kibana afin que nous puissions tous l'attendre ou passer à autre chose.

Bonne chance.

+1

+1

+1 pour la prise en charge de l'agrégation de types imbriqués

+1

+1

+1

+1

+1

+1

Pour ceux qui cherchent à faire des agrégations simples sur des champs spécifiques dans les documents imbriqués (par exemple, une agrégation de « termes » sur un champ pour trouver les premières valeurs), vous pouvez envisager d'ajouter le paramètre « include_in_parent » à votre mappage Elasticsearch. Cela crée une version aplatie d'un champ dans le document imbriqué au niveau parent.

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

Ces champs n'apparaîtront pas dans la liste des champs Découvrir sur le côté gauche, bien que vous les verrez dans la vue détaillée du document sous forme de champ de tableau. Cependant, vous aurez accès aux champs individuels de la liste des métriques dans Visualize, et vous pourrez exécuter des agrégations sur eux.

C'est ce que nous faisons pour visualiser l'historique de surveillance, qui est basé sur une structure de documents imbriqués (voir "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

Au lieu d'un autre +1... Peut-être qu'un résumé de la position des agrégations de types imbriqués aiderait.

Cela fait 5 jours que j'apprends à faire de jolis graphiques, alors pardonnez-moi si tout cela est évident.

Quel est le problème?

Est-ce toujours un problème de requête ElasticSearch ou Lucene ?

Il n'est pas résolu par des agrégations, mais il est résolu par le fait que nous vous permettons de taper Elasticsearch JSON dans la zone de saisie. Ce n'est pas idéal, mais à moins qu'elasticsearch n'étende la syntaxe de la chaîne de requête lucene pour spécifier les champs imbriqués, c'est le mieux que nous puissions faire. -- le commentaire vieux d'un an de rashidkpc

Correction de Kibana possible ?

Si ES/Lucene, Kibana pourrait-il fournir un hack/une solution intermédiaire en attendant ? Pensez aux cales ES6 et au préfixe CSS du fournisseur.

Pour le mapping imbriqué : possibilité de choisir imbriqué dans l'éditeur (et configurer un chemin...) pour les panneaux de Kibana. bobmer

Ou:

Vous lisez le champ _mapping, vous devez donc savoir quand un champ particulier est imbriqué. Il ne peut donc pas appliquer automatiquement la facette/requête imbriquée correcte lorsqu'un tel champ est sélectionné dans des requêtes ou des facettes ?
Alex-Ikanow, OP

Est-ce que quelqu'un pirate une solution ? Quelqu'un a une idée/direction de l'endroit où pirater ?

Contourner ?

Quelqu'un a-t-il eu du succès avec nested/include_in_parent ? Nécessite-t-il le dynamic: static , dynamic: true . Mes tentatives ont échoué avec 0 résultats. tbragin

Quelqu'un a-t-il des exemples de la zone de saisie JSON évoquée ci-dessus par rashidkpc ?

Parent/enfant

C'est ma prochaine étape. Je suis sûr qu'il existe de nombreux documents de référence en ligne pour cela, mais cela ne ferait pas de mal de référencer des exemples/tutoriels pour cette alternative.

Manquant de connaissances sur les composants internes de kibana, j'envisage d'écrire un proxy REST situé entre élastique et kibana. Lors d'une requête à partir de Kibana pour un type spécifique en fonction de certains critères de recherche basés sur des termes, ce proxy interroge d'abord le type de parent pour trouver l'ensemble de parents répondant aux critères de recherche (ils correspondent à la mémoire). Ensuite, il trouve tous les enfants de ces parents et les renvoie à kibana dénormalisé avec tous les champs parents ajoutés. Cela nous permettra d'avoir un modèle parent-enfant dans Elastic Search qui évite l'explosion du stockage de tout dénormaliser à des milliards d'objets enfants, et en même temps de représenter graphiquement les données en fonction des champs parents.

Idéalement, cela faisait partie de Kibana. Le monde n'est pas plat !

+1

+1. Nous avions l'habitude de diviser la pile de fonctions ou les url_args en différents champs. Mais cela est venu avec un état de cluster trop grand et trop d'actions d'actualisation de mappage. Nous changeons donc cela en un objet imbriqué. Maintenant, nous avons besoin d'aggs dans K4....

+1

+1 nécessite une visualisation d'agrégation parent-enfant.

+1

Veuillez ne pas croire que tous les utilisateurs Elastic qui souhaitent utiliser Kibana l'utilisent pour l'analyse des journaux. Nous avons des données étendues, avec des objets imbriqués, peuplés dans notre cluster sur lesquels nous aimerions pouvoir effectuer des analyses sans avoir à extraire et transformer les données dans un autre système.

Il est indispensable de pouvoir créer des agrégations imbriquées, des requêtes imbriquées et même des agrégations reverse_nested. Plus Kibana reste longtemps sans cette fonctionnalité, plus vite nous devons trouver une alternative sans utiliser Elastic/Kibana. Si fournir une interface utilisateur facile à utiliser pour ce type de fonctionnalité est la partie difficile, commencez par donner à vos utilisateurs la possibilité de fournir la requête json complète pour Elastic qui renvoie les données requises.

+1

D'accord avec @ppadovani . Nous évaluions les outils de BI et aurions adoré utiliser Kibana, mais il ne prenait pas en charge les relations dans nos entités commerciales sur lesquelles nous devions rendre compte et n'était pas assez convivial pour qu'un utilisateur non technique puisse les explorer. Nous avons fini par utiliser Looker (une interface graphique pour SQL essentiellement). Regarder looker pourrait offrir quelques idées sur la façon dont kibana pourrait être étendu pour servir des cas d'utilisation plus divers à l'avenir.

J'ai décidé de regarder le code kibana 4.1. ces lignes :

1) Sous la zone réductible « avancée » d'une agrégation, ajoutez un champ de texte appelé quelque chose comme « chemin imbriqué ».
2) Si l'utilisateur place une chaîne dans ce champ, l'agrégation sur laquelle elle est définie aura une agrégation imbriquée comme ceci :
"ags":{
"2":{
"niché":{ "path":"foo" },
"ags":{
"3":{
"histogramme_date":{

Pour gérer le cas de plusieurs niveaux d'objets imbriqués, vous pouvez ajouter un + qui permet à l'utilisateur d'ajouter des chemins imbriqués supplémentaires. De plus, pour gérer l'inversion imbriquée, ajoutez simplement une case à cocher intitulée 'reverse'.

Cela fournirait au moins une prise en charge d'agrégation « imbriquée » limitée.

Pour la prise en charge des requêtes imbriquées, la seule solution à laquelle je puisse penser à court terme serait de permettre à l'utilisateur d'entrer un json de recherche élastique codé à la main.

+1

+1 sur tout cela et permettant à l'utilisateur d'entrer un json de recherche élastique codé en dur

+1

+1

+1. J'étais très enthousiaste à l'idée d'utiliser Kibana pour nos besoins de visualisation d'environnement, mais sans prise en charge de la visualisation d'objets imbriqués, il est assez pénible d'utiliser Kibana pour nos besoins là-bas.

+1, je viens de tomber sur ça.

+1

+1

+1

+1

+1

Au moins 82 personnes obtiennent votre "+1" et ce n'est PAS utile.

Je ne suis pas du tout d'accord. Plus de données n'est jamais mauvaise.

Mon équipe et moi y travaillons et espérons peut-être avoir quelque chose à montrer d'ici la fin de la semaine.

EDIT : veuillez consulter mes commentaires sur : https://github.com/elastic/kibana/pull/4645#issuecomment -132908544

+1

+1

+1

Terminé et une pull request créée ici :
https://github.com/elastic/kibana/pull/4806

Mise à jour rapide pour ceux qui regardent... en attente d'Elasticsearch co. ack le CLA, sinon je pense que c'est bon d'y aller.

+1

+1 aussi

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

Oui s'il vous plaît.

+1

+1

+1

+1

La pull request contre 4.1 est clôturée en faveur de celle-ci contre master.

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

S'il y a une demande pour une version 4.1 de ceci, je peux rouvrir la demande d'extraction avec le code correct.

+1

+1

+1

+1

Je ne comprends pas ce qui bloque sur ce problème.
Il y a une pull request en attente https://github.com/elastic/kibana/pull/5411

Il y a des gens ici prêts à contribuer. Que faut-il faire pour fusionner ce PR ?

Certainement plus de +1 sont nécessaires

@ Filirom1 Quelques-uns d'entre nous ont été sur la route, nous n'avons donc pas encore eu l'occasion de revoir le PR :( Nous essaierons d'y arriver cette semaine. C'est certainement une amélioration indispensable et nous sommes très excités sur la contribution de la communauté ici!

Super :-)
Merci !

J'ai jeté un coup d'œil au #5411 et malheureusement ce n'est pas la direction que nous souhaitons prendre pour le moment. #5411 a mis en place un stop gap, mais a provoqué la rupture de fonctionnalités importantes, telles que le filtrage et la recherche. Cela a également fait que le générateur d'agg lui-même semblait brisé pour ceux qui ne comprenaient pas l'implémentation sous-jacente des agrégations imbriquées. Une fois que nous nous sommes assis et que nous avons examiné de plus près, nous avons réalisé que la quantité de travail nécessaire pour prendre en charge les documents imbriqués de manière cohérente était considérable.

Ce n'est pas que nous ne voulons pas faire cela, c'est que si nous le faisons, nous voulons le faire correctement, pas seulement contourner cela.

Nous reconnaissons que beaucoup sont intéressés par la visualisation des données relationnelles, mais étant donné d'autres priorités et préoccupations, nous n'avons pas de ressources à consacrer à ce projet pour le moment et ne pouvons pas nous engager à l'ajouter à la feuille de route dans un avenir prévisible.

Pour info, nous espérions utiliser kibana avec des agrégations imbriquées pour l'analyse interne, mais nous avons finalement opté pour un produit commercial, « Looker », qui se trouve directement sur nos rdbms. Je recommanderais vivement aux développeurs Elastic de jeter un œil à ce qu'ils ont fait pour simplifier l'exploration d'un modèle relationnel, car de nombreux non-techniciens peuvent désormais parcourir notre base de données en direct pour leurs questions quotidiennes sur le produit. J'ai évalué un certain nombre de produits et Looker est arrivé en tête, et j'aimerais voir des fonctionnalités similaires dans Kibana un jour.

Compte tenu du dernier commentaire de Rashid et de l'attente prolongée de cette fonctionnalité, je recommande que ce problème soit clos. Si ce problème reste ouvert, cela donne simplement aux utilisateurs un faux espoir qu'il y aura une possibilité que cela soit mis en œuvre dans un proche avenir. Fermons-le et testons l'idée jusqu'à ce que les développeurs aient les ressources pour trouver comment la mettre en œuvre.

Copie de mon message à partir de la pull request :

Il y a une solution ici, mais cela demanderait beaucoup de travail et je n'ai tout simplement pas le temps. Nous avons implémenté cela en JAVA donc je sais que c'est possible.

1) Chaque mappage d'index doit extraire et comprendre les champs imbriqués.
2) Créez un AST personnalisé qui fournit un langage de requête simplifié au lieu d'essayer d'utiliser simplement celui d'Elasticsearch.
3) Créez un adaptateur de requête qui comprend l'AST et peut valider et convertir la requête en JSON approprié.
4) Mettre à jour les agrégations dans Kibana pour gérer correctement les champs imbriqués en fonction de la compréhension interne des champs imbriqués.

Ce n'est pas impossible à faire, cela demande juste un travail important. Les avantages de la mise en œuvre de ce qui précède incluent la validation des requêtes et une syntaxe simplifiée. Par exemple, notre AST nous permet de créer une requête comme celle-ci :

(owner.user = "/users/00a0/18066271-29f0-40af-83ad-e5a0c8fc5944") ET (druid = "/druids/0060/77dd14b1-b7f0-4851-9ef8-74daa18d9d4d") ET ((owner.lastMessageReceived. inséré >= 0) OU (conversationLifecycleState = "RESERVATION_REQUEST")) ET (owner.conversationArchived = false) ET ((units.site EST NULL) OU (units.site IN {"HOMEWAY_DE"})) ET ((inquiry.inserted >= 0) OU NON (reservation.availabilityStatus = "DELETE")) ET NON (owner.markedSpam = true) ET (lastMessage.inserted >= 0)

Comment pourrais-je exactement faire cette requête avec la langue existante ?

IMHO - attendre le nirvana d'Elasticsearch avant d'agir entraînera une baisse de l'adoption et la perte d'utilisateurs de Kibana.

Je déteste avoir l'air de faire du marketing, mais c'est pertinent. (vu que les gens mentionnent d'autres produits..)

Nous avons trouvé que beaucoup de personnes qui utilisaient fortement l'imbrication voulaient réellement rechercher des données relationnelles et ont fini par imbriquer des enregistrements qui auraient plutôt dû être simplement "joints" tardivement. (Padovani, cela pourrait être votre cas, je vois des "utilisateurs", des "messages", etc. ceux-ci seraient très bien conservés en tant que dossiers séparés)
C'est la raison pour laquelle nous avons créé le plugin SIREn Join elasticsearch et la fourche Kibi notre -friendly - Kibana qui propose des filtres et des fonctionnalités pour cela.

Nous travaillons maintenant à faire autant de Kibi que possible dans des plugins compatibles Kibana 4.4 (aka 5.0) pour le bénéfice de tous.

Le plugin Join est sorti hier et il est également open source.

En attendant, la version disponible sur http://siren.solutions/kibi fonctionne franchement à merveille et beaucoup de nos clients n'ont plus besoin de données imbriquées.

jccq : Jamais connu pour Kibi ou le plugin join. Merci pour l'info!

+1

+1
c'est un problème incontournable...

@jccq Notre cas d'utilisation ne concerne pas uniquement la jointure pour les requêtes, nous utilisons l'entité "jointe" ou "vue" comme nous l'appelons comme de véritables données d'entité avec son propre cycle de vie. Cela permet aux clients d'extraire les données jointes sans avoir à effectuer plusieurs appels GET à notre API.

En termes de support imbriqué dans Kibana, nous faisons évoluer notre approche et pouvons avoir quelque chose à partager avec la communauté au cours du deuxième trimestre ou plus tôt en fonction des ressources et du temps. Cette nouvelle approche prendrait en charge l'imbrication de manière transparente à la fois dans les agrégations ET dans les requêtes. Je n'en dirai pas plus, car il n'en est encore qu'aux premiers stades de la mise en œuvre.

+1

@ppadovani c'est toi !

+1

+1

+1
C'est vraiment important pour nous.
Nous attendons depuis presque un an cette fonctionnalité...

+1

Mise à jour : je ne vois pas ma nouvelle branche être prête pour les commentaires préliminaires ou les tests avant au moins un mois en raison de ma charge de travail. Cependant, je voulais mettre en avant ce que je fais pour recueillir les commentaires de la communauté au fur et à mesure que j'avance.

La conception de base s'articule autour de deux choses :

1) Un nouvel analyseur de requête pour le champ de requête de forme libre Kibana. Cet analyseur utilise la définition de syntaxe Bison standard (voir le projet Jison pour la version javascript que j'utilise). Le BNF que j'utilise est basé sur le BNF existant que nous utilisons chez Homeaway pour notre langage de requête personnalisé contre Elasticsearch. Voir mon commentaire ci-dessus pour un exemple. J'ai choisi cette approche pour permettre des améliorations futures par la communauté au besoin.

J'ai l'analyseur de requête qui fonctionne dans Kibana, mais j'ai encore du travail à faire pour permettre à l'utilisateur de basculer entre le style de requête existant utilisé par Kibana et ce nouveau style. :

2) Modifiez l'appel getFieldMapping dans mapper.js en getMapping et traitez les résultats différemment de sorte que le chemin imbriqué sur les champs soit capturé et ajouté aux informations de champ que Kibana stocke.

Lorsqu'une requête est saisie dans l'analyseur, non seulement les champs ont été correctement nommés, mais aussi les valeurs fournies sont valides pour les types de champs. C'est-à-dire qu'un champ de date reçoit une date, ou un booléen a reçu un booléen. De plus, les champs imbriqués seront gérés automatiquement par l'analyseur et le json de requête Elasticsearch approprié sera généré à la place du langage de requête simple qui est utilisé actuellement.

Enfin pour les agrégations, puisque les champs contiennent désormais les indices sur les chemins imbriqués, il sera trivial de travailler par rapport à ma branche précédente pour injecter automatiquement les agrégations imbriquées selon les besoins en fonction des champs sélectionnés.

Jalons :
1 - Rendre l'analyseur fonctionnel et générer des requêtes
2 - Mettre à jour mapper.js et implémenter la prise en charge des requêtes imbriquées
3 - Implémenter la prise en charge de l'agrégation imbriquée
4 - Test/nettoyage

Tout commentaire sur cette approche serait grandement apprécié. Merci!

Mise à jour sur ce qui précède :

• Analyseur terminé
• Analyseur inversé terminé (prend un json elasticsearch et le reconvertit dans le langage de requête personnalisé)
• Kibana découvre et enregistre désormais les chemins imbriqués sur les champs
• Les parseurs ont désormais accès aux informations du champ

Reste à faire :

• prise en charge des chemins imbriqués dans les deux analyseurs
• Construction de l'interface utilisateur pour permettre à l'utilisateur de changer le style de requête à utiliser et permet aux requêtes héritées d'être enregistrées/utilisées.
• terminer la gestion des erreurs dans les analyseurs, et comment l'interface utilisateur affiche les problèmes/erreurs d'analyse
• Construction d'interface utilisateur pour fournir une prise en charge de la saisie anticipée des noms de champ dans la requête
• prise en charge imbriquée dans les buckets/métriques
• tests unitaires, tests unitaires, tests unitaires.
• ... ?

+1

Mettre à jour:

• L'analyseur gère/injecte automatiquement les informations imbriquées
• Les agrégations gèrent/injectent désormais automatiquement les informations imbriquées

À FAIRE:

• Modifications de l'interface utilisateur pour la sélection du style de requête et enregistrement de la sélection de style avec la requête dans l'index kibana.
• gestion des erreurs pour les erreurs d'analyseur et comment l'interface utilisateur affiche les problèmes/erreurs d'analyse
• Prise en charge du type d'interface utilisateur pour la création/l'écriture de requêtes
• tests unitaires, tests unitaires, tests unitaires...

Plan:
Je veux obtenir au moins quelques progrès sur le travail de l'interface utilisateur, pas mon point fort, alors nous pousserons une branche/un fork vers le référentiel github HomeAway pour permettre des commentaires/contributions. Je posterai à nouveau ici lorsque cela sera fait afin que tous ceux d'entre vous qui souhaitent tirer la fourchette et jouer avec soient plus que bienvenus. Une fois qu'il sera suffisamment poli, je créerai la demande d'extraction officielle.

Une dernière remarque : ce travail est effectué contre la branche Kibana 4.3.1.

Suite à mon commentaire précédent sur l'utilisation de "include_in_parent" et "include_in_root" pour copier des champs sélectionnés à partir de documents imbriqués vers le niveau supérieur dans le but d'exécuter des agrégations sur eux, dans ES 2.0, la fonctionnalité "copy_to" a été introduite qui fournit un autre option pour ce genre de chose : https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html
Il est question de déprécier "include_in_parent" et "include_in_root" en faveur de "copy_to" dans une future version ES : https://github.com/elastic/elasticsearch/issues/12461 Si vous avez de l'expérience avec les deux, n'hésitez pas à peser.

+1

ppadovani, appréciez ce que vous essayez de faire. Cette fonctionnalité est très importante pour nous
Quelques questions:

1. Je comprends que cela prendra du temps? Y a-t-il une estimation de la durée de disponibilité de cette fonctionnalité ?
2. Quelqu'un a-t-il essayé une alternative ? Comme changer le format du journal de json imbriqué (tableaux) à autre chose? Si oui, quel devrait être le format prévu pour travailler avec ELK ?
3. Existe-t-il un autre produit sur le marché qui peut aider à réaliser cette fonctionnalité ? Je suis tout à fait pour ELK parce qu'il est open source, mais jusqu'à ce qu'il ne le soit pas, nous voulons quelque chose de moins cher que Splunk. Nous avons exploré de nombreuses options, comme Loggly, sumologic, logentries, logscape, graylog (soit aussi cher que splunk ou ils n'ont pas cette fonctionnalité)

Merci beaucoup!

1. Quelqu'un a-t-il essayé une alternative ? Comme changer le format du journal de json imbriqué (tableaux) à autre chose? Si oui, quel devrait être le format prévu pour travailler avec ELK ?

Vous pouvez aplatir le schéma ou utiliser les options de mappage ES "include_in_parent" ou "copy_to" pour copier certains des champs des documents imbriqués vers les documents parents. Ne fonctionne pas pour tous les cas d'utilisation, mais dans certains cas, cela vous permettra d'utiliser Kibana directement. Nous utilisons l'approche "include_in_parent" en interne chez Elastic.

1. J'ai une branche qui «fonctionne», mais a besoin de plus de TLC sous forme de travail d'interface utilisateur. Ce n'est pas mon travail principal, donc je ne peux y travailler que si j'ai le temps.
2. Comme @tbragin l' indique, vous pouvez aplatir les données. Cependant, cela peut conduire à des résultats de requête invalides.
3. Je ne connais pas d'alternative pour le moment.

Pour être plus clair sur ce à quoi ressemble le langage de requête, depuis qu'on m'a demandé sur mon ancienne demande d'extraction, voici un résumé BNF :

Comparaison : champ [=,<,>,<=,>=,~=] valeur
Notez le ~= .. cela indique LIKE qui à son tour provoquera une requête générique
IN : champ IN {valeur,valeur,...} Opération d'ensemble
champ IN [valeur, valeur] Opération de plage utilisant [ ] ou ( ) en fonction de l'inclusif/exclusif
EST : le champ EST NULL
expression : EST | EN | Comparaison
NON : PAS d'expression
ET | OU : expression ET |
EXISTE : expression EXISTE
Existe est la façon dont la portée de l'imbrication se produit. En règle générale, sans utiliser EXISTS, toutes les expressions côte à côte et ayant le même chemin imbriqué seront combinées dans la même requête imbriquée. Cependant, vous pouvez diviser le bloc de requête imbriqué en utilisant EXISTS pour délimiter des requêtes imbriquées particulières les unes des autres.

Comme indiqué précédemment, le langage utilise JISON, un équivalent javascript BISON, et nous permettra d'étendre le langage selon les besoins avec très peu d'effort.

METTRE À JOUR:

Je crois que je suis sur le point de pouvoir partager une branche avec tout le monde pour tester et fournir des commentaires. J'ai le ou les analyseurs qui fonctionnent et au moins le retour de syntaxe ainsi que les tests unitaires contre l'analyseur. Quelques captures d'écran :

J'espère que la branche sera prête plus tard cette semaine. Lorsque je l'aurai prêt, je créerai un lien vers un article de blog ici qui sera lié à la branche et aura un aperçu complet de la syntaxe, de l'utilisation, etc. Mon plan est de recueillir des commentaires sur la branche, de résoudre les problèmes, d'améliorer comme demandé, puis obtenir une demande de tirage soumise.

J'aimerais le tester (voici un exemple de notre utilisation des agrégations imbriquées dans K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523, ne migrera pas sans lui).

@Robitx Je ne pense pas que ce sera un problème... nous avons des documents qui ont au moins deux niveaux d'objets imbriqués... par exemple :

A->B->C

Où un seul document A peut avoir un ou plusieurs B, et chacun de ceux-ci contient une liste de C qui se trouvent sur le B. Chaque document imbriqué a plusieurs champs de types différents. J'ai testé ce code de telle sorte que je puisse créer un histogramme ou un camembert multicouche par rapport aux données imbriquées les plus internes.

Pour être clair, nos mappages sont générés automatiquement à partir de nos pojos et peuvent devenir très complexes.

+1

METTRE À JOUR:

Je voulais que les gens commencent à jouer avec cela plutôt que d'attendre qu'un article de blog officiel de ma part apparaisse.

La fourche/branche peut être trouvée ici :

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

LISEZ-MOI :

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

Le contenu du README est essentiellement le contenu du billet de blog qui apparaîtra à un moment donné.

N'hésitez pas à ouvrir des problèmes/demandes d'extraction contre la branche fullNestedSupport si vous le souhaitez. Je vais essayer de rester au courant de tous les problèmes que les gens trouvent.

+10000

+100500

+100

Salut ppadovani,

Pourriez-vous s'il vous plaît des conseils, que dois-je faire

Ce champ est présent dans votre mappage Elasticsearch mais pas dans les documents des résultats de recherche. Vous pourrez peut-être encore le visualiser ou le rechercher.

Merci beaucoup!

Salut ppadovani,

Nous avons un champ sous forme de tableaux imbriqués.
"abc":[["3815222235847451","131712121218083052"]]
OU
"abc":[["3815222235847451","131712121218083052","131712121217783052"]]
OU
"abc":[["3815222235847451"]]

Les valeurs peuvent être de 1 à 10

Alors que pour les autres champs imbriqués, je vois un avertissement indiquant que le champ n'est pas indexé (dont je suppose que j'ai besoin d'utiliser des mappages ?) Pour ce champ et d'autres comme ceux-ci, chaque ensemble est traité comme une valeur distincte ? De plus, le type de champ s'affiche sous forme de "chaîne" au lieu de nombre, ce qui n'est pas un problème en soi, mais cela signifie que je ne peux pas rechercher de valeur individuelle d'abc.. ?

Merci beaucoup!

Trouvé quelques minutes pour commencer les tests :) :|

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) - Je ne pense pas que ce soit un message généré par mes changements, et peut-être quelque chose qui existait dans Kibana avant.
2) - Alors oui .. il semble que les valeurs soient stockées sous forme de chaîne, mais elles ne sont peut-être pas imbriquées .. Je devrais voir à quoi ressemble le mappage sur l'index pour comprendre si le problème existe. Veuillez coller le mappage ici.

@Robitx
Je suppose qu'il s'agissait d'un champ de date... l'heure de l'époque a trop de chiffres et devrait être 10 et non 13. Pouvez-vous mettre à jour/coller la requête que vous avez émise ?

@ppadovani
Je viens de choisir le modèle d'index par défaut dans les paramètres et je suis revenu à l'onglet découvrir

Nous utilisons

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

K 4.4.1+ES 2.2 fonctionne bien, il se peut que cela soit spécifique à K 4.3 (je n'ai jamais essayé cette version auparavant)

@Robitx
Je recherche la requête utilisée... ou dites-vous que la requête transmise n'était que la fenêtre de date standard de l'interface utilisateur et que vous n'avez pas spécifié de requête ? Je rebaserai mes modifications sur une version ultérieure de Kibana et je republierai lorsque la branche sera mise à jour.

@ppadovani oui juste * et une certaine plage de temps

+1 pour les objets imbriqués dans la section de visualisation

@Robitx
Cette opération que vous avez exécutée n'a jamais touché aucun de mon code d'analyseur... donc je doute que ce soit dû à quelque chose que j'ai fait... Ma configuration est K 4.3.1 + ES 2.1.1 - Je vais mettre à niveau mon ES à 2.2 et voir si j'obtiens le même comportement, alors je rebaserai la branche sur K 4.4.1

Je viens de passer à ES 2.2.1 avec K 4.3.1 + mon code... impossible de reproduire :

Je vais toujours rebaser sur 4.4.1 - la version actuelle, mettra à jour ce message lorsque la branche sera prête.

METTRE À JOUR:

Rebasé en 4.4.1 sur une nouvelle branche : https://github.com/homeaway/kibana/tree/nestedSupport-4.4.1

Testé sur ES 2.2.0 et K 4.4.1

Salut ppadovani,

En ce qui concerne mes questions précédentes, je vais y renoncer. J'ai déjà une instance de recherche élastique dans AWS (avec des mappages) et j'essaie de la connecter à cela. Cependant, l'état du serveur kibana sur l'interface utilisateur indique :

plugin:elasticsearch Cette version de Kibana nécessite Elasticsearch ^2.1.0 sur tous les nœuds. J'ai trouvé les nœuds incompatibles suivants dans votre cluster : Elasticsearch v1.5.2 @ undefined (undefined)

J'utilise toujours https://github.com/homeaway/kibana/tree/fullNestedSupport et pas le dernier fourni par vous. Est-il possible pour vous de le rendre compatible pour 1.5.2 ?
Bon conseil.

Merci beaucoup!!

@ppadovani
Je peux comprendre que cela ne soit pas possible, car nous reculons, cependant, Amazon Elasticsearch Service n'est pas très enclin à passer aux versions plus récentes, ce qui est compréhensible. Donc, je dois travailler avec tout ce que nous avons. Nous avons investi beaucoup d'efforts dans la configuration de l'instance AWS (avec le transfert de journaux à partir de plusieurs nœuds, des événements de streaming et d'autres détails) et tout réinventer sur une plate-forme distincte à partir de zéro n'est pas une option pour nous. Ce serait bien de pouvoir l'accrocher en tant que Frontend supplémentaire. Je ne sais même pas s'il y aura un autre barrage routier plus tard ?

Merci!!

@BigDataEngineer
Après avoir examiné le code Kibana dans les versions précédentes, la première version à laquelle j'ai pu essayer d'appliquer les modifications est la 4.1.6. Cependant, il y a eu une réécriture/refactorisation/réorganisation importante du code et je ne peux pas simplement patcher cette branche. Il faudrait beaucoup de travail pour essayer de faire fonctionner mon code.

Honnêtement, je ne sais pas pourquoi les équipes de Kibana mettent en place la version élastique requise comme elles le font à chaque version. L'interface REST ne change tout simplement pas si souvent. Je suppose qu'ils le font pour forcer les utilisateurs à mettre à niveau leurs clusters élastiques.

Une pensée, vous pouvez essayer de changer la version dans src/plugins/elasticsearch/index.js vers la ligne 27

@ppadovani
ça a marché. Merci.

+1

@ppadovani Bonjour, merci pour la mise à jour vers la version 4.4.1, désolé de ne pas avoir répondu plus tôt (j'ai raté votre mise à jour dans l'un des commentaires précédents).

Cela fonctionne maintenant, mais la première chose que j'ai remarquée, ce sont des problèmes de performances et parfois kibana se bloque complètement (je n'ai pas pu tester des requêtes plus compliquées).

Il y a peu de choses qui pourraient contribuer à ce problème, l'un d'eux est un certain nombre de champs dans notre index quotidien (il y en a des centaines http://pastebin.com/fktN0dR5).

@Robitx Avez-vous les mêmes problèmes avec le code de base 4.4.1 K sans mes modifications ? Ou est-ce juste avec mes modifications? Je sais que les modèles d'index très volumineux causent des problèmes de performances importants pour K. Si c'est juste avec mon code, alors je pense que je sais ce que cela pourrait être. J'y jetterai un coup d'œil quand je prendrai de l'air dans un jour ou deux.

@ppadovani la base K 4.4.1 n'a pas ce problème

Un an que ce problème n'est pas résolu ...

Bon sang, elasticsearch a une fonctionnalité assez nécessaire "Objets imbriqués", et Kibana des mêmes développeurs ne prend toujours pas en charge cette fonctionnalité.

Vous avez un fork qui implémente déjà cette fonctionnalité et qui ne fusionne toujours pas dans le code source principal, avec un support approprié.

Et nous ne pouvons toujours pas utiliser dans notre projet la version stock de Kibana avec la prise en charge des « objets imbriqués ».

Putain d'incroyable !!!

@ppadovani un grand merci pour votre travail sur fork=)

@Robitx Pouvez-vous me dire quand Kibana se bloque pour vous ? Définition du modèle d'index ? Ou lorsque vous lancez une nouvelle requête ? Il y a des domaines possibles où cela pourrait être, et je veux le réduire.

J'ai corrigé un problème qui aurait pu contribuer lors de l'affichage des onglets de découverte/visualisation... J'ai poussé un correctif, veuillez re-tester.

@rashidkpc Je suis prêt à générer une pull request basée sur ce travail. Pouvez-vous me dire sur quelle branche je dois rebaser mon travail ? Je l'ai actuellement contre 4.3.1, 4.4.1 et 4.x. (4.x est proche, mais j'ai des problèmes pour exécuter les tests unitaires. Le cluster de test ne démarre pas...)

Salut la bande (cc @ppadovani)

Comme je l'ai mentionné dans https://github.com/elastic/kibana/pull/5411, il existe un certain nombre de limitations dans Elasticsearch lui-même, en particulier que les aggs/filters imbriqués ne sont pas automatiques et que la syntaxe de requête lucene ne prend pas en charge la recherche imbriquée. Bien que l'approche adoptée ici tracerait une voie différente pour résoudre le problème, ce n'est pas la direction dans laquelle nous voulons aller. Il s'agit d'une solution à un problème limité, mais nous voulons que Kibana résolve un large éventail de défis. Dans ce cas, cela signifie sacrifier les petites victoires pour de plus grandes victoires sur la route.

Alors que nous examinons les possibilités d'un langage pour Kibana, nous n'avons pas décidé exactement ce que nous voulons que l'ensemble de fonctionnalités soit et ne voulons pas le faire à moitié, ou avec un seul objectif en tête. Nous envisageons des tactiques et des ensembles de fonctionnalités, à la fois dans Elasticsearch et dans Kibana, mais nous en sommes encore au stade de la formation. Au fil du temps, nous aimerions que cela inclue la recherche, la transformation et la visualisation, comme vous le voyez dans quelque chose comme timelion, et nous garderons certainement à l'esprit l'idée d'interroger des documents imbriqués pendant que nous le faisons.

J'ai noté que cela stocke le chemin imbriqué, mais nous supprimons le mappage mis en cache https://github.com/elastic/kibana/pull/6648 et le remplaçons par de nouvelles API dans Elasticsearch : https://github.com/elastic /elasticsearch/issues/15728. Veuillez peser sur ce problème, ce serait formidable si Kibana n'avait pas besoin d'analyser le chemin imbriqué. Ceci est particulièrement important pour notre objectif de rendre les documents très volumineux accessibles dans Kibana

Pour l'instant, nous vous recommandons d'adopter l'approche de @tbragin en utilisant include_in_parent ou copy_to . Pour 90 % des agrégations, cette approche fonctionnera parfaitement.

Je suis content que cette solution fonctionne pour ceux qui ne peuvent pas utiliser include_in_parent ou copy_to , super impressionné par ce que @ppadovani a accompli. J'aimerais voir quelque chose comme ça implémenté en tant que plugin. À l'heure actuelle, l'entrée de la requête prend essentiellement 2 types de requêtes de toute façon, nous pourrions probablement trouver un moyen de rendre cela enfichable.

j'ai discuté avec Rashid à ce sujet, et même si je ressens la douleur des utilisateurs qui souhaitent utiliser Kibana pour les mappages imbriqués, le soutenir de manière plus générale (ce qui pourrait impliquer des fonctionnalités supplémentaires au niveau Elasticsearch lui-même) est la voie à suivre qui maintient la flexibilité dont nous avons besoin à Kibana. Bien que l'obtention de ce changement suggéré puisse résoudre le problème à court terme de ne pas prendre en charge l'imbrication, cela s'avérera problématique sur la route.

Je me dirige ici et je ressens le besoin pour Kibana de soutenir l'imbrication, mais c'est l'un de ces cas où s'il n'est pas évident de savoir comment il doit être résolu, il est préférable de le laisser en suspens jusqu'à ce que nous ayons une solution qui semble naturelle. Nous devons absolument continuer et explorer cela, l'un de ceux, dont nous avons discuté à différents endroits, prend automatiquement en charge l'imbrication (emballage, etc.) dans ES lui-même.

Je suis hérissée d'excitation de voir cela élégamment résolu.

+1

+1

IMHO Je dois respectueusement être en désaccord avec la position des mainteneurs de Kibana. Cependant, si nous pouvons trouver un moyen de faire en sorte que quelque chose de ce genre se connecte à Kibana, je serais tout à fait d'accord.

En attendant, je continuerai à maintenir et à corriger les bogues sur mes fork(s)/branches pour ceux qui souhaitent continuer à utiliser la version que j'ai créée. Je sais que nous utiliserons largement cela pour les tableaux de bord analytiques BI en direct à l'avenir.

Bovins. Pas d'animal de compagnie.

+1 :)
Cela pourrait être génial d'utiliser des objets imbriqués dans Kibana !! (Quelqu'un a un plugin pour ça ou pas ?...)

+1

+1

+1

@tbragin L'approche que vous avez mentionnée ne fonctionne pas sur les types imbriqués. Il regroupera toutes les données, quel que soit leur type.

+1

+1

+1

+1

Cette fonctionnalité est tellement évidente que j'ai été choqué de constater que non seulement elle n'est pas prise en charge, mais que les développeurs n'ont apparemment pas l'intention de la prendre en charge. Bon sang , parlez à vos chefs de projet et engagez

+1 car le manque d'objets imbriqués gêne considérablement mon projet

Pour tous ceux qui recherchent une discussion sur la dénormalisation comme moyen de contourner ce problème : contourner le support manquant de Kibana pour les objets imbriqués et le parent/enfant

Elastic, ce serait formidable s'il y avait une clause de non-responsabilité sur le site concernant ce problème pour éviter que les utilisateurs ne perdent leur temps à essayer d'implémenter une fonctionnalité non prise en charge. Pourquoi? La page produit de Kibana dit "Seamless Integration with ElasticSearch" ce qui n'est pas vrai ici :)

Pour info - La branche de mon code référencée dans la discussion ci-dessus est ancienne... la branche actuelle est :

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

Nous l'utilisons activement en interne et continuons à mettre à jour notre version interne. Je peux/je mettrai à jour la version de github en cas d'intérêt.

Pierre

+1

+1

+1

+1

+1

+1

Je me souviens avoir attribué +1 à cela il y a plus d'un an, et depuis lors, l'équipe de développement de Kibana n'a rien fait d'autre que creuser et ignorer pour la plupart les utilisateurs. moins « NON », indiquant que « cela ne semble pas naturel ».

Je vois également ce modèle sur de nombreuses autres fonctionnalités demandées telles que :

• Prise en charge de l'appel de scripts groovy côté système d'exploitation.
• Prise en charge de la possibilité d'utiliser ES Scripted Metric Aggregations (particulièrement utile pour calculer des moyennes pondérées).
• Etc...

Tout cela va à l'encontre de la position sur l'ensemble de la vision Elastic Stack 5 qui a déclaré qu'ils (Elastic) prendraient en charge davantage de fonctionnalités sous-jacentes d'Elasticsearch dans Kibana. Mais j'ai vu très peu pour étayer ces affirmations.

En conséquence, je vois Kibana perdre du terrain face à des fourches telles que Siren's Kibi, qui a décidé de reprendre le flambeau sur des sujets tels que ce sujet et de trouver une solution.

Je remercie les développeurs de Kibana de nous avoir fourni un excellent outil de visualisation. Mais Elastic doit décider à l'avenir si Kibana doit rester un outil de visualisation simpliste ou écouter la communauté et étendre son utilité. Si la décision est la première, attendez-vous à ce que les utilisateurs partent lorsque d'autres décident de profiter de ces lacunes.

+1

@cslinuxboy

Prise en charge de l'appel de scripts groovy côté système d'exploitation.

La plupart des cas d'utilisation couverts par cela seront résolus par https://github.com/elastic/kibana/pull/7700.

Prise en charge de la possibilité d'utiliser les agrégations de métriques scriptées ES

Je ne pense pas que quiconque soit contre cela (du moins, ne voyez aucune opposition ici https://github.com/elastic/kibana/issues/2646), en fait c'est le moment de l'ajouter puisque Elasticsearch a ajouté le langage de script indolore. C'est vraiment juste une question de quelqu'un qui trouve le temps.

+1

+1

+1

Je recommence à travailler sur ma fourche. Je souhaite m'excuser auprès de la communauté, je n'avais aucune idée jusqu'à il y a environ un mois que je n'avais pas activé les problèmes pour le fork, donc personne n'aurait été en mesure d'indiquer qu'il y avait des bugs. Cela a été rectifié.

Branche actuelle : https://github.com/homeaway/kibana/tree/nestedSupport-4.5.4

Les mises à jour dans l'ordre dans lequel j'ai l'intention de les implémenter :

• Ajout de la prise en charge des décalages de date à l'analyseur de requête
• Ajout de la prise en charge de la découverte des champs imbriqués lors de la consultation d'un résultat - TERMINÉ
• Ajout de la prise en charge des requêtes et agrégations parent/enfant
• Ajout de la prise en charge des types de formes géographiques pour les requêtes (c'est-à-dire point, boîte, etc.) Il s'agit d'un portage d'une récente amélioration de notre langage interne.
• Ajouter une saisie anticipée pour les noms de champ dans le champ de requête
• Je pourrais essayer de créer un analyseur syntaxique pour le langage de requête simple Elasticsearch existant afin de résoudre le problème d'une requête invalide provoquant le renvoi d'une trace de pile à partir d'Elasticsearch ou aucun résultat n'étant renvoyé sans aucune indication pourquoi. Si je travaille là-dessus, ce sera après avoir terminé ce qui précède. Si je fais cela, je chercherai à ajouter une prise en charge imbriquée et parent/enfant à la langue du côté de Kibana.

Je souhaite ajouter ma voix à celles qui ont indiqué que l'équipe de Kibana n'est pas à l'écoute de la communauté. L'équipe Kibana NE PEUT PAS simplement compter sur Elasticsearch pour fournir les fonctionnalités nécessaires s'il y a un écart afin de garder Kibana "pur". La part de marché n'est pas gagnée de cette façon, elle est perdue.

+1

+1
@Bargs : Des progrès sur ce problème ? Quand cela sera-t-il traité/priorisé ?
Fil très long....Ce n'est pas bon pour un produit comme le kibana..
Nous apprécions vos efforts

C'est nul :-(

homeway a imbriqué aggs & query suport build sur Kibana 4.3.1 vérifiez-le .. espérons que cette aide ..

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

@ankitchheda Je le sais, mais un fork maintenu par quelques personnes qui va à l'encontre de la philosophie du projet principal (qui est en cours de développement) n'est pas une solution, prétendant que cela n'aidera personne..

J'aimerais faire quelque chose à ce sujet, mais je n'ai pas le temps, donc pour l'instant j'essaie au moins de faire pression et j'espère que les développeurs arrêteront d'ignorer ce problème :|

+1

Pour info - Le fork que je maintiens pour le support imbriqué, prend désormais en charge les versions suivantes :

4.5.X
4.6
4.7
5.X

Cela ne suit peut-être pas la «philosophie» des principaux développeurs, mais cela fonctionne et fonctionne bien.

Je viens de me heurter à ça. C'est un peu un inconvénient et il serait vraiment utile d'avoir une solution viable.

@tbragin , @rashidkpc - la solution de contournement proposée manque le point - vous obtenez
quelque chose avec des objets imbriqués - mais vous obtenez de mauvais résultats ! Imbriqué
les agrégations donnent des résultats différents (je ferai un petit exemple travaillé et le posterai ici plus tard).

Je vais tester le fork de @ppadovani.

+1

:tortue::tiret:

@Bargs Hé, est-ce que les changements de fork nuisent aux performances de la fonctionnalité de base ?

+1

+1

+1

+10086

+1

+1

+1

include_in_parent fonctionne toujours sur ES et Kibana 5.2 ? J'ai essayé d'utiliser comme alternative sans succès.

@gustavomr Je pense que cela fonctionnera, mais uniquement pour certains cas d'utilisation. Cela ne fonctionnera pas pour tous les cas d'utilisation de requêtes possibles que les requêtes/agrégations imbriquées peuvent fournir.

REMARQUE : mon fork 5.1 de Kibana utilise désormais une bascule à côté de l'icône de recherche pour basculer entre le langage de requête simple élastique natif et le langage de requête imbriqué que j'ai inclus. J'ai également résolu divers problèmes liés aux métriques des champs imbriqués.
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovani merci beaucoup pour cela. Est-il possible de séparer votre travail d'activation d'objets imbriqués dans kibana de votre travail de création d'un nouveau langage de requête ? S'il s'agit de branches distinctes, nous pouvons simplement utiliser la première et la fusionner avec les nouvelles versions de kibana au fur et à mesure de leur sortie au lieu de fusionner les deux fonctionnalités.

De plus, avez-vous déjà un docker créé pour cette fourchette ?

@ppadovani +1 pour le conteneur docker pour votre fourche.

@gkozyryatskyy - Veuillez ouvrir un problème sur le fork, et je le regarderai.

@ imranq2 - Je pourrais le faire, mais veuillez noter que le langage de requête élastique simple ne prend pas en charge les requêtes imbriquées. Si vous avez des données imbriquées et que vous souhaitez les interroger, vous devrez créer manuellement la requête en tant que blob json elasticsearch et la coller dans la zone de requête.

+1

Mon fork prend désormais en charge 5.2 sur la branche nestedSupport-5.2.

@ppadovani C'est super ! Faites-moi savoir si vous avez besoin d'aide pour créer un conteneur Docker pour cela.

Je n'ai pas terminé le conteneur Docker, mais j'ai eu le temps de jouer avec l'onglet de découverte et la façon dont il affiche les données imbriquées... à la recherche de commentaires de ceux qui surveillent le problème de support imbriqué. La table est récursive et les filtres pour les champs imbriqués semblent bien fonctionner... mais le champ à bascule dans la colonne ne fonctionne pas encore... Je dois encore réfléchir à comment/si cela devrait fonctionner.

Pour info - Ce travail est pratiquement terminé et tous les forks/branches pris en charge ont les modifications commençant par nestedSupport-4.5.4 jusqu'à nestedSupport-5.2

@Bargs - Je sais qu'aucun des travaux imbriqués que j'ai effectués n'est quelque chose que vous cherchez à intégrer, mais je suis curieux de savoir si le travail autour de l'affichage des données imbriquées dans les résultats de la découverte est quelque chose que vous pourriez souhaiter. Cela ne dépend d'aucun de mes travaux antérieurs. Consultez ce numéro pour des captures d'écran mises à jour :
https://github.com/homeaway/kibana/issues/12

Si c'est quelque chose que vous voulez, faites-le moi savoir et j'ouvrirai un problème et inclurai un correctif.

Ça a l'air intéressant

@ppadovani Je crée un conteneur docker pour cela en ce moment afin que je puisse l'utiliser. Avez-vous déjà créé une boule de goudron comme http://staging.elastic.co/ $(VERSION_TAG)/downloads/kibana/kibana-${ELASTIC_VERSION}-linux-x86_64.tar.gz ? Si c'est le cas, je peux simplement le mettre dans mon conteneur Docker. Sinon, je devrai construire votre branche et créer l'archive tar.

@imranq2 Je ne fournis pas de distributions de mon fork, vous devrez donc le construire vous-même.

Pour info - j'ai créé une pull request pour prendre en charge les données imbriquées dans l'onglet découverte pour ceux qui sont intéressés :
https://github.com/elastic/kibana/pull/10814

+1

+1 pour moi
+10 pour mes collègues

+1

+1

+1

+1

+1

+1

+1. Est-ce pris en charge dans ELK5 ?

+1

c'est vraiment une exigence car ne pas prendre en charge les objets imbriqués est vraiment un obstacle à l'adoption généralisée de kibana dans mon entreprise car vous devez créer un index pour kibana et un autre avec des documents imbriqués pour des recherches plus intelligentes via l'API simple

+1
Dans mon mappage, cela empêcherait une éventuelle "explosion" des propriétés d'index.

+1

+1

+1

S'il vous plaît, arrêtez de publier des commentaires +1 qui ne font que spammer toutes les personnes abonnées à ce fil. Au lieu de cela, cliquez sur le gros bouton jaune « pouce levé » en haut de ce numéro pour le voter.

+1

Développeurs de Kibana, faites quelque chose, les gars vraiment. L'utilisation de Kibana sans objets imbriqués dans de nombreux cas est inutile. Vous préparez la version 6.x sans objets imbriqués...

Notre système scanne le texte pour les maisons, puis enregistre les résultats dans ES. ES contient donc les principaux documents avec un tableau de maisons. House est les objets imbriqués.

Je ne peux pas utiliser la visualisation pour créer un tableau de bord avec une analyse des maisons que nous avons trouvées dans le texte.
Faites quelque chose s'il vous plaît. Les maisons sont en feu.

Besoin désespérément d'utiliser des objets imbriqués dans kibana. C'est dommage que cela ne soit pas disponible en interne.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

un autre ici !

Pour ceux qui ont peut-être utilisé mon fork de Kibana avec un support imbriqué, j'interromps le support de ce fork après la version 5.4.x de Kibana. Au lieu de cela, je vais déplacer la plupart sinon toutes les fonctionnalités dans un plugin Kibana. J'espère que le plugin sera prêt pour la dernière version 5.x d'ici la fin de l'année. Vous pouvez suivre les progrès ici : https://github.com/ppadovani/KibanaNestedSupportPlugin

Je viens de commencer le travail, alors ne vous attendez pas à ce que quelque chose d'important se présente pendant quelques semaines.

+1

+1

+1

+1

+1

J'ai des captures d'écran et des mises à jour de statut publiées pour le travail que je fais sur le plugin de support imbriqué. Regardez le problème pour obtenir des mises à jour de statut.

Captures d'écran et mises à jour

Je suis allé de l'avant et j'ai publié une pré-version de la version 1.0.0 avec la prise en charge de Kibana 5.6.5.

Consultez ce numéro pour plus de détails sur le contenu de la pré-version initiale : captures d'écran et mises à jour

V1.0.0-beta1

Mon plugin est complet pour la version 5.6.5 de Kibana. J'ai quelques tâches de nettoyage, puis je vais couper la version 5.6.5 et commencer le portage en 6.1.X.

Caractéristiques:

• Prise en charge des requêtes imbriquées
• Prise en charge de l'agrégation imbriquée
• Découvrez le support imbriqué des résultats
• Découvrir la priorité d'affichage du champ récapitulatif (c'est en fait quelque chose de nouveau)

Voir le README pour plus de détails.

Mon plugin est maintenant disponible ! Prise en charge de 5.5.3, 5.6.5 et 5.6.6. Je vais porter sur 6.0.X ce week-end.

Je ne mettrai probablement plus à jour le statut ici sur ce problème. Veuillez visiter ma page GitHub pour voir les versions, les problèmes, etc.

Merci!

@ppadovani pouvez-vous publier une version de support pour 5.4.0 merci.

@ppadovani Je surveillerai le portage 6.0.x !

@SolomonShorser-OICR
J'ai publié une version 6.0.1 Beta 1.

La seule limitation connue est que la barre de filtre n'est pas opérationnelle car elle est codée en dur pour ne fonctionner qu'avec le langage de requête lucene. Je cherche un moyen de contourner cela, mais je n'aurai peut-être pas de solution avant le week-end prochain.

J'ai maintenant publié une version de plugin pour 6.0.1, 6.1.x est la prochaine.

@ppadovani
Merci pour votre travail et la version 6.0.1 !

basé sur kibana 6.0.1, après avoir installé ce plugin, certaines fonctionnalités de kibana ne fonctionnent pas bien.

lorsque vous cliquez sur timelion, un message d'erreur s'affiche :

si x-pack est installé, certaines fonctionnalités x-pack "découvrir" ont un autre message d'erreur dans "Foreach"

Salut l'équipe Kibana, pourquoi tu n'as pas encore embauché @ppadovani ?

@sccds - Veuillez déplacer ce rapport de bogue vers mon dépôt GitHub :

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

Si quelqu'un a des problèmes avec mon plugin, veuillez ouvrir les problèmes sur mon dépôt et ne démarrez pas de conversation ici. Ce numéro a beaucoup trop d'abonnés.

@Hronom - J'apprécie l'idée, mais mes points forts ne sont pas en Javascript .... bien que la construction de ce plugin et le piratage de Kibana aient certainement aidé mes capacités dans ce domaine.

Pour info - Mon plugin est maintenant à jour avec les versions de Kibana. J'ai publié le support 6.1.2.

Merci @ppadovani , continuez comme ça !

+1

+1

+1 Bonjour, Tomitribe est très intéressé par cette fonctionnalité. Savez-vous quand cette fonctionnalité sera implémentée ?

@ppadovani où puis-je poser des questions sur les fonctionnalités ? Je suis aux prises avec l'agrégation imbriquée dans la table de données.

@bumerankkk Allez ici et ouvrez un problème : https://github.com/ppadovani/KibanaNestedSupportPlugin

Alternativement, si vous accédez à l'une des pages de documentation qui correspond à votre question, vous pouvez ajouter un commentaire au bas de la page.

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

Est-ce qu'on y travaille activement ? Avons-nous des délais sur le moment où une telle fonctionnalité connaîtrait une sortie de production ?

Joyeux anniversaire 🎂 'Agrégations de type imbriquées', 🎁

Maintenant tu as déjà quatre ans. Il n'y a pas si longtemps, tu étais si petit et mignon.
J'espère que vous grandirez et que nous aurons de bonnes années communes dans le futur.

meilleur Malou

+1

+1

+1

+1

+1

+1

+1

Pourquoi cela n'est-il pas encore implémenté

pour des raisons, avec cette fonctionnalité, le petit-lait n'aurait pas de fil, pas de plaisir et personne n'ira sur github de la kibana, c'est une sorte de balise

La dernière version d'elk prend en charge correctement les données imbriquées pour moi

El El mié, 6 juin 2018 a las 22:08, Eugene [email protected]
description :

pour des raisons, avec cette fonctionnalité, le petit-lait n'aurait pas de fil, pas de plaisir et
personne n'ira au github du kibana, c'est une sorte de balise

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
.

@javixeneize Je suis assis ici sur la version 6.2.4 , je ne trouve pas la prise en charge des objets imbriqués, corrigez-moi si je me trompe

J'ai cette version et je peux accéder à ab, où ma structure est {Id:xx,
a : {b:xx}}

El El mié, 6 juin 2018 a las 22:18, Eugene [email protected]
description :

@javixeneize https://github.com/javixeneize Je suis assis ici sur 6.2.4
version, je ne trouve pas la prise en charge des objets imbriqués dat, corrigez-moi si je me trompe.

-
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
.

@javixeneize avez-vous le prochain mappage avec type : nested ?
Vous pouvez obtenir la cartographie par GET /index-name

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

je vérifierai demain mais j'ai la config par défaut

El El mié, 6 juin 2018 a las 22:24, Eugene [email protected]
description :

@javixeneize https://github.com/javixeneize avez-vous la prochaine cartographie
avec le type : imbriqué ?
Vous pouvez obtenir le mappage par GET /index-name

{
"document": {
"Propriétés": {
"Emplacements": {
"type": "imbriqué",
"Propriétés": {
"commencer": {
"type": "long"
},
"finir": {
"type": "long"
},
"normalisé": {
"type": "mot-clé"
},
"original": {
"type": "mot-clé"
}
}
}
}
}
}
}

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
.

@javixeneize merci d'avance !
Vous avez probablement un objet sub json qui a été aplati dans le document principal, mais ce n'est pas un objet imbriqué.

Oui, faites attention seront pas corrélées comme prévu, à moins que vous ne définissiez spécifiquement le mappage dans ES pour ce champ sur imbriqué

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

Problème principal, chaque champ de l'objet imbriqué devient simplement un tableau et vous perdez la corrélation entre les propriétés.

Je viens d'aplatir mes données avant de les vider dans es pour le moment.

Si vous ne pouvez pas attendre qu'Elastic implémente cela, vous pouvez utiliser mon plugin Kibana :

Aperçu:
https://ppadovani.github.io/knql_plugin/overview/
Installation:
https://ppadovani.github.io/knql_plugin/installation/
Langage de requête (comme SQL) :
https://ppadovani.github.io/knql_plugin/knql/

Prise en charge de 5.5.3 à 6.2.4, si une version est manquante, après la 5.5, veuillez ouvrir un problème :
https://github.com/ppadovani/KibanaNestedSupportPlugin

Les contributions, les demandes de fonctionnalités et les rapports de bogues sont les bienvenus.

Bon, je dois attendre alors...

El El jue, 7 juin 2018 a las 0:38, Pierre Padovani [email protected]
description :

Si vous ne pouvez pas attendre qu'Elastic implémente cela, vous pouvez utiliser mon Kibana
brancher:

Aperçu:
https://ppadovani.github.io/knql_plugin/overview/
Installation:
https://ppadovani.github.io/knql_plugin/installation/
Langage de requête (comme SQL) :
https://ppadovani.github.io/knql_plugin/knql/

Prise en charge de 5.5.3 à 6.2.4, si une version est manquante, après 5.5 s'il vous plaît
ouvrir un problème :
https://github.com/ppadovani/KibanaNestedSupportPlugin

Les contributions, les demandes de fonctionnalités et les rapports de bogues sont les bienvenus.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
.

+1

+1

+1

+1

+1

+1

fonctionnalité très utile... +1

Kibana est absolument inutile pour mes cas d'utilisation sans ce support. Je ne devrais pas avoir à aplatir ou à restructurer mes données. Je devrais juste être capable d'entrer des données et d'obtenir des visualisations ou des agrégations. Quatre ans plus tard et toujours pas de support d'objets imbriqués ?

Une estimation quand cette fonctionnalité est disponible ?

Quelqu'un d'elastic pourrait-il nous indiquer si cette fonctionnalité est ajoutée à Kibana ? Ce billet est ouvert depuis presque 5 ans maintenant.

Aussi, quel est l'intérêt de publier une telle fonctionnalité si elle ne peut pas être utilisée dans Kibana ?

Ne vous méprenez pas, mais ça fait un peu bizarre.

+1

+1

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

Veuillez ne pas ajouter de commentaires comme +1 commentaires. Surtout pour les problèmes qui vous tiennent vraiment à cœur ! Laissez-moi vous expliquer, toute personne ayant activé les notifications sera facilement agacée et se désabonnera du fil. Cela signifie que les contributeurs ne verront pas cela comme un problème important uniquement en fonction du nombre de participants impliqués. Lorsque les gens se désabonnent, ce nombre diminue.

Au lieu de cela, ce que VOUS devriez faire est de vous abonner au fil de discussion via la case dans le coin supérieur droit et de donner un coup de pouce au problème initial de Github pour montrer votre soutien.

@bugs181 cela ne fonctionne pas ici, ce problème est une anomalie et absorbe toutes les vagues entrantes, depuis cinq ans maintenant !

Je pense que les scientifiques devraient explorer ce trou noir !

Les devs de Kibana semblent avoir un pouvoir anormal !!!

@bugs181 cela ne fonctionne pas ici, ce problème est une anomalie et absorbe toutes les vagues entrantes, depuis cinq ans maintenant !

Avez-vous déjà pensé qu'ils ne voulaient pas lire l'intégralité du numéro avec des tonnes de commentaires « +1 moi aussi » à la recherche d'informations qui pourraient leur être utiles ?

@ppadovani a un plugin open source qui pourrait être utilisé (regardez son commentaire ci-dessus)

@mika76
j'utilise ça.

très utile dans un cas simple

@ mika76 sachez simplement qu'en raison de contraintes de temps, il n'est actuellement pas activement maintenu.

ppadovani a commenté il y a 28 jours
Hé les gens... J'ai trouvé mon temps très limité à cause du travail et de la vie. De plus, même si j'ai pu faire avancer les choses en partie, les changements que l'équipe de Kibana a apportés en passant à React nécessiteront principalement de réécrire de gros morceaux de ce que j'ai fait.

@mika76 oui, ce plugin est le seul moyen d'obtenir des objets imbriqués qui fonctionnent actuellement.
Mais ce qui m'est étrange, c'est qu'Elasticsearch a un support officiel pour les objets imbriqués, mais pas Kibana.

Comme mentionné @ bugs181, il n'est actuellement pas activement maintenu et cela signifie que vous ne pouvez pas passer à la dernière version de la pile ELK.

Ainsi, le soutien officiel signifie également un bon entretien. Mais parce que les développeurs crachent sur ce problème, nous n'avons pas de support officiel pour cela.

Je dois seconder @bugs181 ici. '+1'-ing ce problème et sinon le spam, n'aide pas beaucoup à sensibiliser à ce sujet, mais ne fera que rendre les gens muets ou nous rapprochera du point où je devrai le verrouiller, ce que je n'aime vraiment pas Je ne veux pas, parce que je voudrais garder chaque problème ouvert à la discussion pour tout le monde, car je crois en une communication ouverte.

Jusqu'à présent, j'ai également toujours recommandé d'utiliser ce plugin. Je ne savais pas que ce n'est plus activement maintenu et je suis triste d'entendre cela. Nous savons également que ce problème est ouvert depuis 5 ans, et nous effectuons une analyse des problèmes (dans Kibana évidemment - voir capture d'écran ci-jointe) et savons que ce sont les problèmes qui ont le plus réagi :

Mais comme vous le savez à peu près, il y a (littéralement) des milliers d'autres problèmes ouverts, nous devons donc toujours trouver un équilibre entre les fonctionnalités, la correction de bogues, etc. pour trouver une bonne hiérarchisation. Aussi (mais pas seulement) parce que cette fonctionnalité a toujours eu un plugin de communauté de travail assez solide, elle n'a pas eu assez de priorité (pour vaincre d'autres problèmes) jusqu'à présent. De plus, comme il y a souvent des relations techniques entre différentes choses, et par exemple pour les supports de champ imbriqués, nous voulons d'abord terminer notre refonte de l'ensemble du pipeline de rendu de visualisation (#19813), avant de commencer cela, car il est fortement lié ensemble. Néanmoins, nous avons actuellement ce problème sur notre feuille de route pour 7.x et nous espérons ne pas être bloqués par d'autres changements techniques, nous pourrons donc bientôt déplacer cette fonctionnalité dans le noyau Kibana pour la rendre disponible sans plug-in communautaire.

La demande de prise en charge des visualisations d'objets imbriqués inclut-elle la prise en charge des relations parent-enfant ? J'ai un client qui me demande des visualisations parent-enfant.

@MorrieAtElastic non, parent-enfant serait un problème distinct.

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

C'est vraiment un gros problème car nous ne pouvons pas afficher correctement les relations 1:M dans Kibana car ElasticSearch prend en charge les objets imbriqués afin que nous puissions charger les données mais ne pouvons pas les afficher correctement. Cela doit être corrigé rapidement.

Merci,
Rakesh

J'ai commencé à travailler sur la prise en charge des champs imbriqués dans KQL aujourd'hui. Création d'un problème distinct à suivre, car la prise en charge complète des champs imbriqués dans Kibana implique de nombreux changements au-delà de KQL.

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

OMG est-ce réel ? Après 5 ans...

Qu'en est-il du nouveau type de données : aplati ? Y aura-t-il une prise en charge des visualisations pour ce nouveau type à l'avenir ? De nombreux clients du service sont orientés vers ce nouveau type et ils demandent si/quand les visualisations pourraient entrer en jeu.

@Barrybigbuddy Je ne sais pas quels sont les plans pour l'aplatissement, pourriez-vous créer un ticket séparé pour cela?

J'aimerais que la relation parent-enfant soit représentée à Kibana. Je vous demande donc de prioriser cette fonctionnalité. Merci. M'Jay

+1

Impressionnant! +1 ici ! Y a-t-il un délai précis pour cette fonctionnalité ?

Permettez-moi d'être le fêtard ici et de faire un petit rappel : il y a beaucoup de personnes abonnées à ce numéro (228 personnes de la communauté + quelques équipes Elastic), donc ce serait bien si nous gardions +1 pour un minimum. Grâce à la fonction de réaction agréable de GitHubs, vous pouvez également ajouter votre approbation et votre amour pour @Bargs à ses commentaires sans déclencher de notification à tous les abonnés (ou votre désapprobation, il peut alors à nouveau arrêter de travailler sur le support de terrain imbriqué :wink:). Aussi, d'autant plus qu'il s'agit d'un ticket si volumineux, veuillez ne pas l'utiliser pour des questions sans rapport sur d'autres types de champs.

Je vais laisser quelques références ici pour d'autres types de champs :

• Prise en charge du type de champ flattened - actuellement pas sur notre feuille de route à court terme
• Pension alimentaire pour parents/enfants - actuellement pas sur notre feuille de route à court terme

Quand cette fonctionnalité arrivera-t-elle ? Nous y travaillons activement et il y aura différentes phases (KQL, prise en charge du filtrage, visualisations, etc.) qui pourraient arriver dans différentes versions, et cela dépendra de la façon dont le processus de développement se déroulera. Nous publierons les demandes d'extraction liées à cette fonctionnalité sous forme de commentaire ici, afin que vous puissiez voir dans le PR dans quelle version cette phase/partie spécifique du support va atterrir.

Je ne sais pas s'il s'agit du même problème, mais j'ai un index avec une liste d'objets, mais n'utilise pas le type de données "imbriqué". Cependant dans Kibana sous "Champs disponibles", je ne vois pas de champs à l'intérieur des objets qui sont dans la liste. Est-ce une limitation connue ?

@ppadovani est-ce que le plugin est disponible pour kibana-7.3.1 ?

Bonjour à tous, je pense avoir trouvé une solution à ce problème. En lisant le code source des mappages, j'ai trouvé qu'il existe une option include_in_parent pour le type de mappage imbriqué. En utilisant cette option, je peux visualiser un tableau d'objets dans Kibana sans aucun problème !!! Pour une raison quelconque, cette option n'apparaît PAS dans la documentation ES. Peut-être que je me trompe, mais apparemment tout fonctionne. J'utilise l'option champs pour pouvoir rechercher à la fois en tant que mot-clé et en texte intégral.

Mappages

METTRE /test_index
```json
{
"mappages": {
"dynamique": "strict",
"Propriétés": {
"Etat": {
"type": "mot-clé"
},
"créé par": {
"type": "imbriqué",
"include_in_parent": vrai,
"Propriétés": {
"prénom": {
"type": "texte",
"des champs": {
"cru": {
"type": "mot-clé"
}
}
},
"nom de famille": {
"type": "texte",
"des champs": {
"cru": {
"type": "mot-clé"
}
}
}
},
"dynamique": "strict"
},
"personnes": {
"type": "imbriqué",
"include_in_parent": vrai,
"Propriétés": {
"prénom": {
"type": "texte",
"des champs": {
"cru": {
"type": "mot-clé"
}
}
},
"nom de famille": {
"type": "texte",
"des champs": {
"cru": {
"type": "mot-clé"
}
}
}
},
"dynamique": "strict"
}
}
}
}

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

L'utilisation de include_in_parent ou copy_to comme solution de contournement n'est pas prise en charge et peut cesser de fonctionner dans les versions futures.

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

Support de terrain imbriqué Phase 1 publié dans 7.6.0

Une petite mise à jour de ce problème : nous venons de publier la version 7.6.0 de Kibana, qui contient la prise en charge initiale des champs imbriqués. Vous pouvez désormais utiliser des champs imbriqués dans les endroits suivants de Kibana :

• Les modèles d'index détecteront correctement les champs imbriqués
• Vous pourrez regarder les champs imbriqués dans Discover
• Le filtrage sur les champs imbriqués via la barre de filtre fonctionne
• KQL permet de rechercher des champs imbriqués (voir la documentation KQL pour une explication de la syntaxe sur l'interrogation des champs imbriqués)

Nous travaillons actuellement à l'activation des champs imbriqués dans les visualisations et nous continuerons à mettre à jour ce problème avec les informations pertinentes.

Salut! Nous attendons la fonctionnelle NESTED. Quand peut-on le voir ? C'est le seul moment qui ne bascule pas complètement vers Kibana (Elastic est le meilleur). Le monde entier vous regarde.

L'interrogation des champs imbriqués est toujours boguée avec KQL.
Exemple:
Considérez le mappage d'index défini comme
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
J'ai créé un modèle d'index basé sur cet index et je souhaite interroger first.second.field : "test"
Cette requête dans l'onglet inspecter va générer
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
ce qui est incorrect.
La version correcte doit également inclure la syntaxe imbriquée "nested": {"path": "first.second",...}

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

@IlyaHalsky Veuillez vérifier la documentation KQL sur les champs imbriqués. Les champs imbriqués nécessitent une syntaxe spécifique pour interroger, car vous avez plusieurs façons de les interroger (dans votre cas, vous voudrez probablement simplement faire : first.second:{ field: "test" } ).

Vous devriez également voir une notification toast lorsque vous essayez d'utiliser un champ imbriqué pour la première fois dans une requête KQL qui vous liera à cette explication.

Je demande s'il existe une nouvelle version de kibana qui prend en charge les champs imbriqués dans visualize :
mon exemple de données :
{
"champX": "x",
"fiedY": "O",
"anomalies": [
{
"catégorie": "système",
"nom": "cpu",
"date": "2020-03-11T13:33:40.000Z"
},
{
"catégorie": "redémarrer",
"nom": "réinitialiser",
"date": "2020-03-11T13:33:40.000Z"
},
{
"catégorie": "système",
"nom": "mémoire",
"date": "2020-03-11T13:33:40.000Z"
}
]
}

Je veux visualiser un camembert dans kibana où :
slice size count = nombre total d'objets du tableau d'anomalies (nombre de documents x nombre d'objets par tableau d'anomalies)
premier seau = anomalies.category
deuxième seau = anomalies.name

en d'autres termes je veux visualiser la répartition du nom de l'anomalie par catégorie d'anomalie ?

+1

des nouvelles à ce sujet? La version 7.6 date déjà de quelques mois, les versions 7.7 et 7.8 n'en faisaient aucune mention dans les notes de version et les documents pour 7.9, 7.x et master ne contiennent également aucune nouvelle information sur cette fonctionnalité.

Juste pour exprimer nos grands espoirs d'obtenir la prise en charge des agrégations imbriquées dans les visualisations. Serait génial!