Kibana: Soporte de campo anidado

Creado en 21 mar. 2014  ·  364Comentarios  ·  Fuente: elastic/kibana

Esto es una especie de duplicado de algunos otros temas que busqué, pero no he visto este aspecto en particular discutido, así que pensé que valía la pena un tema por separado.

Usted lee el campo _mapping, por lo que debe saber cuándo un campo en particular está anidado, entonces, ¿no puede aplicar automáticamente la faceta / consulta anidada correcta cuando dicho campo se selecciona en consultas o facetas?

(Alternativamente / además como lo sugiere el n. ° 532, podría tener una casilla de verificación para permitir que los usuarios la seleccionen ellos mismos, tal vez como una medida provisional)

Estoy seguro de que hay algunos casos en los que esto se complica, pero también hay un montón de casos en los que es un cambio sencillo de un bloque de JSON a otro.

Aggregations New Field Type AppServices high hanging fruit enhancement

Comentario más útil

Fase 1 de soporte de campo anidado lanzada en 7.6.0

Una pequeña actualización de este problema: acabamos de lanzar 7.6.0 de Kibana, que tiene el soporte inicial para campos anidados. Ahora puede utilizar campos anidados en los siguientes lugares de Kibana:

  • Los patrones de índice detectarán los campos anidados correctamente
  • Podrás ver Campos anidados en Discover
  • Filtrar en campos anidados a través de la barra de filtros funciona
  • KQL permite buscar campos anidados (consulte la documentación de KQL para obtener una explicación de la sintaxis sobre la consulta de campos anidados)

Actualmente estamos trabajando para habilitar campos anidados en visualizaciones y continuaremos actualizando este problema con información relevante.

Todos 364 comentarios

+1 para agregación de objetos anidados.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

para ser claros, no hay forma de hacer un filtro / consulta / agg anidado en kibana 4 en este momento, ¿verdad?

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1 Porque desnormalizar objetos anidados no siempre es una opción, ya que esto puede conducir a una explosión de mapeo.

Cartografía:

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

En primer lugar, me gustaría que el gráfico de líneas pueda mostrar el tamaño promedio a lo largo del tiempo para cada nombre de grupo. Suponiendo que hay tantos nombres, por lo que la desnormalización no es una buena idea, esto podría llevar a muchos gráficos en la tabla. Para trabajar con estos casos, también sería beneficioso poder utilizar la agregación de filtros dentro de una agregación anidada. Ser capaz de filtrar en campos anidados en la búsqueda superior también sería genial.

Para hacer las cosas aún más interesantes, sería genial poder visualizar una agregación como esta:

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

¡Sería poderoso con esto!

Entonces, ¿alguien puede aclarar esto? En esta publicación (https://www.elastic.co/blog/kibana-4-beta-1-released) para Kibana4beta1 se afirma que "Kibana 4 trae el poder de las agregaciones anidadas de Elasticsearch con el clic de un mouse". No puedo crear ninguna visualización en documentos con objetos anidados. También me aseguré de que los objetos anidados en mi plantilla de índice estén marcados como "anidados". Entonces, ¿el soporte de Kibana para agregaciones anidadas no es lo mismo que el soporte de ES para objetos anidados? ¿Qué me estoy perdiendo? Gracias.

@cslinuxboy : creo que están usando "anidado" aquí para referirse a la agrupación a través de varios campos, por ejemplo, "agregado por tiempo y luego geo" (no "anidado" como en su uso en la plataforma para "objetos anidados")

@ Alex-Ikanow - Gracias por la respuesta. Lástima que esto no sea posible en este momento. Me ilusioné al leer la descripción engañosa en su publicación beta-1.

+1 para compatibilidad con objetos anidados dentro de la agregación de visualización.

+1

Actualmente estoy usando las relaciones entre padres e hijos como una solución que parece estar funcionando bien.

@calvdee ¿Tiene consultas has_parent o has_child para trabajar en la barra de búsqueda de Kibana? Esto no está funcionando para nosotros y es un gran problema, estaría ETERNAMENTE agradecido si tiene esto funcionando y me puede avisar ... ¡¡¡gracias !!!

No, para nuestro caso de uso, todos los padres tienen hijos y todos los hijos necesariamente tienen padres, ya que estamos indexando los datos de las facturas, por lo que las consultas regulares simplemente funcionan (ver imagen).

image

@calvdee ¡ Muchas gracias por la respuesta! Tenemos un modelo de datos similar pero queremos poder encontrar padres por sus hijos en Kibana, no funciona: 0 (

¡No te preocupes, buena suerte!

El jueves, 26 de marzo de 2015, 11:36 ajrasch [email protected] escribió:

@calvdee https://github.com/calvdee ¡ Muchas gracias por la respuesta! Nosotros
tienen un modelo de datos similar pero quieren poder encontrar a los padres por sus
niños en Kibana, no funciona: 0 (

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment -86575796.

+1

+1

Usted lee el campo _mapping, por lo que debe saber cuándo un campo en particular está anidado, entonces, ¿no puede aplicar automáticamente la faceta / consulta anidada correcta cuando dicho campo se selecciona en consultas o facetas?

Sí,: +1: en este. Aunque logré escribir la agregación anidada correcta en CLI y puedo extraer datos con curl, no he encontrado una manera de hacer que funcione en la pestaña "Visualizar" de Kibana, ni siquiera usando el cuadro de edición JSON. Es cierto que nunca uso esa función (la caja), pero parece que solo es posible "agregar" cosas a una agregación existente, no usarla para crear una nueva agregación desde cero ... (agradecerá que lo corrijan si me equivoco en esto!).

Sí, las agregaciones de tipos anidados son clave y se utilizan cada vez más porque resuelven un problema específico con datos planos.

Si Kibana4 es el producto de visualización para ES, debería admitir todas las agregaciones de ES.

Sería bueno al menos ver esto en la hoja de ruta de Kibana4 .

+1

+1

+1

+1

+1

De # 3729 :-)

Me gustaría ver una opción agregada "documentos secundarios".
(histograma posterior a la fecha, histograma, etc.) que abre el
parámetros para una consulta DSL para niños agregados, como
"tipo hijo", "campos", etc.

Esto permitirá que uno cree agregados anidados en el niño.
documentos.

Parece que no puedo crear una consulta de este tipo usando
la función de edición avanzada. Puede que alguien pueda
Iluminame.

Gracias

+1

+1

+1

+1 realmente necesita esta habilidad. Podría eliminar a todos los padres con logstash como solución, pero eso requeriría un archivo de configuración enorme ya que tengo cientos de campos.

kibanafields

+1 alguien sabe si esto está planeado?

+1

En este momento, estoy considerando cambiar algunas de mis asignaciones para dejar de usar objetos de tipo "anidado", ya que no puedo crear visualizaciones de Kibana en ninguno de esos campos. Si supiera que el problema está al menos en la hoja de ruta, sería de gran ayuda para tomar esa decisión.

@benjismith - También mordí la bala y cambié el procesamiento de mis datos de documentos anidados a documentos para padres / hijos. Hasta ahora está funcionando bien, pero estoy de acuerdo contigo; Sería bueno saber si existe alguna posibilidad de que esto se convierta en una característica de Kibana para que todos podamos esperarlo o seguir adelante.

La mejor de las suertes.

+1

+1

+1 para soporte de agregación de tipo anidado

+1

+1

+1

+1

+1

+1

Para aquellos que buscan hacer agregaciones simples en campos específicos dentro de los documentos anidados (por ejemplo, una agregación de "términos" en un campo para encontrar los valores principales), puede considerar agregar la configuración "include_in_parent" a su mapeo de Elasticsearch. Esto crea una versión plana de un campo en el documento anidado en el nivel principal.

https://www.elastic.co/guide/en/elasticsearch/reference/1.7/mapping-nested-type.html
screen shot 2015-06-15 at 10 38 53 am

Estos campos no aparecerán en la lista de campos Descubrir en el lado izquierdo, aunque los verá en la vista de detalles del documento como un campo de matriz. Sin embargo, tendrá acceso a los campos individuales en la lista de métricas en Visualize y podrá ejecutar agregaciones en ellos.

Esto es lo que estamos haciendo para visualizar el historial de reproducciones, que se basa en una estructura de documento anidada (consulte "results.actions"):

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

screen shot 2015-06-15 at 11 01 12 am

screen shot 2015-06-15 at 10 52 35 am

screen shot 2015-06-15 at 11 09 26 am

+1

+1

+1

+1

+1

En lugar de otro +1 ... Quizás un resumen de la posición de las agregaciones de tipo anidadas ayudaría.

Llevo 5 días aprendiendo a hacer gráficos bonitos, así que perdóname si algo de esto es obvio.

¿Cuál es el problema?

¿Sigue siendo un problema de consulta de ElasticSearch o Lucene?

No se resuelve mediante agregaciones, pero se resuelve por el hecho de que le permitimos escribir elasticsearch JSON en el cuadro de entrada. No es ideal, pero a menos que elasticsearch amplíe la sintaxis de la cadena de consulta de lucene para especificar campos anidados, es lo mejor que podemos hacer. - comentario de un año de rashidkpc

¿Es posible la reparación de Kibana?

Si ES / Lucene, ¿podría Kibana proporcionar un truco / solución intermedio mientras tanto? Piense en las calzas ES6 y el prefijo CSS del proveedor.

Para mapeo anidado: oportunidad de elegir anidado en el editor (y configurar una ruta ...) para los paneles de Kibana. bobmercer

O:

Usted lee el campo _mapping, por lo que debe saber cuándo un campo en particular está anidado, entonces, ¿no puede aplicar automáticamente la faceta / consulta anidada correcta cuando dicho campo se selecciona en consultas o facetas?
Alex-Ikanow, OP

¿Alguien está pirateando una solución? ¿Alguien con una idea / dirección de dónde piratear?

¿Trabajar alrededor?

¿Alguien ha tenido éxito con nested / include_in_parent? ¿Requiere dynamic: static , dynamic: true . Mis intentos fallaron con 0 resultados. tbragin

¿Alguien tiene ejemplos para el cuadro de entrada JSON mencionado anteriormente por rashidkpc?

Padre / hijo

Este es mi siguiente paso. Estoy seguro de que hay mucho material de referencia en línea para esto, pero no estaría de más consultar ejemplos / tutoriales para esta alternativa.

Sin conocimiento de los aspectos internos de kibana, estoy considerando escribir un proxy REST entre elástico y kibana. Cuando se consulta desde Kibana para un tipo específico dado algunos criterios de búsqueda basados ​​en términos, este proxy primero consulta el tipo principal para encontrar el conjunto de padres que cumplen los criterios de búsqueda (se ajustan a la memoria). Luego, busca todos los elementos secundarios de estos padres y los devuelve a kibana desnormalizados con todos los campos principales agregados. Esto nos permitirá tener un modelo padre-hijo en Elastic Search que evita la explosión del almacenamiento de desnormalizar todo a miles de millones de objetos hijos, y al mismo tiempo graficar los datos basados ​​en campos padres.

Idealmente, esto era parte de Kibana. ¡El mundo no es plano!

+1

+1. Solíamos dividir la pila de funciones o url_args en diferentes campos. Pero esto vino con un estado de clúster demasiado grande y demasiadas acciones de actualización de mapeo. Entonces cambiamos esto a un objeto anidado. Ahora, necesitamos aggs en K4 ...

+1

+1 necesita visualización de agregación padre-hijo.

+1

No crea que todos los usuarios de Elastic que deseen utilizar Kibana lo estén utilizando para el análisis de registros. Tenemos datos extensos, con objetos anidados, poblados en nuestro clúster que nos encantaría poder realizar análisis sin tener que extraer y transformar los datos en otro sistema más.

Es imprescindible poder crear agregaciones anidadas, consultas anidadas e incluso agregaciones anidadas inversas. Cuanto más tiempo pase Kibana sin esta característica, más pronto tendremos que encontrar una alternativa sin usar Elastic / Kibana. Si proporcionar una interfaz de usuario fácil de usar para este tipo de función es la parte difícil, comience proporcionando la capacidad para que sus usuarios proporcionen la consulta json completa para elástico que devuelve los datos requeridos.

+1

De acuerdo con @ppadovani . Estábamos evaluando herramientas de BI y nos hubiera encantado usar Kibana, pero no respaldaba las relaciones en nuestras entidades comerciales sobre las que necesitamos informar y no era lo suficientemente fácil de usar para que un usuario sin conocimientos de tecnología pudiera explorar. Terminamos eligiendo Looker (una GUI para SQL esencialmente). Mirar al observador podría ofrecer algunas ideas de cómo se podría extender kibana para servir a casos de uso más diversos en el futuro.

Decidí mirar el código de kibana 4.1 .. (No puedo usar master ya que solo funciona con 2.x elástico) .. Por favor corríjame si me equivoco, pero parecería un primer paso fácil para hacer algo. Estas líneas:

1) En el área plegable 'avanzada' de una agregación, agregue un campo de texto llamado algo así como 'ruta anidada'.
2) Si el usuario coloca una cadena en ese campo, entonces la agregación en la que está configurada tendrá una agregación anidada antepuesta como esta:
"aggs": {
"2": {
"anidado": {"ruta": "foo"},
"aggs": {
"3": {
"date_histogram": {

Para manejar el caso de múltiples niveles de objetos anidados, puede agregar un + que permite al usuario agregar rutas anidadas adicionales. Además, para manejar el anidado inverso, simplemente agregue una casilla de verificación etiquetada como 'reverso'.

Esto al menos proporcionaría un soporte de agregación "anidado" limitado.

Para el soporte de consultas anidadas, la única solución en la que puedo pensar a corto plazo sería permitir que el usuario ingrese json de búsqueda elástica codificada a mano.

+1

+1 en todo esto y permitiendo al usuario ingresar json de búsqueda elástica codificada

+1

+1

+1. Estaba muy emocionado de usar Kibana para nuestras necesidades de visualización del entorno, pero sin soporte para la visualización de objetos anidados es bastante doloroso usar Kibana para nuestros propósitos allí.

+1, me encontré con esto.

+1

+1

+1

+1

+1

Al menos 82 personas obtienen su "+1" y esto NO es útil.

stop

Estoy totalmente en desacuerdo. Más datos nunca están mal.

Mi equipo y yo estamos trabajando en esto y esperamos tener algo que mostrar al final de la semana.

EDITAR: Consulte mis comentarios en: https://github.com/elastic/kibana/pull/4645#issuecomment -132908544

+1

+1

+1

Hecho y una solicitud de extracción creada aquí:
https://github.com/elastic/kibana/pull/4806

Actualización rápida para aquellos que miran ... esperando en Elasticsearch co. para aceptar el CLA, de lo contrario, creo que es bueno ir.

+1

+1 también

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

Sí, por favor.

+1

+1

+1

+1

La solicitud de extracción contra 4.1 se cierra a favor de esta contra el maestro.

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

Si hay demanda de una versión 4.1 de esto, puedo volver a abrir la solicitud de extracción con el código correcto.

+1

+1

+1

+1

No entiendo qué está bloqueando este tema.
Hay una solicitud de extracción esperando https://github.com/elastic/kibana/pull/5411

Aquí hay gente dispuesta a contribuir. ¿Qué hay que hacer para fusionar este RP?

Definitivamente se necesitan más +1

@ Filirom1 Algunos de nosotros hemos estado

Excelente :-)
Gracias !

Eché un vistazo al número 5411 y, desafortunadamente, no es la dirección en la que queremos ir con esto en este momento. # 5411 implementó una brecha temporal, pero provocó que se rompieran características importantes, como el filtrado y la búsqueda. También hizo que el constructor agg en sí mismo pareciera roto para aquellos que no comprenden la implementación subyacente de las agregaciones anidadas. Después de sentarnos y mirar más a fondo, nos dimos cuenta de que la cantidad de trabajo para respaldar documentos anidados de manera coherente era extensa.

No es que no queramos hacer esto, es que si lo hacemos, queremos hacerlo correctamente, no solo solucionarlo.

Reconocemos que muchos están interesados ​​en visualizar datos relacionales, sin embargo, dadas otras prioridades e inquietudes, no tenemos recursos para dedicar a este proyecto en este momento y no podemos comprometernos a agregarlo a la hoja de ruta en el futuro previsible.

Para su información, esperábamos usar kibana con agregaciones anidadas para análisis internos, pero terminamos con un producto comercial, 'Looker', que se encuentra directamente en nuestros rdbms. Recomiendo encarecidamente que los desarrolladores de Elastic echen un vistazo a lo que han hecho para simplificar la exploración de un modelo relacional, ya que muchas personas sin conocimientos técnicos ahora pueden navegar por nuestra base de datos en vivo para sus preguntas diarias sobre el producto. Evalué una serie de productos y Looker salió a la cabeza, y me encantaría ver una funcionalidad similar en Kibana algún día.

Dado el último comentario de Rashid y la larga espera por esta función, recomiendo que se cierre este problema. Si este problema permanece abierto, entonces solo les da a los usuarios falsas esperanzas de que habrá alguna posibilidad de que esto se implemente en un futuro cercano. Cerrémoslo y analicemos la idea hasta que los desarrolladores tengan los recursos para descubrir cómo implementarlo.

Copiando mi publicación de la solicitud de extracción:

Hay una solución aquí, pero requeriría una cantidad significativa de trabajo y simplemente no tengo el tiempo. Implementamos esto en JAVA, así que sé que es posible.

1) Cada mapeo de índices necesita extraer y comprender los campos anidados.
2) Cree un AST personalizado que proporcione un lenguaje de consulta simplificado en lugar de intentar usar Elasticsearch.
3) Cree un adaptador de consultas que comprenda el AST y pueda validar y convertir la consulta al JSON adecuado.
4) Actualice las agregaciones en Kibana para manejar correctamente los campos anidados según la comprensión interna de los campos anidados.

Esto no es imposible de hacer, solo requiere un trabajo significativo. Los beneficios de implementar lo anterior incluyen la validación de consultas y una sintaxis simplificada. Por ejemplo, nuestro AST nos permite crear una consulta como esta:

(owner.user = "/ users / 00a0 / 18066271-29f0-40af-83ad-e5a0c8fc5944") AND (druid = "/ druids / 0060 / 77dd14b1-b7f0-4851-9ef8-74daa18d9d4d") Y ((owner.lastMessageReceived. insertado> = 0) O (conversionLifecycleState = "RESERVATION_REQUEST")) AND (owner.conversationArchived = false) AND ((units.site IS NULL) OR (units.site IN {"HOMEAWAY_DE"})) Y ((query.inserted > = 0) O NO (booking.availabilityStatus = "DELETE")) Y NO (owner.markedSpam = true) Y (lastMessage.inserted> = 0)

¿Cómo exactamente podría hacer esta consulta con el idioma existente?

En mi humilde opinión, esperar el nirvana de Elasticsearch antes de actuar provocará una caída en la adopción y la pérdida de usuarios de Kibana.

Odio sonar como si estuviera haciendo marketing, pero esto es relevante. (visto gente mencionar otros productos ..)

Descubrimos que muchas personas que usaban mucho el anidamiento querían buscar datos relacionales y terminaron anidando registros que, en su lugar, deberían haberse "unido" tarde. (Padovani, este podría ser su caso, veo "usuarios", "mensajes", etc. Estos se guardarían muy bien como registros separados)
Esta es la razón por la que creamos el complemento Elasticsearch de SIREn Join y el Kibi, nuestro amigable bifurcación Kibana, que ofrece filtros y funcionalidades para esto.

Ahora estamos trabajando para convertir Kibi tanto como sea posible en complementos compatibles con Kibana 4.4 (también conocido como 5.0) para el beneficio de todos.

El complemento Join se lanzó ayer y también es de código abierto.

Mientras tanto, la versión disponible http://siren.solutions/kibi funciona francamente como un encanto y muchos de nuestros clientes ya no necesitan datos anidados.

jccq: Nunca supe de Kibi o el complemento de unión. Gracias por la info!

+1

+1
este es un problema imprescindible ...

@jccq Nuestro caso de uso no se trata de unirse solo para consultas, usamos la entidad 'unida' o 'vista' como la llamamos como datos de entidad verdaderos con su propio ciclo de vida. Esto permite a los clientes extraer los datos combinados sin tener que realizar varias llamadas GET a nuestra API.

En términos de soporte anidado en Kibana, estamos evolucionando nuestro enfoque y es posible que tengamos algo que compartir con la comunidad en algún momento del segundo trimestre o antes, dependiendo de los recursos y el tiempo. Este nuevo enfoque admitiría anidado sin problemas tanto en las agregaciones como en las consultas. No diré más, ya que todavía se encuentra en etapas muy tempranas de implementación.

+1

@ppadovani ¡ tú eres el

+1

+1

+1
Es muy importante para nosotros.
Estamos esperando casi un año para esta función ...

+1

Actualización: No veo que mi nueva sucursal esté lista para comentarios preliminares o pruebas durante al menos un mes debido a mi carga de trabajo. Sin embargo, quería presentar lo que estoy haciendo para recopilar comentarios de la comunidad a medida que avanzo.

El diseño básico gira en torno a dos cosas:

1) Un nuevo analizador de consultas para el campo de consulta de forma libre de Kibana. Este analizador usa la definición de sintaxis estándar de Bison (vea el proyecto Jison para la versión de javascript que estoy usando). El BNF que estoy usando se basa en el BNF existente que usamos en Homeaway para nuestro lenguaje de consulta personalizado contra Elasticsearch. Vea mi comentario de arriba para ver un ejemplo. Elegí este enfoque para permitir futuras mejoras por parte de la comunidad según sea necesario.

Tengo el analizador de consultas funcionando en Kibana, pero todavía tengo trabajo por hacer para permitir que el usuario cambie entre el estilo de consulta existente utilizado por Kibana y este nuevo estilo:
image

2) Cambie la llamada getFieldMapping en mapper.js para getMapping y procese los resultados de manera diferente, de modo que la ruta anidada en los campos se capture y se agregue a la información de campo que almacena Kibana.

Cuando se escribe una consulta en el analizador, se valida que no solo los campos se hayan nombrado correctamente, sino que los valores proporcionados son válidos para los tipos de campo. Es decir, un campo de fecha obtiene una fecha, o un booleano recibió un booleano. Además, los campos anidados serán manejados automáticamente por el analizador y se generará el json de consulta de Elasticsearch adecuado en lugar del lenguaje de consulta simple que se usa ahora.

Finalmente, para las agregaciones, dado que los campos ahora contienen las pistas sobre las rutas anidadas, será trivial trabajar contra mi rama anterior para inyectar automáticamente las agregaciones anidadas según sea necesario en función de los campos seleccionados.

Hitos:
1 - Hacer que el analizador sea funcional y generar consultas
2 - Actualice mapper.js e implemente el soporte de consultas anidadas
3 - Implementar el soporte de agregación anidada
4 - Prueba / limpieza

Cualquier comentario sobre este enfoque será muy apreciado. ¡Gracias!

Actualización sobre lo anterior:

  • Analizador completo
  • Analizador inverso completo (toma un json de elasticsearch y lo convierte de nuevo al lenguaje de consulta personalizado)
  • Kibana ahora descubre y guarda rutas anidadas en campos
  • Los analizadores ahora tienen acceso a la información del campo

Todavía por hacer:

  • Soporte de ruta anidada en ambos analizadores
  • Construcción de interfaz de usuario para permitir al usuario cambiar qué estilo de consulta debe usarse y permite guardar / usar consultas heredadas.
  • finalizar el manejo de errores en analizadores y cómo la interfaz de usuario muestra problemas / errores de análisis
  • Construcción de interfaz de usuario para proporcionar soporte de escritura anticipada para nombres de campo en la consulta
  • soporte anidado en cubos / métricas
  • pruebas unitarias, pruebas unitarias, pruebas unitarias.
  • ...?

+1

Actualizar:

  • El analizador maneja / inyecta automáticamente información anidada
  • Las agregaciones ahora manejan / inyectan automáticamente información anidada

HACER:

  • Cambios en la interfaz de usuario para la selección del estilo de consulta y guardar la selección del estilo con la consulta en el índice de kibana.
  • manejo de errores para los errores del analizador y cómo la interfaz de usuario muestra problemas / errores de análisis
  • Compatibilidad con el tipo de interfaz de usuario anticipada para la creación / escritura de consultas
  • pruebas unitarias, pruebas unitarias, pruebas unitarias ...

Plan:
Quiero obtener al menos algo de progreso en el trabajo de la interfaz de usuario, no en mi punto fuerte, luego enviaremos una rama / bifurcación al repositorio de github de HomeAway para permitir comentarios / contribuciones. Volveré a publicar aquí cuando esté hecho para que cualquiera de ustedes que quiera tirar del tenedor y jugar con él sea más que bienvenido. Una vez que esté lo suficientemente pulido, crearé la solicitud de extracción oficial.

Una nota final: este trabajo se está realizando en la rama Kibana 4.3.1.

Como continuación de mi comentario anterior sobre el uso de "include_in_parent" e "include_in_root" para copiar campos seleccionados de documentos anidados al nivel superior con el fin de ejecutar agregaciones en ellos, en ES 2.0 se introdujo la funcionalidad "copy_to" que proporciona otra opción para este tipo de cosas: https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html
Se habla de desaprobar "include_in_parent" e "include_in_root" a favor de "copy_to" en una futura versión de ES: https://github.com/elastic/elasticsearch/issues/12461 Si tiene experiencia con ambos, no dude en pesarse.

+1

ppadovani, aprecia lo que estás tratando de hacer. Esta característica es muy importante para nosotros.
Unas cuantas preguntas:

  1. ¿Entiendo que esto llevará tiempo? ¿Hay un tiempo estimado en que esta función estará disponible?
  2. ¿Alguien ha probado alguna alternativa? ¿Como cambiar el formato de registro de json anidado (matrices) a otra cosa? Si es así, ¿cuál debería ser el formato previsto para trabajar con ELK?
  3. ¿Existe algún otro producto en el mercado que pueda ayudar a lograr esta funcionalidad? Estoy totalmente a favor de ELK porque es de código abierto, pero hasta que no lo sea, queremos algo más barato que Splunk. Exploramos muchas opciones, como Loggly, sumologic, logentries, logscape, graylog (ya sea tan caro como splunk o no tienen esta funcionalidad)

¡Muchas gracias!

  1. ¿Alguien ha probado alguna alternativa? ¿Como cambiar el formato de registro de json anidado (matrices) a otra cosa? Si es así, ¿cuál debería ser el formato previsto para trabajar con ELK?

Puede aplanar el esquema o utilizar las opciones de mapeo ES "include_in_parent" o "copy_to" para copiar algunos de los campos de los documentos anidados a los documentos principales. No funciona para todos los casos de uso, pero en algunos casos esto le permitirá usar Kibana de fábrica. Usamos el enfoque "include_in_parent" internamente en Elastic.

  1. Tengo una rama que 'funciona', pero necesita más TLC en forma de trabajo de interfaz de usuario. Este no es mi trabajo principal, por lo que solo puedo trabajar en él si tengo tiempo.
  2. Como indica @tbragin , puede aplanar los datos. Sin embargo, esto puede dar lugar a resultados de consulta no válidos.
  3. No tengo conocimiento de ninguna alternativa en este momento.

Para ser más claro en cuanto a cómo se ve el lenguaje de consulta, ya que me preguntaron en mi solicitud de extracción anterior, aquí hay un resumen de BNF:

Comparación: campo [=, <,>, <=,> =, ~ =] valor
Tenga en cuenta que ~ = .. esto indica LIKE, que a su vez provocará una consulta comodín
IN: campo IN {valor, valor, ...} Establecer operación
campo IN [valor, valor] Operación de rango usando [] o () dependiendo de inclusivo / exclusivo
ES: el campo ES NULO
expresión: IS | IN | Comparación
NO: NO expresión
Y | OR: expresión Y |
EXISTS: EXISTS expresión
Existe es la forma en que ocurre el alcance de anidado. Normalmente, sin utilizar EXISTS, todas las expresiones que están una al lado de la otra y tienen la misma ruta anidada se combinarán en la misma consulta anidada. Sin embargo, puede dividir el bloque de consultas anidadas utilizando EXISTS para abarcar consultas anidadas particulares entre sí.

Como se indicó anteriormente, el lenguaje usa JISON, un equivalente de BISON de javascript, y nos permitirá extender el lenguaje según sea necesario con muy poco esfuerzo.

ACTUALIZAR:

Creo que estoy cerca de poder compartir una rama con todos para probar y proporcionar comentarios. Tengo el (los) analizador (es) funcionando y al menos la retroalimentación de sintaxis funciona, así como las pruebas unitarias contra el analizador. Algunas capturas de pantalla:

image
image
image

Espero tener la rama lista a finales de esta semana. Cuando lo tenga listo, lo vincularé a una publicación de blog aquí que se vinculará a la sucursal y tendrá un resumen completo de la sintaxis, el uso, etc. Mi plan es recopilar comentarios sobre la sucursal, solucionar problemas, mejorar según lo solicitado y luego obtener una solicitud de extracción enviada.

Me gustaría probarlo (aquí hay un ejemplo de nuestro uso de agregaciones anidadas en K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523, no migrará sin él).

@Robitx No creo que eso sea un problema ... tenemos documentos que tienen al menos dos niveles de objetos anidados ... por ejemplo:

A-> B-> C

Donde un solo documento A puede tener una o más B, y cada uno de ellos contiene una lista de C que están en B. Cada documento anidado tiene múltiples campos de diferentes tipos. He probado este código de modo que puedo crear un histograma o un gráfico circular de varias capas con los datos anidados más internos.

Para ser claros, nuestros mapeos se generan automáticamente a partir de nuestros pojos y pueden volverse muy complejos.

+1

ACTUALIZAR:

Quería sacar esto para que la gente comenzara a jugar en lugar de esperar a que apareciera una publicación oficial de mi parte.

Fork / Branch se puede encontrar aquí:

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

LÉAME:

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

El contenido del README es esencialmente el contenido de la publicación del blog que aparecerá en algún momento.

No dude en abrir problemas / solicitudes de extracción contra la rama fullNestedSupport si así lo desea. Intentaré estar al tanto de cualquier problema que la gente encuentre.

+10000

+100500

+100

Hola ppadovani,

¿Podrías darme un consejo? ¿Qué debo hacer?

Este campo está presente en su asignación de elasticsearch pero no en ningún documento en los resultados de búsqueda. Es posible que aún pueda visualizarlo o buscarlo.

¡Muchas gracias!

Hola ppadovani,

Tenemos un campo como matrices anidadas.
"abc": [["3815222235847451", "131712121218083052"]]
O
"abc": [["3815222235847451", "131712121218083052", "131712121217783052"]]
O
"abc": [["3815222235847451"]]

Los valores pueden ser de 1 a 10

Mientras que para otros campos anidados veo una advertencia de que el campo no está indexado (¿que supongo que necesito usar asignaciones?) Para este campo y otros como estos, ¿cada conjunto se trata como un valor separado? Además, el tipo de campo se muestra como "cadena" en lugar de número, lo que no es un problema en sí mismo, pero ¿qué significa que no puedo buscar ningún valor individual de abc ..?

¡Muchas gracias!

Encontré unos minutos para comenzar a probar :): |

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) - No creo que sea un mensaje generado por mis cambios, y puede ser algo que existía antes en Kibana.
2) - Entonces sí ... parece que los valores están almacenados como una cadena, pero posiblemente no estén anidados ... Tendría que ver cómo se ve el mapeo en el índice para entender qué / si existe el problema. Pegue el mapeo aquí.

@Robitx
Supongo que este era un campo de fecha ... el tiempo de época tiene demasiados dígitos debería ser 10, no 13. ¿Puede actualizar / pegar la consulta que emitió?

@ppadovani
Acabo de elegir el patrón de índice predeterminado en la configuración y volví a descubrir la pestaña

Usamos

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

K 4.4.1 + ES 2.2 funciona bien, podría ser específico de K 4.3 (no he probado esta versión antes)

@Robitx
Estoy buscando la consulta utilizada ... ¿o está diciendo que la consulta aprobada fue solo la ventana de fecha estándar de la interfaz de usuario y no especificó una consulta? Rebasaré mis cambios con una versión posterior de Kibana y volveré a publicar cuando se actualice la rama.

@ppadovani sí solo * y algún intervalo de tiempo

+1 para objetos anidados en la sección de visualización

@Robitx
Esa operación que ejecutó nunca llegó a ninguno de los códigos de mi analizador ... así que dudo que se deba a algo que hice ... Mi configuración es K 4.3.1 + ES 2.1.1 - Actualizaré mi ES a 2.2 y ver si obtengo el mismo comportamiento, luego cambiaré la base de la rama a K 4.4.1

Acabo de actualizar a ES 2.2.1 con K 4.3.1 + mi código ... no se pudo reproducir:
image

Seguiré cambiando la base a 4.4.1, la versión actual, actualizaré esta publicación cuando la rama esté lista.

ACTUALIZAR:

Rebasado a 4.4.1 en una nueva rama: https://github.com/homeaway/kibana/tree/nestedSupport-4.4.1

Probado en ES 2.2.0 y K 4.4.1

Hola ppadovani,

Con respecto a mis preguntas anteriores, las dejaré. Ya tengo una instancia de búsqueda elástica en AWS (junto con asignaciones) y estoy tratando de conectar esto a eso. Sin embargo, el estado del servidor kibana en la interfaz de usuario dice:

complemento: elasticsearch Esta versión de Kibana requiere Elasticsearch ^ 2.1.0 en todos los nodos. Encontré los siguientes nodos incompatibles en su clúster: Elasticsearch v1.5.2 @ undefined (undefined)

Sigo usando https://github.com/homeaway/kibana/tree/fullNestedSupport y no el último proporcionado por usted. ¿Es posible que lo haga compatible con 1.5.2?
Consejos amablemente.

¡¡Muchas gracias!!

@ppadovani
Puedo entender si esto puede no ser posible, ya que estamos retrocediendo, sin embargo, Amazon Elasticsearch Service no está muy interesado en actualizar a versiones más nuevas, lo cual es comprensible. Entonces, tengo que trabajar con lo que sea que tengamos. Hemos invertido muchos esfuerzos en la configuración de la instancia de AWS (junto con el reenvío de registros desde múltiples nodos, eventos de transmisión y otros detalles minuciosos) y reinventar todo en una plataforma separada desde cero no es una opción para nosotros. Sería bueno poder conectar esto como una interfaz adicional. Ni siquiera estoy seguro de si habrá otro obstáculo en el camino.

¡¡Gracias!!

@BigDataEngineer
Después de mirar el código de Kibana en versiones anteriores, la primera versión a la que pude probar y aplicar los cambios es 4.1.6. Sin embargo, hubo una reescritura / refactorización / reorganización significativa del código y no puedo simplemente parchear esa rama. Se necesitaría una gran cantidad de trabajo para intentar que mi código funcione.

Honestamente, no sé por qué los equipos de Kibana mejoran la versión elástica requerida como lo hacen con cada lanzamiento ... la interfaz REST simplemente no cambia tan a menudo. Especulo que lo hacen para obligar a los usuarios a actualizar sus clústeres elásticos.

Un pensamiento, puede intentar cambiar la versión en src / plugins / elasticsearch / index.js alrededor de la línea 27

@ppadovani
funcionó. Gracias.

+1

@ppadovani Hola, gracias por actualizar a la versión 4.4.1, perdón por no responder antes (me perdí tu actualización en uno de los comentarios anteriores).

Está funcionando ahora, pero lo primero que noté son problemas de rendimiento y, ocasionalmente, kibana se congela por completo (no he podido probar consultas más complicadas).

Hay pocas cosas que podrían contribuir a este problema, una de ellas es una serie de campos en nuestro índice diario (hay cientos de ellos http://pastebin.com/fktN0dR5).

@Robitx ¿Tiene estos mismos problemas con el código base 4.4.1 K sin mis cambios? ¿O es solo con mis cambios? Sé que los patrones de índice muy grandes causan problemas de rendimiento significativos para K. Si es solo con mi código, entonces creo que sé lo que podría ser. Lo echaré un vistazo cuando salga a tomar aire en un día o dos.

@ppadovani la base K 4.4.1 no tiene este problema

Un año desde que este problema no se solucionó ...

Maldita sea, elasticsearch tiene una característica bastante necesaria "Objetos anidados", y Kibana de los mismos desarrolladores aún no tiene soporte para esta característica.

Tiene una bifurcación que ya implementa esta función y aún no se fusionó en el código fuente principal, con el soporte adecuado.

Y todavía no podemos utilizar en nuestro proyecto la versión de stock de KIbana con el soporte de "Objetos anidados".

¡Jodidamente increíble!

@ppadovani muchas gracias por tu trabajo en fork =)

@Robitx ¿Puedes decirme cuando Kibana se congele? Definición de IndexPattern? ¿O cuando está iniciando una nueva consulta? Hay áreas posibles en las que esto podría ocurrir, y quiero reducirlo.

Solucioné un problema que podría haber contribuido al abrir las pestañas de descubrimiento / visualización ... He enviado una solución, vuelva a probar.

@rashidkpc Estoy listo para generar una solicitud de extracción basada en este trabajo. ¿Puede decirme en qué rama debería reafirmar mi trabajo? Actualmente lo tengo contra 4.3.1, 4.4.1 y 4.x. (4.x está cerca, pero tengo problemas para ejecutar las pruebas unitarias. El clúster de prueba no se inicia ...)

Hey pandilla (cc @ppadovani)

Como mencioné en https://github.com/elastic/kibana/pull/5411, hay una serie de limitaciones en el propio Elasticsearch, en particular que los aggs / filtros anidados no son automáticos y la sintaxis de consulta lucene no admite la búsqueda anidada. Si bien el enfoque adoptado aquí trazaría un camino diferente para resolver el problema, no es la dirección que queremos ir. Esta es una solución a un problema limitado, pero queremos que Kibana resuelva una amplia gama de desafíos. En este caso, eso significa sacrificar ganancias más pequeñas por ganancias más grandes en el futuro.

Mientras estamos considerando las posibilidades de un idioma para Kibana, no hemos decidido exactamente qué queremos que sea el conjunto de funciones y no queremos hacerlo a mitad de camino, o con un solo objetivo en mente. Estamos considerando algunas tácticas y conjuntos de funciones, tanto en Elasticsearch como en Kibana, pero todavía estamos en las etapas de formación. Con el tiempo, nos gustaría que esto incluyera búsqueda, transformación y visualización, como puede ver en algo como timelion, y ciertamente tendremos en cuenta la idea de consultar documentos anidados mientras lo hacemos.

Noté que esto almacena la ruta anidada, sin embargo, estamos eliminando el mapeo en caché https://github.com/elastic/kibana/pull/6648 y reemplazándolo con nuevas API en Elasticsearch: https://github.com/elastic / elasticsearch / issues / 15728. Tenga en cuenta ese problema, sería genial si Kibana no necesitara analizar la ruta anidada. Esto es especialmente importante para nuestro objetivo de hacer accesibles documentos muy grandes en Kibana.

Por ahora, recomendamos tomar el enfoque de @ tbragin usando include_in_parent o copy_to . Para el 90% de las agregaciones, este enfoque funcionará perfectamente.

Me alegro de que esta solución funcione para aquellos que no pueden usar include_in_parent o copy_to , muy impresionados con lo que @ppadovani ha logrado. Me encantaría ver algo como esto implementado como complemento. En este momento, la entrada de la consulta esencialmente toma 2 tipos de consultas de todos modos, probablemente podríamos encontrar una manera de hacerlo conectable.

hey, interviniendo. Charlé con Rashid sobre esto, y aunque siento el dolor de que los usuarios quieran usar Kibana para mapeos anidados, admitirlo de una manera más general (que podría implicar características adicionales en el nivel de Elasticsearch) es el camino a seguir. que mantiene la flexibilidad que necesitamos tener en Kibana. Si bien obtener este cambio sugerido podría resolver el problema a corto plazo de no admitir anidado, resultará problemático en el futuro.

Me dirijo y siento la necesidad aquí de que Kibana soporte anidado, pero este es uno de esos casos en los que si no es obvio cómo debe resolverse, es mejor dejarlo sin resolver hasta que tengamos una solución que se sienta natural. Definitivamente necesitamos continuar y explorar que, uno de esos, que conversamos en diferentes lugares, es automáticamente compatible con anidado (envoltura, etc.) en el propio ES.

Estoy lleno de emoción al ver esto elegantemente resuelto.

+1

+1

En mi humilde opinión, debo discrepar respetuosamente con la postura de los mantenedores de Kibana. Sin embargo, si podemos encontrar una manera de hacer algo similar a la conexión a Kibana, estaría totalmente de acuerdo.

Mientras tanto, continuaré manteniendo y corrigiendo errores en mis bifurcaciones / ramas para aquellos que deseen continuar usando la versión que he creado. Sé que usaremos esto ampliamente para paneles analíticos de BI en vivo en el futuro.

Vacas. No mascota.

+1 :)
¡¡Podría ser genial usar objetos anidados en Kibana !! (¿Alguien tiene un complemento para eso o no? ...)

+1

+1

+1

@tbragin El enfoque que mencionaste no funciona en tipos anidados. Agregará todos los datos independientemente del tipo.

+1

+1

+1

+1

Esta función es tan obvia que me sorprendió descubrir que no solo no es compatible, sino que los desarrolladores aparentemente no tienen planes de admitirla. Demonios, hable con sus gerentes de proyecto y contrate a @ppadovani para hacer un complemento si ustedes no lo hacen ustedes mismos.

+1 ya que la falta de objetos anidados dificulta sustancialmente mi proyecto

Para cualquiera que busque una discusión sobre la desnormalización como una forma de eludir este problema: Cómo evitar el soporte que falta en Kibana para objetos anidados y padre / hijo

Elastic sería genial si hubiera un descargo de responsabilidad en el sitio con respecto a este problema para evitar que los usuarios pierdan el tiempo tratando de implementar una función no compatible. ¿Por qué? La página del producto de Kibana dice "Integración perfecta con ElasticSearch", lo cual no es cierto aquí :)

Para su información: la rama de mi código a la que se hace referencia en la discusión anterior es antigua ... la rama actual es:

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

Lo estamos utilizando activamente internamente y continuamos actualizando nuestra versión interna. Puedo / actualizaré la versión de github si hay interés.

Pierre

+1

+1

+1

+1

+1

+1

Recuerdo haber hecho +1 en esto hace más de un año, y desde entonces el equipo de desarrollo de Kibana no ha hecho más que cavar en sus curaciones y en su mayoría ignorar a los usuarios y, finalmente, cuando les ponen los pies en el fuego, responden con un más o ... menos "NO", indicando que "no se siente natural".

También veo este patrón en muchas otras características solicitadas, como:

  • Soporte para llamar a scripts maravillosos del lado del sistema operativo.
  • Soporte para poder usar agregaciones de métricas con guiones de ES (especialmente útil para calcular promedios ponderados).
  • Etcétera...

Todo esto va en contra de la postura de toda la visión de Elastic Stack 5 que se afirmó que ellos (Elastic) apoyarían más características subyacentes de Elasticsearch en Kibana. Pero he visto muy poco que respalde estas afirmaciones.

Como resultado, veo que Kibana pierde terreno frente a bifurcaciones como Siren's Kibi, que decidió tomar la antorcha en elementos como este tema y encontrar una solución.

Agradezco a los desarrolladores de Kibana por brindarnos una excelente herramienta de visualización. Pero Elastic debe decidir en el futuro si Kibana debe seguir siendo una herramienta de visualización simplista o escuchar a la comunidad y expandir su utilidad. Si la decisión es la primera, espere que los usuarios se vayan cuando otros decidan aprovechar estas deficiencias.

+1

@cslinuxboy

Soporte para llamar a scripts maravillosos del lado del sistema operativo.

La mayoría de los casos de uso cubiertos por esto serán resueltos por https://github.com/elastic/kibana/pull/7700.

Soporte para poder utilizar agregaciones de métricas con script de ES

No creo que nadie esté en contra de esto (al menos, no veo ninguna oposición aquí https://github.com/elastic/kibana/issues/2646), de hecho, ahora es el momento de agregarlo ya que Elasticsearch ha agregado el lenguaje de secuencias de comandos indoloro. Realmente es solo una cuestión de que alguien encuentre el tiempo.

+1

+1

+1

Estoy empezando a trabajar en mi tenedor de nuevo. Deseo disculparme con la comunidad, no tenía idea hasta hace aproximadamente un mes de que no había activado los problemas de la bifurcación, por lo que nadie habría podido indicar que había errores. Eso ha sido rectificado.

Rama actual: https://github.com/homeaway/kibana/tree/nestedSupport-4.5.4

Las actualizaciones en el orden en que pretendo implementarlas:

  • Agregue soporte para desplazamientos de fecha al analizador de consultas
  • Agregue soporte al descubrimiento de campos anidados al mirar un resultado: HECHO
  • Agregue soporte para consultas y agregaciones de padres / hijos
  • Agregue soporte para tipos de formas geográficas para consultas (es decir, punto, cuadro, etc.). Este es un puerto de una mejora reciente de nuestro lenguaje interno.
  • Agregar escritura anticipada para nombres de campo en el campo de consulta
  • Podría intentar crear un analizador para el lenguaje de consulta simple de Elasticsearch existente para solucionar la molestia de una consulta no válida que hace que Elasticsearch devuelva un seguimiento de pila o que no se devuelvan resultados sin indicación de por qué. Si trabajo en esto, será después de haber completado lo anterior. Si hago esto, buscaré agregar manutención anidada y para padres / hijos al idioma en el lado de Kibana.

Deseo sumar mi voz a las que han indicado que el equipo de Kibana no está escuchando a la comunidad. El equipo de Kibana NO PUEDE simplemente confiar en Elasticsearch para proporcionar la funcionalidad necesaria si hay una brecha para mantener Kibana "puro". La cuota de mercado no se gana de esa forma, se pierde.

+1

+1
@Bargs : ¿Algún progreso en este tema? ¿Cuándo se abordará / priorizará esto?
Hilo muy largo ... Esto no es bueno para productos como kibana ...
Agradecemos tus esfuerzos

Esto apesta :-(

homeway ha anidado aggs & query support build en Kibana 4.3.1 compruébalo ... espero que esto te ayude ...

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

@ankitchheda Lo sé, pero una bifurcación mantenida por pocas personas que va en contra de la filosofía del proyecto principal (que está en un gran desarrollo) no es una solución, pretender que no ayudará a nadie.

Me gustaría hacer algo al respecto, pero no tengo tiempo, así que por ahora al menos trato de aplicar presión y espero que los desarrolladores dejen de ignorar este problema: |

+1

FYI: la bifurcación que mantengo para el soporte anidado, ahora tiene soporte para las siguientes versiones:

4.5.X
4.6
4,7
5.X

Puede que no siga la 'filosofía' de los desarrolladores principales, pero funciona y funciona bien.

Me acabo de encontrar con esto. Es un pequeño inconveniente y sería realmente útil tener una solución viable.

@tbragin , @rashidkpc - la solución alternativa propuesta pierde el punto - usted obtiene
algo con objetos anidados, ¡pero obtiene resultados incorrectos! Anidado
las agregaciones dan resultados diferentes (haré un pequeño ejemplo trabajado y lo publicaré aquí más adelante).

Probaré la bifurcación de @ppadovani.

+1

: tortuga :: guión:

@Bargs Hey, ¿los cambios de la bifurcación perjudican el rendimiento de la funcionalidad básica?

+1

+1

+1

+10086

+1

+1

+1

include_in_parent todavía funciona en ES y Kibana 5.2? Traté de usarlo como alternativa sin éxito.

@gustavomr Creo que funcionará, pero solo para ciertos casos de uso. No funcionará para todos los posibles casos de uso de consultas que pueden proporcionar las consultas / agregaciones anidadas.

NOTA: Mi bifurcación 5.1 de Kibana ahora usa un interruptor junto al ícono de búsqueda para cambiar entre el lenguaje de consulta simple elástico nativo y el lenguaje de consulta anidado que he incluido. También solucioné una variedad de problemas relacionados con las métricas de los campos anidados.
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovani muchas gracias por hacer esto. ¿Es posible separar su trabajo habilitando objetos anidados en kibana de su trabajo creando un nuevo lenguaje de consulta? Si estas pueden ser ramas separadas, entonces podemos usar la primera y fusionarla con las versiones más nuevas de kibana a medida que surjan en lugar de tener que fusionar ambas características.

Además, ¿ya tiene una ventana acoplable creada para esta bifurcación?

@ppadovani +1 para el contenedor de la

@gkozyryatskyy : abre un problema en la bifurcación y lo

@ imranq2 : podría hacer esto, sin embargo, tenga en cuenta que el lenguaje de consulta elástico simple no admite consultas anidadas. Si tiene datos anidados y desea consultarlos, tendrá que crear manualmente la consulta como un blob json de elasticsearch y pegarlo en el cuadro de consulta.

+1

Mi bifurcación ahora admite 5.2 en la rama nestedSupport-5.2.

@ppadovani ¡ Eso es genial! Avíseme si necesita ayuda para hacer un contenedor Docker para esto.

No he terminado el contenedor de la ventana acoplable, pero tuve algo de tiempo para jugar con la pestaña de descubrimiento y cómo muestra los datos anidados ... en busca de comentarios de aquellos que están monitoreando el problema de soporte anidado. La tabla es recursiva y los filtros para campos anidados parecen funcionar bien ... pero el campo de alternancia en la columna aún no funciona ... Todavía necesito pensar cómo / si debería funcionar.
image

Para su información: este trabajo está básicamente completo y todas las bifurcaciones / ramas admitidas tienen los cambios que comienzan con nestedSupport-4.5.4 hasta nestedSupport-5.2

@Bargs : sé que ninguno de los trabajos anidados que he hecho es algo que ustedes
https://github.com/homeaway/kibana/issues/12

Si esto es algo que quieren, hágamelo saber y abriré un problema e incluiré un parche.

¡Parece interesante @ppadovani ! Si desea abrir un PR, definitivamente me interesaría comprobarlo. Hemos hablado un poco sobre cómo agregar un mejor soporte para campos anidados a Discover, por lo que sería genial tener algo concreto para discutir.

@ppadovani Estoy creando un contenedor de http://staging.elastic.co/ $ (VERSION_TAG) / downloads / kibana / kibana - $ {ELASTIC_VERSION} -linux-x86_64.tar.gz? Si es así, puedo meter eso en mi contenedor de la ventana acoplable. De lo contrario, necesitaré construir su rama y crear el tarball.

@ imranq2 No proporciono distribuciones de mi bifurcación, por lo que deberá compilarlo usted mismo.

Para su información: he creado una solicitud de extracción para admitir datos anidados en la pestaña de descubrimiento para aquellos que estén interesados:
https://github.com/elastic/kibana/pull/10814

+1

+1 para mi
+10 para mis compañeros

+1

+1

+1

+1

+1

+1

+1. ¿Es esto compatible con ELK5?

+1

esto es realmente un requisito, ya que no admitir objetos anidados es realmente un impedimento para la amplia adopción de kibana en mi empresa, ya que debe crear un índice para kibana y otro con documentos anidados para búsquedas más inteligentes a través de la API simple.

+1
En mi mapeo evitaría una posible "explosión" de propiedades de índice.

+1

+1

+1

Por favor, deje de publicar comentarios +1 que solo envían spam a todas las personas suscritas a este hilo. En su lugar, haga clic en el gran botón amarillo "Me gusta" en la parte superior de este número para votarlo.

+1

Desarrolladores de Kibana, por favor hagan algo, muchachos. El uso de Kibana sin objetos anidados en muchos casos es inútil. Estás preparando la versión 6.x sin objetos anidados ...

Nuestro sistema escanea texto en busca de casas y luego guarda los resultados en ES. Entonces, ES contiene documentos principales con una variedad de casas. La casa son los objetos anidados.

No puedo usar la visualización para crear un tablero con análisis de casas que encontramos en texto.
Haz algo por favor. Las casas están en llamas.

Necesito desesperadamente usar objetos anidados en kibana. Se siente mal que esto no esté disponible integrado.

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


Still D.R.E.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

otro aqui!

Para aquellos que pueden haber usado mi bifurcación de Kibana con soporte anidado, suspenderé el soporte para esa bifurcación después de la versión 5.4.x de Kibana. En su lugar, moveré la mayor parte, si no toda, de la funcionalidad a un complemento de Kibana. Espero tener el complemento listo para la última versión 5.x antes de fin de año. Puede seguir el progreso aquí: https://github.com/ppadovani/KibanaNestedSupportPlugin

Acabo de comenzar el trabajo, así que no espere que aparezca nada significativo durante algunas semanas.

+1

+1

+1

+1

+1

Tengo capturas de pantalla y actualizaciones de estado publicadas para el trabajo que estoy haciendo en el complemento de soporte anidado. Mire el problema para obtener actualizaciones de estado.

Capturas de pantalla y actualizaciones

Seguí adelante y lancé una versión preliminar de 1.0.0 con soporte para Kibana 5.6.5.

Consulte este número para obtener detalles sobre el contenido del prelanzamiento inicial: capturas de pantalla y actualizaciones

V1.0.0-beta1

Mi complemento tiene funciones completas para la versión 5.6.5 de Kibana. Tengo algunas tareas de limpieza, luego cortaré la versión 5.6.5 y comenzaré a reenviar a 6.1.X.

Características:

  • Soporte de consultas anidadas
  • Soporte de agregación anidada
  • Descubra los resultados de soporte anidado
  • Descubra la prioridad de visualización del campo de resumen (esto es realmente algo nuevo)

Consulte el archivo README para obtener más detalles.

¡Mi complemento ya está disponible! Soporte para 5.5.3, 5.6.5 y 5.6.6. Estaré portando a 6.0.X este fin de semana.

Es probable que ya no actualice el estado de este tema. Visite mi página de GitHub para ver lanzamientos, problemas, etc.

¡Gracias!

@ppadovani puedes lanzar una versión de soporte para 5.4.0 gracias.

@ppadovani ¡Estaré pendiente del puerto 6.0.x!

@ SolomonShorser-OICR
Lancé una versión 6.0.1 Beta 1.

La única limitación conocida es que la barra de filtro no está operativa debido a que está codificada para funcionar solo con el lenguaje de consulta lucene. Estoy trabajando en una forma de evitar eso, pero es posible que no tenga una solución hasta el próximo fin de semana.

Ahora he lanzado una compilación de complemento para 6.0.1, 6.1.x es el siguiente.

@ppadovani
¡Gracias por su trabajo y la versión 6.0.1!

basado en kibana 6.0.1, después de instalar este complemento, algunas características de kibana no funcionan bien.

al hacer clic en timelion, muestra un mensaje de error:
image

si x-pack está instalado, alguna característica de x-pack "discover" tiene otro mensaje de error en "Foreach"

Hola equipo de Kibana, ¿por qué no contrataste a @ppadovani todavía?

@sccds : mueva este informe de error a mi repositorio de GitHub:

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

Si alguien tiene problemas con mi complemento, abra los problemas en mi repositorio y no inicie una conversación aquí. Este problema tiene demasiados suscriptores.

@Hronom - Aprecio la idea, pero mis puntos fuertes no están en Javascript ... aunque crear este complemento y piratear Kibana ciertamente ha ayudado a mis habilidades en esa área.

Para su información: mi complemento ahora está actualizado con las versiones de Kibana. Lancé el soporte 6.1.2.

Gracias @ppadovani , ¡sigue así!

+1

+1

+1 Hola, Tomitribe está muy interesado en esta función. ¿Sabe cuándo se implementará esta función?

@ppadovani ¿ dónde puedo preguntar sobre la funcionalidad? Estoy luchando con la agregación anidada en la tabla de datos.

@bumerankkk Vaya aquí y abra un problema: https://github.com/ppadovani/KibanaNestedSupportPlugin

Alternativamente, si va a una de las páginas de documentación que se alinea con su pregunta, puede agregar un comentario al final de la página.

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

¿Se está trabajando activamente en esto? ¿Tenemos cronogramas sobre cuándo una característica de este tipo experimentaría un lanzamiento de producción?

Feliz cumpleaños 🎂 'Agregaciones de tipo anidado', 🎁

Ahora ya tienes cuatro años. No hace mucho eras tan pequeño y lindo.
Espero que crezcas y tengamos algunos buenos años en común en el futuro.

mejor Malu

+1

+1

+1

+1

+1

+1

+1

¿Por qué no se ha implementado esto todavía?

Debido a las razones, con esta función, el suero no tendría un hilo, no es divertido y nadie irá al github de la kibana, esta es una especie de baliza.

La última versión de elk admite datos anidados correctamente para mí

El El mié, 6 de junio de 2018 a las 22:08, Eugene [email protected]
escribió:

Por algunas razones, con esta función, el suero no tendría un hilo, no sería divertido y
nadie irá al github de la kibana, esta es una especie de baliza

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
.

@javixeneize Estoy sentado aquí en la versión 6.2.4 , no puedo encontrar el soporte de objetos anidados dat, corrígeme si me equivoco

Tengo esa versión y puedo acceder a ab, donde mi estructura es {Id: xx,
a: {b: xx}}

El El mié, 6 de junio de 2018 a las 22:18, Eugene [email protected]
escribió:

@javixeneize https://github.com/javixeneize Estoy sentado aquí en 6.2.4
versión, no puedo encontrar el soporte de objetos anidados dat, corrígeme si me equivoco.

-
Recibes esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
.

@javixeneize ¿tienes el siguiente mapeo con type : nested ?
Puede obtener el mapeo por GET /index-name

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

Lo comprobaré mañana pero tengo la configuración predeterminada

El El mié, 6 de junio de 2018 a las 22:24, Eugene [email protected]
escribió:

@javixeneize https://github.com/javixeneize ¿tienes el siguiente mapeo?
con tipo: anidado?
Puede obtener el mapeo por GET / index-name

{
"documento": {
"propiedades": {
"ubicaciones": {
"tipo": "anidado",
"propiedades": {
"empezar": {
"tipo": "largo"
},
"fin": {
"tipo": "largo"
},
"normalizado": {
"tipo": "palabra clave"
},
"original": {
"tipo": "palabra clave"
}
}
}
}
}
}
}

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
.

@javixeneize ¡ gracias de antemano!
Probablemente tenga un objeto sub json que se acopló al documento principal, pero este no es un objeto anidado.

Sí, tenga cuidado @javixeneize, sus datos no se correlacionarán como se esperaba a menos que establezca específicamente el mapeo en ES para que ese campo esté anidado

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

Problema principal: cada campo del objeto anidado simplemente se convierte en una matriz y se pierde la correlación entre las propiedades.

Acabo de aplanar mis datos antes de volcarlos en es por ahora.

Si no puede esperar a que Elastic implemente esto, puede usar mi complemento de Kibana:

Visión general:
https://ppadovani.github.io/knql_plugin/overview/
Instalación:
https://ppadovani.github.io/knql_plugin/installation/
Lenguaje de consulta (como SQL):
https://ppadovani.github.io/knql_plugin/knql/

Soporte para 5.5.3 a 6.2.4, si falta una versión, después de 5.5, abra un problema:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Se aceptan contribuciones, solicitudes de funciones e informes de errores.

Ok, tengo que esperar entonces ...

El El jue, 7 de junio de 2018 a las 0:38, Pierre Padovani [email protected]
escribió:

Si no puede esperar a que Elastic implemente esto, puede usar mi Kibana
enchufar:

Visión general:
https://ppadovani.github.io/knql_plugin/overview/
Instalación:
https://ppadovani.github.io/knql_plugin/installation/
Lenguaje de consulta (como SQL):
https://ppadovani.github.io/knql_plugin/knql/

Soporte para 5.5.3 a 6.2.4, si falta una versión, después de 5.5 por favor
abrir un problema:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Se aceptan contribuciones, solicitudes de funciones e informes de errores.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
.

+1

+1

+1

+1

+1

+1

característica muy útil ... +1

Kibana es absolutamente inútil para mis casos de uso sin este soporte. No debería tener que aplanar o reestructurar mis datos. Debería poder introducir datos y sacar visualizaciones o agregaciones. ¿Cuatro años después y todavía no hay soporte para objetos anidados?

¿Alguna estimación cuando esta función esté disponible?

¿Podría alguien de elástico informarnos si esta función se agrega a Kibana? Este boleto está abierto desde hace casi 5 años.

Además, ¿cuál es el punto de lanzar una función de este tipo si no se puede usar en Kibana?

No me malinterpretes, pero se siente un poco extraño.

+1

+1

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

No agregue comentarios como comentarios +1. ¡Especialmente para los problemas que realmente te preocupan! Déjame explicarte, cualquiera que tenga las notificaciones activadas se molestará fácilmente y cancelará la suscripción al hilo. Eso significa que los contribuyentes no verán esto como un tema importante basado únicamente en la cantidad de participantes involucrados. Cuando la gente se da de baja, este número baja.

En cambio, lo que USTED debe hacer es suscribirse al hilo a través del cuadro en la esquina superior derecha y darle al número inicial de Github un pulgar hacia arriba para mostrar su apoyo.

@ bugs181 esto no funciona aquí, este problema es una anomalía y absorbe todas las ondas entrantes, ¡desde hace cinco años!

¡Creo que los científicos deberían explorar este agujero negro!

¡¡¡Los desarrolladores de Kibana parecen tener un poder anormal !!!

@ bugs181 esto no funciona aquí, este problema es una anomalía y absorbe todas las ondas entrantes, ¡desde hace cinco años!

¿Alguna vez pensó que no querían leer todo el número con toneladas de comentarios de "+1 yo también" buscando la información que podría ser valiosa para ellos?

@ppadovani tiene un complemento de código abierto que podría usarse (mira su comentario arriba)

@ mika76
Estoy usando esto.

muy útil en caso simple

@ mika76 solo tenga en cuenta que, debido a limitaciones de tiempo, actualmente no se mantiene de forma activa.

ppadovani comentó hace 28 días
Hola amigos ... He encontrado que mi tiempo está muy limitado debido al trabajo y la vida. Además, aunque pude arreglar las cosas parcialmente, los cambios que hizo el equipo de Kibana al pasar a React requerirán en su mayoría reescribir grandes partes de lo que he hecho.

@ mika76 sí, este complemento es la única forma de conseguir que los objetos anidados funcionen en este momento.
Pero lo que es extraño para mí, Elasticsearch tiene soporte oficial para objetos anidados, pero Kibana no.

Como se mencionó @ bugs181 , actualmente no se mantiene activamente y esto significa que no puede actualizar a la última versión de la pila ELK.

Entonces, el apoyo oficial también significa un mantenimiento adecuado. Pero debido a que los desarrolladores están escupiendo sobre este tema, no tenemos soporte oficial para esto.

Debo segundo @ bugs181 aquí. Hacer +1 en este problema y enviarlo spam no ayuda mucho a crear conciencia sobre esto, pero solo hará que la gente lo silencie o nos acerque al punto en el que tendré que bloquearlo, lo que realmente no hago. No quiero, porque me gustaría mantener todos los temas abiertos a la discusión de todos, ya que creo en la comunicación abierta.

Hasta ahora también siempre recomendé usar ese complemento. No sabía que esto ya no se mantiene activamente y me entristece escuchar eso. También sabemos que este problema ha estado abierto durante 5 años, y estamos analizando los problemas (obviamente en Kibana, vea la captura de pantalla adjunta) y sabemos que estos son los problemas con más reacciones:

screenshot-20190319-185201

Pero como ya sabe, hay (literalmente) miles de otros problemas abiertos, por lo que siempre debemos equilibrar las funciones, la corrección de errores, etc. para encontrar una buena priorización. Además (pero no solo) debido a que esa función siempre tuvo un complemento de comunidad de trabajo bastante sólido, hasta ahora no ha tenido suficiente prioridad (para superar otros problemas). Además, como ocurre con tanta frecuencia, a menudo hay una relación técnica entre diferentes cosas y, por ejemplo, para los soportes de campos anidados, actualmente queremos terminar primero nuestra revisión de toda la canalización de representación de visualización (# 19813), antes de comenzar esto, ya que está muy vinculado juntos. Sin embargo, actualmente tenemos este problema en nuestra hoja de ruta para 7.xy, con suerte, no será bloqueado por otros cambios técnicos, por lo que pronto podremos mover esa función al núcleo de Kibana para que esté disponible sin un complemento de la comunidad.

¿La solicitud para admitir visualizaciones de objetos anidados incluye compatibilidad para relaciones entre padres e hijos? Tengo un cliente que pregunta sobre visualizaciones de padres e hijos.

Es un problema realmente importante, ya que no podemos mostrar las relaciones 1: M correctamente en Kibana, ya que ElasticSearch admite objetos anidados, por lo que podemos cargar datos pero no podemos verlos correctamente. Esto debe solucionarse pronto.

Gracias,
Rakesh

Comencé a trabajar en el soporte de campo anidado en KQL hoy. Se creó un problema separado para realizar un seguimiento, ya que el soporte de campo anidado completo en Kibana implica muchos cambios más allá de KQL.

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

Dios mío, ¿esto es real? Después de 5 años...

¿Qué pasa con el nuevo tipo de datos: aplanado? ¿Habrá soporte para visualizaciones para ese nuevo tipo en el futuro? Muchos clientes de servicios están siendo dirigidos a este nuevo tipo y se preguntan si las visualizaciones podrían entrar en juego y cuándo.

@Barrybigbuddy No estoy seguro de cuáles son los planes para aplanado, ¿podrías crear un boleto separado para eso?

Me gustaría tener la relación padre-hijo representada en Kibana. Así que solicítele que le dé prioridad a esta función. Gracias. M'Jay

+1

¡Impresionante! ¡+1 aquí! ¿Existe un plazo específico para esta función?

Permíteme ser el aguafiestas aquí y darte un breve recordatorio: hay muchas personas suscritas a este problema (228 personas de la comunidad + un par de equipos de Elastic), por lo que sería bueno si mantenemos +1 para un mínimo. Gracias a la función de reacción agradable de GitHubs, también puede agregar su aprobación y amor por @Bargs a sus comentarios sin

Dejaré aquí un par de referencias para otros tipos de campos:

¿Cuándo llegará esta función? Estamos trabajando activamente en esto y habrá diferentes fases (KQL, soporte de filtrado, visualizaciones, etc.) que podrían llegar en diferentes versiones, y dependerá de cómo vaya el proceso de desarrollo en eso. Publicaremos solicitudes de extracción relacionadas con esta función como un comentario aquí, para que pueda ver en el PR en qué versión aterrizará esa fase / parte de soporte específica.

No estoy seguro de si se trata del mismo problema, pero tengo un índice con una lista de objetos, pero no utilizo el tipo de datos "anidado". Sin embargo, en Kibana, en "Campos disponibles", no veo campos dentro de los objetos que están en la lista. ¿Es esta una limitación conocida?

@ppadovani ¿el complemento está disponible para kibana-7.3.1?

Hola a todos, creo que encontré algún tipo de solución para este problema. Al leer el código fuente de las asignaciones, encontré que hay una opción include_in_parent para el tipo de asignación anidada. Al usar esta opción, puedo visualizar una variedad de objetos en Kibana sin ningún problema. Por alguna razón, esta opción NO aparece en la documentación de ES. Tal vez me esté equivocando en algo, pero aparentemente todo funciona. Utilizo la opción de campos para poder buscar tanto como palabra clave como en texto completo.

Mapeos

PUT / test_index
json
{
"asignaciones": {
"dinámico": "estricto",
"propiedades": {
"estado": {
"tipo": "palabra clave"
},
"creado por": {
"tipo": "anidado",
"include_in_parent": verdadero,
"propiedades": {
"primer nombre": {
"teclee el texto",
"los campos": {
"crudo": {
"tipo": "palabra clave"
}
}
},
"apellido": {
"teclee el texto",
"los campos": {
"crudo": {
"tipo": "palabra clave"
}
}
}
},
"dinámico": "estricto"
},
"gente": {
"tipo": "anidado",
"include_in_parent": verdadero,
"propiedades": {
"primer nombre": {
"teclee el texto",
"los campos": {
"crudo": {
"tipo": "palabra clave"
}
}
},
"apellido": {
"teclee el texto",
"los campos": {
"crudo": {
"tipo": "palabra clave"
}
}
}
},
"dinámico": "estricto"
}
}
}
}

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

El uso de include_in_parent o copy_to como solución alternativa no es compatible y puede dejar de funcionar en versiones futuras.

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

Fase 1 de soporte de campo anidado lanzada en 7.6.0

Una pequeña actualización de este problema: acabamos de lanzar 7.6.0 de Kibana, que tiene el soporte inicial para campos anidados. Ahora puede utilizar campos anidados en los siguientes lugares de Kibana:

  • Los patrones de índice detectarán los campos anidados correctamente
  • Podrás ver Campos anidados en Discover
  • Filtrar en campos anidados a través de la barra de filtros funciona
  • KQL permite buscar campos anidados (consulte la documentación de KQL para obtener una explicación de la sintaxis sobre la consulta de campos anidados)

Actualmente estamos trabajando para habilitar campos anidados en visualizaciones y continuaremos actualizando este problema con información relevante.

¡Hola! Estamos esperando el funcional NESTED. ¿Cuándo podremos verlo? Este es el único momento que no cambia completamente a Kibana (Elastic es el mejor). El mundo entero te está mirando.

La consulta de campos anidados todavía tiene errores con KQL.
Ejemplo:
Considere el mapeo de índices definido como
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
He creado un patrón de índice basado en este índice y quiero consultar first.second.field : "test"
Esta consulta en la pestaña inspeccionar generará
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
lo cual es incorrecto.
La versión correcta también debe incluir la sintaxis anidada "nested": {"path": "first.second",...}

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

@IlyaHalsky Consulte la documentación de KQL sobre campos anidados. Los campos anidados requieren una sintaxis específica para realizar consultas, ya que tiene varias formas de consultarlos (en su caso, lo más probable es que solo desee hacer: first.second:{ field: "test" } ).

También debería ver una notificación de brindis cuando intente utilizar un campo anidado por primera vez en una consulta KQL que lo vinculará a esa explicación.

Pregunto si hay una nueva versión de kibana que admita el campo anidado en visualizar:
mi ejemplo de datos:
{
"campoX": "x",
"fiedY": "Y",
"anomalías": [
{
"categoría": "sistema",
"nombre": "cpu",
"fecha": "2020-03-11T13: 33: 40.000Z"
},
{
"categoría": "reiniciar",
"nombre": "restablecer",
"fecha": "2020-03-11T13: 33: 40.000Z"
},
{
"categoría": "sistema",
"nombre": "memoria",
"fecha": "2020-03-11T13: 33: 40.000Z"
}
]
}

Quiero visualizar un gráfico circular en kibana donde:
recuento de tamaño de rebanada = recuento total de objetos de matriz de anomalías (recuento de documentos x recuento de objetos por matriz de anomalías)
primer depósito = anomalías.categoría
segundo depósito = anomalías.nombre

en otras palabras, quiero visualizar la distribución del nombre de la anomalía por categoría de anomalía.

+1

¿Alguna noticia sobre esto? La versión 7.6 ya tiene un par de meses, 7.7 y 7.8 no tenían ninguna mención de esto en las notas de la versión y los documentos para 7.9, 7.xy master tampoco contienen información nueva sobre esta funcionalidad.

Simplemente interviniendo para expresar también nuestras grandes esperanzas de obtener soporte para agregaciones anidadas en Visualizaciones. ¡Sería increíble!

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

timroes picture timroes  ·  3Comentarios

spalger picture spalger  ·  3Comentarios

tbragin picture tbragin  ·  3Comentarios

cafuego picture cafuego  ·  3Comentarios

socialmineruser1 picture socialmineruser1  ·  3Comentarios