Kibana: Изменить индекс на визуализации / приборной панели

Вы можете сделать это, скопировав документы визуализации в elasticsearch и изменив параметр для index. Я не вижу в ближайшее время поддержки пользовательского интерфейса для такого рода функций.

:( Затем это становится трудноразрешимой проблемой O (M * N) (N = количество индексов, а M - количество визуализаций.

Возможно ли это с нынешней архитектурой? Индекс кажется привязанным к визуализации, а не к приборной панели в K4. Это было бы очень полезно для меня. Как и у большинства людей (я полагаю), каждая из моих сред разделена на отдельные индексы; становится сложно поддерживать информационные панели ...

В Kibana 3 я взломал поле со списком выбора, которое позволяет пользователям переключать индексы для каждой панели мониторинга, что означает, что для всех сред необходимо поддерживать только одну панель. Kibana 4, однако, связывает индекс с визуализацией, а не с приборной панелью. Было бы полезно, если бы дашбаорд мог (необязательно) переопределить индекс в своих визуализациях? Однако я понимаю, насколько полезно иметь панель мониторинга, не зависящую от индекса, в некоторых случаях использования.

+1

Копирование документов визуализации в elasticsearch на самом деле не вариант. Это создает много дублирующейся информации, и обновление будет кошмаром.

+1 по этому поводу. Концепция «шаблона индекса» естественным образом отображается на «источник» данных, и панель инструментов в настоящее время делает это невозможным.

По крайней мере, панель поиска в верхней части страницы панели управления должна позволять фильтрацию по «более конкретному» шаблону индекса, но, похоже, она не принимает поисковые запросы с шаблонами _index:­...-* (или конкретными значениями в этом отношении ).

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

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

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

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

Спасибо.

+1 за это.
На данный момент я использую Ansible и шаблоны, чтобы хотя бы немного автоматизировать процесс копирования и подстановки, но это не должно быть ТОЛЬКО способ сделать это. Резервирование - это не круто с точки зрения обслуживания ...

+1

+1 за это.
Было бы очень полезно иметь эту функцию, когда у вас есть один шаблон индекса для каждой среды (dev, homolog, prod), но панели мониторинга и визуализации одинаковы.

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

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

+1 Сейчас это полный кошмар, когда у вас сложные платформы.

+1 Пожалуйста, добавьте эту поддержку быстро ...

+1

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

+1

+1

+1

+1
Дублировать визуализацию нельзя.
Почему вы изменили способ обработки приборных панелей в Kibana 3!?!?

+1

+1

+1

+1

+1

+1 это было бы действительно важно для нас

+1

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

Вот инструмент с открытым исходным кодом на случай, если он кому-то будет полезен:

https://github.com/acs/GrimoireELK/blob/master/utils/e2k.py

+1

+1

@rashidkpc : Я попробовал ваше предложение, и у меня возникли трудности с созданием правильных записей. Затем я получаю предупреждение Kibana:

"Действовать с осторожностью

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

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

+1

+1

+5

+1

+1

+1

+1

+1

Привет @rashidkpc
По-прежнему чувствуете то же самое по поводу этой проблемы год спустя, учитывая приведенные выше ответы?

Возможно, это «официальный» ответ о том, как обращаться с упомянутыми выше средами?

+1

+1

+1

+1

+1 пожалуйста.

+1

+1

+1

+1

+1

+1

+1

+1

+1

👍

+1

+1

+1

+1

+1

+1

+1

МОЙ БОГ. Это было бы так полезно !!!

+1 - Kibana действительно нужно поддерживать многоразовые «активы».

+1

+1

+1111 !!! 1один

+1

+1

+1 это было бы здорово!

+1 за это.

+1

+1

+1

+1

+1

+1

+1! Может быть очень полезно

+1

+1

+1

+1

+1
Думал, это уже возможно :(

+1

Это деф. должно быть. Пожалуйста, сделай это.

+1

+1

+1

Будет ли запрошенная функция существовать через 2 года? Кто знает! +1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000000000

+1

+1

+1

+1

+1

+1

+1

+1

Так кто-нибудь в Elastic хочет это реализовать?

+1

+1

+1

+1

+1 для этого есть планы по реализации?

К вашему сведению, вы можете довольно легко вручную отредактировать JSON-представление каждой визуализации на вкладке «Сохраненные объекты»: /app/kibana#/management/kibana/objects?_g=()&_a=(tab:visualizations) . Не пробовал, но выполнение экспорта, поиска-замены (или конвейера в jq ) и

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

+1

+1

можно использовать экспорт и импорт реализован

+1

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

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

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

Пожалуйста, добавьте это.

+1

+1

Я реализовал эту функцию, внедрив JS-скрипт на страницу Kibana. См. Https://github.com/gofreddo/kibana-copy-objects/ .

+1

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

+1

+1

+1

+1

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

@svadapalli, чем это может быть полезно, если поисковый запрос все равно сохраняется с шаблоном индекса?

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

₊1

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

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

+1

+1

+1

+1

+1

+1 ........... Но 111+ человек * два года ожидания ...... Должен быть некоторый порог в программном обеспечении с открытым исходным кодом, где после определенного количества человеко-лет (человеко-лет ?) запрос должен быть прикреплен к началу списка проблем, и человек, который любезно посвятил свое время, чтобы быть владельцем области, должен ввести несколько подробных указателей (код, стратегию) для решения проблемы, а затем один из остальных мы почувствуем себя вправе сделать это возможным.

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

+1

+1

1+. После нового обновления ELK до 6.X, когда типы больше не поддерживаются, нам придется полностью перенести наши информационные панели, поскольку все они основаны на одном индексе, но отличаются только типом.

+1

+1

+1
Можно ли поменять индекс дашборда в графане ??

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

При просмотре .kibana нам может потребоваться обновить индекс значения в searchsourcejson визуализаций и поисков.

"searchSourceJSON": "" "{" index ":" 024642a0-faf5-11e7-bacc-890ff6c3f975 "," filter ": []," query ": {" query ":" "," language ":" lucene " }} "

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

Также хотелось бы это +1

Я сделал это возможным https://github.com/ArtemUstynov/kibana_dashboard_manager . также, если вам нужно скопировать панель инструментов для нового индекса, просто напишите мне

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

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

Проблема 1. Невозможно легко заменить один шаблон индекса на другой в данном наборе существующих панелей мониторинга и визуализаций.

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

Это звучит точно?

А пока я хотел бы сосредоточиться только на проблеме 2.

В качестве гипотетического сценария компания создает информационные панели Kibana для своих клиентов, клиента A и клиента B. Данные клиента A находятся в шаблоне индекса client-a-* а данные клиента B - в шаблоне индекса client-b-* . Теперь у компании есть два повторяющихся набора визуализаций и информационных панелей, где все одинаково, за исключением шаблона индекса, используемого для создания визуализаций.

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

Если проблема в том, что создатель панели мониторинга хочет иметь возможность легко видеть данные, которые видит каждый клиент, не могли бы вы добавить поле client для фильтрации?

В качестве примечания: есть мета-поле _index но вы не можете выполнять поиск с использованием подстановочного знака, что означает, что если ваш шаблон client-a-date вы не сможете видеть через даты .

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

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

Что ж, то, что вы описываете, для меня не проблема. Скажем, я индексирую N элементов в
эластичный и назовите его "подход 1", затем я проиндексирую данные с такими же Jsons
поля, но эти данные были извлечены в другом (надеюсь, лучшем) и
назовите его "подход 2", так что теперь я хочу, чтобы набор моих визуализаций был
применяется к другому индексу. Думайте о приборной панели как о указателе и указателе
как указывает указатель данных, поэтому мне нужен указатель (панель со всеми
мои визуализации) для применения к новому индексу.

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

В чт, 1 марта 2018 г., в 17:11, Стейси Гаммон [email protected]
написал:

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

Сначала позвольте мне попытаться разобраться в основных обсуждаемых проблемах.
здесь:

Проблема 1. Невозможно легко заменить один индексный шаблон на
другой в данном наборе существующих панелей мониторинга и визуализаций.

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

Это звучит точно?

А пока я хотел бы сосредоточиться только на проблеме 2.

Чтобы дать гипотетический сценарий, компания создает информационные панели Kibana для
их клиенты, клиент A и клиент B. данные клиента A находятся в client-a- *
шаблон индекса, а данные клиента B находятся в шаблоне индекса client-b- *. В
компания теперь имеет два дублирующих набора визуализаций и информационных панелей, где
все равно, но шаблон индекса, используемый для создания визуализаций.

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

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

[изображение: снимок экрана 2018-03-01 в 10 47 49]
https://user-images.githubusercontent.com/16563603/36854121-2f297614-1d3e-11e8-8036-c9f69aa99ea0.png

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

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

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

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

Интересно, спасибо за ответ @ArtemUstynov. Я не могу перейти по указанной вами ссылке, я получаю ошибку 404.

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

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

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

Я определенно мог видеть полезность массового изменения индекса для выбранной группы сохраненных объектов для разовых ситуаций. Например, вы создали все свои визуализации, указывающие на approach-a-* и теперь хотите указать им на approach-* .

Я просто не уверен, в чем разница между изменением индексов и фильтрацией по индексам (при условии, что сопоставления индексов одинаковы, что должно быть для бесперебойной работы подкачки индексов). Оба варианта - это способ сказать: «Я хочу только просмотреть этот набор данных, исключить все остальное». Пользователи уже знают, как фильтровать свои данные на панели инструментов, но изменение индекса будет новой концепцией с новым пользовательским интерфейсом. Прежде чем мы представим новый UI / UX, я хочу убедиться, что он не слишком усложняет и не запутывает, и что нет чего-то уже используемого, чем мы могли бы воспользоваться для решения проблемы.

@ Стейси-Гаммон, вот иди https://github.com/ArtemUstynov/kibana_dashboard_manager/blob/master/kibana_manager.py
`

import os
import string
import requests
import json

nativeURL = "http://localhost:5601/es_admin/.kibana/_mget"
HEADERS = {'Content-Type': 'application/json', 'kbn-xsrf': 'true', 'Host': 'localhost:5601',
'Connection': 'keep-alive', 'Accept': 'application/json'}

visURL = "http://localhost:5601/api/saved_objects/visualization?per_page=2000"

vis_list = requests.get(visURL, headers=HEADERS).json()['saved_objects']
oldName = input("Old index name: ")
newName = input("New index name: ")
for vis in vis_list:
    payload = "{\"docs\":[{\"_id\":\"" + vis['id'] + "\" ,\"_type\": \"visualization\"}]}" `'`

    VIS = json.dumps(requests.post(nativeURL, json=json.loads(payload), headers=HEADERS).json())
    VIS = json.dumps(json.loads(VIS)['docs'][0]['_source']).replace(oldName, newName)

    POSTURL = "http://localhost:5601/es_admin/.kibana/visualization/" + vis['id']
    print("ERRORS: " + str(requests.post(POSTURL, json=json.loads(VIS), headers=HEADERS).raise_for_status()))`

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

Привет @ArtemUstynov !

У меня проблема:
nativeURL = " http: // localhost : 5601 / es_admin / .kibana / _mget"
{"statusCode": 404, "error": "Not Found"} '

в строке: VIS = json.dumps (requests.post (nativeURL, json = json.loads (payload), headers = HEADERS) .json ())

Можешь мне помочь?

Спасибо!!!

я получаю доступ к кибане через ssh, поэтому ваш URL-адрес может быть другим, вы можете узнать
что это такое, зайдя в свой браузер и наблюдая за сетью (щелкните правой кнопкой мыши ->
проверить элемент -> сеть). затем перейдите к менеджменту кибаны и посмотрите и
скачать что-нибудь, что должно дать вам ваш "родной URL" где-нибудь в
ответ (он не будет называться "родным URL"), но его будет легко
найди это, просто поменяй мой URL на свой.

13 марта 2018 г., 21:17, juancar1979 [email protected]
написал:

Привет @ArtemUstynov https://github.com/artemustynov !

У меня проблема:
nativeURL = " http: // localhost : 5601 / es_admin / .kibana / _mget"
{"statusCode": 404, "error": "Not Found"} '

в строке: VIS = json.dumps (requests.post (nativeURL,
json = json.loads (полезная нагрузка), заголовки = ЗАГОЛОВКИ) .json ())

Можешь мне помочь?

Спасибо!!!

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

Спасибо @ArtemUstynov , но я нигде не могу найти этот URL. Вы знаете, как я могу его найти? Большое тебе спасибо!
:)

@ juancar1979, как я уже сказал выше -> откройте свою кибану -> перейдите в раздел управления -> сохраненные объекты -> щелкните правой кнопкой мыши в браузере -> проверьте элемент -> сеть -> (если есть что-то очищающее (перечеркнутый круг)) -> сейчас в кибане нажмите «Экспортировать все» -> некоторые вещи появятся в вашем сетевом меню -> в столбце «имя» выберите любое поле (например, первое) -> будет «URL-адрес запроса» -> поиграйте с ним, и вы определите свой URL. возможно, скачать что-нибудь еще, это тоже было непросто для меня, но я попытался сделать это как можно более общим подходом. Также попробуйте распечатать промежуточные значения из скрипта, потому что URL-адреса консоли по какой-то причине не всегда совпадают с ui. Извините, но я не думаю, что могу помочь вам больше, чем это, если вы используете какую-то необычную конфигурацию для эластичного сервера и так далее, я смогу отладить ее для вас. Спросите человека, который настраивал серверы, он мог бы помочь. Удачи (также вы можете просто экспортировать все и изменить имена индексов в текстовом редакторе и импортировать их обратно, но это не так круто)

спасибо @ArtemUstynov !!!! Я пытаюсь сказать тебе !!! 👍

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

+1. Почему, черт возьми, этому очень простому запросу уже три года, и на него не обращают внимания?

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

Изменение шаблонов индекса при визуализации: https://github.com/elastic/kibana/issues/17542
Шаблоны индекса на уровне панели мониторинга: https://github.com/elastic/kibana/issues/16917
Улучшен экспорт / импорт для включения объектов, на которые есть ссылки. Затем вы можете выполнить поиск / замену идентификатора шаблона индекса в одном файле: https://github.com/elastic/kibana/issues/16831

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

Повторяю то, что я только что добавил в начало проблемы:

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

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

Изменение шаблонов индекса в визуализации: # 17542
Шаблоны индекса уровня панели инструментов: # 16917
Улучшен экспорт / импорт для включения объектов, на которые есть ссылки. Затем вы можете выполнить поиск / замену идентификатора шаблона индекса в одном файле: # 16831

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

Если эти три проблемы не относятся к вашему конкретному случаю, сообщите нам об этом!

Единственное, на что не обращено внимания, это то, что я мог видеть, что кто-то хочет сделать и обратное - отслеживать одно и то же поле с нескольких сайтов (при условии, что sites == indexes) на одной панели инструментов, изменяя некоторые другие части поиска ... например, «Покажи мне влажность» уровни на всех участках при температуре> 50 ». «Хорошо, теперь> 51». Splunk использует необязательные «глобальные» пользовательские переменные и элементы управления на уровне приборной панели, которые вводятся в строку поиска каждой визуализации (включая индекс), чтобы решить как эту проблему, так и проблему с индексом, как я описал в # 17542. Я не думаю, что текущая фильтрация может обработать такой запрос по нескольким индексам, но я могу ошибаться. Тем не менее, я думаю, что простое изменение визуальных элементов по сайту (индексу), очевидно, будет гораздо более распространенным явлением. Я подозреваю, что простое «глобальное» раскрывающееся меню для изменения индекса или способ массового изменения индекса для нескольких визуализаций было бы лучше и быстрее для реализации промежуточных решений, чем те, которые существуют в настоящее время.

Очень интересно @ReanimationXP. Я думаю, что наши фильтры справятся с этим, по крайней мере, используя обходной путь, упомянутый в https://github.com/elastic/kibana/issues/16917.

Вот моя попытка - у меня есть два индекса animal-cats и animal-dogs , и у меня есть три визуализации - одна для отображения только звуков кошки, одна для звуков собаки и одна для всех. Я могу добавить фильтр, и он будет фильтровать визуализации, даже если в них есть данные из разных индексов:

Это примерно так?

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

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

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

1. сохраните визуализацию. (установите флажок «Сохранить как новую визуализацию»)
2. перейти Управление. => сохраненные объекты => Визуализации
   и сохраните желаемые визуализации.
3. и удалите визуализации.
4. откройте файл json. и измените "kibanaSavedObjectMeta - searchSourceJSON - index uuid" на любой uuid
   я меняю "5dad88d0-475b-11e8-9a8b-51472dd99c91" на "5dad88d0-475b-11e8-9a8b-51472dd99c92"
5. перейти Управление. => сохраненные объекты => Визуализации
   и импортируйте этот файл json.
6. вы можете выбрать новый индекс.

удачи.

+1

+1

+1

+1

+1

@ heris25 , не могли бы вы объяснить, почему на шаге 3 вы

{
  "query": {
    "query": "",
    "language": "kuery"
  },
  "filter": [
    {
      "$state": {
        "store": "appState"
      },
      "meta": {
        "alias": null,
        "disabled": false,
        "key": "cloudwatch_logs.log_group",
        "negate": false,
        "params": {
          "query": "/aws/lambda/b2_record_processor"
        },
        "type": "phrase",
        "value": "/aws/lambda/b2_record_processor",
        "indexRefName": "kibanaSavedObjectMeta.searchSourceJSON.filter[0].meta.index"
      },
      "query": {
        "match": {
          "cloudwatch_logs.log_group": {
            "query": "/aws/lambda/b2_record_processor",
            "type": "phrase"
          }
        }
      }
    },
    {
      "meta": {
        "alias": null,
        "negate": false,
        "type": "phrase",
        "key": "message",
        "value": "ERROR - RECPROC - PROCESS",
        "params": {
          "query": "ERROR - RECPROC - PROCESS"
        },
        "disabled": false,
        "indexRefName": "kibanaSavedObjectMeta.searchSourceJSON.filter[1].meta.index"
      },
      "query": {
        "match": {
          "message": {
            "query": "ERROR - RECPROC - PROCESS",
            "type": "phrase"
          }
        }
      },
      "$state": {
        "store": "appState"
      }
    }
  ],
  "indexRefName": "kibanaSavedObjectMeta.searchSourceJSON.index"
}