+1 для агрегирования вложенных объектов.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000

+1

для ясности, сейчас нет возможности сделать вложенный фильтр / запрос / агг в kibana 4, не так ли?

+1

+11111

+1

+1

+1

+1

+1

+1

+1

+2

+1

+1 Потому что денормализация вложенных объектов не всегда возможна, так как это может привести к взрыву отображения.

Отображение:

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

Прежде всего, я хотел бы, чтобы линейная диаграмма показывала средний размер с течением времени для каждого имени пула. Предполагая, что существует так много имен, что денормализация не является хорошей идеей, это может привести к появлению множества графиков на диаграмме. Для работы с такими случаями также было бы полезно иметь возможность использовать агрегирование фильтров внутри вложенного агрегирования. Также было бы здорово иметь возможность фильтровать вложенные поля в верхнем поиске.

Чтобы сделать вещи еще более интересными, было бы действительно здорово иметь возможность визуализировать такую ​​агрегацию:

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

+1

+2

+1

+1

+1

+1

+10!

Было бы здорово с этим!

Так может кто-нибудь прояснить это; В этом сообщении (https://www.elastic.co/blog/kibana-4-beta-1-released) для Kibana4beta1 говорится, что «Kibana 4 предоставляет возможности вложенных агрегатов Elasticsearch одним щелчком мыши». Однако Я не могу создавать визуализации в документах с вложенными объектами. Я также удостоверился, что вложенные объекты в моем шаблоне индекса помечены как «вложенные». Разве поддержка вложенных агрегатов в Kibana отличается от поддержки вложенных объектов в ES? Что мне не хватает? Спасибо.

@cslinuxboy - я думаю, здесь используется

@ Alex-Ikanow - Спасибо за ответ. Жаль, что в настоящее время это невозможно. Я получил надежду, когда прочитал вводящее в заблуждение описание в их посте о бета-1.

+1 за поддержку вложенных объектов в агрегацию визуализаций.

+1

В настоящее время я использую отношения родитель / потомок в качестве обходного пути, который, похоже, работает нормально.

@calvdee У вас есть запросы has_parent или has_child для работы в строке поиска Kibana? Это не работает для нас, и это огромная проблема, я был бы ВЕЧНО благодарен, если у вас это будет работать и вы дадите мне знать ... спасибо !!!

Нет, в нашем случае у всех родителей есть дети, и у всех детей обязательно есть родители, поскольку мы индексируем данные счетов, поэтому обычные запросы просто работают (см. Изображение).

@calvdee Большое спасибо за ответ! У нас есть аналогичная модель данных, но мы хотим найти родителей по их детям в Кибане, она не работает: 0 (

Не беспокойтесь, удачи!

В чт, 26 марта 2015 г., 11:36 ajrasch [email protected] написал:

@calvdee https://github.com/calvdee Большое спасибо за ответ! Мы
имеют похожую модель данных, но хотят найти родителей по их
детей в Кибане, не работает: 0 (

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment -86575796.

+1

+1

Вы читаете поле _mapping, поэтому вы должны знать, когда конкретное поле является вложенным, поэтому не может ли оно автоматически применить правильный вложенный фасет / запрос, когда такое поле выбрано в запросах или фасетах?

Да, +1: на этом. Хотя мне удалось написать правильную вложенную агрегацию в CLI и получить данные с помощью curl, я не нашел способа заставить его работать на вкладке «Визуализация» Kibana, даже не используя поле редактирования JSON. По общему признанию, я никогда не использую эту функцию (поле), но кажется, что можно только «добавить» материал к существующей агрегации, а не использовать ее для создания новой агрегации с нуля ... (буду признателен за исправление если я ошибаюсь в этом!).

Да, агрегаты вложенных типов являются ключевыми и становятся все более широко используемыми, поскольку они решают конкретную проблему с плоскими данными.

Если Kibana4 является продуктом визуализации для ES, он должен поддерживать все агрегаты ES.

Было бы неплохо хотя бы увидеть это в дорожной карте Kibana4 .

+1

+1

+1

+1

+1

С № 3729 :-)

Хотелось бы видеть агрегатный вариант «дочерние документы»
(гистограмма после даты, гистограмма и т. д.), которая открывает
параметры для агрегата DSL запроса для дочерних элементов, например
«дочерний тип», «поля» и т. д.

Это позволит создавать вложенные агрегаты для дочерних
документы.

Кажется, я не могу создать такой запрос, используя
расширенная функция редактирования. Может быть кто-то может
просветите меня.

Спасибо

+1

+1

+1

+1 очень нужна эта способность. Я мог бы исключить всех родителей с помощью logstash в качестве обходного пути, но для этого потребуется огромный файл конфигурации, так как у меня есть сотни полей.

+1 кто-нибудь знает, планируется ли это?

+1

Прямо сейчас я подумываю изменить некоторые из моих сопоставлений, чтобы отказаться от использования объектов «вложенного» типа, поскольку я не могу создавать визуализации Kibana ни в одном из этих полей. Если бы я знал, что проблема есть хотя бы в дорожной карте, это бы очень помогло в принятии этого решения.

@benjismith - я тоже укусил пулю и переключил обработку моих данных с вложенных на родительские / дочерние документы. Пока все работает нормально, но я с вами согласен; Было бы неплохо узнать, есть ли шанс, что это когда-нибудь станет особенностью Кибаны, чтобы мы все могли либо дождаться этого, либо двигаться дальше.

Удачи.

+1

+1

+1 для поддержки агрегирования вложенных типов

+1

+1

+1

+1

+1

+1

Для тех, кто хочет выполнить простую агрегацию по определенным полям во вложенных документах (например, агрегация «терминов» в поле для поиска верхних значений), вы можете рассмотреть возможность добавления параметра «include_in_parent» в свое сопоставление Elasticsearch. Это создает плоскую версию поля во вложенном документе на родительском уровне.

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

Эти поля не будут отображаться в списке полей обнаружения с левой стороны, хотя вы увидите их в подробном представлении документа как поле массива. Однако у вас будет доступ к отдельным полям в списке показателей в Visualize, и вы сможете выполнять по ним агрегаты.

Вот что мы делаем для визуализации истории просмотра, которая основана на вложенной структуре документа (см. «Results.actions»):

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

+1

+1

+1

+1

+1

Вместо еще одного +1 ... Может быть, поможет краткая информация о том, где находятся агрегаты вложенных типов.

У меня 5 дней на то, чтобы научиться делать красивые графики, так что простите меня, если что-то из этого очевидно.

В чем проблема?

Это все еще проблема с запросом ElasticSearch или Lucene?

Это не решается агрегациями, но решается тем, что мы позволяем вам вводить elasticsearch JSON в поле ввода. Это не идеально, но если elasticsearch не расширяет синтаксис строки запроса lucene для указания вложенных полей, это лучшее, что мы можем сделать. - комментарий годичной давности rashidkpc

Кибана Исправить возможно?

Если ES / Lucene, может ли Kibana тем временем предоставить промежуточный хак / решение? Вспомните прокладки ES6 и префикс поставщика CSS.

Для вложенного отображения: возможность выбрать вложенное в редакторе (и настроить путь ...) для панелей Kibana. бобмер

Или:

Вы читаете поле _mapping, поэтому вы должны знать, когда конкретное поле является вложенным, поэтому не может ли оно автоматически применить правильный вложенный фасет / запрос, когда такое поле выбрано в запросах или фасетах?
Алекс-Иканов, ОП

Кто-нибудь взламывает решение? Кто-нибудь, у кого есть идея / направление взлома?

Работа вокруг?

Кто-нибудь имел успех с вложенным / include_in_parent? Требуются ли для этого dynamic: static , dynamic: true . Мои попытки не увенчались успехом, 0 результатов. трагин

У кого-нибудь есть примеры для поля ввода JSON, упомянутого выше rashidkpc?

Родитель / Ребенок

Это мой следующий шаг. Я уверен, что для этого есть много справочных материалов в Интернете, но не помешало бы ссылаться на примеры / учебные пособия для этой альтернативы.

Не имея знаний о внутреннем устройстве кибаны, я подумываю написать REST-прокси, расположенный между эластичным и кибанским. При запросе из Kibana определенного типа с учетом некоторых критериев поиска на основе терминов этот прокси-сервер сначала запрашивает родительский тип, чтобы найти набор родителей, удовлетворяющих критериям поиска (они соответствуют памяти). Затем он находит всех дочерних элементов для этих родителей и возвращает их в кибану денормализованными, со всеми добавленными родительскими полями. Это позволит нам иметь родительско-дочернюю модель в эластичном поиске, которая предотвращает взрывной рост хранилища из-за денормализации всего до миллиардов дочерних объектов и в то же время графически отображает данные на основе родительских полей.

В идеале это была часть Кибаны. Мир не плоский!

+1

+1. Мы использовали для разделения стека функций или url_args на разные поля. Но это произошло из-за слишком большого состояния кластера и слишком большого количества действий по обновлению сопоставлений. Итак, мы превращаем это во вложенный объект. Теперь нам нужны aggs в K4 ....

+1

+1 нужна визуализация агрегации родитель-ребенок.

+1

Не верьте, что все пользователи Elastic, которые хотят использовать Kibana, используют его для анализа журналов. У нас есть обширные данные с вложенными объектами, заполненные в нашем кластере, и мы хотели бы иметь возможность выполнять аналитику без необходимости извлекать и преобразовывать данные в еще одну систему.

Необходимо иметь возможность создавать вложенные агрегаты, вложенные запросы и даже агрегаты reverse_nested. Чем дольше Kibana обходится без этой функции, тем быстрее мы должны найти альтернативу без использования Elastic / Kibana. Если создание простого в использовании пользовательского интерфейса для такого рода функций является сложной задачей, начните с предоставления пользователям возможности предоставлять полный json-запрос для эластичного, который возвращает требуемые данные.

+1

Согласен с @ppadovani . Мы оценивали инструменты бизнес-аналитики и хотели бы использовать Kibana, но она не поддерживала отношения в наших бизнес-структурах, о которых нам нужно отчитываться, и была недостаточно удобна для использования неспециалистом. В итоге мы остановились на Looker (по сути, это графический интерфейс для SQL). Взгляд на looker может предложить некоторые идеи о том, как кибана может быть расширена для обслуживания более разнообразных вариантов использования в будущем.

Я решил взглянуть на код kibana 4.1 .. (я не могу использовать мастер, так как он работает только с эластичными версиями 2.x). Пожалуйста, поправьте меня, если я ошибаюсь, но это может показаться простым первым шагом, чтобы что-то сделать вместе эти строки:

1) В «расширенной» сворачиваемой области агрегации добавьте текстовое поле, называемое чем-то вроде «вложенный путь».
2) Если пользователь помещает строку в это поле, то агрегирование, на которое оно установлено, будет иметь вложенное агрегирование, добавленное к нему следующим образом:
"aggs": {
"2": {
"вложенный": {"путь": "foo"},
"aggs": {
"3": {
"date_histogram": {

Чтобы справиться с несколькими уровнями вложенных объектов, вы можете добавить +, который позволяет пользователю добавлять дополнительные вложенные пути. Кроме того, чтобы обрабатывать обратную вложенность, просто добавьте флажок с надписью «reverse».

Это, по крайней мере, обеспечит ограниченную поддержку «вложенной» агрегации.

Для поддержки вложенных запросов единственное решение, которое я могу придумать в краткосрочной перспективе, - это позволить пользователю вводить кодированный вручную эластичный поиск json.

+1

+1 ко всему этому и позволяет пользователю вводить жестко запрограммированный эластичный поиск json

+1

+1

+1. Я был очень взволнован использованием Kibana для наших нужд визуализации среды, но без поддержки визуализации вложенных объектов довольно болезненно использовать Kibana для наших целей.

+1, только что столкнулся с этим.

+1

+1

+1

+1

+1

По крайней мере 82 человека получили ваш "+1", и это НЕ помогает.

Я категорически не согласен. Больше данных никогда не бывает плохим.

Моя команда и я работаем над этим и надеемся, что, возможно, у нас будет что показать к концу недели.

РЕДАКТИРОВАТЬ: пожалуйста, посмотрите мои комментарии: https://github.com/elastic/kibana/pull/4645#issuecomment -132908544

+1

+1

+1

Готово, и здесь создан пул-реквест:
https://github.com/elastic/kibana/pull/4806

Быстрое обновление для тех, кто смотрит ... ожидает Elasticsearch co. чтобы подтвердить CLA, в противном случае я думаю, что это хорошо.

+1

+1 тоже

+1

+1

+1

+1

+1

+1

+10

+1

+1

+1

+1

Да, пожалуйста.

+1

+1

+1

+1

Запрос на вытягивание против 4.1 закрывается в пользу этого против мастера.

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

Если есть спрос на версию 4.1, я могу повторно открыть запрос на перенос с правильным кодом.

+1

+1

+1

+1

Я не понимаю, что блокирует по этой проблеме.
Ожидается пул-реквест https://github.com/elastic/kibana/pull/5411

Здесь есть люди, готовые внести свой вклад. Что нужно сделать для слияния этого пиара?

Определенно нужно больше +1

@ Filirom1 Некоторые из нас были в пути, поэтому у нас еще не было возможности просмотреть PR :( Мы постараемся добраться до него на этой неделе. Это определенно очень необходимое улучшение, и мы очень рады о вкладе сообщества здесь!

Большой :-)
Спасибо !

Я взглянул на № 5411 и, к сожалению, сейчас не в том направлении, в котором мы хотим двигаться. В # 5411 реализован стоп-интервал, но из-за этого важные функции, такие как фильтрация и поиск, не работают. Это также привело к тому, что сам построитель аггрегатов казался неисправным для тех, кто не понимает лежащую в основе реализацию вложенных агрегатов. После того, как мы сели и посмотрели глубже, мы поняли, что объем работы по согласованной поддержке вложенных документов был огромным.

Дело не в том, что мы не хотим этого делать, дело в том, что если мы это делаем, мы хотим делать это правильно, а не просто обходить это стороной.

Мы понимаем, что многие заинтересованы в визуализации реляционных данных, однако, учитывая другие приоритеты и проблемы, у нас нет ресурсов для этого проекта в настоящее время, и мы не можем взять на себя обязательство добавить его в дорожную карту в обозримом будущем.

К вашему сведению, мы надеялись использовать кибану с вложенными агрегатами для внутренней аналитики, но в итоге остановились на коммерческом продукте Looker, который находится непосредственно в наших rdbms. Я настоятельно рекомендую разработчикам Elastic взглянуть на то, что они сделали, чтобы упростить изучение реляционной модели, поскольку многие люди, не являющиеся техническими специалистами, теперь могут просматривать нашу живую базу данных, чтобы задать повседневные вопросы о продукте. Я оценил ряд продуктов, и Looker вышел на первое место, и я хотел бы однажды увидеть аналогичную функциональность в Kibana.

Учитывая последний комментарий Рашида и долгое ожидание этой функции, я рекомендую закрыть эту проблему. Если проблема останется открытой, это даст пользователям ложную надежду на то, что в ближайшем будущем это будет реализовано. Давайте закроем его и протестируем идею, пока у разработчиков не появятся ресурсы, чтобы выяснить, как ее реализовать.

Копирование моего поста из пул реквеста:

Здесь ЕСТЬ решение, но это потребует значительного объема работы, а у меня просто нет времени. Мы реализовали это в JAVA, поэтому я знаю, что это возможно.

1) Каждое отображение индекса должно извлекать и понимать вложенные поля.
2) Создайте собственный AST, который предоставляет упрощенный язык запросов, вместо того, чтобы пытаться просто использовать Elasticsearch.
3) Создайте адаптер запроса, который понимает AST и может проверять и преобразовывать запрос в правильный JSON.
4) Обновите агрегаты в Kibana, чтобы правильно обрабатывать вложенные поля на основе внутреннего понимания вложенных полей.

Это не невозможно, просто требуется значительная работа. Преимущества реализации вышеизложенного включают проверку запроса и упрощенный синтаксис. Например, наш AST позволяет нам создать такой запрос:

(owner.user = "/ users / 00a0 / 18066271-29f0-40af-83ad-e5a0c8fc5944") И (druid = "/ druids / 0060 / 77dd14b1-b7f0-4851-9ef8-74daa18d9d4d") И ((owner.lastMessageReceived. вставлено> = 0) ИЛИ (talkLifecycleState = "RESERVATION_REQUEST")) И (owner.conversationArchived = false) И ((units.site IS NULL) OR (units.site IN {"HOMEAWAY_DE"})) AND ((query.inserted > = 0) ИЛИ НЕ (Booking.availabilityStatus = "DELETE")) И НЕ (owner.markedSpam = true) И (lastMessage.inserted> = 0)

Как именно я могу сделать этот запрос на существующем языке?

ИМХО - ожидание нирваны от Elasticsearch до начала действия приведет к падению принятия и потере пользователей Kibana.

Ненавижу звучать так, будто я занимаюсь маркетингом, но это актуально. (видели, как люди упоминали другие продукты ..)

Мы обнаружили, что многие пользователи, которые интенсивно использовали вложение, хотели на самом деле искать в реляционных данных и закончили тем, что вложили записи, которые вместо этого следовало просто «объединить» поздно. (Падовани, это может быть ваш случай, я вижу "сообщения" пользователей и т. Д., Это было бы очень хорошо хранить как отдельные записи)
По этой причине мы создали плагин SIREn Join elasticsearch и вилку Kibi our-friendly - Kibana, которая предлагает фильтры и функции для этого.

Сейчас мы работаем над тем, чтобы сделать как можно больше от Kibi в плагинах, совместимых с Kibana 4.4 (также известный как 5.0), для всеобщего блага.

Плагин Join был выпущен вчера, и он также имеет открытый исходный код.

Между тем, доступная версия http://siren.solutions/kibi, откровенно говоря, работает как шарм, и многим нашим клиентам больше не нужны вложенные данные.

jccq: Никогда не знал о Kibi или плагине соединения. Спасибо за информацию!

+1

+1
это обязательная проблема ...

@jccq Наш

Что касается вложенной поддержки в Kibana, мы развиваем наш подход и, возможно, нам есть чем поделиться с сообществом во втором квартале или раньше, в зависимости от ресурсов и времени. Этот новый подход будет поддерживать беспрепятственное вложение как в агрегаты, так и в запросы. Я не буду говорить больше, так как он все еще находится на очень ранних стадиях реализации.

+1

@ppadovani ты тот!

+1

+1

+1
Для нас это действительно важно.
Ждем эту фичу почти год ...

+1

Обновление: я не вижу, чтобы моя новая ветка была готова для предварительной обратной связи или тестирования в течение как минимум месяца из-за моей рабочей нагрузки. Однако я хотел рассказать о том, что я делаю, чтобы собрать отзывы сообщества по мере продвижения вперед.

Базовый дизайн вращается вокруг двух вещей:

1) Новый парсер запросов для поля запроса произвольной формы Kibana. Этот синтаксический анализатор использует стандартное определение синтаксиса Bison (см. Проект Jison для версии javascript, которую я использую). Используемый мной BNF основан на существующем BNF, который мы используем в Homeaway для нашего настраиваемого языка запросов к Elasticsearch. См. Мой комментарий выше для примера. Я выбрал этот подход, чтобы сообщество могло вносить улучшения в будущем по мере необходимости.

У меня есть синтаксический анализатор запросов, работающий в Kibana, но мне еще нужно поработать, чтобы позволить пользователю переключаться между существующим стилем запроса, используемым Kibana, и этим новым стилем:

2) Измените вызов getFieldMapping в mapper.js на getMapping и обработайте результаты по-другому, чтобы вложенный путь в полях фиксировался и добавлялся к информации поля, которую хранит Kibana.

Когда запрос вводится в синтаксический анализатор, он проверяет, что не только поля были правильно названы, но и что предоставленные значения действительны для типов полей. Т.е. поле даты получает дату, или логическому значению было присвоено логическое значение. Кроме того, вложенные поля будут автоматически обрабатываться парсером, и вместо простого языка запросов, который используется сейчас, будет сгенерирован правильный json-запрос Elasticsearch.

Наконец, для агрегатов, поскольку поля теперь содержат подсказки о вложенных путях, будет тривиально работать с моей предыдущей веткой, чтобы автоматически вводить вложенные агрегаты по мере необходимости на основе выбранных полей.

Основные вехи:
1 - Получите функционал парсера и генерацию запросов
2 - Обновите mapper.js и реализуйте поддержку вложенных запросов.
3 - Реализовать поддержку вложенной агрегации
4 - Тестирование / очистка

Мы будем очень благодарны за любые отзывы об этом подходе. Спасибо!

Обновите указанное выше:

• Парсер завершен
• Обратный синтаксический анализатор завершен (принимает файл elasticsearch json и преобразует его обратно в язык пользовательских запросов)
• Kibana теперь определяет и сохраняет вложенные пути в полях
• Парсеры теперь имеют доступ к информации о поле

Еще предстоит:

• поддержка вложенных путей в обоих парсерах
• Конструкция пользовательского интерфейса, позволяющая пользователю переключать стиль запроса, который следует использовать, и позволяет сохранять / использовать устаревшие запросы.
• закончить обработку ошибок в парсерах и как пользовательский интерфейс отображает проблемы / ошибки парсинга
• Конструкция пользовательского интерфейса для поддержки опережающего ввода имен полей в запросе
• вложенная поддержка в сегментах / метриках
• модульные тесты, модульные тесты, модульные тесты.
• ...?

+1

Обновлять:

• Парсер автоматически обрабатывает / вводит вложенную информацию
• Агрегации теперь автоматически обрабатывают / вводят вложенную информацию

ДЕЛАТЬ:

• Изменения пользовательского интерфейса для выбора стиля запроса и сохранения выбора стиля с запросом в индексе кибаны.
• обработка ошибок для ошибок парсера, и как пользовательский интерфейс отображает проблемы / ошибки синтаксического анализа
• Поддержка опережающего ввода пользовательского интерфейса для создания / написания запросов
• модульные тесты, модульные тесты, модульные тесты ...

План:
Я хочу добиться хотя бы некоторого прогресса в работе с пользовательским интерфейсом, а не моей сильной стороной, тогда мы отправим ветку / разветвление в репозиторий HomeAway на github, чтобы обеспечить обратную связь / вклад. Я опубликую здесь еще раз, когда это будет сделано, чтобы любой из вас, кто хочет вытащить вилку и поиграть с ней, был более чем рад. Как только он будет достаточно отполирован, я создам официальный запрос на перенос.

И последнее замечание: эта работа ведется против ветки Kibana 4.3.1.

В продолжение моего предыдущего комментария об использовании «include_in_parent» и «include_in_root» для копирования выбранных полей из вложенных документов на верхний уровень с целью выполнения на них агрегатов, в ES 2.0 была введена функция «copy_to», которая предоставляет еще один вариант для такого рода вещей: https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html
Есть разговоры об отказе от "include_in_parent" и "include_in_root" в пользу copy_to в будущей версии ES: https://github.com/elastic/elasticsearch/issues/12461 Если у вас есть опыт работы с обоими, не стесняйтесь взвесить.

+1

ppadovani, цените то, что вы пытаетесь сделать. Эта функция очень важна для нас
Несколько вопросов:

1. Я так понимаю, это займет время? Есть ли приблизительное время, когда эта функция будет доступна?
2. Кто-нибудь пробовал альтернативу? Как изменить формат журнала с вложенных json (массивов) на что-то другое? Если да, то каким должен быть предполагаемый формат для работы с ELK?
3. Есть ли на рынке какой-либо другой продукт, который может помочь в достижении этой функциональности? Я полностью за ELK, потому что это открытый исходный код, но пока это не так, нам нужно что-то подешевле, чем Splunk. Мы изучили множество вариантов, таких как Loggly, sumologic, logentries, logscape, graylog (либо такие же дорогие, как splunk, либо у них нет этой функции)

Большое спасибо!

1. Кто-нибудь пробовал альтернативу? Как изменить формат журнала с вложенных json (массивов) на что-то другое? Если да, то каким должен быть предполагаемый формат для работы с ELK?

Вы можете сгладить схему или использовать параметры сопоставления ES «include_in_parent» или «copy_to» для копирования некоторых полей из вложенных документов в родительские документы. Не работает для всех случаев использования, но в некоторых случаях это позволит вам использовать Kibana из коробки. Мы используем подход «include_in_parent» внутри компании Elastic.

1. У меня есть ветка, которая «работает», но мне нужно больше TLC в виде работы с пользовательским интерфейсом. Это не моя основная работа, поэтому я могу работать над ней только тогда, когда у меня есть время.
2. Как указывает @tbragin , вы можете сгладить данные. Однако это может привести к неверным результатам запроса.
3. На данный момент я не знаю никаких альтернатив.

Чтобы быть более ясным относительно того, как выглядит язык запросов, поскольку меня спрашивали в моем старом запросе на перенос, вот краткое изложение BNF:

Сравнение: значение поля [=, <,>, <=,> =, ~ =]
Обратите внимание на ~ = .. это указывает на LIKE, что, в свою очередь, вызовет запрос с подстановочными знаками.
IN: поле IN {значение, значение, ...} Установить операцию
поле IN [значение, значение] Операция диапазона с использованием [] или () в зависимости от включения / исключения
IS: поле IS NULL
выражение: IS | В | Сравнение
НЕ: НЕ выражение
И | ИЛИ: выражение И |
EXISTS: EXISTS выражение
Существует способ определения вложенного. Обычно без использования EXISTS все выражения, расположенные рядом друг с другом и имеющие один и тот же вложенный путь, будут объединены в один и тот же вложенный запрос. Однако вы можете разбить блок вложенных запросов, используя EXISTS, чтобы ограничить отдельные вложенные запросы друг от друга.

Как указывалось ранее, язык использует JISON, эквивалент BISON в javascript, и позволяет нам расширять язык по мере необходимости с очень небольшими усилиями.

ОБНОВИТЬ:

Я считаю, что я близок к тому, чтобы поделиться веткой со всеми, чтобы протестировать и оставить отзыв. У меня работает синтаксический анализатор (-ы) и, по крайней мере, работает синтаксическая обратная связь, а также модульные тесты против анализатора. Некоторые скриншоты:

Я надеюсь, что позже на этой неделе у меня будет готовая ветка. Когда он будет готов, я дам ссылку на сообщение в блоге здесь, которое будет ссылаться на ветку и иметь полное изложение синтаксиса, использования и т. Д. Мой план состоит в том, чтобы собрать отзывы о ветке, исправить проблемы, улучшить по запросу, а затем получить запрос на перенос.

Я хотел бы протестировать его (вот пример нашего использования вложенных агрегатов в K3 https://discuss.elastic.co/t/nested-aggregation-charts/41523, без него миграция не будет).

@Robitx Я не думаю, что это будет проблемой ... у нас есть документы, в которых есть как минимум два уровня вложенных объектов ... например:

А-> В-> С

Если в одном документе A может быть один или несколько B, и каждый из них содержит список C, которые находятся на B. Каждый вложенный документ имеет несколько полей разных типов. Я протестировал этот код, чтобы построить гистограмму или многослойную круговую диаграмму по самым внутренним вложенным данным.

Чтобы было ясно, наши сопоставления автоматически генерируются из наших pojos и могут стать очень сложными.

+1

ОБНОВИТЬ:

Я хотел дать людям возможность начать играть, а не ждать появления официального сообщения в блоге с моей стороны.

Вилку / ветку можно найти здесь:

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

ПРОЧТИ МЕНЯ:

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

Содержимое README - это, по сути, содержимое сообщения в блоге, которое в какой-то момент появится.

Не стесняйтесь открывать вопросы / запросы на включение в ветку fullNestedSupport, если хотите. Я постараюсь быть в курсе любых проблем, которые обнаруживают люди.

+10000

+100500

+100

Привет, ппадовани,

Не могли бы вы посоветовать, что мне делать

Это поле присутствует в вашем сопоставлении elasticsearch, но не присутствует ни в каких документах в результатах поиска. Вы все еще можете визуализировать или искать по нему.

Большое спасибо!

Привет, ппадовани,

У нас есть поле в виде вложенных массивов.
"abc": [["3815222235847451", "131712121218083052"]]
ИЛИ
«abc»: [[«3815222235847451», «131712121218083052», «131712121217783052»]]
ИЛИ
"abc": [["3815222235847451"]]

Значения могут быть любыми от 1 до 10.

В то время как для других вложенных полей я вижу предупреждение о том, что поле не проиндексировано (что, я полагаю, мне нужно использовать сопоставления?) Для этого поля и других подобных полей, каждый набор обрабатывается как отдельное значение? Кроме того, тип поля отображается как «строка» вместо числа, что само по себе не является проблемой, но это означает, что я не могу найти какое-либо отдельное значение abc ..?

Большое спасибо!

Нашел несколько минут для начала тестирования :): |

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

@BigDataEngineer
1) - Я не верю, что это сообщение, созданное моими изменениями, и может быть чем-то, что существовало в Kibana ранее.
2) - Так что да ... похоже, что значения хранятся в виде строки, но они, возможно, не вложены ... Мне нужно было бы посмотреть, как выглядит сопоставление в индексе, чтобы понять, какая / если проблема существует. Пожалуйста, вставьте карту сюда.

@Robitx
Я предполагаю, что это было поле даты ... время эпохи имеет слишком много цифр, должно быть 10, а не 13 .. вы можете обновить / вставить запрос, который вы отправили?

@ppadovani
Я только что выбрал шаблон индекса по умолчанию в настройках и вернулся, чтобы открыть вкладку

Мы используем

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

K 4.4.1 + ES 2.2 работает нормально, возможно, это специфично для K 4.3 (раньше я эту версию не пробовал)

@Robitx
Я ищу используемый запрос ... или вы говорите, что переданный запрос был просто стандартным окном даты из пользовательского интерфейса, и вы не указали запрос? Я перенастрою свои изменения на более позднюю версию Kibana и сделаю репост, когда ветка будет обновлена.

@ppadovani да просто * и некоторый временной диапазон

+1 для вложенных объектов в разделе визуализации

@Robitx
Эта операция, которую вы выполнили, никогда не попадала в мой код парсера ... поэтому я сомневаюсь, что это произошло из-за того, что я сделал ... Моя установка - K 4.3.1 + ES 2.1.1 - я обновлю свой ES до 2.2 и посмотрим, получу ли я такое же поведение, тогда я переустановлю ветку на K 4.4.1

Только что обновился до ES 2.2.1 с K 4.3.1 + мой код ... не удалось воспроизвести:

Я все равно сделаю ребаз до 4.4.1 - текущий выпуск, обновлю этот пост, когда ветка будет готова.

ОБНОВИТЬ:

Перешел на 4.4.1 в новой ветке: https://github.com/homeaway/kibana/tree/nestedSupport-4.4.1

Проверено на ES 2.2.0 и K 4.4.1

Привет, ппадовани,

Что касается моих предыдущих вопросов, я откажусь от них. У меня уже есть экземпляр эластичного поиска в AWS (вместе с сопоставлениями), и я пытаюсь подключить его к этому. Однако статус сервера кибаны в пользовательском интерфейсе говорит:

плагин: elasticsearch Эта версия Kibana требует Elasticsearch ^ 2.1.0 на всех узлах. Я обнаружил следующие несовместимые узлы в вашем кластере: Elasticsearch v1.5.2 @ undefined (undefined)

Я все еще использую https://github.com/homeaway/kibana/tree/fullNestedSupport, а не последнюю версию, предоставленную вами. Возможно ли сделать его совместимым с 1.5.2?
Добрый совет.

Большое спасибо!!

@ppadovani
Я могу понять, возможно ли это, поскольку мы идем в обратном направлении, однако Amazon Elasticsearch Service не очень заинтересован в обновлении до более новых версий, что понятно. Итак, я должен работать с тем, что у нас есть. Мы вложили много усилий в настройку экземпляра AWS (наряду с пересылкой журналов с нескольких узлов, потоковыми событиями и другими мельчайшими подробностями), и заново изобретать все на отдельной платформе с нуля для нас не вариант. Было бы хорошо иметь возможность подключить это как дополнительный Frontend. Я даже не уверен, будет ли еще один блокпост в будущем?

Спасибо!!

@BigDataEngineer
Посмотрев на код Kibana в предыдущих версиях, первой версией, к которой я смог попробовать применить изменения, является 4.1.6. Однако произошла значительная переработка / рефакторинг / реорганизация кода, и я не могу просто исправить эту ветку. Потребуется значительный объем работы, чтобы попытаться заставить мой код работать.

Честно говоря, я не знаю, почему команды Kibana выпускают необходимую эластичную версию, как они делают это с каждым выпуском ... интерфейс REST просто не так часто меняется. Я предполагаю, что они делают это, чтобы заставить пользователей обновить свои эластичные кластеры.

Одна мысль, вы можете попробовать изменить версию в src / plugins / elasticsearch / index.js около строки 27

@ppadovani
это сработало. Спасибо.

+1

@ppadovani Привет, спасибо за обновление до версии 4.4.1, извините, что не ответил раньше (я пропустил ваше обновление в одном из предыдущих комментариев).

Сейчас он работает, но первое, что я заметил, это проблемы с производительностью и иногда кибана полностью зависает (более сложные запросы мне не удалось протестировать).

Есть несколько вещей, которые могут способствовать возникновению этой проблемы, одно из них - это количество полей в нашем ежедневном индексе (их сотни http://pastebin.com/fktN0dR5).

@Robitx У вас есть те же проблемы с базовым кодом 4.4.1 K без моих изменений? Или это только с моими изменениями? Я знаю, что очень большие шаблоны индекса вызывают значительные проблемы с производительностью для K. Если это связано только с моим кодом, то я думаю, что знаю, что это может быть. Я посмотрю на него, когда выйду подышать воздухом через день или около того.

@ppadovani у базы K 4.4.1 этой проблемы нет

Год с тех пор, как проблема не устранена ...

Блин, у elasticsearch есть довольно необходимая функция «Вложенные объекты», а Kibana от тех же разработчиков до сих пор не поддерживает эту функцию.

У вас есть форк, который уже реализует эту функцию и до сих пор не объединен в основной исходный код с надлежащей поддержкой.

И мы по-прежнему не можем использовать в нашем проекте стандартную версию KIbana с поддержкой «Вложенных объектов».

Чертовски потрясающе !!!

@ppadovani большое спасибо за вашу работу над форком =)

@Robitx Можешь сказать мне, когда Кибана замерзает из-за тебя? Определение IndexPattern? Или когда вы начинаете новый запрос? Есть возможные области, в которых это может быть, и я хочу сузить круг вопросов.

Я исправил одну проблему, которая могла быть связана с открытием вкладок обнаружения / визуализации ... Я внес исправление, повторите попытку.

@rashidkpc Я готов сгенерировать

Эй, банда (cc @ppadovani)

Как я уже упоминал в https://github.com/elastic/kibana/pull/5411, в самом Elasticsearch есть ряд ограничений, в частности, вложенные агг / фильтры не являются автоматическими, а синтаксис запросов lucene не поддерживает вложенный поиск. Хотя применяемый здесь подход может наметить другой путь к решению проблемы, это не то направление, в котором мы хотим двигаться. Это решение узкой проблемы, но мы хотим, чтобы Kibana решила широкий круг задач. В данном случае это означает, что в будущем придется жертвовать меньшими победами ради более крупных.

Пока мы рассматриваем возможности языка для Kibana, мы еще не решили, какой именно набор функций мы хотим, и не хотим делать это на полпути или с единственной целью. Мы рассматриваем некоторые тактики и наборы функций как в Elasticsearch, так и в Kibana, но мы все еще находимся в стадии формирования. Со временем мы хотели бы, чтобы это включало поиск, преобразование и визуализацию, как вы видите в чем-то вроде timelion, и мы, безусловно, будем помнить об идее запроса вложенных документов, когда мы это делаем.

Я заметил, что это сохраняет вложенный путь, однако мы удаляем кешированное сопоставление https://github.com/elastic/kibana/pull/6648 и заменяем его новыми API в Elasticsearch: https://github.com/elastic / elasticsearch / вопросы / 15728. Пожалуйста, взвесьте этот вопрос, было бы здорово, если бы Kibana не нужно было разбирать вложенный путь. Это особенно важно для нашей цели сделать очень большие документы доступными в Кибане.

На данный момент мы рекомендуем использовать подход @ tbragin с использованием include_in_parent или copy_to . Для 90% агрегатов этот подход будет работать отлично.

Я рад, что это решение работает для тех, кто не может использовать include_in_parent или copy_to , очень впечатлен тем, что удалось сделать

эй, вмешиваюсь. Я поговорил с Рашидом об этом, и, хотя я чувствую боль пользователей, желающих использовать Kibana для вложенных сопоставлений, поддержка его в более общем виде (что может подразумевать дополнительные функции на самом уровне Elasticsearch) - это путь вперед это поддерживает гибкость, необходимую нам в Кибане. Хотя получение этого предлагаемого изменения может решить краткосрочную проблему отсутствия поддержки вложенности, в будущем это окажется проблематичным.

Я возглавляю и чувствую, что здесь Kibana должна поддерживать вложенные, но это один из тех случаев, когда, если неочевидно, как это нужно решить, лучше оставить его нерешенным, пока мы не получим решение, которое кажется естественным. Нам определенно нужно продолжить и исследовать это, один из тех, о которых мы болтали в разных местах, автоматически поддерживает вложенность (обертывание и так далее) в самом ES.

Я ощетинился от волнения, увидев, как это элегантно решено.

+1

+1

ИМХО, я должен с уважением не согласиться с позицией разработчиков Kibana. Однако, если мы сможем найти способ подключить что-то в этом роде к Kibana, я буду всем за это.

А пока я буду продолжать поддерживать и исправлять ошибки в моей вилке (-ах) / ветвях для тех, кто хочет и дальше использовать созданную мной версию. Я знаю, что в будущем мы будем широко использовать это для живых панелей аналитики BI.

Крупный рогатый скот. Не домашнее животное.

+1 :)
Было бы здорово использовать вложенные объекты в Кибане !! (У кого-то есть плагин для этого или нет? ...)

+1

+1

+1

@tbragin Упомянутый вами подход не работает с вложенными типами. Он объединит все данные независимо от типа.

+1

+1

+1

+1

Эта функция настолько проста, что я был шокирован, обнаружив, что она не только не поддерживается, но и, по-видимому, разработчики не планируют ее поддерживать. Черт возьми, поговорите со своими менеджерами проектов и наймите @ppadovani, чтобы он сделал плагин, если вы, ребята, сами этого не сделаете.

+1 так как отсутствие вложенных объектов существенно мешает моему проекту

Для тех, кто хочет обсудить денормализацию как способ обойти эту проблему: Обойти отсутствующую поддержку Kibana для вложенных объектов и родительского / дочернего элементов.

Elastic было бы замечательно, если бы на сайте был отказ от ответственности по этой проблеме, чтобы пользователи не тратили там время, пытаясь реализовать неподдерживаемую функцию. Почему? На странице продукта Kibana написано «Полная интеграция с ElasticSearch», что здесь неверно :)

К вашему сведению - ветвь моего кода, на которую ссылается вышеупомянутое обсуждение, старая .. текущая ветвь:

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

Мы активно используем его внутри и продолжаем обновлять нашу внутреннюю версию. Я могу / обновлю версию на github, если будет интерес.

Пьер

+1

+1

+1

+1

+1

+1

Я помню, как добавил +1 к этому больше года назад, и с тех пор команда разработчиков Kibana ничего не делала, кроме как выкапывала свои исцеления и в основном игнорировала пользователей, и, наконец, когда их ноги подвергаются огню, они отвечают более-или- меньше «НЕТ», заявив, что «это неестественно».

Я также вижу этот шаблон во многих других запрошенных функциях, таких как:

• Поддержка вызова groovy-скриптов на стороне ОС.
• Поддержка использования ES Scripted Metric Aggregations (особенно полезно для расчета средневзвешенных значений).
• И так далее...

Все это идет вразрез со всем видением Elastic Stack 5, в котором говорилось, что они (Elastic) будут поддерживать более базовые функции Elasticsearch в Kibana. Но я очень мало видел, чтобы подтвердить эти утверждения.

В результате я вижу, что Kibana уступает место вилкам, таким как Siren's Kibi, которые решили взять эстафету на такие предметы, как эта тема, и придумали решение.

Я благодарен разработчикам Kibana за то, что они предоставили нам отличный инструмент для визуализации. Но Elastic необходимо решить, будет ли Kibana оставаться упрощенным инструментом визуализации или прислушиваться к сообществу и расширять его полезность. Если решение первое, то ожидайте, что пользователи уйдут, когда другие решат воспользоваться этими недостатками.

+1

@cslinuxboy

Поддержка вызова groovy-скриптов на стороне ОС.

Большинство случаев использования, охватываемых этим, будут решены https://github.com/elastic/kibana/pull/7700.

Поддержка использования ES Scripted Metric Aggregations

Я не думаю, что кто-то против этого (по крайней мере, не вижу здесь возражений https://github.com/elastic/kibana/issues/2646), на самом деле сейчас самое время добавить это, так как Elasticsearch добавил безболезненный язык сценариев. На самом деле это просто вопрос того, чтобы кто-то нашел время.

+1

+1

+1

Я снова начинаю работать над своей вилкой. Я хочу извиниться перед сообществом, примерно месяц назад я понятия не имел, что я не включил проблемы для вилки, поэтому никто не смог бы указать на наличие ошибок. Это было исправлено.

Текущая ветка: https://github.com/homeaway/kibana/tree/nestedSupport-4.5.4

Обновления в том порядке, в котором я собираюсь их реализовать:

• Добавить поддержку смещения дат в парсер запросов
• Добавить поддержку обнаружения вложенных полей при просмотре результата - ГОТОВО
• Добавить поддержку родительских / дочерних запросов и агрегатов
• Добавить поддержку типов гео-форм для запросов (например, точка, прямоугольник и т. Д.). Это порт недавнего улучшения нашего внутреннего языка.
• Добавить опережающий ввод для имен полей в поле запроса
• Я мог бы попытаться создать синтаксический анализатор для существующего простого языка запросов Elasticsearch, чтобы устранить раздражение из-за недопустимого запроса, вызывающего либо возвращение трассировки стека из Elasticsearch, либо отсутствие результатов без указания причины. Если я буду над этим работать, то это будет после того, как я выполню все вышеизложенное. Если я сделаю это, я посмотрю на добавление вложенной и родительской / дочерней поддержки к языку на стороне Kibana.

Я хочу добавить свой голос к тем, кто указал, что команда Kibana не слушает сообщество. Команда Kibana НЕ МОЖЕТ просто полагаться на Elasticsearch для обеспечения необходимой функциональности, если есть пробел, чтобы сохранить Kibana «чистым». Таким образом рыночная доля не достигается, она теряется.

+1

+1
@Bargs : Есть ли прогресс по этому вопросу? Когда это будет рассмотрено / расставлено по приоритетам?
Очень длинная нить .... Это не подходит для таких продуктов, как кибана ..
Мы ценим ваши старания

Это отстой :-(

У homeway есть вложенные сборки aggs и поддержки запросов на Kibana 4.3.1, проверьте это .. надеюсь, что это поможет ..

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

@ankitchheda Я знаю об этом, но форк, поддерживаемый немногими людьми, который идет вразрез с философией основного проекта (который находится в стадии интенсивной разработки), не является решением, делая вид, что он никому не поможет.

Я бы хотел что-то с этим сделать, но у меня нет времени, поэтому сейчас я, по крайней мере, пытаюсь оказать давление и надеюсь, что разработчики перестанут игнорировать эту проблему: |

+1

К вашему сведению - вилка, которую я поддерживаю для вложенной поддержки, теперь поддерживает следующие версии:

4.5.X
4.6
4,7
5.X

Возможно, он не соответствует «философии» основных разработчиков, но работает и работает хорошо.

Я только что столкнулся с этим. Это небольшой недостаток, и было бы действительно полезно иметь работоспособное решение.

@tbragin , @rashidkpc - предлагаемый обходной путь упускает суть - вы получаете
что-то не так с вложенными объектами - но вы получите неправильные результаты! Вложенный
агрегации дают разные результаты (я сделаю небольшой рабочий пример и опубликую его здесь позже).

Протестирую форк @ppadovani.

+1

: черепаха :: тире:

@Bargs Привет, изменения от вилки вредит производительности базовой функциональности?

+1

+1

+1

+10086

+1

+1

+1

include_in_parent все еще работает на ES и Kibana 5.2? Я безуспешно пытался использовать как альтернативу.

@gustavomr Я считаю, что это сработает, но только для определенных случаев использования. Он не будет работать для всех возможных вариантов использования запросов, которые могут предоставить вложенные запросы / агрегаты.

ПРИМЕЧАНИЕ. Моя вилка Kibana 5.1 теперь использует переключатель рядом со значком поиска для переключения между собственным эластичным языком простых запросов и языком вложенных запросов, который я включил. Я также исправил множество проблем, связанных с показателями вложенных полей.
https://github.com/homeaway/kibana/tree/nestedSupport-5.1

@ppadovani большое спасибо за это. Можно ли отделить вашу работу по включению вложенных объектов в кибане от вашей работы по созданию нового языка запросов? Если это могут быть отдельные ветки, тогда мы можем просто использовать предыдущую и объединять ее с новыми выпусками kibana по мере их выхода, вместо того, чтобы объединять обе функции.

Также у вас уже есть докер для этой вилки?

@ppadovani +1 для контейнера

@gkozyryatskyy - Пожалуйста, откройте вопрос на вилке, и я посмотрю на него.

@ imranq2 - я мог бы это сделать, однако учтите, что простой эластичный язык запросов не поддерживает вложенные запросы. Если у вас есть вложенные данные и вы хотите запросить их, вам придется вручную создать запрос как большой двоичный объект elasticsearch json и вставить его в поле запроса.

+1

Моя вилка теперь поддерживает 5.2 в ветке nestedSupport-5.2.

@ppadovani Замечательно ! Дайте мне знать, если вам понадобится помощь в создании контейнера для докеров.

Еще не закончили контейнер докеров, но у меня было время поиграть с вкладкой обнаружения и тем, как она отображает вложенные данные ... ищу отзывы от тех, кто следит за проблемой вложенной поддержки. Таблица является рекурсивной, и фильтры для вложенных полей, похоже, работают хорошо ... но поле переключения в столбце еще не работает ... Мне все еще нужно подумать, как / если это должно работать.

К вашему сведению - эта работа в основном завершена, и все поддерживаемые вилки / ветки имеют изменения, начиная с nestedSupport-4.5.4 и заканчивая nestedSupport-5.2.

@Bargs - Я знаю, что ни одна из вложенных мной работ не является тем, что вы, ребята, хотите реализовать, но мне любопытно, может ли вам понадобиться работа по отображению вложенных данных в результатах обнаружения. Это не зависит от моей предыдущей работы. См. Обновленные снимки экрана в этой проблеме:
https://github.com/homeaway/kibana/issues/12

Если вам это нужно, дайте мне знать, и я открою проблему и включу патч.

Интересно выглядит @ppadovani ! Если вы хотите открыть PR, мне определенно будет интересно его проверить. Мы немного поговорили о добавлении улучшенной поддержки вложенных полей в Discover, поэтому было бы здорово обсудить что-то конкретное.

@ppadovani Я создаю для этого http://staging.elastic.co/ $ (VERSION_TAG) / downloads / kibana / kibana - $ {ELASTIC_VERSION} -linux-x86_64.tar.gz? Если да, я могу просто поместить это в свой контейнер докеров. В противном случае мне нужно будет создать вашу ветку и архив.

@ imranq2 Я не предоставляю дистрибутивы своего форка, поэтому вам нужно будет собрать его самостоятельно.

К вашему сведению - я создал пул-реквест для поддержки вложенных данных на вкладке обнаружения для тех, кто заинтересован:
https://github.com/elastic/kibana/pull/10814

+1

+1 для меня
+10 для моих коллег

+1

+1

+1

+1

+1

+1

+1. Поддерживается ли это в ELK5?

+1

это действительно требование, поскольку отсутствие поддержки вложенных объектов действительно препятствует широкому внедрению кибаны в моей компании, поскольку вам нужно создать индекс для кибаны и еще один с вложенными документами для более умного поиска через простой API

+1
В моем отображении это предотвратило бы возможный "взрыв" свойств индекса.

+1

+1

+1

Пожалуйста, прекратите публиковать комментарии +1, которые только рассылают спам всем людям, подписавшимся на эту ветку. Вместо этого нажмите на большую желтую кнопку с изображением большого пальца вверху этого вопроса, чтобы проголосовать за него.

+1

Ребята, пожалуйста, сделайте что-нибудь, разработчики Kibana. Использование Кибаны без вложенных объектов во многих случаях бесполезно. Вы готовите версию 6.x без вложенных объектов ...

Наша система сканирует текст на наличие домов, а затем сохраняет результаты в ES. Итак, ES содержит основные документы с массивом домов. Дом - это вложенные объекты.

Я не могу использовать визуализацию для создания дашборда с анализом домов, которые мы нашли в тексте.
Сделайте что-нибудь, пожалуйста. Дом горит.

Отчаянно нужно использовать вложенные объекты в кибане. Плохо, что это не встроено.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

еще один здесь!

Для тех, кто, возможно, использовал мою вилку Kibana с вложенной поддержкой, я прекращаю поддержку этой вилки после выпуска Kibana 5.4.x. Вместо этого я перенесу большую часть, если не всю функциональность в плагин Kibana. Я надеюсь, что плагин будет готов к последней версии 5.x к концу года. Вы можете следить за прогрессом здесь: https://github.com/ppadovani/KibanaNestedSupportPlugin

Я только начал работу, поэтому не ждите, что в ближайшие несколько недель появится что-нибудь значимое.

+1

+1

+1

+1

+1

У меня есть снимки экрана и обновления статуса работы, которую я делаю над вложенным подключаемым модулем поддержки. Следите за выпуском, чтобы получать обновления статуса.

Скриншоты и обновления

Я пошел дальше и выпустил предварительную версию 1.0.0 с поддержкой Kibana 5.6.5.

См. Этот выпуск для получения подробной информации о том, что находится в первоначальном предварительном выпуске: Скриншоты и обновления

V1.0.0-beta1

Мой плагин завершен для версии 5.6.5 Kibana. У меня есть несколько задач по очистке, затем я сокращу версию 5.6.5 и начну форвард-портирование на 6.1.X.

Функции:

• Поддержка вложенных запросов
• Поддержка вложенной агрегации
• Откройте для себя результаты вложенной поддержки
• Откройте для себя приоритет отображения поля сводки (это на самом деле что-то новое)

Подробности смотрите в README .

Мой плагин выпущен! Поддержка 5.5.3, 5.6.5 и 5.6.6. В эти выходные я буду портировать на 6.0.X.

Я, скорее всего, больше не буду обновлять здесь статус по этой проблеме. Посетите мою страницу GitHub, чтобы просмотреть выпуски, проблемы и т. Д.

Спасибо!

@ppadovani, не могли бы вы выпустить версию поддержки 5.4.0, спасибо.

@ppadovani Я буду следить за портом 6.0.x!

@ SolomonShorser-OICR
Я выпустил сборку 6.0.1 Beta 1.

Единственное известное ограничение заключается в том, что панель фильтров не работает из-за того, что она жестко запрограммирована для работы только с языком запросов lucene. Я работаю над этим, но, возможно, не смогу найти решения до следующих выходных.

Сейчас я выпустил сборку плагина для 6.0.1, на очереди 6.1.x.

@ppadovani
Спасибо за вашу работу и выпуск 6.0.1!

на основе kibana 6.0.1, после установки этого плагина некоторые функции kibana не работают.

при нажатии timelion отображается сообщение об ошибке:

если установлен x-pack, у некоторой функции x-pack «обнаружение» появляется другое сообщение об ошибке в «Foreach»

Привет, команда Кибаны, почему вы еще не наняли @ppadovani ?

@sccds - переместите этот отчет об ошибке в мой

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

Если у кого-то есть проблемы с моим плагином, пожалуйста, открывайте вопросы в моем репо и не начинайте здесь разговор. У этого выпуска слишком много подписчиков.

@Hronom - Я ценю эту мысль, но мои сильные стороны не в Javascript .... хотя создание этого плагина и взлом Kibana, безусловно, помогли моим способностям в этой области.

К вашему сведению - мой плагин теперь обновлен до последней версии Kibana. Я выпустил поддержку 6.1.2.

Спасибо @ppadovani , продолжайте!

+1

+1

+1 Здравствуйте, Tomitribe очень заинтересовался этой функцией. Вы знаете, когда эта функция будет реализована?

@ppadovani где я могу спросить о функционале? Я борюсь с вложенной агрегацией в таблице данных.

@bumerankkk Перейдите сюда и откройте вопрос: https://github.com/ppadovani/KibanaNestedSupportPlugin

В качестве альтернативы, если вы перейдете на одну из страниц документации, которая соответствует вашему вопросу, вы можете добавить комментарий внизу страницы.

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

Над этим активно работают? Есть ли у нас сроки, когда такая функция будет выпущена в производство?

С Днем Рождения 🎂 'Агрегации вложенных типов', 🎁

Сейчас тебе уже четыре года. Не так давно ты был таким маленьким и милым.
Надеюсь, ты вырастешь, и в будущем у нас будет несколько общих хороших лет.

лучший малу

+1

+1

+1

+1

+1

+1

+1

Почему это еще не реализовано

Причины, с этой функцией, у меня не было бы потока, никакого удовольствия, и никто не пойдет на github кибаны, это своего рода маяк

Последняя версия лося правильно поддерживает вложенные данные для меня

Эль-Мие, 6 июн 2018 в 22:08, Евгений [email protected]
написать:

Причины: с этой функцией у сыворотки не было бы нити, никакого удовольствия и
никто не зайдет в гитхаб кибана, это маяк какой-то

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395214259 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AMK55lokgriJHhPF5EuBN6yREr5-dT4-ks5t6ETAgaJpZM4Bru7J
.

@javixeneize Я сижу здесь на версии 6.2.4 , не могу найти поддержку вложенных объектов, поправьте меня, если я ошибаюсь

У меня есть эта версия, и я могу получить доступ к ab, где моя структура {Id: xx,
а: {b: xx}}

Эль-Мие, 6 июн 2018 в 22:18, Евгений [email protected]
написать:

@javixeneize https://github.com/javixeneize Я сижу здесь на 6.2.4
версия, не могу найти поддержку вложенных объектов dat, поправьте меня, если я ошибаюсь.

-
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395216828 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AMK55tPrh5Qi8m7PyHbQatkRAw8qj4RGks5t6EcKgaJpZM4Bru7J
.

@javixeneize у вас есть следующее сопоставление с type : nested ?
Вы можете получить отображение по GET /index-name

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

Завтра проверю, но у меня конфигурация по умолчанию

Эль-Эль-Мие, 6 июн 2018 в 22:24, Юджин [email protected]
написать:

@javixeneize https://github.com/javixeneize у вас есть следующее сопоставление
с типом: вложенный?
Вы можете получить отображение по GET / index-name

{
"документ": {
"характеристики": {
"location": {
"тип": "вложенный",
"характеристики": {
"начинать": {
"тип": "длинный"
},
"конец": {
"тип": "длинный"
},
"normalized": {
"тип": "ключевое слово"
},
"original": {
"тип": "ключевое слово"
}
}
}
}
}
}
}

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395218644 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AMK55npNY8uTVUPgVIbjXfAXSB5tPwDwks5t6EikgaJpZM4Bru7J
.

@javixeneize заранее спасибо!
У вас, вероятно, есть объект sub json, который был сведен к основному документу, но это не вложенный объект.

Да, будьте осторожны @javixeneize, ваши данные не будут коррелировать

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

Основная проблема: каждое поле во вложенном объекте просто становится массивом, и вы теряете корреляцию между свойствами.

Я просто сгладил свои данные, прежде чем загружать их в es.

Если вы не можете дождаться, пока Elastic реализует это, вы можете использовать мой плагин Kibana:

Обзор:
https://ppadovani.github.io/knql_plugin/overview/
Установка:
https://ppadovani.github.io/knql_plugin/installation/
Язык запросов (например, SQL):
https://ppadovani.github.io/knql_plugin/knql/

Поддержка версий с 5.5.3 по 6.2.4, если версия отсутствует, после 5.5, пожалуйста, откройте вопрос:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Вклады, запросы функций и отчеты об ошибках приветствуются.

Хорошо, тогда мне нужно подождать ...

Эль-июнь, 7 июн 2018 в 0:38, Пьер Падовани [email protected]
написать:

Если вы не можете дождаться, пока Elastic реализует это, вы можете использовать мою Kibana.
плагин:

Обзор:
https://ppadovani.github.io/knql_plugin/overview/
Установка:
https://ppadovani.github.io/knql_plugin/installation/
Язык запросов (например, SQL):
https://ppadovani.github.io/knql_plugin/knql/

Поддержка версий с 5.5.3 по 6.2.4, если версия отсутствует, после 5.5, пожалуйста
открыть вопрос:
https://github.com/ppadovani/KibanaNestedSupportPlugin

Вклады, запросы функций и отчеты об ошибках приветствуются.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/elastic/kibana/issues/1084#issuecomment-395246977 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AMK55q36DWICC4QoNald5fO7rCBnLdTgks5t6GgJgaJpZM4Bru7J
.

+1

+1

+1

+1

+1

+1

очень полезная функция ... +1

Кибана абсолютно бесполезна для моих сценариев использования без этой поддержки. Мне не нужно сглаживать или реструктурировать свои данные. Я должен просто иметь возможность вводить данные и выводить визуализации или агрегаты. Четыре года спустя, но все еще нет поддержки вложенных объектов?

Какая-нибудь оценка, когда эта функция будет доступна?

Не мог бы кто-нибудь из elastic сообщить нам, будет ли эта функция добавлена ​​в Kibana? Этот билет открыт уже почти 5 лет.

Кроме того, какой смысл выпускать такую ​​функцию, если ее нельзя использовать в Kibana?

Не поймите меня неправильно, но это немного странно.

+1

+1

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

Пожалуйста, не добавляйте комментарии, такие как +1. Особенно по вопросам, которые вам действительно небезразличны! Позвольте мне объяснить, любой, у кого включены уведомления, легко разозлится и откажется от подписки. Это означает, что участники не будут рассматривать это как важный вопрос, исходя исключительно из того, сколько участников было задействовано. Когда люди отказываются от подписки, это число уменьшается.

Вместо этого ВЫ должны подписаться на поток через поле в правом верхнем углу и поставить первый вопрос Github большим пальцем вверх, чтобы продемонстрировать свою поддержку.

@ bugs181 здесь не работает, это аномалия, которая поглощает все приходящие волны уже пять лет!

Я считаю, что ученые должны исследовать эту черную дыру!

Кажется, что у разработчиков Kibana ненормальная сила !!!

@ bugs181 здесь не работает, это аномалия, которая поглощает все приходящие волны уже пять лет!

Вы когда-нибудь думали, что они не хотят читать весь выпуск с тоннами комментариев типа «+1 я тоже», выискивая информацию, которая может быть для них ценной?

@ppadovani имеет плагин с открытым исходным кодом, который можно использовать (см. его комментарий выше)

@ mika76
Я использую это.

очень полезно в простом случае

@ mika76 просто

ppadovani прокомментировал 28 дней назад
Привет, ребята ... Я обнаружил, что мое время сильно ограничено из-за работы и жизни. Кроме того, хотя мне удалось частично поднять ситуацию, изменения, внесенные командой Kibana при переходе на React, потребуют в основном переписывания больших кусков того, что я сделал.

@ mika76 да, этот плагин - единственный способ заставить вложенные объекты работать прямо сейчас.
Но что для меня странно, у Elasticsearch есть официальная поддержка вложенных объектов, а у Kibana - нет.

Как упоминалось в @ bugs181, он в настоящее время активно не поддерживается, и это означает, что вы не можете обновить стек ELK до последней версии.

Так что официальная поддержка означает и надлежащее обслуживание. Но из-за того, что разработчики плюют на эту проблему, у нас нет официальной поддержки для этого.

Я должен поддержать @ bugs181 здесь. Добавление "+1" к этой проблеме и иная рассылка спама не очень помогает повысить осведомленность об этом, но только заставит людей отключить ее или приблизит нас к точке, где мне нужно будет заблокировать ее, что я действительно не делаю. Не хочу, потому что я хотел бы, чтобы каждый вопрос оставался открытым для всех, так как я верю в открытое общение.

До сих пор я также всегда рекомендовал использовать этот плагин. Я не знал, что это больше не поддерживается, и мне грустно это слышать. Мы также знаем, что эта проблема открыта в течение 5 лет, и мы проводим анализ проблем (очевидно, в Кибане - см. Прилагаемый снимок экрана) и знаем, что это проблемы, на которые чаще всего реагируют:

Но, как вы в значительной степени знаете, существуют (буквально) тысячи других открытых проблем, поэтому нам всегда нужно балансировать между функциями, исправлением ошибок и т. Д., Чтобы найти хорошую приоритезацию. Кроме того (но не только), поскольку у этой функции всегда был довольно надежный рабочий плагин сообщества, до сих пор ей не уделялось достаточного приоритета (чтобы преодолеть другие проблемы). Кроме того, как это часто бывает, между разными вещами часто существует техническая связь, и, например, для поддержки вложенных полей мы в настоящее время сначала хотим завершить капитальный ремонт всего конвейера визуализации визуализации (# 19813), прежде чем мы начнем это, поскольку он тесно связан вместе. Тем не менее, в настоящее время у нас есть эта проблема в нашей дорожной карте для 7.x, и мы надеемся, что она не будет заблокирована другими техническими изменениями, поэтому мы скоро сможем переместить эту функцию в ядро ​​Kibana, чтобы сделать ее доступной без плагина сообщества.

Включает ли запрос на поддержку визуализаций вложенных объектов поддержку родительско-дочерних отношений? У меня есть заказчик, который интересуется визуализациями родитель-ребенок.

@MorrieAtElastic нет, родитель-потомок будет отдельной проблемой.

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

Это действительно большая проблема, поскольку мы не можем правильно отобразить отношения 1: M в Kibana, поскольку ElasticSearch поддерживает вложенный объект, поэтому мы можем загружать данные, но не можем просматривать их должным образом. Это должно быть скоро исправлено.

Спасибо,
Ракеш

Сегодня начал работу над поддержкой вложенных полей в KQL. Создана отдельная проблема для отслеживания, поскольку полная поддержка вложенных полей в Kibana включает в себя множество изменений, помимо KQL.

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

OMG это реально? Через 5 лет ...

А как насчет нового типа данных: сглаженный? Будет ли поддержка визуализации для этого нового типа в будущем? Многие сервисные клиенты обращаются к этому новому типу, и они спрашивают, могут ли / когда визуализации вступить в игру.

@Barrybigbuddy Я не уверен, каковы планы по сглаживанию, не могли бы вы создать для этого отдельный билет?

Я хотел бы, чтобы отношения между родителями и детьми были представлены в Кибане. Поэтому просим вас сделать эту функцию приоритетной. Спасибо. M'Jay

+1

Потрясающие! +1 здесь! Есть ли конкретные временные рамки для этой функции?

Позвольте мне поиграть здесь и сделать короткое напоминание: на этот выпуск подписано много людей (228 человек из сообщества + пара эластичных команд), поэтому было бы неплохо, если бы мы оставили +1 в минимум. Благодаря функции приятной реакции GitHubs вы также можете добавить свое одобрение и любовь к @Bargs в его комментарии, не вызывая уведомления для всех подписчиков (или ваше неодобрение, тогда он снова может прекратить работу над поддержкой вложенных полей: wink :). Кроме того, особенно из-за того, что это такой большой билет, пожалуйста, не используйте его для несвязанных вопросов о других типах полей.

Я оставлю здесь пару ссылок для других типов полей:

• Поддержка типа поля flattened - в настоящее время не входит в нашу краткосрочную дорожную карту
• Поддержка родителей / детей - в настоящее время не входит в нашу краткосрочную дорожную карту

Когда появится эта функция? Мы активно работаем над этим, и будут разные фазы (KQL, поддержка фильтрации, визуализации и т. Д.), Которые могут появиться в разных версиях, и это будет зависеть от того, как будет идти процесс разработки. Мы будем публиковать запросы на вытягивание, связанные с этой функцией, в качестве комментария здесь, чтобы вы могли видеть в PR, в какой версии будет задействована эта конкретная фаза / часть поддержки.

Я не уверен, что это та же проблема, но у меня есть индекс со списком объектов, но без "вложенного" типа данных. Однако в Kibana в разделе «Доступные поля» я не вижу полей внутри объектов, находящихся в списке. Это известное ограничение?

@ppadovani, есть ли плагин для kibana-7.3.1?

Всем привет, думаю я нашел какое то решение этой проблемы. Читая исходный код сопоставлений, я обнаружил, что существует опция include_in_parent для вложенного типа сопоставления. Используя эту опцию, я могу без проблем визуализировать массив объектов в Kibana !!! По какой-то причине эта опция НЕ появляется в документации ES. Может, я что-то не так понимаю, но, видимо, все работает. Я использую опцию полей, поэтому я могу искать как по ключевым словам, так и по полному тексту.

Сопоставления

PUT / test_index
`` json
{
"mappings": {
"динамический": "строгий",
"характеристики": {
"штат": {
"тип": "ключевое слово"
},
"создан": {
"тип": "вложенный",
"include_in_parent": правда,
"характеристики": {
"имя": {
"тип": "текст",
"fields": {
"сырой": {
"тип": "ключевое слово"
}
}
},
"фамилия": {
"тип": "текст",
"fields": {
"сырой": {
"тип": "ключевое слово"
}
}
}
},
"динамический": "строгий"
},
"люди": {
"тип": "вложенный",
"include_in_parent": правда,
"характеристики": {
"имя": {
"тип": "текст",
"fields": {
"сырой": {
"тип": "ключевое слово"
}
}
},
"фамилия": {
"тип": "текст",
"fields": {
"сырой": {
"тип": "ключевое слово"
}
}
}
},
"динамический": "строгий"
}
}
}
}

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

@patodevilla

Использование include_in_parent или copy_to в качестве обходного пути не поддерживается и может перестать работать в будущих выпусках.

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

Фаза 1 поддержки вложенных полей выпущена в 7.6.0

Небольшое обновление для этой проблемы: мы только что выпустили версию 7.6.0 Kibana, которая изначально поддерживает вложенные поля. Теперь вы можете использовать вложенные поля в следующих местах в Kibana:

• Шаблоны индекса правильно обнаруживают вложенные поля
• Вы сможете посмотреть вложенные поля в Discover
• Фильтрация вложенных полей через панель фильтров работает
• KQL позволяет искать вложенные поля (см. Документацию KQL для объяснения синтаксиса запроса вложенных полей)

В настоящее время мы работаем над включением вложенных полей в визуализациях и продолжим обновлять эту проблему, добавляя соответствующую информацию.

Привет! Ждем ВСТАВЛЕННЫЙ функционал. Когда мы сможем это увидеть? Это единственный момент, который полностью не переключается на Kibana (Elastic - лучший). Весь мир наблюдает за тобой.

Запросы вложенных полей по-прежнему ошибаются с помощью KQL.
Пример:
Рассмотрим отображение индекса, определенное как
"first": { "type": "nested", "properties": { "second": { "type": "nested", "properties": { "field": { "type": "text" } } } } }
Я создал шаблон индекса на основе этого индекса и хочу запросить first.second.field : "test"
Этот запрос на вкладке проверки сгенерирует
"filter": [ { "bool": { "should": [ { "match": { "first.second.field": "test" } } ], "minimum_should_match": 1 } } ],
что неверно.
Правильная версия также должна включать вложенный синтаксис "nested": {"path": "first.second",...}

Pinging @ elastic / kibana-app-arch (команда: AppArch)

@IlyaHalsky Пожалуйста, проверьте документацию KQL по вложенным полям. Вложенные поля требуют определенного синтаксиса для запроса, поскольку у вас есть несколько способов запроса по ним (в вашем случае вы, скорее всего, просто захотите сделать: first.second:{ field: "test" } ).

Вы также должны увидеть всплывающее уведомление, когда впервые попытаетесь использовать вложенное поле в запросе KQL, который свяжет вас с этим объяснением.

Я спрашиваю, есть ли новый выпуск кибаны, поддерживающий вложенное поле в visualize:
мой пример данных:
{
"fieldX": "x",
"fiedY": "Y",
"аномалии": [
{
"категория": "система",
"name": "cpu",
"date": "2020-03-11T13: 33: 40.000Z"
},
{
"категория": "перезагрузка",
"имя": "сбросить",
"date": "2020-03-11T13: 33: 40.000Z"
},
{
"категория": "система",
"имя": "память",
"date": "2020-03-11T13: 33: 40.000Z"
}
]
}

Я хочу визуализировать круговую диаграмму в кибане, где:
количество срезов = Общее количество объектов массива аномалий (количество документов x количество объектов по массиву аномалий)
первая корзина = anomalies.category
вторая корзина = anomalies.name

другими словами, я хочу визуализировать распределение имен аномалий по категориям аномалий?

+1

Есть новости по этому поводу? Релизу 7.6 уже несколько месяцев, 7.7 и 7.8 не упоминали об этом в примечаниях к выпуску, а документы для 7.9, 7.x и master также не содержат новой информации об этой функциональности.

Просто хочу выразить наши большие надежды на поддержку вложенных агрегатов в Visualizations. Было бы здорово!