Mise en oeuvre d'Elastic Common Schema

(Raphael THERY) #1

Bonjour,

j'ai parcouru l'article
Lancement d'Elastic Common Schema ainsi que les liens vers les Modules des metricbeats.

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.

Raphaël

(Mathieu Martin) #2

Bonjour Raphaël,

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 :slight_smile:

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.
2 Likes
(Raphael THERY) #3

Bonjour,

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.

1 Like