Kibana: Index auf Visualisierung/Dashboard ändern

Sie können dies tun, indem Sie die Visualisierungsdokumente in elasticsearch kopieren und den Parameter für den Index ändern. Ich sehe nicht, dass wir in absehbarer Zeit eine Benutzeroberfläche für diese Art von Funktionalität unterstützen.

:( Es wird dann zu einem schnell hartnäckigen O(M*N)-Problem (N = die Anzahl der Indizes und M die Anzahl der Visualisierungen.

Ist das mit der aktuellen Architektur möglich? Der Index erscheint an die Visualisierung gebunden, nicht an das Dashboard in K4. Das wäre für mich enorm nützlich. Wie die meisten Leute (ich stelle mir vor) habe ich jede meiner Umgebungen in separate Indizes aufgeteilt; Die Pflege der Dashboards wird schwierig...

In Kibana 3 habe ich ein Auswahllistenfeld gehackt, das es Benutzern ermöglicht, die Indizes für jedes Dashboard zu wechseln, was bedeutet, dass nur 1 Dashboard für alle Umgebungen gepflegt werden muss. Kibana 4 bindet jedoch den Index an die Visualisierung und nicht an das Dashboard. Es könnte hilfreich sein, wenn das Dashboard (optional) den Index seiner Visualisierungen überschreiben könnte? Ich kann jedoch sehen, wie nützlich es ist, ein Dashboard zu haben, das in einigen Anwendungsfällen indexunabhängig ist.

+1

Das Kopieren der Visualisierungsdokumente in elasticsearch ist nicht wirklich eine Option. Das erzeugt viele duplizierte Informationen und die Aktualisierung wäre ein Albtraum.

+1 dazu. Das Konzept des „Indexmusters“ bildet natürlich eine „Quelle“ von Daten ab und das Dashboard macht dies derzeit unmöglich.

Zumindest sollte die Suchleiste oben auf der Dashboard-Seite das Filtern nach einem "spezifischeren" Indexmuster ermöglichen, aber sie scheint keine Suchen mit _index:­...-* Mustern zu akzeptieren (auch nicht mit bestimmten Werten). ).

Unsere derzeitige Problemumgehung besteht darin, für jede Quelle einen separaten Dokumenttyp zu verwenden, da dies die einzige Möglichkeit ist, schnell nach Quelle zu filtern, während das gleiche Dashboard beibehalten wird. Dies führt jedoch zu einem weiteren Konfigurationsproblem (tm), da wir für jede Umgebung neue Typzuordnungen erstellen müssen ...

Wir stehen vor einer Situation, in der Benutzer aus verschiedenen Abteilungen unterschiedliche Rollen übernehmen und über ihre eigenen Dashboards auf dieselben Daten zugreifen.
zB Entwickler vs. Support-Mitarbeiter an vorderster Front.

Wie können wir die Dashboard-Änderungen einschränken - damit die von Entwicklern erstellten Dashboards z. nicht vom Support-Personal geändert werden können?

Wenn Shield ausschließlich an den Index gebunden ist, würde es nicht funktionieren, da die zugrunde liegenden Daten für beide Dashboards gleich sind.

Danke schön.

+1 dafür.
Im Moment verwende ich Ansible und Vorlagen, um den Kopier- und Ersetzungsprozess zumindest ein wenig zu automatisieren, aber dies sollte nicht _DER_ Weg sein, dies zu tun. Redundanz ist aus Wartungssicht nicht cool...

+1

+1 dafür.
Es wäre sehr nützlich, diese Funktion zu haben, wenn Sie ein Indexmuster für jede Umgebung (dev, homolog, prod) haben, aber Dashboards und Visualisierungen gleich sind.

+1
Ein an die Visualisierung gebundener Index, eingebettet in Dashboards, ist ein absoluter Albtraum. Es macht unmöglich, Aliase für aktuelle Daten und langfristige Logstash-Daten zu verwenden, ohne die Dashboards vollständig neu zu schreiben.

Bitte sehen Sie sich an, wie die Dashboard-Oberfläche und das Design in Grafana 2 funktionieren, das meiner Meinung nach völlig gepasst hat. Diagramme sind beispielsweise keine separate Einheit, sondern werden innerhalb eines Dashboards erstellt.

+1 Im Moment ist es ein absoluter Albtraum, wenn Sie komplexe Plattformen haben.

+1 Bitte fügen Sie diese Unterstützung schnell hinzu...

+1

+1 Es ist ein großer Albtraum für uns, 3 verschiedene Dashboards in 3 verschiedenen Umgebungen erstellen und dann pflegen zu müssen. Die Dashboards sollten für uns in jeder Umgebung gleich sein, aber ohne diese Funktion müssen wir Visualisierungen und Dashboards dreimal manuell erstellen.

+1

+1

+1

+1
Doppelte Visualisierungen sind nicht der richtige Weg.
Warum haben Sie die Handhabung von Dashboards in Kibana 3 geändert?!?

+1

+1

+1

+1

+1

+1 das wäre wirklich wichtig für uns

+1

In Bitergia haben wir ein Tool erstellt, um automatische Dashboards aus einem Vorlagen-Dashboard zu erstellen. Eine der Hauptaufgaben besteht darin, den Index zu ändern.

Hier ist das Open-Source-Tool, falls es für jeden nützlich ist:

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

+1

+1

@rashidkpc : Ich habe Ihren Vorschlag ausprobiert und habe Schwierigkeiten, die richtigen Einträge zu erstellen. Dann bekomme ich eine Kibana-Warnung:

"Mit Vorsicht fortfahren

Das Ändern von Objekten ist nur für fortgeschrittene Benutzer. Objekteigenschaften werden nicht validiert und ungültige Objekte können Fehler, Datenverlust oder Schlimmeres verursachen. Wenn Ihnen nicht jemand mit genauer Kenntnis des Codes gesagt hat, dass Sie hier drin sein sollen, sollten Sie es wahrscheinlich nicht sein."

Können Sie ein Beispiel für das Kopieren eines solchen Dashboards geben? Es sieht so aus, als könnten Benutzer ihre Kibana-Instanz damit vermasseln.

+1

+1

+5

+1

+1

+1

+1

+1

Hallo @rashidkpc
Fühlen Sie sich auch ein Jahr später mit den oben gegebenen Antworten bei diesem Thema immer noch genauso?

Vielleicht eine "offizielle" Antwort zum Umgang mit den oben genannten Umgebungen?

+1

+1

+1

+1

+1 bitte.

+1

+1

+1

+1

+1

+1

+1

+1

+1

👍

+1

+1

+1

+1

+1

+1

+1

OMG. Das wäre so praktisch!!!

+1 – Kibana muss wirklich wiederverwendbare „Assets“ unterstützen.

+1

+1

+1111!!!1eins

+1

+1

+1 das wäre super!

+1 dafür.

+1

+1

+1

+1

+1

+1

+1! Könnte sehr nützlich sein

+1

+1

+1

+1

+1
Ich dachte das wäre schon möglich :(

+1

Das ist def. ein Must-have. Bitte lass es geschehen.

+1

+1

+1

Wird eine angeforderte Funktion nach 2 Jahren existieren? Wer weiß! +1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000000000

+1

+1

+1

+1

+1

+1

+1

+1

Möchte jemand bei Elastic dies tatsächlich implementieren?

+1

+1

+1

+1

+1 dafür, gibt es Pläne zur Umsetzung?

Zu Ihrer Information, Sie können die JSON-Darstellung jeder Visualisierung auf der Registerkarte "Gespeicherte Objekte" ziemlich einfach manuell bearbeiten: /app/kibana#/management/kibana/objects?_g=()&_a=(tab:visualizations) . Ich habe es noch nicht ausprobiert, aber ein Export, Find- Replace (oder Pipe zu

+1 absolut, es ist ein dringend benötigtes Feature; Es wird viele manuelle Dashboard-Erstellungsarbeiten und deren Wartungsarbeiten reduzieren.

+1

+1

kann Export und Import verwenden implementiert

+1

Ich verstehe nicht, warum wir bei der Entdeckung Indizes ändern können, aber bei der Visualisierung sind wir gezwungen, von vorne anzufangen.

Ich baue gerade einige komplexe Visualisierungen mit nginx index und wollte prüfen, ob ich mit dem Lackindex bessere Ergebnisse erzielen kann... aber da wir keine Indizes ändern dürfen, muss ich einen neuen Tab öffnen, den Index ändern und richten Sie die Visualisierungsfelder erneut ein.

Beachten Sie, dass dies nicht nützlich ist, um bereits implementierte Visualisierungen zwischen verschiedenen Umgebungen zu kopieren, aber auch nützlich, um Indexvisualisierungen zu vergleichen und den besten Index für eine Visualisierung zu erstellen. Es ist auch sehr hilfreich für die Wartung, wenn sich ein Feldname ändert, können wir eine Visualisierung ändern und für mehrere Umgebungen speichern. Die Alternative besteht darin, alle Visualisierungen zu exportieren, zu bearbeiten und erneut zu importieren ... es funktioniert, aber es ist sehr hackig

Bitte fügen Sie dies hinzu.

+1

+1

Ich habe diese Funktion implementiert, indem ich ein JS-Skript in die Kibana-Seite eingefügt habe. Siehe https://github.com/gofreddo/kibana-copy-objects/ .

+1

+1 Dies wäre eine massive Verbesserung für uns. Derzeit müssen wir entweder alle unsere Daten in einem Satz täglicher Indizes haben, damit wir Dashboards teilen können, oder wir müssen die Dashboards manuell kopieren und auf dem neuesten Stand halten, nur um den Index zu ändern, an dem sie arbeiten.

+1

+1

+1

+1

Die beste Lösung besteht darin, die Suche auf der Registerkarte "Entdecken" von Kibana zu speichern und Ihre Visualisierungen/Dashboards aus der gespeicherten Suche anstelle des Indexmusters zu erstellen. Wenn Sie jetzt zu einem anderen Index wechseln müssen, können Sie zur gespeicherten Suche zurückkehren und den Index aus der Dropdown-Liste ändern und speichern. Dadurch ändert sich der Index in der Visualisierung/dem Dashboard.

@svadapalli wie ist das hilfreich, wenn eine Suche trotzdem mit einem

Sie können die vorhandene Suche ersetzen, indem Sie sie einem neuen Index zuordnen. Wenn Sie abhängige Visualisierungen haben, wird automatisch zum Index gewechselt.

₊1

Leute, dies ist eine Open-Source-Software, und ehrlich gesagt, mit der Ebene der übergebenen URI-Konfiguration für jede Visualisierung / jedes Dashboard habe ich das Gefühl, dass es eine einfache Möglichkeit gibt, alle Instanzen eines referenzierten Indexmusters zu überschreiben.

Dieser Anwendungsfall ist in der Welt der Berechtigungen und der Sicherheitsdurchsetzung üblich, wo Sie möglicherweise Tonnen von JSON-Buckets mit denselben Schemas, aber unterschiedlichen Kategorien dieser Buckets und unterschiedlichen Daten haben, um Benutzer mit denselben Dashboards, aber unterschiedlichen Indizes anzuzeigen. Es ist super sexy, wenn du es sagst

+1

+1

+1

+1

+1

+1 ........... Aber die 111+ Leute * zwei Jahre warten...... Es sollte eine Schwelle bei Open Source Software geben, wo nach einer bestimmten Anzahl von Mannjahren (Personenjahren ?) Eine Anfrage sollte an die Spitze der Problemliste gesetzt werden und die Person, die gnädigerweise ihre Zeit als Gebietsbesitzer zur Verfügung gestellt hat, sollte einige detaillierte Hinweise (Code, Strategie) zur Lösung des Problems eingeben, dann einen der anderen von wir werden uns ermächtigt fühlen, es zu verwirklichen.

Ich bin sicher, es gibt noch viel mehr Leute, die eintauchen würden, wenn sie auf die 10.000er-Ebene gehoben werden könnten.

+1

+1

1+. Nach dem neuen Upgrade von ELK auf 6.X, bei dem Typen nicht mehr unterstützt werden, müssen wir eine komplette Migration unserer Dashboards durchführen, da sie alle auf demselben Index basieren und sich nur in ihrem Typ unterscheiden.

+1

+1

+1
Können wir den Index des Dashboards in Grafana ändern??

Jeder Kibana kann dieses Problem schließen, wenn kein Plan für diese Funktion vorhanden ist

Wenn wir .kibana betrachten, müssen wir möglicherweise den Werteindex in searchsourcejson von Visualisierungen und Suchen aktualisieren.

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

Unabhängig davon würde es allen helfen, wenn wir den Index als separates Attribut abrufen und eine API zum Ändern des Attributs bereitstellen können.

Möchte das auch +1

Ich habe es möglich gemacht https://github.com/ArtemUstynov/kibana_dashboard_manager . Auch wenn Sie das Dashboard für einen neuen Index kopieren müssen, schreiben Sie mir einfach eine Nachricht

Ich habe ein paar Fragen an alle, die gespannt auf die Implementierung dieser Funktion warten, während ich beginne, verschiedene Ansätze zur Lösung dieser Probleme zu erkunden.

Lassen Sie mich zunächst versuchen, die Hauptprobleme zu verstehen, die hier diskutiert wurden:

Problem 1: Es gibt keine Möglichkeit, in einem gegebenen Satz bestehender Dashboards und Visualisierungen einfach ein Indexmuster gegen ein anderes auszutauschen.

Problem 2: Sie möchten nicht viele doppelte Visualisierungen und Dashboards verwalten, bei denen sich nur das Indexmuster unterscheidet. Diese Situation tritt auf, weil Betrachter Ihrer Dashboards Zugriff auf Daten haben, die sich in unterschiedlichen Indexmustern befinden.

Klingt das richtig?

Ich möchte mich vorerst nur auf Problem 2 konzentrieren.

Um ein hypothetisches Szenario zu geben, erstellt ein Unternehmen Kibana-Dashboards für seine Kunden, Kunde A und Kunde B. Die Daten von Kunde A liegen im Indexmuster client-a-* und die Daten von Kunde B im Indexmuster client-b-* . Das Unternehmen verfügt jetzt über zwei doppelte Sätze von Visualisierungen und Dashboards, bei denen alles gleich ist, außer dem Indexmuster, das zum Erstellen der Visualisierungen verwendet wurde.

Ist das der Situation ähnlich, in die viele von Ihnen geraten? Wenn ja, bin ich gespannt, ob jemand versucht hat, dies zu umgehen, indem er einen einzelnen Satz von Visualisierungen erstellt hat, die auf das Indexmuster client-* . Die Daten der beiden Clients würden natürlich aufgrund ihrer Berechtigungen gefiltert, sodass sie nur ihre eigenen Daten sehen würden.

Wenn das Problem darin besteht, dass der Dashboard-Ersteller die Daten, die jedem Client angezeigt werden, leicht anzeigen möchte, könnten Sie dann ein Feld client hinzufügen, nach dem gefiltert werden soll?

Als Randnotiz gibt es ein _index Metafeld, aber Sie können nicht mit einem Platzhalter suchen, was bedeutet, dass Sie bei einem Muster von client-a-date nicht datenübergreifend sehen können .

Wenn Sie diesen Weg gehen, müssen Sie nur einen Satz Visualisierungen und ein Dashboard verwalten. Die Daten werden für Betrachter natürlich basierend auf ihren Berechtigungen gefiltert, aber Administratoren, die Zugriff auf alle Indexmuster haben, können alles anzeigen oder die Daten segmentieren. Kunden sehen das Kundenfeld, sehen jedoch nur ihren eigenen Namen als Option zur Auswahl darin (damit sie überhaupt keinen Verweis auf a ).

Wenn ich verstehe, dass diese Problemumgehung als Lösung nicht ausreicht, kann ich herausfinden, welche Bedenken bei der Implementierung dieser Funktion berücksichtigt werden müssen.

naja was du beschreibst ist bei mir nicht das problem. Sagen wir, ich indiziere N Elemente zu
elastisch und nenne es "Ansatz 1", dann indiziere ich Daten, die dieselben Jsons hatten
Felder, aber diese Daten wurden in einem anderen (hoffentlich besseren) extrahiert und
Nennen Sie es "Ansatz 2", also möchte ich jetzt eine Reihe meiner Visualisierungen haben
auf einen anderen Index angewendet. Stellen Sie sich das Dashboard als Zeiger und Index vor
Da ein Datenzeiger auf zeigt, möchte ich einen Zeiger (Dashboard mit allen)
Minenvisualisierungen ), die auf einen neuen Index angewendet werden sollen.

Um ehrlich zu sein, habe ich ein Python-Skript erstellt, um dieses Problem zu umgehen.
Sie können es sich ansehen, ich habe es als Lösung gepostet. Außerdem habe ich eine Funktion hinzugefügt
"Clone"-Dashboard, das es auf einen neuen Index anwendet, sodass Sie zwei haben
Dashboards, aber sie verweisen auf verschiedene Indizes .

Am Do, 1. März 2018 um 17:11 Uhr, Stacey Gammon [email protected]
schrieb:

Ich habe ein paar Fragen an alle, die sich sehnsüchtig darauf freuen
Feature implementiert wird, während ich beginne, verschiedene Ansätze zu erkunden
Lösung dieser Probleme.

Lassen Sie mich zunächst versuchen, die Hauptprobleme zu verstehen, die besprochen wurden
Hier:

Problem 1: Es gibt keine Möglichkeit, ein Indexmuster einfach gegen . auszutauschen
einen anderen in einem bestimmten Satz bestehender Dashboards und Visualisierungen.

Problem 2: Sie möchten nicht viele doppelte Visualisierungen pflegen
und Dashboards, bei denen sich nur das Indexmuster unterscheidet. Dies
Situation auftritt, weil Betrachter Ihrer Dashboards Zugriff auf Daten haben
die sich in verschiedenen Indexmustern befindet.

Klingt das richtig?

Ich möchte mich vorerst nur auf Problem 2 konzentrieren.

Um ein hypothetisches Szenario darzustellen, erstellt ein Unternehmen Kibana-Dashboards für
deren Kunden, Kunde A und Kunde B. Die Daten von Kunde A sind in Kunde-a-*
Indexmuster und die Daten von Client B befinden sich im client-b-*-Indexmuster. Der
Unternehmen hat jetzt zwei doppelte Sätze von Visualisierungen und Dashboards, wobei
alles ist gleich, außer dem Indexmuster, das zum Erstellen der Visualisierungen verwendet wird.

Ist das der Situation ähnlich, in die viele von Ihnen geraten? Wenn ja, bin ich
neugierig, ob jemand versucht hat, das zu umgehen, indem er eine Single erstellt hat
Satz von Visualisierungen, die auf das Indexmuster client-*. Die Zwei
Kundendaten würden natürlich aufgrund ihrer Berechtigungen gefiltert, also
sie würden nur ihre eigenen Daten sehen.

Wenn das Problem darin besteht, dass der Dashboard-Ersteller es leicht sehen möchte
die Daten, die jeder Kunde sieht, könnten Sie ein Kundenfeld hinzufügen, nach dem gefiltert werden soll?

[Bild: Screenshot 2018-03-01 um 10.47.49 Uhr]
https://user-images.githubusercontent.com/16563603/36854121-2f297614-1d3e-11e8-8036-c9f69aa99ea0.png

Als Randnotiz gibt es ein _index-Metafeld, aber Sie können nicht suchen mit
ein Platzhalter darauf, was bedeutet, dass Sie, wenn Ihr Muster ein Kunde für ein Datum ist, Sie
würde nicht in der Lage sein, über Daten hinweg zu sehen.

Wenn Sie diesen Weg gehen, gibt es nur einen Satz von Visualisierungen und einen
Armaturenbrett zu pflegen. Die Daten werden für Zuschauer auf natürliche Weise gefiltert, basierend auf
ihre Berechtigungen, aber Administratoren, die Zugriff auf alle Indexmuster haben, können
alles anzeigen oder die Daten segmentieren. Kunden sehen das Kundenfeld, aber
sehen nur ihren eigenen Namen als Option zur Auswahl (damit sie es nicht tun würden)
siehe überhaupt einen Verweis auf a).

Zu verstehen, wie diese Problemumgehung als Lösung nicht ausreicht, wird mir helfen
Finden Sie heraus, welche Bedenken angesprochen werden müssen, wenn ich über die Implementierung nachdenke
Dieses Feature.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/elastic/kibana/issues/3668#issuecomment-369642283 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/Ae1KBra2IKRCwsvTuL6wLY0UKVBlwDXxks5taB2_gaJpZM4EHRML
.

Interessant, danke für die Antwort @ArtemUstynov. Ich kann den oben angegebenen Link nicht aufrufen. Ich erhalte einen 404-Fehler.

Wie oft erstellen Sie neue Indizes mit unterschiedlichen Ansätzen? Wenn Sie diese beiden Ansätze haben, behalten Sie beide bei oder wählen Sie einen und verwerfen den anderen?

Wenn Ihr zweiter Index ein Präfix mit dem von Ihrem ersten Ansatz erstellten Index teilt und Sie beiden Indizes ein Feld namens "Ansatz" hinzugefügt haben, würde meine obige Lösung dann für Sie funktionieren? Sie könnten einen einzigen Satz von Visualisierungen verwenden, die das gemeinsame Präfix als Indexmuster verwenden, und die Ansätze durch Filtern wechseln.

Wenn wir Benutzern erlauben würden, mit einem Platzhalter für das automatisch _index Feld

Ich konnte definitiv die Nützlichkeit einer Massenindexänderung für eine ausgewählte Gruppe gespeicherter Objekte für einmalige Situationen erkennen. Sie haben beispielsweise alle Ihre Visualisierungen mit dem Verweis auf approach-a-* und möchten sie nun auf approach-* verweisen.

Ich bin mir nur nicht sicher, was der Unterschied zwischen dem Ändern von Indizes und dem Filtern nach Indizes ist (vorausgesetzt, die Indexzuordnungen sind die gleichen, die sie sein müssten, damit ein Indexaustausch nahtlos funktioniert). Beides ist eine Möglichkeit, um zu sagen: "Ich möchte diesen Datensatz nur anzeigen, alles andere ausschließen". Benutzer wissen bereits, wie sie ihre Daten auf einem Dashboard filtern, aber das Ändern des Index wäre ein neues Konzept mit einer neuen Benutzeroberfläche. Bevor wir ein neues UI/UX einführen, möchte ich sicherstellen, dass es nicht zu kompliziert oder verwirrend ist und dass nicht bereits etwas verwendet wird, das wir stattdessen zur Lösung des Problems nutzen könnten.

@Stacey-Gammon hier gehts 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()))`

Es tut mir leid, wenn ich mich nicht richtig erklärt habe und wir am Ende über zwei verschiedene Dinge gesprochen haben. Dieses Skript macht ziemlich genau das, was ich wollte. Ich habe auch eine für das "Klonen" des Dashboards erstellt. Wenn es eine Möglichkeit gibt, dies nativ zu tun, dann tut es mir leid, dass ich Ihre Zeit verschwende.

Hallo @ArtemUstynov !

Ich habe das Problem:
nativeURL = " http://localhost :5601/es_admin/.kibana/_mget"
{"statusCode":404,"error":"Nicht gefunden"}'

in der Zeile: VIS = json.dumps(requests.post(nativeURL, json=json.loads(payload), headers=HEADERS).json())

Können Sie mir helfen?

Vielen Dank!!!

Ich greife über ssh auf Kibana zu, also könnte Ihre URL anders sein, Sie können es herausfinden
was ist es, indem Sie zu Ihrem Browser gehen und das Netzwerk überwachen (Rechtsklick ->
Element prüfen -> Netzwerk). dann geh zum Kibana-Management und sieh und
Laden Sie etwas herunter, das Ihnen Ihre "native URL" irgendwo geben sollte
die Antwort (sie wird nicht "native URL" genannt), aber es wird einfach sein,
Finde es, ändere einfach meine URL in deine.

Am Dienstag, 13. März 2018 um 21:17 Uhr, juancar1979 [email protected]
schrieb:

Hallo @ArtemUstynov https://github.com/artemustynov !

Ich habe das Problem:
nativeURL = " http://localhost :5601/es_admin/.kibana/_mget"
{"statusCode":404,"error":"Nicht gefunden"}'

in der Zeile: VIS = json.dumps(requests.post(nativeURL,
json=json.loads(payload), headers=HEADERS).json())

Können Sie mir helfen?

Vielen Dank!!!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/elastic/kibana/issues/3668#issuecomment-372803715 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/Ae1KBmkOB6q1cFJaBnm_s6NXcdv92W86ks5teClUgaJpZM4EHRML
.

Danke @ArtemUstynov , aber ich kann diese URL nirgendwo finden. Weißt du wie ich danach suchen kann? Vielen Dank!
:)

@juancar1979 wie ich oben sagte -> öffne deine Kibana -> gehe zur Verwaltung -> gespeicherte Objekte -> Rechtsklick im Browser -> Element inspizieren -> Netzwerk -> (wenn etwas klar ist (gekreuzter Kreis)) -> jetzt in Kibana klicke alles exportieren -> einige Sachen werden in deinem Netzwerkmenü erscheinen -> unter der Spalte "Name" wähle ein beliebiges Feld aus (als erstes zum Beispiel) -> es wird "Request URL" geben -> spiele damit und du wirst deine url. vielleicht etwas anderes herunterladen, es war auch nicht gerade für mich, aber ich habe versucht, es so allgemein wie möglich zu machen. Versuchen Sie auch, Zwischenwerte aus dem Skript auszudrucken, da die Konsolen-URLs aus irgendeinem Grund nicht immer mit der Benutzeroberfläche übereinstimmen. Tut mir leid, aber ich glaube nicht, dass ich Ihnen mehr helfen kann. Wenn Sie eine ungewöhnliche Konfiguration für einen elastischen Server usw. verwenden, könnte ich es für Sie debuggen. Fragen Sie die Person, die die Server eingerichtet hat, der er helfen könnte. Viel Glück (auch Sie können einfach alles exportieren und Indexnamen im Texteditor ändern und wieder importieren, aber das ist nicht so cool)

danke @ArtemUstynov !!!! Ich versuche dich zu sagen!!! 👍

@juancar1979 Wenn Sie eine Art von Proxy verwenden, kann dies ein Grund dafür sein, dass es fehlschlägt. Fügen Sie einfach ein Flag hinzu, um keine Proxys im Skript zu verwenden (es ist leicht zu googlen, ich erinnere mich nicht genau)

+1. Warum zum Teufel ist diese sehr grundlegende Bitte 3 Jahre alt und wird nicht beachtet?

@ReanimationXP - das ist auf unserem Radar. Ein Teil des Problems ist, dass viele Anfragen in diesem einzigen Problem zusammengefasst sind. Ich habe sie aufgeteilt, um uns zu helfen, die Arbeit besser zu priorisieren:

Ändern von Indexmustern in einer Visualisierung: https://github.com/elastic/kibana/issues/17542
Indexmuster auf Dashboard-Ebene: https://github.com/elastic/kibana/issues/16917
Verbesserter Export/Import, um referenzierte Objekte einzuschließen. Dann können Sie eine Indexmuster-ID in einer einzigen Datei suchen/ersetzen: https://github.com/elastic/kibana/issues/16831

Nachdem ich darüber nachgedacht habe, glaube ich, dass der beste Weg in die Zukunft darin besteht, dieses Megaproblem zu schließen, um die Community hoffentlich dazu zu bringen, uns konkreteres Feedback zu den Unterproblemen zu geben. Wenn jemand mit diesem Weg nach vorne nicht einverstanden ist, bin ich sicherlich offen für eine Überlegung, also zögern Sie nicht, einen Kommentar abzugeben!

Um zu wiederholen, was ich gerade oben in das Thema eingefügt habe:

Wir freuen uns sehr über Ihr bisheriges Feedback zu diesem Mega-Thema, aber wir brauchen Ihre Hilfe, um es in konkretere Punkte aufzuschlüsseln, an denen wir arbeiten können. Auch wenn Sie für dieses spezielle Problem bereits +1 gegeben haben, wäre es äußerst hilfreich, wenn Sie +1 geben und Ihren Anwendungsfall in den unten aufgeführten detaillierteren Problemen beschreiben könnten. Wir werden nicht alle Rückmeldungen ignorieren, die die Leute bisher in dieser Ausgabe gegeben haben, aber ein gezielteres Feedback zu den einzelnen Feature-Vorschlägen wäre von unschätzbarem Wert.

Hier sind die drei Unterthemen, von denen ich glaube, dass sie dieses Mega-Thema ausmachen:

Ändern von Indexmustern in einer Visualisierung: #17542
Indexmuster auf Dashboard-Ebene: #16917
Verbesserter Export/Import, um referenzierte Objekte einzuschließen. Dann können Sie eine Indexmuster-ID in einer einzelnen Datei suchen/ersetzen: #16831

Indexmuster auf Dashboard-Ebene scheinen dieser ersten Anfrage am besten zu entsprechen, und es gibt derzeit eine verfügbare Problemumgehung dafür, die in #16917 erwähnt wird.

Wenn diese drei Probleme Ihren speziellen Fall nicht abdecken, teilen Sie uns dies bitte mit!

Das einzige, was nicht angesprochen wurde, ist, dass jemand auch das Gegenteil tun möchte - dasselbe Feld von mehreren Sites aus (unter der Annahme von Sites == Indizes) in einem Dashboard überwachen und einen anderen Teil der Suche variieren.. dh "Zeige mir Feuchtigkeit" an allen Standorten, wenn die Temperatur > 50 ist." "Okay, jetzt > 51." Splunk verwendet optionale "globale" Benutzervariablen und Steuerelemente auf Dashboard-Ebene, die in die Suchzeichenfolge jeder Visualisierung (einschließlich Index) eingefügt werden, um sowohl dieses als auch das Indexproblem zu lösen, wie ich in #17542 beschrieben habe. Ich glaube nicht, dass die aktuelle Filterung eine solche Anfrage über mehrere Indizes hinweg verarbeiten könnte, aber ich könnte mich irren. Trotzdem denke ich, dass es offensichtlich viel häufiger vorkommen wird, Visuals einfach nach Site (Index) zu ändern. Ein einfaches „globales“ Dropdown-Menü zum Ändern des Indexes oder eine Möglichkeit, den Index über mehrere Visualisierungen hinweg zu ändern, wäre beides besser, da ich vermute, dass Zwischenlösungen schneller implementiert werden können als die derzeit vorhandenen.

Sehr interessant @ReanimationXP. Ich denke, unsere Filter können damit umgehen, zumindest mit der in https://github.com/elastic/kibana/issues/16917 erwähnten

Hier ist mein Versuch – ich habe zwei Indizes animal-cats und animal-dogs und ich habe drei Visualisierungen – eine um nur die Katzengeräusche anzuzeigen, eine für die Hundegeräusche und eine für alle. Ich kann einen Filter hinzufügen und er filtert die Visualisierungen, obwohl sie Daten aus verschiedenen Indizes enthalten:

Ist das ungefähr richtig?

Der Nachteil dieser Problemumgehung ist meiner Meinung nach, dass Sie möglicherweise nicht für jedes "Site-/Indexmuster" eine Visualisierung erstellen möchten wir haben einige der gleichen Probleme mit Indexmustern auf Dashboard-Ebene).

Klingt so, als ob es eine Untersuchung wert wäre, indem Sie eine Art von Suchen/Ersetzen für Variablen verwenden, wie Sie es von Splunk erwähnt haben. Es wäre jedoch schwierig, es in unsere aktuelle Infrastruktur zu integrieren, wir müssten viele Dinge ändern, um sie benutzerfreundlich zu machen, IMO.

Ich leide unter dem gleichen Problem.
Ich benutze einen Trick, um das zu lösen.

1. Speichern Sie Ihre Visualisierung. (Aktivieren Sie "Als neue Visualisierung speichern")
2. Geschäftsführung gehen. => gespeicherte Objekte => Visualisierungen
   und speichern Sie die gewünschten Visualisierungen.
3. und löschen Sie die Visualisierungen.
4. öffne die json-Datei. und ändern Sie "kibanaSavedObjectMeta - searchSourceJSON - index uuid" in eine beliebige uuid
   Ich ändere "5dad88d0-475b-11e8-9a8b-51472dd99c91" in "5dad88d0-475b-11e8-9a8b-51472dd99c92"
5. Geschäftsführung gehen. => gespeicherte Objekte => Visualisierungen
   und importieren Sie diese JSON-Datei.
6. Sie können einen neuen Index auswählen.

viel Glück.

+1

+1

+1

+1

+1

@heris25 , könnten Sie bitte erklären, warum Sie in Schritt 3 die Visualisierung löschen? Könnten Sie in Schritt 4 bitte auch klären, wo Sie die Index-UUID gefunden haben. Ich sehe nichts namens UUID. Ich freue mich, wenn Sie klären können, welches Feld ich in kibanaSavedObjectMeta.searchSourceJSON ändern muss.

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