Elasticsearch: Ajouter une méthode pour calculer les noms d'alias pour les modèles d'index

Dans le même ordre d'idées, le guide définitif d'elasticsearch dit "d'utiliser des alias au lieu d'indices dans votre application", mais avec des modèles et des indices horodatés, cela n'est pas possible AFAIK, par exemple. Je ne peux pas avoir de modèle correspondant à my_index_v1-2014.03.26 et créer un alias de my_index-2014.03.26

C'est fondamentalement le même que le commentaire de Shay sur #5180

J'aimerais vraiment avoir aussi l'alias avec la partie date ajoutée à partir du nom de l'index, car cela fera en sorte que la requête n'atteigne que les index avec une date spécifique, sinon cela touchera tous les index et dégradera les performances.

J'adorerais revoir ça. Il est plutôt maladroit de contourner cela avec une tâche cron pour créer des alias tous les jours.

Ce serait bien de pouvoir faire des scripts pour créer un nom d'alias. Mais la plupart du temps, il serait utilisé pour implémenter le modèle d'index par jour. Cela ressemble donc toujours à un hack.
C'est pourquoi j'ai créé un problème distinct ( #7631 ) pour prendre en charge nativement ce modèle commun.

Qu'en penses-tu?

Une autre façon de déclencher des créations d'alias, au lieu de répéter des tâches, serait de savoir si l'index a été créé automatiquement après avoir effectué l'action d'indexation. J'ai également créé un numéro séparé ( #7634 ) pour cela. Je suppose que c'est l'approche la plus simple à mettre en œuvre (par rapport aux scripts dans les modèles ou aux index glissants natifs).

+1

Pour commencer, j'aimerais pouvoir spécifier des alias basés sur le temps. Par example:

METTRE /_modèle/mon_modèle

...
"aliases": { "my_alias-{YYYY}-{MM}-{DD}" } 

créerait my_alias-2015.03.27 sur le nouvel index, etc. Bien que le script complet soit génial.

Nous en avons discuté aujourd'hui et réfléchi à la solution basée sur les expressions régulières suggérée par Shay dans le problème lié, par exemple, si nous prenions en charge les expressions régulières complètes dans le nom du modèle avec des variables capturées :

{ 
  "template": "(logstash-\d\d\d\d)-*",
  ...
  "aliases": {
    "{index:$1}": { ... }
  }
}

L'alias d'un index logstash-2014-03-20 serait alors logstash-2014 . Je suis préoccupé par l'exécution de scripts lors de la création d'index (en particulier avec la désactivation des scripts dynamiques pour Groovy).

@javanna qu'est-ce que tu en penses ? Vous avez été assez impliqué dans les trucs de modèles d'alias.

que pensez-vous de cela?

que puis-je dire? Je n'aime pas les regex... si je dois choisir entre des scripts groovy et des regex... je pourrais en fait aller avec des scripts... désolé.

Les scripts semblent beaucoup trop compliqués ici. En fait, nous prenons déjà en charge les regex dans le paramètre template (le seul opérateur étant * ?), cela les étendrait simplement en _real_ regex afin que vous puissiez utiliser des sous-modèles dans d'autres des endroits.

Je pense que les regex avec vars capturés seraient suffisamment puissants pour résoudre ce problème. Ce serait fantastique si cela fonctionnait également avec le #7634.

J'espérais un nom d'alias, calculé/basé sur la valeur d'un champ.

+1

Je suis tout à fait d'accord pour dire que quelque chose comme ça est nécessaire. J'utilise également actuellement des tâches cron pour créer des alias pour les index quotidiens, mais résoudre ce problème dans le modèle serait certainement un meilleur moyen.
Une solution complète de regex n'est même pas vraiment nécessaire, une solution simple serait de permettre la substitution de la partie fixe de la valeur "template", donc si le modèle s'applique à "logstash-*", gardez la partie correspondant au * mais autoriser la substitution de la partie logstash par une autre chaîne fixe.
Cela répondrait efficacement à tout indice récurrent.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Un autre cas d'utilisation courant qui bénéficiera de l'extension de la prise en charge des alias est celui des index partagés avec routage. Il serait utile de pouvoir les générer dynamiquement à l'aide d'un modèle (pour certains déploiements, il peut y en avoir des milliers et plus).

POST /_aliases
{ 
"actions": [{ 
"add": { 
"index": "sales", 
"alias": sales_<CUST_ID>, 
"filter": {"term": {"customer_id": <CUST_ID>}}, 
"routing": <CUST_ID> 
} 
}] 
}

@martijnvg ce problème a-t-il été résolu par https://github.com/elastic/elasticsearch/pull/12209 ?

En partie oui, et je suis sûr que cela résoudrait mon problème immédiat.

Plus intéressant serait d'étendre le concept et d'avoir des groupes de capture dans le nom regex pour les modèles d'index, afin de pouvoir réutiliser une partie du nom d'index dans la définition d'alias. Mais je peux me dire assez heureux avec #12209 :+1:

Si je définis un alias par utilisateur et que j'ai des millions d'utilisateurs, cette amélioration me permettrait de conserver un alias pour tous les utilisateurs au lieu de définir manuellement un alias par utilisateur ?

En raison de moins d'alias, une partie de la charge serait réduite par rapport à l'état du cluster, n'est-ce pas ?

Pourrait vraiment utiliser cette fonctionnalité. Peut-être créer un chemin à définir dans l'alias comme cela fonctionne dans le mappage pour d'autres champs afin que nous puissions faire une solution de contournement ?

Comme je l'ai pour le champ _id, par exemple, pour le personnaliser, vous pouvez également permettre à l'alias de le prendre en charge.
"_identifiant": {
"path": "event_id"
},

+1

:+1: Juste curieux s'il y a une mise à jour pour savoir si cela est toujours considéré et/ou travaillé ?

+1

+1

+1

Existe-t-il un moyen de faire pivoter l'alias en fonction d'événements temporels ?
Je me demandais si je pouvais créer des alias "actuels", "hier", "dernier_mois", "dernière_année" et les faire pivoter en fonction de la date actuelle. Par exemple, lorsque le jour passe du 2016.06.30 au 2016.07.01, les alias seraient automatiquement modifiés de telle sorte que l'actuel serait l'index 2016.07.01, hier serait le 2016.06.30 et ainsi de suite.
J'aurais donc toujours un alias mis à jour pointant vers le bon index.

@marcelovcpereira jetez un œil à la nouvelle API de rollover https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-rollover-index.html

Merci pour votre réponse Clinton, mais je ne sais pas si cela résoudrait mon problème. Cela roule les index en fonction d'un entier incrémentiel.
Je ne veux pas rouler mes index, je veux rouler mes alias sur les index nouvellement créés.
Je veux que l'alias "current" pointe toujours vers l'index d'aujourd'hui (par exemple, index-2016.07.01) .
Mais à la fin de la journée, l'alias "actuel" doit pointer vers le nouvel index créé index-2016.07.02.
J'ai résolu la partie de création d'index automatiquement quotidienne.
J'ai besoin de résoudre les pointeurs d'alias.
Et il y a une autre restriction : j'utilise actuellement Elasticsearch 1.7.3.
Je n'aurais donc pas cette fonctionnalité de toute façon.

+1

+1

+1

+1

https://github.com/elastic/elasticsearch/issues/20367 devrait principalement résoudre ce problème pour le cas d'utilisation de la journalisation

Discuté dans le réparer vendredi. Clôture au profit du #20367.

S'il vous plaît, laissons-le ouvert. #20367 ne résout qu'un seul cas d'utilisation (c'est probablement le cas le plus populaire), mais ce qui a été discuté ici a une portée plus large.

Quelque chose a changé depuis le dernier message ? Une chance d'avoir des fonctionnalités complètes?

+1

+1

+1

+1

+1

+1

+1

Cela peut-il être rouvert ? @clintongormley

+1

+1
Je voudrais dire que cette conversation ne parle pas du cas où l'index contient un numéro de version
À titre d'exemple, j'utilise index avec ce genre de nom : july_dec_2018_v2 , (où v2 est le numéro de version de l'index, et devrait être incrémentiel).
L'alias de cet index ressemble à : @july_dec_2018

Ce serait génial de pouvoir le faire avec un modèle ! Je ne pense pas que ce soit possible pour l'instant, n'est-ce pas ?

Je suis désolé, c'est mon réglage.

{
"template" : "debug-*",
"réglages" : {
"number_of_shards" : 1
},
"alias": {
"{application}-alias-for-{env}": {
"formater": {
"env": {
"lang": "expression",
"script": "doc['nom'].valeur"
},
"application": {
"lang": "expression",
"script": "doc['app'].value"
}
}
}
}
}

mais le résultat est
"debug-2018": {
"alias": {
"application": {},
"{application}-alias-for-{env}": {}
}
}

+1

+1

Nous utilisons également des index basés sur le temps versionnés et pourrions vraiment utiliser cette fonctionnalité. Dans l'état actuel des choses, nous devons créer des index avant d'écrire afin de pouvoir créer l'alias sans version que nous utilisons pour l'écriture.

+1

+1

@rbraley cela a-t-il été introduit ?

En général, si ElasticSearch recommande aux utilisateurs d'utiliser une approche, il est important que la fonctionnalité puisse satisfaire les besoins des utilisateurs. Cependant, ils ne constituent toujours pas un moyen bien conçu d'utiliser les alias. #20367 ne résout qu'un problème très spécifique.

+1

J'ai trouvé ça, peut-être que ça aide :
https://stackoverflow.com/questions/37690083/elasticsearch-alias-auto-update-for-rolling-index

PUT /_template/my_elmah_template
   {
       "template" : "elmah_*",
       "aliases" : {
             "elmah_all" : { }
       }
   }