Bonsoir,
J'utilise une application web qui transmet des fichiers vers elastic afin de pouvoir visualiser la donnée dans Kibana.
Tout fonctionnait très bien depuis 2 ans, mais je suis désormais bloqué : les fichiers qui jusqu'à présent apparaissaient dans Kibana sous la forme d'indices ne sont plus intégrés.
Là où ça devient très étrange, c'est que je me suis aperçu que le blocage intervient au 478ème index. Il me suffit de supprimer un index pour pouvoir intégrer un nouveau fichier (et peu importe la taille du fichier). Est-ce que quelqu'un a une idée de ce qui se passe ? Merci par avance pour vos lumières. Bonne soirée.
Bienvenue !
Tu peux exécuter ça et fournir le résultat ?
GET /
GET /_cat/nodes?v
GET /_cat/health?v
GET /_cat/indices?v
Merci ! Je suis absolument novice en la matière. Dois-je copier le code dans Dev Tools Console ? Merci d'avance.
Bonjour @renaud_l,
Ton probleme vient peut etre de ca:
Il serait peut etre utile de reduire ton nombre d'index.
Mais ca depends de tes donnees et de tes besoins, peux-tu nous donner plus d'informations a propos de la taille de ton serveur (CPU, RAM, memoire allouee pour la HEAP etc...), le types de donnees (ex: logs serveur, donnees metier etc...) indexes et l'organisation de tes index (ex: un index par mois, par semaine etc...).
Un peu de lecture pour la gestion des index:
- Tutorial: Customize built-in ILM policies | Elasticsearch Guide [8.11] | Elastic
- Roll up or transform your data | Elasticsearch Guide [8.11] | Elastic
Desole pour les accents.
Oui et poster la reponse avec du formattage sinon ca va gronder 
Bonjour Gabriel et merci pour ta réponse.
J'ai copié le code dans console / dev tools, sous un code qui était déjà présent.
J'ai cliqué sur "click to send request".
Sur la partie droite, j'ai le message "No requests in range".
J'imagine que je n'ai pas procédé correctement.
Je joins une copie d'écran.
Excellente journée à tous et merci d'avance pour votre aide.
Tu dois cliquer sur "click to send request" pour chaque command.
Tu mets ton curseur sur la ligne de la command par exemple "GET /" et tu click sur "click to send request" pour executer la command.
GET /
Résultat de la requête :
{
"name" : "epyo-stocker",
"cluster_name" : "epyo-cluster",
"cluster_uuid" : "B5zzc4ZuRae0j9A8Q1Vomw",
"version" : {
"number" : "7.6.1",
"build_flavor" : "default",
"build_type" : "docker",
"build_hash" : "aa751e09be0a5072e8570670309b1f12348f023b",
"build_date" : "2020-02-29T00:15:25.529771Z",
"build_snapshot" : false,
"lucene_version" : "8.4.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
GET /_cat/nodes?v
Résultat de la requête :
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1 84 78 12 0.17 0.26 0.30 dilm * epyo-stocker
GET /_cat/health?v
Résultat de la requête :
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1662716056 09:34:16 epyo-cluster yellow 1 1 514 514 0 0 471 0 - 52.2%
GET /_cat/indices?v
Résultat de la requête :
J'avais préparé un fichier excel contenant le résultat de la requête car j'ai dû modifier le nom des indices qui contenaient des informations clients. Mais je ne peux pas joindre le fichier en question. Je joins une image des premiers enregistrements et j'ajoute quelques commentaires :
Le fichier comprend :
- 471 indices correspondant aux fichiers envoyés par l'appli web vers elastic. J'avais supprimé 7 indices avant de lancer la requête. On retrouve bien le seuil des 478 indices que j'évoquais dans mon message initial. Ces fichiers ont pour valeur "1" dans le champ "rep".
- 43 indices Kibana (ces fichiers ont pour valeur "0" dans le champ "rep") :
*.apm-agent-configuration
*.kibana_1
*.transform-notifications-000002
*.security-7
*.transform-internal-004
*.kibana_task_manager_1
et 37 fichiers de reporting (par exemple ".reporting-2021.06.13")
Tous les indices ont "1" comme valeur pour le champ "pri".
Tous les status sont "open".
Health est "green" pour les 43 fichiers Kibana et "yellow" pour les 471 indices générés par l'appli web.
Le nombre de caractères max du nom des indices vaut 71.
Max(docs.count) = 3575
Sum(docs.deleted) = 0
store.size = pri.store.size
store.size = 5 Mb pour un fichier reporting ; sinon, store.size < 100 kb pour chacun des 471 indices générés par l'appli web.
Je me pose plusieurs questions :
1 - Dois-je relancer ces requêtes avec 478 indices ?
2 - A quoi correspondent les fichiers "reporting" générés régulièrement par Kibana ?
3 - Puis-je supprimer ces fichiers en attendant de trouver le problème afin de gagner un peu d'indices (augmenter le seuil actuel de 478) ?
Enfin, voici quelques éléments de contexte :
L'appli web est un outil de diagnostic qui permet de collecter des données métiers dans des environnements logistiques et industriels. Le principe est assez simple : on définit une gamme opératoire des actions à réaliser dans le cadre du processus audité. On charge la gamme dans l'appli web et on audite. A tout moment, on peut sauver une séquence d'audit et l'envoyer vers elastic pour visualiser la donnée dans Kibana. En pratique, on génère donc autant d'indices qu'on a sauvé de séquences d'audit. On peut donc en générer beaucoup chaque jour si on décide de découper l'audit par processus / sous-processus / opérateur audité...
J'imagine qu'il y a des possibilités d'agréger la donnée selon des critères bien choisis (client, processus par exemple) afin de diminuer le nombre d'indices. Cependant, j'aimerais bien comprendre ce qui se cache derrière ce seuil de 478 indices intégrés (ou 521 en comptant ceux générés par Kibana) pour ne pas déplacer le problème et me retrouver dans la même situation dans quelques semaines.
Merci d'avance pour votre aide et bonne fin de semaine.
PS : j'espère avoir formatté correctement. Est-ce qu'il existe un moyen de prévisualiser son message avant de le poster ?
471 indices correspondant aux fichiers envoyés par l'appli web vers elastic. J'avais supprimé 7 indices avant de lancer la requête. On retrouve bien le seuil des 478 indices que j'évoquais dans mon message initial. Ces fichiers ont pour valeur "1" dans le champ "rep".
store.size < 100 kb pour chacun des 471 indices générés par l'appli web
C'est tout à fait inefficace. Un seul index suffit largement pour toutes ces données. Je t'invite à lire ceci:
1 - Dois-je relancer ces requêtes avec 478 indices ?
Non. Réduis ton nombre d'index
2 - A quoi correspondent les fichiers "reporting" générés régulièrement par Kibana ?
Quand tu fais un rapport PDF dans Kibana, c'est utilisé.
3 - Puis-je supprimer ces fichiers en attendant de trouver le problème afin de gagner un peu d'indices (augmenter le seuil actuel de 478) ?
Oui si tu n'as plus besoin des rapports.
J'imagine qu'il y a des possibilités d'agréger la donnée selon des critères bien choisis (client, processus par exemple) afin de diminuer le nombre d'indices.
Oui. Si les données sont les mêmes (même mapping), il est inutile de les mettre dans des index séparés.
PS : j'espère avoir formatté correctement.
oui parfait.
Est-ce qu'il existe un moyen de prévisualiser son message avant de le poster ?
Oui. Sur mon PC, on le voit à droite au fur et à mesure qu'on écrit.
Merci David pour ta réponse.
Je vais bouquiner les différentes docs que vous m'avez envoyées Gabriel et toi.
Et je vais réfléchir à une autre organisation des indices.
Actuellement, les indices sont structurés de la même manière pour tous les clients et sont lus par des index patterns propres à chaque "space" (un space par client). Lorsqu'un utilisateur transmet un fichier de l'appli web vers elastic, le nom du fichier comporte un préfixe "nom_client" puis d'autres informations libres choisies par l'utilisateur pour définir son audit. Le nom du fichier devient ensuite le nom de l'index dans Kibana. Dans chaque "space", j'ai créé un index_pattern "nom_client*" qui permet au client de consulter ses données sans avoir accès aux données des autres clients. Passer à un seul index, voire à un index par client, va changer pas mal de choses.
Il y a moyen de faire un alias filtré par client.
Le filtre portant sur l'id du client.
Ensuite, quelle mémoire as-tu alloué à la JVM? Combien y a t'il de RAM sur ta machine ?
Juste pour compléter la réponse de David et te donner plus de lecture 
Le lien vers la documentation pour faire un alias filtré par client.
Merci David et Gabriel pour vos réponses.
Je n'ai pas encore l'info.
Mon idée est de modifier l'alimentation de mes indices (un par client), en ajoutant au nouvel index "client" le nom de la session (qui constitue aujourd'hui le nom de l'index) au moment de l'intégration.
En attendant d'être capable de réaliser cette modification, je voudrais réduire le nombre des indices actuels. J'ai pensé que l'opération "Force_Merge" dans Kibana pourrait me permettre de le faire. Kibana me demande de renseigner le "Maximum number of segments per shard" (je joins une copie d'écran de Kibana).
PS : Dois-je fermer cette discussion pour en ouvrir une autre sur la manière d'alimenter des indices en fonction du préfixe du nom des fichiers ?
Merci et bonne journée.
J'ai réalisé un Force_Merge dans Kibana mais ça ne me permet pas de réduire le nombre d'indices.
Si je souhaite regrouper les indices alo_renaud_session1 jusqu'à alo_renaud_session8 dans un nouvel index alo_renaud_session_tt, est-ce que je peux lancer la commande suivante ?
POST /_reindex
{
"source":{
"index":"alo_renaud_session*"
},
"dest":{
"index":"alo_renaud_session_tt"
}
}
Si c'est le cas, comment puis-je conserver dans un nouveau champ à mapper l'information du nom de fichier initial qui constituait le nom de l'index ?
Merci par avance pour votre aide.
Bonne fin de journée.
Bonsoir, j'ai lancé le reindex du message précédent. Depuis, quand je fais afficher "Reporting", Kibana met fin à ma session avec le message "Too many requests". Est-ce que cela provient du reindex ?
Merci par avance pour vos lumières et bonne semaine.
Bonjour Gabriel et merci pour la doc. Toutefois, je ne suis pas certain de bien comprendre. Dans mon cas, je devrais créer autant d'indices que de clients, puis utiliser un alias "nom_client" pour filtrer les fichiers envoyés par l'appli web vers elastic afin d'alimenter les indices correspondants ?
Merci d'avance pour ta réponse.
Bonjour, je crois que je viens de comprendre d'où venait le blocage. J'ai généré des fichiers dans l'appli web que j'ai envoyés vers elastic jusqu'à atteindre le seuil à partir duquel je ne peux plus rien intégrer. Ensuite j'ai fait un reindex dans devtools, ce qui a généré le message d'erreur suivant :
{
"index" : "alo_demo_user01_test_rl_tt",
"type" : "_doc",
"id" : "eLIzX4MBTZpeRPJYtpdl",
"cause" : {
"type" : "validation_exception",
"reason" : "Validation Failed: 1: this action would add [2] total shards, but this cluster currently has [999]/[1000] maximum shards open;"
},
"status" : 400
}
Le seuil est donc de 1 000 shards.
Merci David et Gabriel pour votre aide.
Bonne journée.
1 Like
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.