Kibana: Modifier l'index sur la visualisation/le tableau de bord

Vous pouvez le faire en copiant les documents de visualisation dans elasticsearch et en modifiant le paramètre pour index. Je ne nous vois pas prendre en charge une interface utilisateur pour ce type de fonctionnalité de sitôt.

:( Cela devient alors un problème O(M*N) rapidement insoluble (N=le nombre d'index, et M le nombre de visualisations.

Est-ce possible avec l'architecture actuelle ? L'index apparaît lié à la visualisation, pas au tableau de bord dans K4. Cela me serait extrêmement utile. Comme la plupart des gens (j'imagine), chacun de mes environnements est divisé en index distincts ; maintenir les tableaux de bord devient difficile...

Dans Kibana 3, j'ai piraté une zone de liste de sélection qui permet aux utilisateurs de changer d'index pour chaque tableau de bord, ce qui signifie qu'un seul tableau de bord doit être maintenu pour tous les environnements. Kibana 4 lie cependant l'index à la visualisation et non au tableau de bord. Cela pourrait être utile si le tableau de bord pouvait (éventuellement) remplacer l'index sur ses visualisations ? Je peux voir à quel point il est utile d'avoir un tableau de bord indépendant des index dans certains cas d'utilisation.

+1

Copier les documents de visualisation dans Elasticsearch n'est pas vraiment une option. Cela génère beaucoup d'informations dupliquées et la mise à jour serait un cauchemar.

+1 à ce sujet. Le concept de « modèle d'index » correspond naturellement à une « source » de données et le tableau de bord rend actuellement impossible cette opération.

À tout le moins, la barre de recherche en haut de la page du tableau de bord devrait permettre le filtrage par un modèle d'index "plus spécifique" mais elle ne semble pas accepter les recherches avec des modèles _index:­...-* (ni des valeurs spécifiques d'ailleurs ).

Notre solution de contournement actuelle consiste à avoir un type de document distinct pour chaque source car c'est le seul moyen de filtrer rapidement par source tout en restant le même tableau de bord, mais cela crée un autre problème de configuration (tm) car nous devons créer de nouveaux mappages de type pour chaque environnement ...

Nous sommes confrontés à une situation où nous aurons des utilisateurs de différents départements jouant des rôles différents et accédant aux mêmes données via leurs propres tableaux de bord.
par exemple les développeurs vs le personnel d'assistance de première ligne.

Comment pouvons-nous restreindre les modifications du tableau de bord - de sorte que l'ensemble des tableaux de bord créés par les développeurs pour, par exemple. ne peut pas être modifié par le personnel d'assistance ?

Si shield est lié uniquement à l'index, cela ne fonctionnera pas car les données sous-jacentes des deux tableaux de bord sont les mêmes.

Merci.

+1 pour cela.
En ce moment, j'utilise Ansible et des modèles pour au moins automatiser un peu le processus de copie et de remplacement, mais cela ne devrait pas être _LA_ façon de le faire. La redondance n'est pas cool du point de vue de la maintenance...

+1

+1 pour cela.
Il serait très utile d'avoir cette fonctionnalité lorsque vous avez un modèle d'index pour chaque environnement (dev, homologue, prod) mais les tableaux de bord et les visualisations sont les mêmes.

+1
Avoir un index lié à la visualisation, intégré dans les tableaux de bord, est un cauchemar complet. Il rend impossible l'utilisation d'alias pour les données récentes et les données de logstash à long terme, sans réécrire complètement les tableaux de bord.

Veuillez jeter un coup d'œil au fonctionnement de l'interface et de la conception du tableau de bord dans Grafana 2, ce qui m'a totalement convaincu de mon point de vue. Par exemple, les graphiques ne sont pas des entités distinctes mais créés à l'intérieur d'un tableau de bord.

+1 En ce moment, c'est un cauchemar complet lorsque vous avez des plates-formes complexes.

+1 Veuillez ajouter ce support rapidement...

+1

+1 C'est un énorme cauchemar pour nous de devoir créer puis entretenir 3 tableaux de bord différents dans 3 environnements différents. Les tableaux de bord devraient être les mêmes pour nous dans chaque environnement, mais sans cette fonctionnalité, nous devons créer manuellement des visualisations et des tableaux de bord 3 fois.

+1

+1

+1

+1
Les visualisations en double ne sont pas la solution.
Pourquoi avez-vous changé la façon dont Kibana 3 gère les tableaux de bord !?!?

+1

+1

+1

+1

+1

+1 ce serait vraiment important pour nous

+1

Dans Bitergia, nous avons créé un outil pour créer des tableaux de bord automatiques à partir d'un tableau de bord modèle. L'une des tâches principales est de modifier l'index.

Voici l'outil open source au cas où il serait utile à quelqu'un :

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

+1

+1

@rashidkpc : J'ai essayé votre suggestion et j'ai du mal à créer les entrées appropriées. Ensuite, je reçois un avertissement Kibana :

"Procéder avec prudence

La modification des objets est réservée aux utilisateurs avancés. Les propriétés des objets ne sont pas validées et les objets non valides peuvent provoquer des erreurs, des pertes de données ou pire. À moins que quelqu'un ayant une connaissance intime du code ne vous dise d'être ici, vous ne devriez probablement pas y être."

Pouvez-vous fournir un exemple de copie d'un tel tableau de bord ? Il semble que les utilisateurs pourraient très bien gâcher leur instance de kibana avec cela.

+1

+1

+5

+1

+1

+1

+1

+1

Salut @rashidkpc
Vous ressentez toujours la même chose à propos de cette question un an plus tard avec les réponses données ci-dessus ?

Peut-être une réponse "officielle" sur la façon de gérer les environnements mentionnés ci-dessus ?

+1

+1

+1

+1

+1 s'il vous plaît.

+1

+1

+1

+1

+1

+1

+1

+1

+1

??

+1

+1

+1

+1

+1

+1

+1

OH MON DIEU. Ce serait tellement utile !!!

+1 - Kibana a vraiment besoin de prendre en charge les « actifs » réutilisables.

+1

+1

+1111!!!1un

+1

+1

+1 ce serait super !

+1 pour cela.

+1

+1

+1

+1

+1

+1

+1 ! Peut être très utile

+1

+1

+1

+1

+1
Je pensais que c'était déjà possible :(

+1

C'est la déf. la chose à avoir. S'il vous plaît, faites en sorte que cela se produise.

+1

+1

+1

Une fonctionnalité demandée existera-t-elle après 2 ans ? Qui sait! +1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+100000000000

+1

+1

+1

+1

+1

+1

+1

+1

Alors, est-ce que quelqu'un chez Elastic veut réellement implémenter cela ?

+1

+1

+1

+1

+1 pour cela, est-il prévu de le mettre en œuvre ?

Pour info, vous pouvez assez facilement modifier manuellement la représentation JSON de chaque visualisation dans l'onglet Objets enregistrés : /app/kibana#/management/kibana/objects?_g=()&_a=(tab:visualizations) . Je ne l'ai pas essayé, mais effectuer une exportation, rechercher-remplacer (ou diriger vers

+1 absolument , c'est une fonctionnalité très nécessaire ; Cela réduira beaucoup d'efforts de création manuelle de tableaux de bord et leur travail de maintenance.

+1

+1

peut utiliser l'exportation et l'importation mis en œuvre

+1

Je ne comprends pas pourquoi lors de la découverte, nous pouvons changer les index, mais lors de la visualisation, nous sommes obligés de recommencer.

Je construis juste des visualisations compex avec l'index nginx et je voulais vérifier si en utilisant l'index vernis je pouvais obtenir de meilleurs résultats... mais comme nous ne sommes pas autorisés à changer les index, je dois ouvrir un nouvel onglet, changer l'index et configurer à nouveau les champs de visualisation.

Notez que cela n'est pas utile pour copier des visualisations déjà implémentées entre différents environnements, mais également utile pour comparer des visualisations d'index et aider à créer le meilleur index à utiliser pour une visualisation. C'est également très utile pour la maintenance, si un nom de champ change, nous pouvons changer une visualisation et enregistrer pour plusieurs environnements. L'alternative est d'exporter toutes les visualisations, de les éditer et de les importer à nouveau... ça marche, mais c'est très bidon

S'il vous plaît, ajoutez ceci.

+1

+1

J'ai implémenté cette fonctionnalité en injectant un script JS dans la page Kibana. Voir https://github.com/gofreddo/kibana-copy-objects/ .

+1

+1 Ce serait une énorme amélioration pour nous. Actuellement, nous sommes obligés soit d'avoir toutes nos données dans un seul ensemble d'index quotidiens afin que nous puissions partager des tableaux de bord, soit de devoir copier manuellement et maintenir à jour les tableaux de bord simplement afin de modifier l'index sur lequel ils travaillent.

+1

+1

+1

+1

La meilleure solution consiste à enregistrer la recherche dans l'onglet de découverte de Kibana et à créer vos visualisations/tableaux de bord à partir de la recherche enregistrée au lieu du modèle d'index. Désormais, chaque fois que vous devez passer à un index différent, vous pouvez revenir à la recherche enregistrée et modifier l'index à partir de la liste déroulante et l'enregistrer. Cela changera l'index dans la visualisation/le tableau de bord.

@svadapalli en quoi est-ce utile, lorsqu'une recherche est de toute façon enregistrée avec un modèle d'index ?

Vous pouvez remplacer la recherche existante en la mappant à un nouvel index. S'il vous arrive d'avoir des visualisations dépendantes, le basculement vers l'index se produit automatiquement.

1

Les gars, il s'agit d'un logiciel open source, et honnêtement, avec le niveau de configuration URI passé pour chaque visualisation / tableau de bord, j'ai l'impression qu'il existe un moyen simple de remplacer toutes les instances d'un modèle d'index référencé.

Ce cas d'utilisation est courant dans le monde des autorisations et de l'application de la sécurité, où vous pouvez avoir des tonnes de buckets de JSON avec les mêmes schémas, mais différentes catégories de ces buckets et des données différentes pour montrer aux utilisateurs les mêmes tableaux de bord mais des indices différents. C'est super sexy quand tu le dis

+1

+1

+1

+1

+1

+1 ........... Mais les 111+ personnes * deux ans d'attente......Il devrait y avoir un certain seuil dans les logiciels open source où après un certain nombre d'années-personnes (années-personnes ?) une demande doit être épinglée en haut de la liste des problèmes et la personne qui a gracieusement donné de son temps pour être le propriétaire de la zone doit entrer des pointeurs détaillés (code, stratégie) pour résoudre le problème, puis l'un des autres nous nous sentirons habilités à y parvenir.

Je suis sûr qu'il y a beaucoup plus de gens qui plongeraient s'ils pouvaient faire monter l'air au niveau 10 000.

+1

+1

1+. Après la nouvelle mise à niveau d'ELK vers 6.X, où les types ne sont plus pris en charge, nous devrons effectuer une migration complète de nos tableaux de bord, car ils étaient tous basés sur le même index, ne différant que par leur type.

+1

+1

+1
Peut-on changer l'index du tableau de bord dans grafana ??

n'importe qui kibana peut fermer ce problème si aucun plan pour cette fonctionnalité

En regardant .kibana, nous devrons peut-être mettre à jour l'index de valeur dans searchsourcejson des visualisations et des recherches.

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

Quoi qu'il en soit, si nous pouvons obtenir l'index en tant qu'attribut séparé et fournir une API pour modifier l'attribut, cela aiderait tout le monde.

J'aimerai aussi ça +1

J'ai rendu cela possible https://github.com/ArtemUstynov/kibana_dashboard_manager . aussi si vous avez besoin de copier le tableau de bord pour un nouvel index, envoyez-moi simplement un SMS

J'ai quelques questions à poser à tous ceux qui attendent avec impatience la mise en œuvre de cette fonctionnalité, alors que je commence à explorer différentes approches pour résoudre ces problèmes.

Permettez-moi d'abord d'essayer de comprendre les principaux problèmes qui ont été discutés ici :

Problème 1 : il n'existe aucun moyen d'échanger facilement un modèle d'index contre un autre dans un ensemble donné de tableaux de bord et de visualisations existants.

Problème 2 : vous ne voulez pas conserver une multitude de visualisations et de tableaux de bord en double où la seule chose qui diffère est le modèle d'index. Cette situation se produit parce que les utilisateurs de vos tableaux de bord ont accès aux données qui résident dans différents modèles d'index.

Cela semble-t-il exact ?

Pour l'instant, je voudrais me concentrer uniquement sur le problème 2.

Pour donner un scénario hypothétique, une entreprise crée des tableaux de bord Kibana pour ses clients, le client A et le client B. Les données du client A sont en modèle d'index client-a-* et les données du client B sont en modèle d'index client-b-* . L'entreprise dispose désormais de deux ensembles de visualisations et de tableaux de bord en double, où tout est égal à l'exception du modèle d'index utilisé pour créer les visualisations.

Est-ce similaire à la situation que beaucoup d'entre vous rencontrent ? Si c'est le cas, je suis curieux de savoir si quelqu'un a essayé de contourner ce problème en créant un seul ensemble de visualisations qui pointent vers le modèle d'index client-* . Les données des deux clients seraient naturellement filtrées en raison de leurs autorisations, de sorte qu'ils ne verraient que leurs propres données.

Si le problème est que le créateur du tableau de bord veut pouvoir facilement voir les données que chaque client voit, pourriez-vous ajouter un champ client pour filtrer ?

En remarque, il y a un champ méta _index mais vous ne pouvez pas rechercher en utilisant un caractère générique dessus, ce qui signifie que si votre modèle est client-a-date vous ne pourrez pas voir à travers les dates .

Si vous suivez cette voie, il n'y a qu'un seul ensemble de visualisations et un seul tableau de bord à gérer. Les données sont filtrées naturellement pour les téléspectateurs en fonction de leurs autorisations, mais les administrateurs qui ont accès à tous les modèles d'index peuvent tout voir ou segmenter les données. Les clients verront le champ client mais ne verront que leur propre nom comme option à sélectionner (ils ne verront donc aucune référence à a ).

Comprendre comment cette solution de contournement échoue en tant que solution m'aidera à déterminer les problèmes à résoudre lorsque je pense à la mise en œuvre de cette fonctionnalité.

bien ce que vous décrivez n'est pas le problème pour moi. Disons que j'indexe N éléments à
élastique et nommez-le "approche 1" puis j'indexe les données qui avaient les mêmes Jsons
champs, mais ces données ont été extraites dans un autre (espérons mieux) et
nommez-le "approche 2", alors maintenant je veux que l'ensemble de mes visualisations soit
appliqué à un indice différent. Considérez le tableau de bord comme un pointeur et un index
comme un pointeur de données pointe vers, donc je veux un pointeur (tableau de bord avec tous
visualisations de mine ) à appliquer à un nouvel index.

Pour être honnête avec vous, j'ai créé un script python pour contourner ce problème.
vous pouvez le vérifier, je l'ai posté comme solution. J'ai également ajouté une fonctionnalité à
"cloner" le tableau de bord en l'appliquant au nouvel index, vous aurez donc deux
tableaux de bord, mais ils référenceront différents index .

Le jeu. 1 mars 2018 à 17:11, Stacey Gammon [email protected]
a écrit:

J'ai quelques questions à tous ceux qui attendent cela avec impatience
fonctionnalité en cours d'implémentation, alors que je commence à explorer différentes approches pour
résoudre ces problèmes.

Permettez-moi d'abord d'essayer de comprendre les principaux problèmes qui ont été discutés
ici:

Problème 1 : Il n'y a aucun moyen d'échanger facilement un modèle d'index contre
un autre dans un ensemble donné de tableaux de bord et de visualisations existants.

Problème 2 : vous ne voulez pas conserver une multitude de visualisations en double
et des tableaux de bord où la seule chose qui diffère est le modèle d'index. Cette
situation se produit parce que les utilisateurs de vos tableaux de bord ont accès aux données
qui réside dans différents modèles d'index.

Cela semble-t-il exact ?

Pour l'instant, je voudrais me concentrer uniquement sur le problème 2.

Pour donner un scénario hypothétique, une entreprise crée des tableaux de bord Kibana pour
leurs clients, client A et client B. les données du client A sont dans client-a-*
modèle d'index et les données du client B sont dans le modèle d'index client-b-*. le
l'entreprise dispose désormais de deux ensembles de visualisations et de tableaux de bord en double, où
tout est égal sauf le modèle d'index utilisé pour créer les visualisations.

Est-ce similaire à la situation que beaucoup d'entre vous rencontrent ? Si oui, je suis
curieux de savoir si quelqu'un a essayé de contourner ce problème en créant un seul
ensemble de visualisations qui pointent vers le modèle d'index client-*. Les deux
les données des clients seraient naturellement filtrées en raison de leurs autorisations, donc
ils ne verraient que leurs propres données.

Si le problème est que le créateur du tableau de bord veut pouvoir facilement voir
les données que chaque client voit, pourriez-vous ajouter un champ client à filtrer ?

[image : capture d'écran 01-03-2018 à 10 47 49 h]
https://user-images.githubusercontent.com/16563603/36854121-2f297614-1d3e-11e8-8036-c9f69aa99ea0.png

En remarque, il existe un champ méta _index mais vous ne pouvez pas rechercher en utilisant
un caractère générique dessus, ce qui signifie que si votre modèle est client-a-date, vous
ne serait pas en mesure de voir à travers les dates.

Si vous suivez cette route, il n'y a qu'un seul ensemble de visualisations, et un
tableau de bord à maintenir. Les données sont filtrées naturellement pour les téléspectateurs en fonction de
leurs autorisations, mais les administrateurs qui ont accès à tous les modèles d'index peuvent
tout voir ou segmenter les données. Les clients verront le champ client mais
verront uniquement leur propre nom comme une option à sélectionner (ainsi ils ne verraient pas
voir une référence à un du tout).

Comprendre comment cette solution de contournement échoue en tant que solution m'aidera
déterminer les problèmes qui doivent être résolus lorsque je pense à la mise en œuvre
cette fonctionnalité.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/3668#issuecomment-369642283 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/Ae1KBra2IKRCwsvTuL6wLY0UKVBlwDXxks5taB2_gaJpZM4EHRML
.

Intéressant, merci pour la réponse @ArtemUstynov. Je ne suis pas en mesure de visiter le lien que vous avez fourni ci-dessus, j'obtiens une erreur 404.

À quelle fréquence créez-vous de nouveaux index avec des approches différentes ? Une fois que vous avez ces deux approches, gardez-vous les deux ou en choisissez-vous une et jetez-vous l'autre ?

Si votre deuxième index partage un préfixe avec l'index créé par votre première approche et que vous avez ajouté un champ appelé « approche » aux deux index, ma solution ci-dessus fonctionnerait-elle alors pour vous ? Vous pourriez avoir un seul ensemble de visualisations en utilisant le préfixe partagé comme modèle d'index et changer d'approche par filtrage.

Si nous permettions aux utilisateurs de filtrer avec un caractère générique sur le champ _index automatiquement inclus, vous n'auriez même pas besoin d'ajouter manuellement un champ supplémentaire.

Je pouvais certainement voir l'utilité d'un changement d'index en bloc pour un groupe sélectionné d'objets enregistrés pour des situations ponctuelles. Par exemple, vous avez créé toutes vos visualisations pointant vers approach-a-* et maintenant vous voulez les pointer vers approach-* .

Je ne suis tout simplement pas sûr de la différence entre la modification des index et le filtrage sur les index (en supposant que les mappages d'index soient les mêmes, ce qu'ils devraient être pour qu'un échange d'index fonctionne de manière transparente). Les deux sont une façon de dire "Je veux seulement afficher cet ensemble de données, exclure tout le reste". Les utilisateurs savent déjà filtrer leurs données sur un tableau de bord, mais changer l'index serait un nouveau concept avec une nouvelle interface utilisateur. Je veux m'assurer, avant d'introduire une nouvelle UI/UX, qu'elle ne complique pas trop ou ne prête pas à confusion, et qu'il n'y a pas quelque chose déjà utilisé dont nous pourrions profiter pour résoudre le problème à la place.

@Stacey-Gammon et voilà 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()))`

Eh bien, je suis désolé si je ne me suis pas bien expliqué et que nous avons fini par parler de deux choses différentes. Ce script fait à peu près ce que je voulais. j'en ai aussi fait un pour "cloner" le tableau de bord. S'il existe un moyen de le faire nativement, je suis désolé de vous avoir fait perdre du temps.

Salut @ArtemUstynov !

j'ai le problème :
nativeURL = " http://localhost :5601/es_admin/.kibana/_mget"
{"statusCode":404,"error":"Non trouvé"}'

en ligne : VIS = json.dumps(requests.post(nativeURL, json=json.loads(payload), headers=HEADERS).json())

Pouvez-vous m'aider?

Merci!!!

j'accède à kibana via ssh, donc votre URL peut être différente, vous pouvez le découvrir
qu'est-ce que c'est en allant sur votre navigateur et surveillez le réseau (clic droit ->
inspecter l'élément -> réseau). puis allez à la gestion de kibana et voyez et
télécharger quelque chose qui devrait vous donner votre "URL native" quelque part dans
la réponse (elle ne s'appellera pas "native url") mais il sera facile de
repérez-le, changez simplement mon URL en la vôtre.

Le mar. 13 mars 2018 à 21:17, juancar1979 [email protected]
a écrit:

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

j'ai le problème :
nativeURL = " http://localhost :5601/es_admin/.kibana/_mget"
{"statusCode":404,"error":"Non trouvé"}'

en ligne : VIS = json.dumps(requests.post(nativeURL,
json=json.loads(payload), headers=HEADERS).json())

Pouvez-vous m'aider?

Merci!!!

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/elastic/kibana/issues/3668#issuecomment-372803715 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/Ae1KBmkOB6q1cFJaBnm_s6NXcdv92W86ks5teClUgaJpZM4EHRML
.

Merci @ArtemUstynov , mais je ne trouve cette URL nulle part. Savez-vous comment je peux le chercher ? Merci beaucoup!
:)

@juancar1979 comme je l'ai dit ci-dessus -> ouvrez votre kibana -> accédez à la gestion -> objets enregistrés -> faites un clic droit dans le navigateur -> inspectez l'élément -> réseau -> (s'il y a quelque chose, effacez-le (cercle croisé)) -> maintenant dans kibana, cliquez sur tout exporter -> certaines choses apparaîtront dans votre menu réseau -> dans la colonne "nom", sélectionnez n'importe quel champ (d'abord par exemple) -> il y aura "URL de demande" -> jouez avec et vous comprendrez votre URL. peut-être télécharger quelque chose d'autre, ce n'était pas simple pour moi non plus, mais j'ai essayé de rendre l'approche aussi générale que possible. Essayez également d'imprimer les valeurs intermédiaires à partir du script, car pour une raison quelconque, les URL de la console ne correspondent pas toujours à l'interface utilisateur. Désolé, mais je ne pense pas pouvoir vous aider plus que cela, si vous utilisez une configuration inhabituelle pour le serveur élastique, etc., je serais en mesure de la déboguer pour vous. Demandez à la personne qui a configuré les serveurs qu'il pourrait vous aider. Bonne chance (vous pouvez également tout exporter et modifier les noms d'index dans l'éditeur de texte et le réimporter, mais ce n'est pas aussi cool)

merci @ArtemUstynov !!!! J'essaie de te dire !!! ??

@ juancar1979 si vous utilisez une sorte de proxy, cela pourrait être une raison pour laquelle il échoue. ajoutez simplement un indicateur pour ne pas utiliser de proxy dans le script (c'est facilement googleble je ne me souviens pas exactement)

+1. Pourquoi diable cette demande très basique a-t-elle 3 ans et ne reçoit-elle aucune attention ?

@ReanimationXP - c'est sur notre radar. Une partie du problème est qu'il y a de nombreuses demandes regroupées dans ce seul problème. Je les ai séparés pour nous aider à mieux prioriser le travail :

Modification des modèles d'index sur une visualisation : https://github.com/elastic/kibana/issues/17542
Modèles d'index au niveau du tableau de bord : https://github.com/elastic/kibana/issues/16917
Exportation/importation améliorée pour inclure les objets référencés. Ensuite, vous pouvez effectuer une recherche/remplacer sur un identifiant de modèle d'index dans un seul fichier : https://github.com/elastic/kibana/issues/16831

Après y avoir réfléchi, je pense que la meilleure façon d'avancer est de fermer ce méga problème pour, espérons-le, inciter la communauté à nous donner des commentaires plus spécifiques sur les sous-problèmes. Si quelqu'un n'est pas du tout d'accord avec cette voie à suivre, je suis certainement ouvert à reconsidérer, alors n'hésitez pas à commenter !

Pour réitérer ce que je viens d'ajouter au début du problème :

Nous apprécions vraiment tous vos commentaires sur ce méga problème jusqu'à présent, mais nous avons besoin de votre aide pour le décomposer en éléments plus concrets sur lesquels travailler. Même si vous avez déjà attribué +1 à ce problème spécifique, il serait extrêmement utile que vous puissiez attribuer +1 et décrire votre cas d'utilisation dans les problèmes plus détaillés fournis ci-dessous. Nous n'ignorerons pas tous les commentaires que les gens ont fournis jusqu'à présent dans ce numéro, mais des commentaires plus ciblés sur les propositions de fonctionnalités individuelles seraient inestimables.

Voici les trois sous-problèmes qui, selon moi, constituent ce méga problème :

Modification des modèles d'index sur une visualisation : #17542
Modèles d'index de niveau de tableau de bord : #16917
Exportation/importation améliorée pour inclure les objets référencés. Ensuite, vous pouvez effectuer une recherche/remplacer sur un identifiant de modèle d'index dans un seul fichier : #16831

Les modèles d'index de niveau de tableau de bord semblent correspondre le mieux à cette demande initiale et il existe actuellement une solution de contournement pour cela, qui est mentionnée dans #16917.

Si ces trois problèmes ne couvrent pas votre cas particulier, merci de nous le faire savoir !

La seule chose qui n'est pas abordée est que je pouvais voir quelqu'un vouloir faire l'inverse également - surveiller le même champ à partir de plusieurs sites (en supposant que les sites == index) dans un tableau de bord, en faisant varier une autre partie de la recherche. niveaux sur tous les sites lorsque la température est > 50." "D'accord, maintenant > 51." Splunk utilise des variables et des commandes utilisateur "globales" facultatives au niveau du tableau de bord qui sont injectées dans la chaîne de recherche de chaque visualisation (y compris l'index) pour résoudre à la fois ce problème et le problème de l'index, comme je l'ai décrit dans #17542. Je ne pense pas que le filtrage actuel puisse gérer une telle demande sur plusieurs index, mais je peux me tromper. Cela dit, je pense que le simple fait de changer les visuels par site (index) sera évidemment beaucoup plus courant. Une simple liste déroulante « globale » pour modifier l'index, ou un moyen de modifier en bloc l'index sur plusieurs visualisations serait mieux, plus rapide pour mettre en œuvre des solutions intermédiaires que ce qui existe actuellement, je suppose.

Très intéressant @ReanimationXP. Je pense que nos filtres peuvent gérer cela, au moins en utilisant la solution de contournement mentionnée dans https://github.com/elastic/kibana/issues/16917.

Voici ma tentative - j'ai deux index animal-cats et animal-dogs , et j'ai trois visualisations - une pour montrer uniquement les sons du chat, une pour les sons du chien et une pour tous. Je peux ajouter un filtre et il filtrera les visualisations même si elles contiennent des données provenant de différents index :

Est-ce juste?

L'inconvénient de cette solution de contournement, que je vois, est que vous ne voudrez peut-être pas avoir à créer une visualisation pour chaque "modèle de site/index", auquel cas je pourrais voir que les modèles d'index au niveau du panneau du tableau de bord sont une meilleure solution (bien qu'alors nous rencontrons certains des mêmes problèmes avec les modèles d'index au niveau du tableau de bord).

On dirait qu'il vaut la peine d'étudier l'utilisation d'une sorte de recherche/remplacement de variables comme vous le mentionnez splunk. Il serait cependant difficile de l'intégrer dans notre infrastructure actuelle, nous aurions besoin de changer beaucoup de choses pour la rendre conviviale, selon l'OMI.

Je souffre du même problème.
J'utilise une astuce pour résoudre ce problème.

1. enregistrez votre visualisation. (cochez la case "Enregistrer en tant que nouvelle visualisation")
2. allez Gestion. => objets sauvegardés => Visualisations
   et enregistrez que vous voulez les visualisations.
3. et supprimez les visualisations.
4. ouvrez le fichier json. et remplacez "kibanaSavedObjectMeta - searchSourceJSON - index uuid" par n'importe quel uuid
   je change "5dad88d0-475b-11e8-9a8b-51472dd99c91" en "5dad88d0-475b-11e8-9a8b-51472dd99c92"
5. allez Gestion. => objets sauvegardés => Visualisations
   et importez ce fichier json.
6. vous pouvez choisir un nouvel index.

Bonne chance.

+1

+1

+1

+1

+1

@heris25 , pourriez-vous s'il vous plaît expliquer pourquoi à l'étape 3 vous supprimez la visualisation ? De plus, à l'étape 4, pourriez-vous s'il vous plaît préciser où vous avez trouvé l'index uuid, je ne vois rien nommé uuid. J'apprécie si vous pouvez préciser quel champ je dois modifier dans 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"
}