Kibana: ビジュアライゼーション/ダッシュボードのインデックスを変更する

これを行うには、elasticsearchで視覚化ドキュメントをコピーし、インデックスのパラメーターを変更します。 この種の機能のUIをすぐにサポートすることはありません。

:(その後、すぐに手に負えないO（M * N）の問題になります（N =インデックスの数、Mは視覚化の数です。

現在のアーキテクチャで可能ですか？ インデックスは、K4のダッシュボードではなく、ビジュアライゼーションにバインドされているように見えます。 これは私にとって非常に便利です。 ほとんどの人と同じように（私は想像しますが）、各環境を別々のインデックスに分割しています。 ダッシュボードのメンテナンスが難しくなります...

Kibana 3では、ユーザーが各ダッシュボードのインデックスを切り替えることができる選択リストボックスをハッキングしました。つまり、すべての環境で1つのダッシュボードのみを維持する必要があります。 ただし、Kibana 4は、ダッシュボードではなくビジュアライゼーションにインデックスをバインドします。 dashbaordが（オプションで）その視覚化のインデックスをオーバーライドできると便利かもしれません。 ただし、一部のユースケースでは、インデックスに依存しないダッシュボードがどのように役立つかがわかります。

+1

Elasticsearchで視覚化ドキュメントをコピーすることは実際にはオプションではありません。 それは多くの重複した情報を生成し、更新は悪夢になります。

これに+1。 「インデックスパターン」の概念は当然データの「ソース」にマッピングされ、ダッシュボードは現在これを行うことを不可能にしています。

少なくとも、ダッシュボードページの上部にある検索バーでは、「より具体的な」インデックスパターンによるフィルタリングが可能である必要がありますが、 _index:­...-*パターン（または特定の値）の検索は受け入れられないようです。 ）。

現在の回避策は、同じダッシュボードを維持しながらソースですばやくフィルタリングする唯一の方法であるため、ソースごとに個別のドキュメントタイプを使用することですが、環境ごとに新しいタイプマッピングを作成する必要があるため、さらに別の構成問題（tm）が発生します。 ..。。

さまざまな部門のユーザーが、独自のダッシュボードを介して同じデータにアクセスするさまざまな役割を果たしているという状況に直面しています。
たとえば、開発者と最前線のサポートスタッフ。

ダッシュボードの変更をどのように制限できますか？たとえば、開発者によって作成されたダッシュボードのセット。 サポートスタッフが変更することはできませんか？

シールドがインデックスのみに関連付けられている場合、両方のダッシュボードの基になるデータが同じであるため、機能しません。

ありがとう。

このために+1。
現時点では、Ansibleとテンプレートを使用して、少なくともコピーと置換のプロセスを少し自動化していますが、これは_THE_方法ではありません。 冗長性は、メンテナンスの観点からはクールではありません...

+1

このために+1。
すべての環境（dev、holog、prod）に対して1つのインデックスパターンがあるが、ダッシュボードと視覚化が同じである場合、この機能があると非常に便利です。

+1
インデックスを視覚化に結び付け、ダッシュボードに埋め込むことは、完全な悪夢です。 ダッシュボードを完全に書き直さずに、最近のデータと長期のログスタッシュデータにエイリアスを使用することは不可能です。

ダッシュボードのインターフェースとデザインがGrafana2でどのように機能するかを見てください。これは、私の視点から完全に釘付けになっています。 たとえば、グラフは個別のエンティティではなく、ダッシュボード内に作成されます。

+1今のところ、複雑なプラットフォームがある場合、それは完全な悪夢です。

+1このサポートをすばやく追加してください...

+1

+1 3つの異なる環境にわたって、3つの異なるダッシュボードを作成し、維持しなければならないことは、私たちにとって大きな悪夢です。 ダッシュボードは各環境で同じである必要がありますが、この機能がないと、視覚化とダッシュボードを3回以上手動で作成する必要があります。

+1

+1

+1

+1
重複した視覚化は方法ではありません。
ダッシュボードの処理方法をKibana3に変更したのはなぜですか！？！？

+1

+1

+1

+1

+1

+1これは私たちにとって本当に重要です

+1

Bitergiaでは、テンプレートダッシュボードから自動ダッシュボードを作成するためのツールを作成しました。 主なタスクの1つは、インデックスの変更です。

誰にとっても役立つオープンソースツールは次のとおりです。

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

ああ、神様。 これはとても便利でしょう!!!

+ 1-Kibanaは本当に再利用可能な「アセット」をサポートする必要があります。

+1

+1

+1111 !!! 1one

+1

+1

+1これは素晴らしいでしょう！

このために+1。

+1

+1

+1

+1

+1

+1

+1！ とても便利かもしれません

+1

+1

+1

+1

+1
私はこれがすでに可能だと思った:(

+1

これはdefです。 持っている必要があります。 それを実現させてください。

+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インデックスを使用していくつかの複雑な視覚化を構築していて、ワニスインデックスを使用するとより良い結果が得られるかどうかを確認したいのですが、インデックスを変更することは許可されていないため、新しいタブを開いてインデックスを変更し、視覚化フィールドを再度設定します。

これは、異なる環境間ですでに実装されているビジュアライゼーションをコピーするのには役立ちませんが、インデックスのビジュアライゼーションを比較し、ビジュアライゼーションに使用するのに最適なインデックスを作成するのにも役立ちます。 また、メンテナンスにも非常に役立ちます。1つのフィールド名が変更された場合、1つの視覚化を変更して、複数の環境に保存できます。 別の方法は、すべてのビジュアライゼーションをエクスポートし、編集して再度インポートすることです...それは機能しますが、非常にハッキーです

これを追加してください。

+1

+1

この機能は、JSスクリプトをKibanaページに挿入することで実装しました。 https://github.com/gofreddo/kibana-copy-objects/を参照して

+1

+1これは私たちにとって大きな改善になるでしょう。 現在、ダッシュボードを共有できるようにすべてのデータを1セットの日次インデックスに含めるか、作業中のインデックスを変更するためだけにダッシュボードを手動でコピーして最新の状態に保つ必要があります。

+1

+1

+1

+1

最善の回避策は、Kibanaの[検出]タブに検索を保存し、インデックスパターンではなく、保存した検索からビジュアライゼーション/ダッシュボードを作成することです。 これで、別のインデックスに切り替える必要があるときはいつでも、保存された検索に戻り、ドロップダウンからインデックスを変更して保存することができます。 これにより、ビジュアライゼーション/ダッシュボードのインデックスが変更されます。

@svadapalliとにかく検索がインデックスパターンで保存される場合、それはどのように役立ちますか？

既存の検索を新しいインデックスにマッピングすることで置き換えることができます。 依存するビジュアライゼーションがある場合、インデックスへの切り替えは自動的に行われます。

₊1

これはオープンソースのソフトウェアであり、正直なところ、各視覚化/ダッシュボードのURIで渡される構成のレベルを考えると、参照されるインデックスパターンのすべてのインスタンスをオーバーライドする簡単な方法があるように感じます。

このユースケースは、権限とセキュリティの実施の世界で一般的です。同じスキーマで異なるカテゴリのJSONのバケットが大量にあり、同じダッシュボードで異なるインデックスを持つユーザーに表示するデータが異なる場合があります。 あなたがそれを言うとき、その超セクシー

+1

+1

+1

+1

+1

+1 ...........しかし、111人以上* 2年待っています......オープンソースソフトウェアには、一定の人年（人年）が経過した後、ある程度のしきい値があるはずです。 ？）リクエストは問題リストの一番上に固定する必要があり、エリアの所有者になる時間を丁寧に与えた人は、問題を解決するための詳細なポインタ（コード、戦略）を入力してから、残りの1つを入力する必要があります私たちはそれを実現するために行く力を感じます。

空気を10,000レベルまで持ち上げることができれば、飛び込む人はもっとたくさんいると思います。

+1

+1

1+。 ELKを6.Xに新しくアップグレードした後、タイプはサポートされなくなりました。ダッシュボードはすべて同じインデックスに基づいており、タイプのみが異なるため、ダッシュボード全体を移行する必要があります。

+1

+1

+1
grafanaのダッシュボードのインデックスを変更できますか？

この機能の計画がない場合、kibanaは誰でもこの問題を解決できます

.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のみに焦点を当てたいと思います。

架空のシナリオを示すために、会社はクライアント、クライアントA、およびクライアントBのKibanaダッシュボードを作成します。クライアントAのデータはclient-a-*インデックスパターンであり、クライアントBのデータはclient-b-*インデックスパターンです。 現在、会社には2つの重複した視覚化とダッシュボードのセットがあり、すべてが同じですが、視覚化の作成に使用されるインデックスパターンがあります。

それはあなた方の多くが遭遇している状況に似ていますか？ もしそうなら、誰かがインデックスパターンclient-*を指す単一の視覚化セットを作成することによってそれを回避しようとしたかどうか興味があります。 2つのクライアントのデータは、アクセス許可のために当然フィルタリングされるため、自分のデータのみが表示されます。

ダッシュボードの作成者が各クライアントに表示されるデータを簡単に表示できるようにすることが問題である場合、フィルタリングするclientフィールドを追加できますか？

ちなみに、 _indexメタフィールドがありますが、ワイルドカードを使用して検索することはできません。つまり、パターンがclient-a-date場合、日付をまたいで表示することはできません。 。

このルートを使用する場合、視覚化のセットは1つだけで、維持するダッシュボードは1つだけです。 閲覧者の権限に基づいてデータは自然にフィルタリングされますが、すべてのインデックスパターンにアクセスできる管理者は、すべてを表示したり、データをセグメント化したりできます。 クライアントにはクライアントフィールドが表示されますが、選択するオプションとして自分の名前のみが表示されます（したがって、 aへの参照はまったく表示されません）。

この回避策が解決策としてどのように不十分であるかを理解することは、この機能の実装について考えるときに対処する必要のある懸念事項を理解するのに役立ちます。

あなたが説明することは私にとって問題ではありません。 N個の要素にインデックスを付けると言います
エラスティックで「アプローチ1」という名前を付けてから、同じJSONを持つデータにインデックスを付けます
フィールドですが、そのデータは別の（うまくいけばより良い）で抽出されました
「アプローチ2」のように名前を付けて、今度は私の視覚化のセットを
別のインデックスに適用されます。 ダッシュボードをポインターとインデックスと考えてください
データポインタが指しているので、ポインタが必要です（すべてのダッシュボード
鉱山の視覚化）新しいインデックスに適用されます。

あなたに正直に言うと、私はその問題を回避するためにPythonスクリプトを作成しました。
あなたはそれをチェックすることができます私はそれを解決策として投稿しました。 また、私はに機能を追加しました
新しいインデックスに適用する「クローン」ダッシュボードなので、2つあります
ダッシュボードですが、異なるインデックスを参照します。

5時11分PMの木、2018年3月1日には、ステイシーギャモン[email protected]
書きました：

これを熱心に楽しみにしている皆さんにいくつか質問があります
さまざまなアプローチを模索し始めると、機能が実装されます
これらの問題を解決します。

まず、議論されてきた主な問題を理解しようと思います
ここ：

問題1：1つのインデックスパターンを簡単に交換する方法はありません
既存のダッシュボードと視覚化の特定のセットにもう1つあります。

問題2：多数の重複した視覚化を維持したくない
ダッシュボードで異なるのはインデックスパターンだけです。 この
ダッシュボードの閲覧者がデータにアクセスできるため、状況が発生します
さまざまなインデックスパターンに存在します。

これは正確に聞こえますか？

今のところ、問題2のみに焦点を当てたいと思います。

架空のシナリオを提供するために、ある会社がKibanaダッシュボードを作成します。
クライアント、クライアントA、およびクライアントB。クライアントAのデータはclient-a- *にあります。
インデックスパターンとクライアントBのデータはclient-b- *インデックスパターンです。 ザ
会社には現在、視覚化とダッシュボードの2つの重複セットがあります。
すべてが同じですが、視覚化の作成に使用されるインデックスパターンです。

それはあなた方の多くが遭遇している状況に似ていますか？ もしそうなら、私は
誰かがシングルを作成することによってそれを回避しようとしたかどうか興味があります
インデックスパターンクライアントを指す視覚化のセット-*。 二つ
クライアントのデータは、アクセス許可のために自然にフィルタリングされるため、
彼らは自分のデータしか見ることができませんでした。

問題がダッシュボードの作成者が簡単に見られるようにしたいということである場合
各クライアントに表示されるデータ、フィルタリングするクライアントフィールドを追加できますか？

[画像：スクリーンショット2018-03-01 at 10 47 49 am]
https://user-images.githubusercontent.com/16563603/36854121-2f297614-1d3e-11e8-8036-c9f69aa99ea0.png

補足として、_indexメタフィールドがありますが、を使用して検索することはできません
その上にワイルドカードがあります。これは、パターンがクライアント日付である場合を意味します。
日付をまたいで見ることはできません。

このルートを使用すると、視覚化のセットは1つだけで、1つだけです。
維持するダッシュボード。 データは、に基づいて視聴者向けに自然にフィルタリングされます
それらの権限が、すべてのインデックスパターンにアクセスできる管理者は
すべてを表示するか、データをセグメント化します。 クライアントにはクライアントフィールドが表示されますが
自分の名前を選択するオプションとしてのみ表示されます（したがって、表示されません）
aへの参照を参照してください）。

解決策としてその回避策がどのように不十分であるかを理解することは私を助けます
実装について考えるときに、どのような懸念に対処する必要があるかを理解する
この機能。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/3668#issuecomment-369642283 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/Ae1KBra2IKRCwsvTuL6wLY0UKVBlwDXxks5taB2_gaJpZM4EHRML
。

興味深いことに、@ ArtemUstynovの回答に感謝します。 上記のリンクにアクセスできません。404エラーが発生します。

さまざまなアプローチで新しいインデックスを作成する頻度はどれくらいですか。 これらの2つのアプローチができたら、両方を維持しますか、それとも一方を選択してもう一方を破棄しますか？

2番目のインデックスが最初のアプローチで作成されたインデックスとプレフィックスを共有し、両方のインデックスに「approach」というフィールドを追加した場合、上記のソリューションは機能しますか？ 共有プレフィックスをインデックスパターンとして使用して単一の視覚化セットを作成し、フィルタリングによってアプローチを切り替えることができます。

自動的に含まれる_indexフィールドでユーザーがワイルドカードでフィルタリングできるようにした場合は、手動でフィールドを追加する必要もありません。

1回限りの状況で、保存されたオブジェクトの選択されたグループの一括インデックス変更の有用性を確実に確認できました。 たとえば、 approach-a-*を指すすべてのビジュアライゼーションを作成し、次にそれらをapproach-*を指すようにします。

インデックスの変更とインデックスのフィルタリングの違いがわかりません（インデックスのマッピングが同じであると仮定すると、インデックスのスワップがシームレスに機能するために必要です）。 どちらも「このデータセットのみを表示し、他のすべてを除外したい」という言い方です。 ユーザーはダッシュボードでデータをフィルタリングする方法をすでに知っていますが、インデックスを変更することは、新しいUIを備えた新しい概念になります。 新しいUI / UXを導入する前に、それが過度に複雑になったり混乱したりしないこと、そして代わりに問題を解決するために利用できるものがすでに使用されていないことを確認したいと思います。

@ Stacey-ギャモンここに行く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()))`

さて、私が自分自身を適切に説明しなかった場合は申し訳ありませんが、私たちは2つの異なることについて話すことになりました。 このスクリプトは、私が望んでいたことをほぼ実行します。 また、「クローン」ダッシュボード用に作成しました。 これをネイティブに行う方法がある場合は、時間を無駄にして申し訳ありません。

こんにちは@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経由でkibanaにアクセスするので、URLが異なる可能性があります。
ブラウザに移動してネットワークを監視するとどうなりますか（右クリック->
要素を検査->ネットワーク）。 次に、kibana管理に移動して、
何かをダウンロードしてください。これにより、「ネイティブURL」がどこかに表示されます。
応答（「ネイティブURL」とは呼ばれません）が、簡単に実行できます
それを見つけて、私のURLをあなたのものに変更してください。

21:17で火、2018年3月13日には、juancar1979 [email protected]
書きました：

こんにちは@ArtemUstynovhttps ：//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（payload）、headers = HEADERS）.json（））

手伝って頂けますか？

どうも！！！

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/elastic/kibana/issues/3668#issuecomment-372803715 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/Ae1KBmkOB6q1cFJaBnm_s6NXcdv92W86ks5teClUgaJpZM4EHRML
。

@ArtemUstynovに感謝し
:)

@ juancar1979上記のように->キバナを開きます->管理に移動します->保存されたオブジェクト->ブラウザで右クリックします->要素を検査します->ネットワーク->（何か明確なものがある場合（交差した円））->今kibanaで[すべてエクスポート]をクリックします->ネットワークメニューにいくつかのものが表示されます-> [名前]列の下で任意のフィールドを選択します（たとえば最初に）-> [URLのリクエスト]が表示されます->それで遊んでくださいurl。 たぶん他のものをダウンロードするのも私にとっては簡単ではありませんでしたが、私はそれをできるだけ一般的なアプローチにしようとしました。 また、何らかの理由でコンソールのURLが常にUIと一致するとは限らないため、スクリプトから中間値を出力してみてください。 申し訳ありませんが、これ以上のことはできないと思います。エラスティックサーバーなどに通常とは異なる構成を使用している場合は、デバッグすることができます。 サーバーをセットアップした人に助けてもらいましょう。 頑張ってください（テキストエディタですべてをエクスポートしてインデックス名を変更し、インポートし直すこともできますが、これはそれほどクールではありません）

ありがとう@ArtemUstynov !!!! 私はあなたを言ってみます!!! 👍

@ juancar1979何らかのプロキシを使用している場合、それが失敗する理由である可能性があります。 スクリプトでプロキシを使用しないようにフラグを追加するだけです（正確には覚えていませんが、簡単にグーグル可能です）

+1。 なぜこの非常に基本的な要求が3歳で、注目されていないのですか？

@ ReanimationXP-これは私たちのレーダーです。 問題の一部は、この単一の問題にまとめられた多くの要求があることです。 作業の優先順位を上げるために、それらを分割しました。

ビジュアライゼーションのインデックスパターンの変更： https ：
ダッシュボードレベルのインデックスパターン： https ：
参照オブジェクトを含めるようにエクスポート/インポートを改善しました。 次に、単一のファイル内のインデックスパターンIDで検索/置換を実行できます： https ：

それについて考えた後、私は前進するための最善の方法は、このメガイシューを閉じて、サブイシューに関するより具体的なフィードバックを提供するようにコミュニティを導くことであると信じています。 誰かがこの前進に強く反対するなら、私は確かに再考することを歓迎しますので、遠慮なくコメントしてください！

問題の先頭に追加した内容を繰り返します。

これまでのところ、この巨大な問題についてのフィードバックのすべてに心から感謝していますが、これをより具体的な項目に分解して取り組むために、あなたの助けが必要です。 この特定の問題をすでに+1している場合でも、以下に示すより詳細な問題で+1してユースケースを説明できれば、非常に役立ちます。 この号でこれまでに提供されたすべてのフィードバックを無視することはありませんが、個々の機能の提案についてより焦点を絞ったフィードバックは非常に貴重です。

このメガイシューを構成すると私が信じる3つのサブイシューは次のとおりです。

ビジュアライゼーションのインデックスパターンの変更：＃17542
ダッシュボードレベルのインデックスパターン：＃16917
参照オブジェクトを含めるようにエクスポート/インポートを改善しました。 次に、単一のファイル内のインデックスパターンIDで検索/置換を実行できます：＃16831

ダッシュボードレベルのインデックスパターンは、この最初のリクエストに最もよく一致しているようで、現在利用可能な回避策があります。これについては、＃16917に記載されています。

これらの3つの問題が特定のケースをカバーしていない場合は、お知らせください。

対処されていない唯一のことは、誰かが逆のことをしたいと思っているのを見ることができたということです-検索の他の部分を変えて、1つのダッシュボードで複数のサイト（サイト==インデックスを想定）から同じフィールドを監視します。温度が50を超える場合、すべてのサイトのレベル。」 「さて、今は51を超えています。」 Splunkは、オプションのダッシュボードレベルの「グローバル」ユーザー変数とコントロールを使用して、各ビジュアライゼーションの検索文字列（インデックスを含む）に挿入し、＃17542で説明したように、この問題とインデックスの問題の両方を解決します。 現在のフィルタリングでは、複数のインデックスにまたがるこのようなリクエストを処理できるとは思いませんが、間違っている可能性があります。 そうは言っても、サイト（インデックス）ごとにビジュアルを変更するだけの方が明らかにはるかに一般的だと思います。 インデックスを変更するための単純な「グローバル」ドロップダウン、または複数のビジュアライゼーション間でインデックスを一括変更する方法は、どちらも現在存在するものよりも優れており、中間ソリューションを実装するのが速いと思います。

非常に興味深い@ReanimationXP。 少なくともhttps://github.com/elastic/kibana/issues/16917に記載されている回避策を使用して、フィルターでこれを処理できると思い

これが私の試みです-私は2つのインデックスanimal-catsとanimal-dogsを持っており、3つの視覚化を持っています

そうですか？

この回避策の欠点は、「サイト/インデックスパターン」ごとに視覚化を作成する必要がない場合があることです。その場合、ダッシュボードパネルレベルのインデックスパターンの方が優れたソリューションであることがわかります（ただし、ダッシュボードレベルのインデックスパターンで同じ問題が発生します）。

splunkのように、ある種の検索/置換を使用して変数を調査する価値があるように思えますか。 現在のインフラストラクチャに組み込むのは難しいでしょうが、ユーザーフレンドリーなIMOにするために、多くのものを変更する必要があります。

私も同じ問題を抱えています。
私はそれを解決するためにいくつかのトリックを使用しています。

1. ビジュアライゼーションを保存します。（[新しいビジュアライゼーションとして保存]をオンにします）
2. 管理に行きます。 =>保存されたオブジェクト=>視覚化
   視覚化が必要な場合は保存します。
3. ビジュアライゼーションを削除します。
4. jsonファイルを開きます。 「kibanaSavedObjectMeta--searchSourceJSON--indexuuid」を任意のuuidに変更します
   「5dad88d0-475b-11e8-9a8b-51472dd99c91」を「5dad88d0-475b-11e8-9a8b-51472dd99c92」に変更します
5. 管理に行きます。 =>保存されたオブジェクト=>視覚化
   そのjsonファイルをインポートします。
6. 新しいインデックスを選択できます。

幸運を。

+1

+1

+1

+1

+1

@ heris25 、ステップ3でビジュアライゼーションを削除する理由を説明してください。 また、手順4で、インデックスuuidがどこにあるかを明確にしてください。uuidという名前のものは表示されません。 kibanaSavedObjectMeta.searchSourceJSONで変更する必要のあるフィールドを明確にしていただければ幸いです。

{
  "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"
}