je trouve l'idée très interessante mais je ne vois pas bien comment integrer cela avec des flux spécifiques. y-a-t-il un index ECS- ? comment utiliser ces définitions dans un flux propriétaire ? juste en utilisant le même nom ? que se passe-t-il si demain ECS ajoute un nom de champs que j'utilise déjà mais avec un format différent ?
A l'évidence je découvre le sujet, merci pour vos éclaircissements.
Vous pouvez continuer de nommer vos indices de comme vous le voulez. L'index template fourni dans le repo github a comme index pattern ecs-* simplement parce que ça simplifie l'expérimentation.
Voici comment je suggère d'approcher ECS:
Le but est effectivement d'adapter le plus de flux possibles à ECS. De cette façon beaucoup de vos sources de données vont se ressembler plus, rendant plus facile la création de contenu commun (visualisations, ML, etc)
Vos flux peuvent aller dans les indices que vous voulez, peu importe le nom de l'index. La façon de faire des requêtes au travers plusieurs flux différents qui suivent ECS ne sera pas basée sur un nom d'index commun (e.g. ecs-*) mais plutôt sur des requêtes explicites aux indices intéressants.
e.g. GET filebeat-*,logstash-*/_search
ou encore avec des alias d'index qui vous permettent de regrouper vos index de façon logique selon votre situation.
Nous voulons éventuellement modifier le générateur de fichiers d'ECS pour permette aux utilisateurs de construire leurs propres templates basé sur ECS + leurs champs propriétaires. Nous n'en sommes pas encore rendu là, par contre. En attendant, vous avez plusieurs options.
Continuer de construire les templates manuellement.
Vous pouvez utiliser plus d'une template: une qui définit les champs ECS avec un index pattern général, puis une template par index, qui ajoute vos champs propriétaires. La priorité entre les deux est dans ce cas déterminée par le paramètre order dans l'index patterns. Voir Multiple Templates Matching
Certains utilisateurs ont fait un "fork" GitHub de ECS et ajoutent leurs propres champs dans leur copie du code. Cette méthode n'est pas très agréable lorsque nous continuons de modifier ECS, par contre
En ce qui a trait aux conflits, la meilleure façon d'ajouter des champs propriétaires est de suivre ces lignes directrices:
Si vous avez très peu de champs à ajouter, peut-être que vous pouvez les ajouter sous labels., sans aucune modification à l'index template
sinon, ECS essaie d'éviter d'utiliser des noms de marques de commerce dans ses noms de champs (e.g. apache, docker, etc), donc ajouter des champs propriétaires sous un nom propre aidera à éviter les conflits. Par contre cette approche peut être problématique au moment des requêtes vs des flux qui contiennent aussi ces noms relativement communs (e.g. les modules Beats pour apache, docker, etc)
une autre approche est encore d'ajouter vos champs propriétaires sous le nom de votre compagnie, ou par nom de projet interne (e.g. acme.phenix.*)
finalement, pas mal tous les noms de champs définis par ECS ou les autres solutions d'Elastic sont en lettres minuscules, donc ajouter des champs "CamelCase" vous assurera d'éviter un conflit futur.
merci pour ce retour très fourni et interessant pour comprendre la trajectoire ECS à venir. Je vais continuer à suivre ce sujet et appliquer les conseils que vous exposez dans ce ticket.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
