+1 para agregação de objetos aninhados.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

para ser claro, não há como fazer um filtro / consulta / agg aninhado no kibana 4 agora, não é?

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1 Porque desnormalizar objetos aninhados nem sempre é uma opção, pois isso pode levar a uma explosão de mapeamento.

Mapeamento:

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

Em primeiro lugar, gostaria que o gráfico de linhas pudesse mostrar o tamanho médio ao longo do tempo para cada nome de pool. Supondo que existam tantos nomes, então desnormalizar não é uma boa ideia, isso pode levar a muitos gráficos no gráfico. Para trabalhar com esses casos, também seria benéfico poder usar a agregação de filtro dentro de uma agregação aninhada. Ser capaz de filtrar em campos aninhados na pesquisa superior também seria ótimo.

Para tornar as coisas ainda mais interessantes, seria realmente ótimo poder visualizar uma agregação 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!

Seria poderoso com isso!

Então, alguém pode esclarecer isso; Neste post (https://www.elastic.co/blog/kibana-4-beta-1-released) para Kibana4beta1, afirma que "Kibana 4 traz o poder das agregações aninhadas de Elasticsearch com o clique de um mouse." Não consigo criar visualizações em documentos com objetos aninhados. Também verifiquei se os objetos aninhados em meu modelo de índice estão marcados como "aninhados". Então, o suporte de Kibana para agregações aninhadas não é o mesmo que o suporte de ES para objetos aninhados? o que estou perdendo? Obrigado.

@cslinuxboy - Acho que eles estão usando "aninhado" aqui para se referir ao agrupamento por meio de vários campos, por exemplo, "agregado por tempo e geo" (não "aninhado" como em seu uso na plataforma para "objetos aninhados")

@Alex-Ikanow - Obrigado pela resposta. Que pena que não é possível neste momento. Eu tive minhas esperanças ao ler a descrição enganosa em seu post beta-1.

+1 para suporte de objetos aninhados na agregação de visualização.

+1

No momento, estou usando relacionamentos pai / filho como uma solução alternativa que parece estar funcionando bem.

@calvdee Você tem consultas has_parent ou has_child para trabalhar na barra de pesquisa Kibana? Isso não está funcionando para nós e é um grande problema, eu ficaria ETERNAMENTE grato se você tivesse isso funcionando e pudesse me informar ... obrigado !!!

Não, para nosso caso de uso, todos os pais têm filhos e todos os filhos necessariamente têm pais, pois estamos indexando os dados da fatura, portanto, as consultas regulares funcionam (veja a imagem).

@calvdee Muito obrigado pela resposta! Temos um modelo de dados semelhante, mas queremos ser capazes de encontrar pais de seus filhos em Kibana, não está funcionando: 0 (

Não se preocupe, boa sorte!

Na quinta-feira, 26 de março de 2015, 11h36, ajrasch [email protected] escreveu:

@calvdee https://github.com/calvdee Muito obrigado pela resposta! Nós
têm um modelo de dados semelhante, mas desejam encontrar os pais por meio de seus
crianças em Kibana, não está funcionando: 0 (

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment -86575796.

+1

+1

Você leu o campo _mapping, portanto, deve saber quando um determinado campo está aninhado; portanto, ele não pode aplicar automaticamente a faceta / consulta aninhada correta quando esse campo é selecionado em consultas ou facetas?

Sim,: +1: neste. Embora eu tenha conseguido escrever a agregação aninhada correta na CLI e possa puxar dados com curl, não encontrei uma maneira de fazê-la funcionar na guia "Visualizar" do Kibana, nem mesmo usando a caixa de edição JSON. Reconheço que nunca uso esse recurso (a caixa), mas parece que só é possível "adicionar" coisas a uma agregação existente, não usá-lo para criar uma nova agregação do zero ... (agradecerá ser corrigido se eu estiver errado nisso!).

Sim, as agregações de tipo aninhado são essenciais e estão se tornando mais amplamente usadas porque resolvem um problema específico com dados simples.

Se Kibana4 for o produto de visualização para ES, ele deve oferecer suporte a todas as agregações ES.

Seria bom pelo menos ver isso no roteiro para Kibana4 .

+1

+1

+1

+1

+1

De # 3729 :-)

Eu gostaria de ver uma opção agregada "documentos filho"
(após o histograma de data, histograma, etc.) que abre o
parâmetros para uma consulta DSL para agregação de filhos, como
"tipo filho", "campos", etc.

Isso permitirá que se crie agregados aninhados no filho
documentos.

Não consigo criar tal consulta usando
o recurso de edição avançada. Pode ser alguem pode
me esclareça.

Obrigado

+1

+1

+1

1 realmente preciso dessa habilidade. Eu poderia remover todos os pais com logstash como uma solução alternativa, mas isso exigiria um arquivo de configuração enorme, pois tenho centenas de campos.

+1 alguém sabe se isso está planejado?

+1

No momento, estou pensando em alterar alguns dos meus mapeamentos para parar de usar objetos do tipo "aninhados", já que não posso criar visualizações Kibana em nenhum desses campos. Se eu soubesse que o problema estava pelo menos no roteiro, seria de grande ajuda para tomar essa decisão.

@benjismith - Eu também mordi o marcador e mudei o processamento dos meus dados de documentos aninhados para documentos pai / filho. Até agora está funcionando bem, mas concordo com você; Seria bom saber se há alguma chance de isso se tornar um recurso no Kibana para que todos possamos esperar ou seguir em frente.

Boa sorte.

+1

+1

+1 para suporte de agregação de tipo aninhado

+1

+1

+1

+1

+1

+1

Para aqueles que desejam fazer agregações simples em campos específicos dentro dos documentos aninhados (por exemplo, uma agregação de "termos" em um campo para encontrar os valores principais), você pode considerar adicionar a configuração "include_in_parent" ao seu mapeamento Elasticsearch. Isso cria uma versão simplificada de um campo no documento aninhado no nível pai.

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

Esses campos não aparecerão na lista de campos Descobrir no lado esquerdo, embora você os veja na visualização de detalhes do documento como um campo de matriz. No entanto, você terá acesso aos campos individuais na lista de métricas em Visualize e poderá executar agregações neles.

Isso é o que estamos fazendo para visualizar o histórico de observação, que se baseia em uma estrutura de documento aninhada (consulte "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

Em vez de outro +1 ... Talvez um resumo de onde se encontram as Agregações de Tipo Aninhado ajudaria.

Estou há 5 dias aprendendo a fazer gráficos bonitos, então me perdoe se isso for óbvio.

Qual é o problema?

Ainda é um problema de consulta ElasticSearch ou Lucene?

Não é resolvido por agregações, mas é resolvido pelo fato de permitirmos que você digite elasticsearch JSON na caixa de entrada. Não é o ideal, mas a menos que elasticsearch estenda a sintaxe de string de consulta lucene para especificar campos aninhados, é o melhor que podemos fazer. - comentário de um ano de rashidkpc

Kibana Fix é possível?

Se ES / Lucene, Kibana poderia fornecer um hack / solução intermediário nesse meio tempo? Pense em shims ES6 e CSS de prefixo de fornecedor.

Para mapeamento aninhado: oportunidade de escolher aninhado no editor (e configurar um caminho ...) para os painéis de Kibana. Bobmercer

Ou:

Você leu o campo _mapping, portanto, deve saber quando um determinado campo está aninhado; portanto, ele não pode aplicar automaticamente a faceta / consulta aninhada correta quando esse campo é selecionado em consultas ou facetas?
Alex-Ikanow, OP

Alguém está hackeando uma solução? Alguém com uma ideia / direção de onde hackear?

Trabalho em torno?

Alguém teve algum sucesso com nested / include_in_parent? Requer dynamic: static , dynamic: true . Minhas tentativas falharam com 0 resultados. tbragin

Alguém tem exemplos para a caixa de entrada JSON mencionada acima por rashidkpc?

Pai / Filho

Este é meu próximo passo. Tenho certeza de que há muito material de referência online para isso, mas não faria mal nenhum consultar exemplos / tutoriais para essa alternativa.

Por não ter conhecimento de componentes internos de kibana, estou pensando em escrever um proxy REST entre elastic e kibana. Ao consultar Kibana por um tipo específico, dados alguns critérios de pesquisa baseados em termos, esse proxy primeiro consulta o tipo pai para encontrar o conjunto de pais que atendem aos critérios de pesquisa (eles cabem na memória). Em seguida, ele encontra todos os filhos desses pais e os retorna para kibana desnormalizado com todos os campos pais adicionados. Isso nos permitirá ter um modelo pai-filho no Elastic Search que evita que a explosão do armazenamento desnormalize tudo em bilhões de objetos filho e, ao mesmo tempo, represente graficamente os dados com base nos campos pai.

Idealmente, isso fazia parte de Kibana. O mundo não é plano!

+1

+1. Costumávamos dividir a pilha de funções ou url_args em campos diferentes. Mas isso veio com um estado de cluster muito grande e muitas ações de atualização de mapeamento. Portanto, transformamos isso em um objeto aninhado. Agora, precisamos aggs em K4 ....

+1

+1 precisa de visualização de agregação pai-filho.

+1

Não acredite que todos os usuários do Elastic que desejam usar o Kibana o estejam usando para análise de log. Temos dados extensos, com objetos aninhados, preenchidos em nosso cluster que adoraríamos poder realizar análises sem ter que extrair e transformar os dados em outro sistema.

Ser capaz de criar agregações aninhadas, consultas aninhadas e até mesmo agregações reverse_nested é imprescindível. Quanto mais tempo Kibana ficar sem esse recurso, mais cedo devemos encontrar uma alternativa sem usar Elastic / Kibana. Se fornecer uma IU fácil de usar para esse tipo de recurso é a parte difícil, comece fornecendo a capacidade de seus usuários fornecerem a consulta json completa para elástico que retorna os dados necessários.

+1

Acordado com @ppadovani . Estávamos avaliando ferramentas de BI e adoraríamos usar o Kibana, mas ele não dava suporte aos relacionamentos em nossas entidades de negócios sobre as quais precisamos relatar e não era amigável o suficiente para um usuário não técnico explorar. Acabamos optando pelo Looker (essencialmente uma GUI para SQL). Analisar o looker pode oferecer algumas idéias de como o kibana pode ser estendido para servir a casos de uso mais diversos no futuro.

Decidi dar uma olhada no código kibana 4.1 .. (Não posso usar o master porque ele só funciona com elástico 2.x) .. Por favor, corrija-me se eu estiver errado, mas parece um primeiro passo fácil para fazer algo junto estas linhas:

1) Na área recolhível 'avançada' de uma agregação, adicione um campo de texto denominado algo como 'caminho aninhado'.
2) Se o usuário colocar uma string nesse campo, a agregação em que está definido terá uma agregação aninhada anexada a ele assim:
"aggs": {
"2": {
"aninhado": {"caminho": "foo"},
"aggs": {
"3": {
"date_histogram": {

Para lidar com o caso de vários níveis de objetos aninhados, você pode adicionar um + que permite ao usuário adicionar caminhos aninhados adicionais. Além disso, para lidar com o aninhado reverso, basta adicionar uma caixa de seleção rotulada 'reverso'.

Isso forneceria pelo menos suporte de agregação 'aninhado' limitado.

Para suporte de consulta aninhada, a única solução que posso pensar em curto prazo seria permitir que o usuário insira o json de pesquisa elástica codificado manualmente.

+1

+1 em tudo isso e permitindo que o usuário insira pesquisa elástica embutida em código json

+1

+1

+1. Fiquei muito animado em usar Kibana para nossas necessidades de visualização de ambiente, mas sem suporte para visualização de objetos aninhados é muito doloroso usar Kibana para nossos propósitos lá.

1, acabei de correr para isso.

+1

+1

+1

+1

+1

Pelo menos 82 pessoas recebem o seu "+1" e isso NÃO é útil.

Eu discordo totalmente. Mais dados nunca são ruins.

Minha equipe e eu estamos trabalhando nisso e esperamos ter algo para mostrar até o final da semana.

EDIT: Por favor, veja meus comentários em: https://github.com/elastic/kibana/pull/4645#issuecomment -132908544

+1

+1

+1

Concluído e uma solicitação pull criada aqui:
https://github.com/elastic/kibana/pull/4806

Atualização rápida para quem está assistindo ... esperando na Elasticsearch co. para ack o CLA, senão acho que está bom ir.

+1

+1 também

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

Sim por favor.

+1

+1

+1

+1

A solicitação de pull contra 4.1 está fechada em favor desta contra master.

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

Se houver demanda para uma versão 4.1 disso, posso reabrir a solicitação de pull com o código correto.

+1

+1

+1

+1

Não estou entendendo o que está bloqueando esse problema.
Há uma solicitação pull aguardando https://github.com/elastic/kibana/pull/5411

Há pessoas aqui dispostas a contribuir. O que precisa ser feito para fundir este PR?

Definitivamente, mais +1 são necessários

@ Filirom1 Alguns de nós estiveram na estrada, então não tivemos a chance de revisar o PR ainda :( Vamos tentar fazer isso esta semana. É definitivamente um aprimoramento muito necessário e estamos muito animados sobre a contribuição da comunidade aqui!

Excelente :-)
Obrigado !

Dei uma olhada no # 5411 e, infelizmente, não é a direção que desejamos seguir com isso agora. # 5411 implementou uma lacuna temporária, mas fez com que recursos importantes, como filtragem e pesquisa fossem interrompidos. Isso também fez com que o próprio agg builder parecesse quebrado para aqueles que não entendiam a implementação subjacente de agregações aninhadas. Depois de nos sentarmos e olharmos mais a fundo, percebemos que a quantidade de trabalho para oferecer suporte a documentos aninhados de uma forma coesa era extensa.

Não é que não queiramos fazer isso, é que, se o fizermos, queremos fazer de maneira adequada, não apenas contornar isso.

Reconhecemos que muitos estão interessados ​​em visualizar dados relacionais, no entanto, dadas outras prioridades e preocupações, não temos recursos para dedicar a este projeto no momento e não podemos nos comprometer a adicioná-lo ao roteiro para um futuro previsível.

Para sua informação, esperávamos usar kibana com agregações aninhadas para análises internas, mas acabamos optando por um produto comercial, 'Looker', que fica diretamente em nossos rdbms. Eu recomendo fortemente que os desenvolvedores do Elastic dêem uma olhada no que eles fizeram para tornar a exploração de um modelo relacional simples, já que muitas pessoas que não são da área de tecnologia agora podem navegar em nosso banco de dados ao vivo para suas perguntas do dia a dia sobre o produto. Avaliei vários produtos e o Looker saiu por cima, e adoraria ver uma funcionalidade semelhante no Kibana um dia.

Dado o comentário mais recente de Rashid e a longa espera por esse recurso, recomendo que este problema seja encerrado. Se esse problema permanecer aberto, isso apenas dará aos usuários uma falsa esperança de que haverá alguma possibilidade de implementação em um futuro próximo. Vamos fechar e testar a ideia até que os desenvolvedores tenham recursos para descobrir como implementá-la.

Copiando minha postagem da solicitação pull:

EXISTE uma solução aqui, mas exigiria uma quantidade significativa de trabalho e eu simplesmente não tenho tempo. Implementamos isso em JAVA, então sei que é possível.

1) Cada mapeamento de índice precisa extrair e entender os campos aninhados.
2) Crie um AST personalizado que forneça uma linguagem de consulta simplificada em vez de tentar usar apenas o Elasticsearch.
3) Construa um adaptador de consulta que entenda o AST e possa validar e converter a consulta para o JSON adequado.
4) Atualize as agregações em Kibana para tratar adequadamente os campos aninhados com base no entendimento interno dos campos aninhados.

Isso não é impossível de fazer, apenas requer um trabalho significativo. Os benefícios de implementar o acima incluem validação de consulta e uma sintaxe simplificada. Por exemplo, nosso AST nos permite criar uma consulta como esta:

(owner.user = "/ users / 00a0 / 18066271-29f0-40af-83ad-e5a0c8fc5944") AND (druid = "/ druids / 0060 / 77dd14b1-b7f0-4851-9ef8-74daa18d9d4d") E ((owner.lastageReceived. inserido> = 0) OR (conversaçãoLifecycleState = "RESERVATION_REQUEST")) AND (owner.conversationArchived = false) AND ((units.site IS NULL) OR (units.site IN {"HOMEAWAY_DE"})) AND ((question.inserted > = 0) OU NÃO (reservation.availabilityStatus = "DELETE")) E NÃO (owner.markedSpam = true) E (lastMessage.inserted> = 0)

Como exatamente eu poderia fazer essa consulta com o idioma existente?

IMHO - esperar pelo nirvana do Elasticsearch antes de agir levará a uma queda na adoção e perda de usuários do Kibana.

Odeio parecer que estou fazendo marketing, mas isso é relevante. (vi pessoas mencionarem outros produtos ..)

Encontramos muitos ppl que estavam usando fortemente o aninhamento e queriam realmente pesquisar dados relacionais e acabamos aninhando os registros que deveriam ter sido simplesmente "unidos" tardiamente. (Padovani, este pode ser o seu caso, vejo "mensagens" de "usuários" etc. Estas seriam muito bem mantidas como registros separados)
Este é o motivo pelo qual criamos o plugin SIREn Join elasticsearch e o fork Kibi our -friendly - Kibana que oferece filtros e funcionalidades para isso.

Agora estamos trabalhando para tornar o máximo possível do Kibi em plug-ins compatíveis com o Kibana 4.4 (também conhecido como 5.0) para o benefício de todos.

O plugin Join foi lançado ontem e também é open source.

Enquanto isso, a versão disponível http://siren.solutions/kibi funciona perfeitamente e faz com que muitos de nossos clientes não precisem mais de dados aninhados.

jccq: Nunca soube do Kibi ou do plugin de junção. Obrigado pela informação!

+1

+1
este é um problema obrigatório ...

@jccq Nosso caso de uso não é sobre unir apenas para consultas, usamos a entidade 'unida' ou 'visualização', como a chamamos, como dados de entidade verdadeiros com seu próprio ciclo de vida. Isso permite que os clientes extraiam os dados agregados sem ter que fazer várias chamadas GET para nossa API.

Em termos de suporte aninhado em Kibana, estamos evoluindo nossa abordagem e podemos ter algo a compartilhar com a comunidade em algum momento do segundo trimestre ou antes, dependendo dos recursos e do tempo. Essa nova abordagem ofereceria suporte aninhado perfeitamente nas agregações E nas consultas. Não direi mais, pois ainda está nos estágios iniciais de implementação.

+1

@ppadovani você é o único!

+1

+1

+1
É muito importante para nós.
Estamos esperando quase um ano por este recurso ...

+1

Atualização: Não vejo meu novo branch pronto para feedback preliminar ou teste por pelo menos um mês devido à minha carga de trabalho. No entanto, gostaria de expor o que estou fazendo para obter qualquer feedback da comunidade à medida que prossigo.

O design básico gira em torno de duas coisas:

1) Um novo analisador de consulta para o campo de consulta de formato livre Kibana. Este analisador usa a definição de sintaxe Bison padrão (consulte o projeto Jison para a versão javascript que estou usando). O BNF que estou usando é baseado no BNF existente que usamos em Homeaway para nossa linguagem de consulta personalizada no Elasticsearch. Veja meu comentário acima para um exemplo. Escolhi essa abordagem para permitir melhorias futuras pela comunidade, conforme necessário.

Eu tenho o analisador de consulta funcionando no Kibana, mas ainda tenho trabalho a fazer para permitir que o usuário alterne entre o estilo de consulta existente usado pelo Kibana e este novo estilo:

2) Altere a chamada getFieldMapping em mapper.js para getMapping e processe os resultados de maneira diferente, de modo que o caminho aninhado nos campos seja capturado e adicionado às informações de campo que o Kibana armazena.

Quando uma consulta é digitada, o analisador irá validar que não apenas os campos foram nomeados corretamente, mas que os valores fornecidos são válidos para os tipos de campo. Ou seja, um campo de data obtém uma data, ou um booleano recebeu um booleano. Além disso, os campos aninhados serão tratados automaticamente pelo analisador e a consulta json Elasticsearch adequada será gerada em vez da linguagem de consulta simples que é usada agora.

Finalmente, para agregações, uma vez que os campos agora contêm as dicas sobre caminhos aninhados, será trivial trabalhar em meu branch anterior para injetar automaticamente as agregações aninhadas conforme necessário com base nos campos selecionados.

Milestones:
1 - Obtenha o analisador funcional e gerando consultas
2 - Atualize mapper.js e implemente o suporte a consultas aninhadas
3 - Implementar suporte de agregação aninhada
4 - Teste / limpeza

Qualquer feedback sobre esta abordagem seria muito apreciado. Obrigado!

Atualização sobre o acima:

• Analisador completo
• Analisador reverso concluído (pega um elasticsearch json e o converte de volta para a linguagem de consulta personalizada)
• Kibana agora descobre e salva nestedPaths nos campos
• Analisadores agora têm acesso às informações de campo

Ainda por fazer:

• suporte de caminho aninhado em ambos os analisadores
• Construção de IU para permitir que o usuário alterne o estilo de consulta que deve ser usado e permite que as consultas legadas sejam salvas / usadas.
• terminar o tratamento de erros em analisadores e como a IU exibe problemas / erros de análise
• Construção de IU para fornecer suporte de digitação antecipada para nomes de campo na consulta
• suporte aninhado em intervalos / métricas
• testes de unidade, testes de unidade, testes de unidade.
• ...?

+1

Atualizar:

• O analisador manipula / injeta automaticamente informações aninhadas
• As agregações agora manipulam / injetam informações aninhadas automaticamente

PENDÊNCIA:

• Mudanças na IU para seleção de estilo de consulta e salvamento da seleção de estilo com consulta no índice kibana.
• tratamento de erros para erros do analisador e como a IU exibe problemas / erros de análise
• Suporte de tipo de IU antecipado para construção / gravação de consulta
• testes de unidade, testes de unidade, testes de unidade ...

Plano:
Desejo obter pelo menos algum progresso no trabalho de interface do usuário, não meu ponto forte, então enviaremos um branch / fork para o repositório github da HomeAway para permitir feedback / contribuições. Vou postar aqui novamente quando isso for feito para que qualquer um de vocês que quiser puxar o garfo e brincar com ele seja mais do que bem-vindo. Depois de polido o suficiente, criarei a solicitação de pull oficial.

Uma nota final: este trabalho está sendo feito no branch Kibana 4.3.1.

Na sequência do meu comentário anterior sobre o uso de "include_in_parent" e "include_in_root" para copiar campos selecionados de documentos aninhados para o nível superior para fins de execução de agregações neles, no ES 2.0 foi introduzida a funcionalidade "copy_to" que fornece outro opção para esse tipo de coisa: https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html
Fala-se em descontinuar "include_in_parent" e "include_in_root" em favor de "copy_to" em uma versão ES futura: https://github.com/elastic/elasticsearch/issues/12461 Se você tiver experiência com ambos, sinta-se à vontade para pesar.

+1

ppadovani, aprecie o que você está tentando fazer. Esse recurso é muito importante para nós
Algumas questões:

1. Eu entendo que isso vai demorar? Há uma estimativa de tempo em que esse recurso estará disponível?
2. Alguém já tentou alguma alternativa? Como alterar o formato de log de json aninhado (matrizes) para outra coisa? Em caso afirmativo, qual deve ser o formato pretendido para trabalhar com ELK?
3. Existe algum outro produto no mercado que pode ajudar a alcançar essa funcionalidade? Eu sou totalmente a favor do ELK porque ele é open source, mas até que não seja, queremos algo mais barato do que o Splunk. Exploramos muitas opções, como Loggly, sumologic, logentries, logscape, graylog (tão caro quanto splunk ou eles não têm essa funcionalidade)

Muito obrigado!

1. Alguém já tentou alguma alternativa? Como alterar o formato de log de json aninhado (matrizes) para outra coisa? Em caso afirmativo, qual deve ser o formato pretendido para trabalhar com ELK?

Você pode nivelar o esquema ou usar as opções de mapeamento ES "include_in_parent" ou "copy_to" para copiar alguns dos campos de documentos aninhados para documentos pai. Não funciona para todos os casos de uso, mas, em alguns casos, permitirá que você use o Kibana pronto para uso. Usamos a abordagem "include_in_parent" internamente na Elastic.

1. Eu tenho um branch que 'funciona', mas precisa de mais TLC na forma de trabalho de interface do usuário. Este não é meu trabalho principal, então só posso trabalhar nisso quando tenho tempo.
2. Como @tbragin indica, você pode nivelar os dados. No entanto, isso pode levar a resultados de consulta inválidos.
3. Não estou ciente de quaisquer alternativas neste momento.

Para ser mais claro sobre a aparência da linguagem de consulta, uma vez que fui questionado em minha antiga solicitação de pull, aqui está um resumo do BNF:

Comparação: campo [=, <,>, <=,> =, ~ =] valor
Observe o ~ = .. isso indica LIKE, que por sua vez causará uma consulta curinga
IN: campo IN {valor, valor, ...} Definir operação
campo IN [valor, valor] Operação de intervalo usando [] ou () dependendo de inclusivo / exclusivo
IS: campo IS NULL
expressão: IS | IN | Comparação
NÃO: NÃO expressão
E | OR: expressão AND |
EXISTS: EXISTS expression
Existe é a forma como o escopo do aninhado acontece. Normalmente, sem usar EXISTS, todas as expressões próximas umas das outras e com o mesmo caminho aninhado serão combinadas na mesma consulta aninhada. No entanto, você pode dividir o bloco de consulta aninhado usando EXISTS para fazer o escopo de consultas aninhadas particulares umas das outras.

Conforme declarado anteriormente, a linguagem usa JISON, um equivalente em javascript BISON, e nos permitirá estender a linguagem conforme necessário com muito pouco esforço.

ATUALIZAR:

Acredito que estou perto de poder compartilhar um branch com todos para testar e fornecer feedback. Eu tenho o (s) analisador (es) funcionando e pelo menos o feedback de sintaxe funcionando, bem como testes de unidade contra o analisador. Algumas capturas de tela:

Tenho esperança de ter o ramo pronto ainda esta semana. Quando eu estiver pronto, farei um link para uma postagem do blog aqui que terá um link para o branch e terá um resumo completo da sintaxe, uso, etc. Meu plano é coletar feedback sobre o branch, corrigir problemas, melhorar conforme solicitado e então obter uma solicitação pull enviada.

Eu gostaria de testá-lo (aqui está um exemplo de nosso uso de agregações aninhadas em K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523, não migrará sem ele).

@Robitx Não acho que será um problema ... temos documentos que têm pelo menos dois níveis de objetos aninhados ... por exemplo:

A-> B-> C

Onde um único documento A pode ter um ou mais B, e cada um deles contém uma lista de C que estão no B. Cada documento aninhado tem vários campos de vários tipos. Eu testei esse código para que eu possa construir um histograma ou gráfico de pizza multicamadas contra os dados aninhados mais internos.

Para ser claro, nossos mapeamentos são gerados automaticamente a partir de nossos pojos e podem se tornar muito complexos.

+1

ATUALIZAR:

Eu queria divulgar isso para as pessoas começarem a brincar, em vez de esperar que um post oficial de minha parte aparecesse.

Fork / Branch pode ser encontrado aqui:

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

LEIA-ME:

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

O conteúdo do README é essencialmente o conteúdo da postagem do blog que aparecerá em algum momento.

Sinta-se à vontade para abrir questões / solicitar solicitações no branch fullNestedSupport, se desejar. Vou tentar ficar por dentro de todos os problemas que as pessoas encontrarem.

+10000

+100500

+100

Oi ppadovani,

Você poderia, por favor, aconselhar, o que devo fazer

Este campo está presente no mapeamento do elasticsearch, mas não em nenhum documento nos resultados da pesquisa. Você ainda pode ser capaz de visualizar ou pesquisar nele.

Muito obrigado!

Oi ppadovani,

Temos um campo como matrizes aninhadas.
"abc": [["3815222235847451", "131712121218083052"]]
OU
"abc": [["3815222235847451", "131712121218083052", "131712121217783052"]]
OU
"abc": [["3815222235847451"]]

Os valores podem ser de 1 a 10

Enquanto para outros campos aninhados vejo um aviso de que o campo não está indexado (suponho que preciso usar mapeamentos?) Para este campo e outros como esses, cada conjunto é tratado como um valor separado. Além disso, o tipo de campo está sendo exibido como "string" em vez de número, o que não é um problema em si, mas o que significa é que não posso pesquisar nenhum valor individual de abc ..?

Muito obrigado!

Encontrado alguns minutos para iniciar o teste :): |

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) - Não acredito que seja uma mensagem gerada pelas minhas mudanças, podendo ser algo que existia em Kibana antes.
2) - Sim ... parece que os valores são armazenados como uma string, mas possivelmente não estão aninhados. Eu teria que ver como é o mapeamento no índice para entender qual problema existe. Cole o mapeamento aqui.

@Robitx
Presumo que este seja um campo de data ... o tempo da época tem muitos dígitos deve ser 10 e não 13 .. você pode atualizar / colar a consulta que emitiu?

@ppadovani
Acabei de escolher o padrão de índice padrão nas configurações e voltei para descobrir a guia

Nós usamos

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

K 4.4.1 + ES 2.2 funciona bem, pode ser específico do K 4.3 (eu não tentei esta versão antes)

@Robitx
Estou procurando a consulta usada ... ou você está dizendo que a consulta passada era apenas a janela de data padrão da IU e você não especificou uma consulta? Vou rebase minhas alterações em uma versão posterior do Kibana e repassar quando o branch for atualizado.

@ppadovani sim, apenas * e algum intervalo de tempo

+1 para objetos aninhados na seção de visualização

@Robitx
Essa operação que você executou nunca atingiu nenhum código do meu analisador ... então duvido que tenha sido devido a algo que eu fiz ... Minha configuração é K 4.3.1 + ES 2.1.1 - vou atualizar meu ES para 2.2 e ver se obtenho o mesmo comportamento, então vou realocar o branch para K 4.4.1

Acabei de atualizar para ES 2.2.1 com K 4.3.1 + meu código ... não consegui reproduzir:

Eu ainda vou rebase para 4.4.1 - a versão atual, vou atualizar este post quando o branch estiver pronto.

ATUALIZAR:

Rebaseado para 4.4.1 em um novo branch: https://github.com/homeaway/kibana/tree/nestedSupport-4.4.1

Testado em ES 2.2.0 e K 4.4.1

Oi ppadovani,

Em relação às minhas perguntas anteriores, eu as esquecerei. Já tenho uma instância de pesquisa elástica no AWS (junto com mapeamentos) e estou tentando conectar isso a isso. No entanto, o status do servidor kibana na IU diz:

plugin: elasticsearch Esta versão do Kibana requer Elasticsearch ^ 2.1.0 em todos os nós. Encontrei os seguintes nós incompatíveis em seu cluster: Elasticsearch v1.5.2 @ undefined (undefined)

Ainda estou usando https://github.com/homeaway/kibana/tree/fullNestedSupport e não o mais recente fornecido por você. É possível torná-lo compatível com 1.5.2?
Conselho gentil.

Muito obrigado !!

@ppadovani
Posso entender se isso não for possível, já que estamos retrocedendo, no entanto, o Amazon Elasticsearch Service não está muito interessado em atualizar para versões mais novas, o que é compreensível. Então, eu tenho que trabalhar com tudo o que temos. Investimos muitos esforços na configuração da instância AWS (junto com o encaminhamento de log de vários nós, eventos de streaming e outros detalhes minuciosos) e reinventar tudo em uma plataforma separada a partir do zero não é uma opção para nós. Seria bom poder conectá-lo como um front-end adicional. Eu nem tenho certeza se haverá outro obstáculo na linha?

Obrigado!!

@BigDataEngineer
Depois de examinar o código Kibana nas versões anteriores, a primeira versão que eu poderia tentar e aplicar as mudanças é a 4.1.6. No entanto, houve uma reescrita / refatoração / reorganização significativa do código e não posso simplesmente corrigir esse branch. Seria necessário muito trabalho para tentar fazer com que meu código funcionasse.

Sinceramente, não sei por que as equipes Kibana aumentam a versão elástica exigida como fazem com cada versão ... a interface REST simplesmente não muda com tanta frequência. Eu especulo que eles fazem isso para forçar os usuários a atualizar seus clusters elásticos.

Pensando bem, você pode tentar alterar a versão em src / plugins / elasticsearch / index.js na linha 27

@ppadovani
funcionou. Obrigado.

+1

@ppadovani Olá, obrigado por atualizar para a versão 4.4.1, desculpe por não responder antes (perdi sua atualização em um dos comentários anteriores).

Está funcionando agora, mas a primeira coisa que notei são problemas de desempenho e, ocasionalmente, o kibana congela completamente (não consegui testar consultas mais complicadas).

Existem poucas coisas que podem contribuir para este problema, uma delas é uma série de campos em nosso índice diário (existem centenas deles http://pastebin.com/fktN0dR5).

@Robitx Você tem esses mesmos problemas com o código base 4.4.1 K sem minhas alterações? Ou é só com minhas mudanças? Eu sei que padrões de índice muito grandes causam problemas de desempenho significativos para K. Se for apenas com meu código, então acho que sei o que pode ser. Vou dar uma olhada nele quando subir para respirar em um dia ou dois.

@ppadovani the base K 4.4.1 não tem esse problema

Um ano desde que este problema não foi corrigido ...

Droga, elasticsearch tem o recurso "Objetos Aninhados" muito necessário, e Kibana dos mesmos desenvolvedores ainda não tem suporte para esse recurso.

Você tem um fork que já implementou esse recurso e ainda não fez a fusão no código-fonte principal, com suporte adequado.

E ainda não podemos usar em nosso projeto a versão de estoque do KIbana com suporte a "Objetos Aninhados".

F * cking incrível !!!

@ppadovani muito obrigado pelo seu trabalho no fork =)

@Robitx Você pode me dizer quando Kibana congelar para você? Definição de IndexPattern? Ou quando você está iniciando uma nova consulta? Existem áreas possíveis onde isso pode ocorrer, e eu quero restringi-lo.

Corrigi um problema que pode ter contribuído ao abrir as guias de descoberta / visualização ... Eu enviei uma correção, por favor, teste novamente.

@rashidkpc Estou pronto para gerar uma solicitação de pull com base neste trabalho. Você pode me dizer em qual branch devo realocar meu trabalho? Atualmente tenho contra 4.3.1, 4.4.1 e 4.x. (4.x está próximo, mas estou tendo problemas para executar os testes de unidade. O cluster de teste falha ao iniciar ...)

Ei galera (cc @ppadovani)

Como mencionei em https://github.com/elastic/kibana/pull/5411, há uma série de limitações no próprio Elasticsearch, particularmente que os aggs / filtros aninhados não são automáticos e a sintaxe de consulta lucene não oferece suporte à pesquisa aninhada. Embora a abordagem adotada aqui traçasse um caminho diferente para resolver o problema, não é a direção que queremos seguir. Esta é uma solução para um problema limitado, mas queremos que Kibana resolva uma ampla gama de desafios. Nesse caso, isso significa sacrificar vitórias menores por vitórias maiores no futuro.

Enquanto estamos considerando as possibilidades de um idioma para Kibana, não decidimos exatamente o que queremos que seja o conjunto de recursos e não queremos fazê-lo pela metade ou com um único objetivo em mente. Estamos considerando algumas táticas e conjuntos de recursos, tanto no Elasticsearch quanto no Kibana, mas ainda estamos nos estágios de formação. Com o tempo, gostaríamos que isso incluísse pesquisa, transformação e visualização, como você vê em algo como timelion, e certamente manteremos a ideia de consultar documentos aninhados em mente enquanto fazemos isso

Observei que isso armazena o caminho aninhado, no entanto, estamos removendo o mapeamento em cache https://github.com/elastic/kibana/pull/6648 e substituindo-o por novas APIs no Elasticsearch: https://github.com/elastic / elasticsearch / issues / 15728. Pense nisso, seria ótimo se Kibana não precisasse analisar o caminho aninhado. Isso é especialmente importante para nosso objetivo de tornar documentos muito grandes acessíveis em Kibana

Por enquanto, recomendamos seguir a abordagem de @tbragin usando include_in_parent ou copy_to . Para 90% das agregações, essa abordagem funcionará perfeitamente.

Estou feliz que esta solução esteja funcionando para aqueles que não podem usar include_in_parent ou copy_to , super impressionados com o que @ppadovani conseguiu. Eu adoraria ver algo assim implementado como um plugin. No momento, a entrada da consulta leva essencialmente 2 tipos de consulta de qualquer maneira, provavelmente poderíamos encontrar uma maneira de torná-la plugável.

hey, entrando na conversa isso mantém a flexibilidade que precisamos ter em Kibana. Embora essa alteração sugerida possa resolver o problema de curto prazo de não suporte aninhado, será problemático no futuro.

Dirijo-me e sinto a necessidade aqui do Kibana de suporte aninhado, mas este é um daqueles casos em que se não está claro como deve ser resolvido, é melhor deixar sem solução até que tenhamos uma solução que pareça natural. Definitivamente, precisamos continuar e explorar isso, um daqueles, com o qual conversamos em diferentes lugares, é automaticamente compatível com aninhados (agrupamento e assim por diante) no próprio ES.

Estou empolgado em ver isso resolvido com elegância.

+1

+1

IMHO Devo discordar respeitosamente com a postura dos mantenedores do Kibana. No entanto, se pudermos encontrar uma maneira de fazer algo nesse sentido se conectar ao Kibana, eu estaria totalmente a favor.

Nesse ínterim, continuarei a manter e corrigir bugs em meus fork (s) / branches para aqueles que desejam continuar a usar a versão que criei. Eu sei que usaremos isso extensivamente para painéis analíticos de BI ao vivo no futuro.

Gado. Não é animal de estimação.

+1 :)
Pode ser ótimo usar objetos aninhados em Kibana !! (Alguém tem um plugin para isso ou não? ...)

+1

+1

+1

@tbragin A abordagem que você mencionou não funciona em tipos aninhados. Ele irá agregar todos os dados, independentemente do tipo.

+1

+1

+1

+1

Esse recurso é tão óbvio que fiquei chocado ao descobrir que não só não é compatível, mas que os desenvolvedores aparentemente não têm planos de oferecer suporte algum dia. Inferno, fale com seus gerentes de projeto e contrate @ppadovani para fazer um plugin se vocês não o fizerem.

+1, pois a falta de objetos aninhados atrapalha meu projeto substancialmente

Para quem procura uma discussão sobre a desnormalização como uma forma de contornar este problema: Contornar a falta de suporte de Kibana para objetos aninhados e pai / filho

Elastic, seria ótimo se houvesse uma isenção de responsabilidade no site em relação a esse problema para evitar que os usuários perdessem tempo tentando implementar um recurso não compatível. Porque? A página do produto Kibana diz "Integração perfeita com ElasticSearch", o que não é verdade aqui :)

Para sua informação - o branch do meu código mencionado na discussão acima é antigo ... o branch atual é:

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

Estamos usando-o ativamente internamente e continuamos a atualizar nossa versão interna. Posso / irei atualizar a versão do github caso haja interesse.

Pierre

+1

+1

+1

+1

+1

+1

Lembro-me de ter marcado isso com +1 há mais de um ano, e desde então a equipe de desenvolvimento de Kibana não fez nada além de cavar sua cura e principalmente os usuários ignorados e, finalmente, quando seus pés são postos no fogo, eles respondem com um mais-ou- menos "NÃO", afirmando que "não parece natural".

Também vejo esse padrão em vários outros recursos solicitados, como:

• Suporte para chamar scripts bacanas do lado do sistema operacional.
• Suporte para poder usar agregações de métricas com script ES (especialmente útil para calcular médias ponderadas).
• E assim por diante...

Isso tudo vai contra a posição de toda a visão do Elastic Stack 5, que foi declarada que eles (Elastic) apoiariam mais recursos subjacentes do Elasticsearch em Kibana. Mas tenho visto muito pouco para apoiar essas afirmações.

Como resultado, vejo Kibana perdendo terreno para garfos como o Kibi da Siren, que decidiu assumir a responsabilidade em itens como este tópico e chegar a uma solução.

Agradeço aos desenvolvedores do Kibana por nos dar uma ótima ferramenta de visualização. Mas Elastic precisa decidir no futuro se Kibana deve continuar sendo uma ferramenta de visualização simplista ou ouvir a comunidade e expandir sua utilidade. Se a decisão for a primeira, espere que os usuários saiam quando outros decidirem tirar proveito dessas deficiências.

+1

@cslinuxboy

Suporte para chamar scripts bacanas do lado do sistema operacional.

A maioria dos casos de uso cobertos por isso serão resolvidos por https://github.com/elastic/kibana/pull/7700.

Suporte para poder usar agregações de métricas com script ES

Não acho que ninguém seja contra isso (pelo menos, não vejo nenhuma oposição aqui https://github.com/elastic/kibana/issues/2646), na verdade agora é a hora de adicioná-lo, já que o Elasticsearch adicionou a linguagem de script indolor. Na verdade, é só uma questão de alguém encontrar tempo.

+1

+1

+1

Estou começando a trabalhar no garfo novamente. Desejo me desculpar com a comunidade, eu não tinha ideia até cerca de um mês atrás que não tinha ativado os problemas para o fork, então ninguém teria sido capaz de indicar que havia bugs. Isso foi corrigido.

Filial atual: https://github.com/homeaway/kibana/tree/nestedSupport-4.5.4

As atualizações na ordem em que pretendo implementá-las:

• Adicionar suporte para deslocamentos de data ao analisador de consulta
• Adicionar suporte à descoberta de campos aninhados ao observar um resultado - FEITO
• Adicionar suporte para consultas e agregações pai / filho
• Adicionar suporte para tipos de formas geográficas para consultas (ou seja, ponto, caixa, etc.) Esta é uma porta de um aprimoramento recente em nossa linguagem interna.
• Adicionar digitação antecipada para nomes de campo no campo de consulta
• Eu poderia tentar construir um analisador para a linguagem de consulta simples Elasticsearch existente a fim de consertar o incômodo de uma consulta inválida que faz com que um rastreamento de pilha seja retornado do Elasticsearch ou nenhum resultado seja retornado sem indicação do motivo. Se eu trabalhar nisso, será depois de ter concluído o acima. Se eu fizer isso, examinarei a adição de suporte aninhado e de pai / filho ao idioma no lado Kibana.

Desejo somar minha voz àqueles que indicaram que a equipe Kibana não está ouvindo a comunidade. A equipe Kibana NÃO PODE simplesmente confiar no Elasticsearch para fornecer a funcionalidade necessária se houver uma lacuna para manter o Kibana "puro". Marketshare não é ganho dessa forma, ele é perdido.

+1

+1
@Bargs : Algum progresso nessa questão? Quando isso será tratado / priorizado?
Tópico muito longo ... Isso não é bom para produtos como kibana ..
Agradecemos seus esforços

Isso é péssimo :-(

homeway aninhado aggs & query support build on Kibana 4.3.1 confira .. espero que esta ajuda ..

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

@ankitchheda eu sei disso, mas um fork mantido por poucas pessoas que vai contra a filosofia do projeto principal (que está em forte desenvolvimento) não é uma solução, fingir que é não vai ajudar ninguém ..

Gostaria de fazer algo a respeito, mas não tenho tempo, então, por enquanto, pelo menos tento aplicar pressão e espero que os desenvolvedores parem de ignorar esse problema: |

+1

Para sua informação - o fork que mantenho para suporte aninhado, agora tem suporte para as seguintes versões:

4.5.X
4,6
4,7
5.X

Pode não seguir a 'filosofia' dos desenvolvedores principais, mas funciona e funciona bem.

Acabei de enfrentar isso. É um pouco inconveniente e seria muito útil ter uma solução viável.

@tbragin , @rashidkpc - a solução proposta perde o ponto - você
algo com objetos aninhados - mas você obtém os resultados errados! Aninhado
agregações fornecem resultados diferentes (farei um pequeno exemplo trabalhado e postarei aqui mais tarde).

Vou testar o fork do @ppadovani.

+1

: tartaruga :: traço:

@Bargs Ei, as mudanças de danos de bifurcação para o desempenho da funcionalidade básica?

+1

+1

+1

+10086

+1

+1

+1

include_in_parent ainda funciona no ES e Kibana 5.2? Tentei usar como alternativa sem sucesso.

@gustavomr Eu acredito que funcionará, mas apenas para alguns casos de uso. Não funcionará para todos os casos de uso de consulta possíveis que consultas / agregações aninhadas podem fornecer.

NOTA: Meu fork 5.1 do Kibana agora usa uma alternância ao lado do ícone de pesquisa para alternar entre a linguagem de consulta simples elástica nativa e a linguagem de consulta aninhada que incluí. Também resolvi vários problemas de métricas para campos aninhados.
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovani muito obrigado por fazer isso. É possível separar seu trabalho ativando objetos aninhados em kibana de seu trabalho criando uma nova linguagem de consulta? Se esses forem ramos separados, então podemos apenas usar o anterior e mesclá-lo com as versões mais recentes do kibana à medida que forem surgindo, em vez de ter que mesclar os dois recursos.

Além disso, você já tem uma janela de encaixe criada para esta bifurcação?

@ppadovani +1 para contêiner docker para seu garfo.

@gkozyryatskyy - Por favor, abra um problema no fork e eu o examinarei.

@ imranq2 - Eu poderia fazer isso, no entanto, observe que a linguagem de consulta elástica simples não oferece suporte a consultas aninhadas. Se você tiver dados aninhados e quiser consultá-los, terá que construir manualmente a consulta como um blob json elasticsearch e colá-lo na caixa de consulta.

+1

Meu fork agora oferece suporte a 5.2 no branch nestedSupport-5.2.

@ppadovani Isso é ótimo! Avise-me se precisar de ajuda para fazer um contêiner docker para isso.

Ainda não terminei o contêiner do docker, mas tive algum tempo para brincar com a guia de descoberta e como ela exibe dados aninhados ... procurando feedback daqueles que estão monitorando o problema de suporte aninhado. A tabela é recursiva e os filtros para campos aninhados parecem funcionar bem ... mas o campo de alternância na coluna ainda não funciona ... Ainda preciso pensar em como / se isso deve funcionar.

Para sua informação - este trabalho está basicamente completo e todos os garfos / ramificações com suporte têm as alterações começando com o nestedSupport-4.5.4 até nestedSupport-5.2

@Bargs - Eu sei que nenhum dos trabalhos aninhados que fiz é algo que vocês estão procurando, mas estou curioso para saber se o trabalho em torno da exibição de dados aninhados nos resultados da descoberta é algo que vocês possam querer. Não depende de nenhum dos meus trabalhos anteriores. Veja este problema para capturas de tela atualizadas:
https://github.com/homeaway/kibana/issues/12

Se isso é algo que vocês querem, me avise e abrirei um problema e incluirei um patch.

Parece interessante @ppadovani ! Se você gostaria de abrir um PR, eu definitivamente estaria interessado em dar uma olhada. Falamos um pouco sobre como adicionar melhor suporte para campos aninhados ao Discover, então seria ótimo ter algo concreto para discutir.

@ppadovani Estou criando um contêiner docker para isso agora para que possa usá-lo. Você já tem o tarball criado como http://staging.elastic.co/ $ (VERSION_TAG) / downloads / kibana / kibana - $ {ELASTIC_VERSION} -linux-x86_64.tar.gz? Nesse caso, posso simplesmente puxar para o meu contêiner do docker. Caso contrário, precisarei construir seu branch e criar o tarball.

@ imranq2 Não forneço distribuições do meu fork, então você precisará criá-lo sozinho.

Para sua informação - criei uma solicitação pull para oferecer suporte a dados aninhados na guia de descoberta para aqueles que estão interessados:
https://github.com/elastic/kibana/pull/10814

+1

1 para mim
+10 para meus colegas

+1

+1

+1

+1

+1

+1

+1. Isso é compatível com ELK5?

+1

este é realmente um requisito, pois não oferecer suporte a objetos aninhados é realmente um impedimento para a ampla adoção de kibana em minha empresa, pois você tem que criar um índice para kibana e outro com documentos aninhados para pesquisas mais inteligentes por meio da API simples

+1
No meu mapeamento, isso evitaria uma possível "explosão" das propriedades do índice.

+1

+1

+1

Por favor, pare de postar comentários +1 que são spam apenas para todas as pessoas inscritas neste tópico. Em vez disso, clique no grande botão amarelo "polegar para cima" no topo desta edição para votar a favor.

+1

Desenvolvedores do Kibana, por favor, façam alguma coisa, gente sério. O uso de Kibana sem objetos aninhados em muitos casos é inútil. Você está preparando a versão 6.x sem objetos aninhados ...

Nosso sistema verifica o texto em busca de casas e, em seguida, salva os resultados no ES. Portanto, ES contém documentos principais com matriz de casas. Casa são os objetos aninhados.

Não consigo usar a visualização para criar um painel com análise de casas que encontramos no texto.
Faça algo, por favor. As casas estão pegando fogo.

Precisa desesperadamente usar objetos aninhados em kibana. É uma sensação ruim que isso não esteja disponível embutido.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

outro aqui!

Para aqueles que podem ter usado meu fork do Kibana com suporte aninhado, estou descontinuando o suporte para esse fork após o Kibana release 5.4.x. Em vez disso, irei mover a maioria, senão todas as funcionalidades para um plug-in Kibana. Espero ter o plugin pronto para o último lançamento 5.x até o final do ano. Você pode acompanhar o progresso aqui: https://github.com/ppadovani/KibanaNestedSupportPlugin

Acabei de começar o trabalho, então não espere que nada significativo apareça por algumas semanas.

+1

+1

+1

+1

+1

Eu tenho capturas de tela e atualizações de status postadas para o trabalho que estou fazendo no plug-in de suporte aninhado. Observe o problema para obter atualizações de status.

Capturas de tela e atualizações

Eu fui em frente e lancei um pré-lançamento de 1.0.0 com suporte para Kibana 5.6.5.

Consulte este problema para obter detalhes sobre o que está no pré-lançamento inicial: Capturas de tela e atualizações

V1.0.0-beta1

Meu plugin está completo para a versão 5.6.5 do Kibana. Tenho algumas tarefas de limpeza, então irei cortar a versão 5.6.5 e começar a encaminhar a portabilidade para 6.1.X.

Recursos:

• Suporte de consulta aninhada
• Suporte de agregação aninhada
• Descubra o suporte aninhado de resultados
• Descubra a prioridade de exibição do campo de resumo (na verdade, é algo novo)

Consulte o README para obter detalhes.

Meu plugin foi lançado! Suporte para 5.5.3, 5.6.5 e 5.6.6. Estarei migrando para 6.0.X neste fim de semana.

Provavelmente não atualizarei mais o status aqui sobre esse problema. Visite minha página do GitHub para ver os lançamentos, problemas etc.

Obrigado!

@ppadovani você pode lançar uma versão de suporte para 5.4.0 obrigado.

@ppadovani Estarei de olho na porta 6.0.x!

@ SolomonShorser-OICR
Eu lancei uma versão 6.0.1 Beta 1.

A única limitação conhecida é que a barra de filtro não está operacional devido a ser codificada para funcionar apenas com a linguagem de consulta lucene. Estou trabalhando em uma maneira de contornar isso, mas posso não ter uma solução até o próximo fim de semana.

Agora eu lancei uma versão de plugin para 6.0.1, 6.1.x é o próximo.

@ppadovani
Obrigado pelo seu trabalho e versão 6.0.1!

baseado no kibana 6.0.1, após a instalação deste plugin, alguns recursos do kibana não funcionam bem.

ao clicar em timelion, ele mostra uma mensagem de erro:

se x-pack instalado, algum recurso x-pack "descobrir" tem outra mensagem de erro em "Foreach"

Ei equipe Kibana, por que você ainda não contratou @ppadovani ?

@sccds - Mova este relatório de bug para meu

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

Se alguém tiver problemas com meu plug-in, abra os problemas no meu repositório e não inicie uma conversa aqui. Este problema tem muitos assinantes.

@Hronom - Agradeço a ideia, mas meus pontos fortes não estão em Javascript .... embora construir este plugin e hackear Kibana certamente tenha ajudado minhas habilidades nessa área.

FYI - Meu plugin agora está atualizado com os lançamentos do Kibana. Eu lancei o suporte 6.1.2.

Obrigado @ppadovani , continue assim!

+1

+1

+1 Olá, Tomitribe está muito interessado neste recurso. Você sabe quando esse recurso será implementado?

@ppadovani onde posso perguntar sobre a funcionalidade? Estou lutando com a agregação aninhada na tabela de dados.

@bumerankkk Vá aqui e abra um problema: https://github.com/ppadovani/KibanaNestedSupportPlugin

Como alternativa, se você for para uma das páginas de documentação que se alinham com sua pergunta, você pode adicionar um comentário na parte inferior da página.

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

Isso está sendo trabalhado ativamente? Temos prazos para quando esse recurso seria lançado em produção?

Feliz aniversário 🎂 'Agregações de tipo aninhado', 🎁

Agora você já tem quatro anos. Não faz muito tempo, você era tão pequeno e fofo.
Espero que você cresça e tenhamos alguns anos bons em comum no futuro.

melhor Malu

+1

+1

+1

+1

+1

+1

+1

Por que ainda não foi implementado

pq motivos, com esse recurso o whey não teria dis thread, não teria diversão e ninguém iria ao github da kibana, isso algum tipo de beacon

A última versão do elk oferece suporte a dados aninhados corretamente para mim

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

Por razões de razão, com esse recurso o whey não teria essa discussão, sem diversão e
ninguem vai ao github da kibana, isso algum tipo de beacon

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
.

@javixeneize Estou sentado aqui na versão 6.2.4 , não consigo encontrar suporte a objetos aninhados dat, corrija-me se estiver errado

Eu tenho essa versão e posso acessar ab, onde minha estrutura é {Id: xx,
a: {b: xx}}

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

@javixeneize https://github.com/javixeneize Estou sentado aqui no 6.2.4
versão, não consigo encontrar suporte a objetos aninhados dat, corrija-me se eu estiver errado.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
.

@javixeneize , você tem o próximo mapeamento com type : nested ?
Você pode obter o mapeamento por GET /index-name

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

Vou verificar amanhã, mas tenho a configuração padrão

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

@javixeneize https://github.com/javixeneize você tem o próximo mapeamento
com tipo: aninhado?
Você pode obter o mapeamento por GET / index-name

{
"documento": {
"propriedades": {
"Localizações": {
"tipo": "aninhado",
"propriedades": {
"começar": {
"tipo": "longo"
},
"fim": {
"tipo": "longo"
},
"normalizado": {
"tipo": "palavra-chave"
},
"original": {
"tipo": "palavra-chave"
}
}
}
}
}
}
}

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
.

@javixeneize, obrigado antecipadamente!
Você provavelmente tem um objeto sub json que foi achatado no documento principal, mas este não é um objeto aninhado.

Sim, tenha cuidado @javixeneize seus dados não se correlacionarão conforme o esperado, a menos que você defina especificamente o mapeamento no ES para esse campo como aninhado

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

O problema principal: cada campo no objeto aninhado torna-se apenas um array e você perde a correlação entre as propriedades.

Acabei de achatar meus dados antes de despejar no ES por enquanto.

Se você não puder esperar que o Elastic implemente isso, você pode usar meu plug-in Kibana:

Visão geral:
https://ppadovani.github.io/knql_plugin/overview/
Instalação:
https://ppadovani.github.io/knql_plugin/installation/
Linguagem de consulta (como SQL):
https://ppadovani.github.io/knql_plugin/knql/

Suporte para 5.5.3 a 6.2.4, se uma versão estiver faltando, após 5.5, abra um problema:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Contribuições, solicitações de recursos e relatórios de bugs são bem-vindos.

Ok, eu tenho que esperar então ...

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

Se você não pode esperar pelo Elastic para implementar isso, você pode usar meu Kibana
plugar:

Visão geral:
https://ppadovani.github.io/knql_plugin/overview/
Instalação:
https://ppadovani.github.io/knql_plugin/installation/
Linguagem de consulta (como SQL):
https://ppadovani.github.io/knql_plugin/knql/

Suporte para 5.5.3 a 6.2.4, se uma versão estiver faltando, após 5.5, por favor
abrir um problema:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Contribuições, solicitações de recursos e relatórios de bugs são bem-vindos.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
.

+1

+1

+1

+1

+1

+1

recurso muito útil ... +1

Kibana é absolutamente inútil para meus casos de uso sem esse suporte. Eu não deveria ter que nivelar ou reestruturar meus dados. Devo apenas ser capaz de inserir dados e obter visualizações ou agregações. Quatro anos depois e ainda sem suporte a objetos aninhados?

Alguma estimativa quando esse recurso estiver disponível?

Alguém da elasticidade poderia nos dizer se esse recurso foi adicionado ao Kibana? Este bilhete está aberto há quase 5 anos.

Além disso, qual é o ponto de lançar esse recurso se ele não pode ser usado no Kibana?

Não me entenda mal, mas parece um pouco estranho.

+1

+1

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

Por favor, não adicione comentários como comentários de +1. Especialmente para questões com as quais você realmente se preocupa! Deixe-me explicar, qualquer pessoa com as notificações ativadas ficará facilmente irritada e cancelará a inscrição no tópico. Isso significa que os colaboradores não verão isso como uma questão importante apenas com base no número de participantes envolvidos. Quando as pessoas cancelam a assinatura, esse número diminui.

Em vez disso, o que VOCÊ deve fazer é se inscrever no tópico por meio da caixa no canto superior direito e dar um sinal de positivo para a edição inicial do Github para mostrar seu apoio.

@ bugs181 isso não funciona aqui, esse problema é uma anomalia e absorve todas as ondas que chegam, há cinco anos!

Acho que os cientistas deveriam explorar este buraco negro!

Os desenvolvedores de Kibana parecem ter um poder anormal !!!

@ bugs181 isso não funciona aqui, esse problema é uma anomalia e absorve todas as ondas que chegam, há cinco anos!

Você já pensou que eles não queriam ler a edição inteira com toneladas de comentários "+1 eu também" pescando informações que poderiam ser valiosas para eles?

@ppadovani tem um plugin de código aberto que pode ser usado (veja o comentário dele acima)

@ mika76
estou usando isso.

muito útil no caso simples

@ mika76 esteja ciente de que, devido a restrições de tempo, não é mantido ativamente no momento.

ppadovani comentou 28 dias atrás
Ei pessoal ... Eu achei meu tempo severamente limitado devido ao trabalho e à vida. Além disso, embora eu tenha conseguido fazer as coisas funcionar parcialmente, as mudanças que a equipe Kibana fez ao mudar para o React exigirão principalmente a reescrita de grandes partes do que eu fiz.

@ mika76 sim, este plugin é a única maneira de fazer com que objetos aninhados funcionem no momento.
Mas o que é estranho para mim, que Elasticsearch tenha suporte oficial para objetos aninhados, mas Kibana não.

Como mencionado @ bugs181 , atualmente não é mantido ativamente e isso significa que você não pode atualizar para a versão mais recente da pilha ELK.

Portanto, o suporte oficial também significa uma manutenção adequada. Mas como os desenvolvedores estão cuspindo sobre esse problema, não temos suporte oficial para isso.

Devo colocar @ bugs181 aqui. Marcar este problema com +1 e enviá-lo de outra forma não ajuda muito a aumentar a conscientização sobre isso, mas só fará as pessoas silenciarem ou nos aproximar do ponto em que precisarei bloqueá-lo, o que realmente não faço quero, porque gostaria de manter todos os assuntos abertos para discussão para todos, pois acredito na comunicação aberta.

Até agora, sempre recomendei o uso desse plugin. Eu não estava ciente de que isso não era mais mantido ativamente e fico triste em ouvir isso. Também sabemos que este problema está aberto há 5 anos e estamos executando uma análise sobre os problemas (em Kibana, obviamente - veja a captura de tela em anexo) e sabemos que este é o problema que mais reagiu:

Mas, como você sabe, existem (literalmente) milhares de outros problemas abertos, portanto, sempre precisamos equilibrar os recursos, correção de bugs, etc. para encontrar uma boa priorização. Além disso (mas não só), como esse recurso sempre teve um plug-in de comunidade de trabalho bastante sólido, ele não teve prioridade suficiente (para superar outros problemas) até agora. Além disso, como muitas vezes há muitas vezes relações técnicas entre coisas diferentes, e por exemplo para suportes de campo aninhados, atualmente queremos primeiro terminar nossa revisão de todo o pipeline de renderização de visualização (# 19813), antes de começarmos, uma vez que é altamente vinculado juntos. No entanto, estamos atualmente tendo esse problema em nosso roteiro para 7.xe esperançosamente não será bloqueado por outras mudanças técnicas, portanto, podemos mover esse recurso para o núcleo Kibana para torná-lo disponível sem um plug-in da comunidade.

A solicitação de suporte a visualizações de objetos aninhados inclui suporte para relacionamentos pai-filho? Tenho um cliente perguntando sobre visualizações pai-filho.

@MorrieAtElastic não, pai-filho seria um problema separado.

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

É realmente um grande problema, pois não podemos mostrar as relações 1: M corretamente em Kibana, pois o ElasticSearch oferece suporte a objetos aninhados, de modo que podemos carregar os dados, mas não podemos visualizá-los corretamente. Isso deve ser corrigido em breve.

Obrigado,
Rakesh

Comecei a trabalhar no suporte de campo aninhado em KQL hoje. Foi criado um problema separado para rastrear, já que o suporte total a campos aninhados em Kibana envolve muitas mudanças além de apenas KQL.

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

OMG isso é real? Depois de 5 anos ...

E quanto ao novo tipo de dados: achatado? Haverá suporte para visualizações para esse novo tipo no futuro? Muitos clientes de serviço estão sendo direcionados para esse novo tipo e estão perguntando se / quando as visualizações podem entrar em jogo.

@Barrybigbuddy Não tenho certeza de quais são os planos para o nivelamento, você poderia criar um tíquete separado para isso?

Eu gostaria de ter o relacionamento entre pais e filhos representado em Kibana. Portanto, solicite que você priorize esse recurso. Obrigado. M'Jay

+1

Incrível! +1 aqui! Existe um prazo específico para este recurso?

Deixe-me ser o estraga-prazeres aqui e dar um pequeno lembrete: há muitas pessoas que se inscreveram nesta edição (228 pessoas da comunidade + algumas equipes do Elastic), então seria bom se mantivéssemos +1 para um mínimo. Graças ao bom recurso de reação do GitHubs, você também pode adicionar sua aprovação e amor por @Bargs aos comentários dele sem acionar uma notificação para todos os assinantes (ou sua desaprovação, então ele pode parar de trabalhar no suporte de campo aninhado novamente: wink :). Além disso, especialmente por ser um tíquete tão grande, não o use para perguntas não relacionadas sobre outros tipos de campo.

Vou deixar algumas referências aqui para outros tipos de campo:

• Suporte para o tipo de campo flattened - atualmente não está em nosso roteiro de curto prazo
• Pensão aos pais / filhos - atualmente não está em nosso roteiro de curto prazo

Quando esse recurso chegará? Estamos trabalhando ativamente nisso e haverá diferentes fases para isso (KQL, suporte de filtragem, visualizações, etc.) que podem chegar em diferentes versões, e isso vai depender de como o processo de desenvolvimento será. Publicaremos solicitações de pull relacionadas a esse recurso como um comentário aqui, para que você possa ver no PR em qual versão essa fase / parte específica do suporte chegará.

Não tenho certeza se este é o mesmo problema, mas tenho um índice com lista de objetos, mas não usando o tipo de dados "aninhado". No entanto, em Kibana em "Campos disponíveis", não vejo campos dentro dos objetos que estão na lista. Esta é uma limitação conhecida?

@ppadovani o plugin está disponível para kibana-7.3.1?

Olá a todos, Acho que encontrei algum tipo de solução para este problema. Lendo o código-fonte dos mapeamentos, descobri que há uma opção include_in_parent para o tipo de mapeamento aninhado. Ao usar esta opção, consigo visualizar uma série de objetos em Kibana sem problemas !!! Por algum motivo, esta opção NÃO aparece na documentação do ES. Talvez eu esteja entendendo algo errado, mas aparentemente tudo funciona. Eu uso a opção de campos para que eu possa pesquisar tanto como palavra-chave quanto como texto completo.

Mapeamentos

PUT / test_index
`` `json
{
"mapeamentos": {
"dinâmico": "estrito",
"propriedades": {
"Estado": {
"tipo": "palavra-chave"
},
"criado por": {
"tipo": "aninhado",
"include_in_parent": verdadeiro,
"propriedades": {
"primeiro nome": {
"tipo": "texto",
"Campos": {
"cru": {
"tipo": "palavra-chave"
}
}
},
"último nome": {
"tipo": "texto",
"Campos": {
"cru": {
"tipo": "palavra-chave"
}
}
}
},
"dinâmico": "estrito"
},
"pessoas": {
"tipo": "aninhado",
"include_in_parent": verdadeiro,
"propriedades": {
"primeiro nome": {
"tipo": "texto",
"Campos": {
"cru": {
"tipo": "palavra-chave"
}
}
},
"último nome": {
"tipo": "texto",
"Campos": {
"cru": {
"tipo": "palavra-chave"
}
}
}
},
"dinâmico": "estrito"
}
}
}
}

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

O uso de include_in_parent ou copy_to como solução alternativa não é suportado e pode parar de funcionar em versões futuras.

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

Suporte a campo aninhado Fase 1 lançado em 7.6.0

Uma pequena atualização para este problema: acabamos de lançar o 7.6.0 do Kibana, que tem o suporte inicial para campos aninhados. Agora você pode usar campos aninhados nos seguintes lugares em Kibana:

• Os padrões de índice detectarão os campos aninhados corretamente
• Você será capaz de assistir a campos aninhados no Discover
• Filtrar em campos aninhados por meio da barra de filtros funciona
• KQL permite pesquisar campos aninhados (consulte a documentação KQL para obter uma explicação da sintaxe na consulta de campos aninhados)

No momento, estamos trabalhando para habilitar campos aninhados em visualizações e continuaremos atualizando este problema com informações relevantes.

Oi! Estamos aguardando o funcional NESTED. Quando podemos ver isso? Este é o único momento que não muda completamente para Kibana (Elastic é o melhor). O mundo inteiro está te observando.

A consulta de campo aninhado ainda está bugada com KQL.
Exemplo:
Considere o mapeamento de índice definido como
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
Eu criei o padrão de índice com base neste índice e desejo consultar first.second.field : "test"
Esta consulta na guia inspecionar irá gerar
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
o que está incorreto.
A versão correta também deve incluir sintaxe aninhada "nested": {"path": "first.second",...}

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

@IlyaHalsky Verifique a documentação KQL nos campos aninhados. Os campos aninhados requerem uma sintaxe específica para consulta, uma vez que você tem várias maneiras de consultá-los (no seu caso, você provavelmente deseja apenas fazer: first.second:{ field: "test" } ).

Você também deve ver uma notificação do sistema ao tentar usar um campo aninhado pela primeira vez em uma consulta KQL que o vinculará a essa explicação.

Eu pergunto se há uma nova versão do kibana que suporte o campo aninhado no visualizar:
meu exemplo de dados:
{
"fieldX": "x",
"fiedY": "Y",
"anomalias": [
{
"categoria": "sistema",
"nome": "cpu",
"data": "2020-03-11T13: 33: 40.000Z"
},
{
"categoria": "reiniciar",
"nome": "redefinir",
"data": "2020-03-11T13: 33: 40.000Z"
},
{
"categoria": "sistema",
"nome": "memória",
"data": "2020-03-11T13: 33: 40.000Z"
}
]
}

Quero visualizar um gráfico de pizza em kibana onde:
contagem de tamanho de fatia = contagem total de objetos da matriz de anomalias (contagem de documentos x contagem de objetos por matriz de anomalias)
primeiro balde = anomalies.category
segundo intervalo = anomalies.name

em outras palavras, eu quero visualizar a distribuição do nome da anomalia por categoria de anomalia?

+1

Alguma novidade sobre isso? A versão 7.6 já tem alguns meses, 7.7 e 7.8 não têm nenhuma menção a isso nas notas de versão e os documentos para 7.9, 7.xe master também não contêm informações novas sobre esta funcionalidade.

Apenas entrando na conversa também para expressar nossas grandes esperanças de obter suporte para agregações aninhadas em visualizações. Seria incrível!