Existe-t-il des conventions pour nommer/organiser les index Elasticsearch qui stockent les données du journal?

Question

Je suis en train de mettre en place Elasticsearch et Kibana en tant que plate-forme de journalisation centralisée dans notre bureau.

Nous avons un certain nombre d'utilitaires et de plug-ins personnalisés dont je voudrais suivre l'utilisation et si des utilisateurs rencontrent des erreurs. Sans compter qu'il y a des serveurs, et des travaux programmés que je voudrais suivre ainsi. Donc, si j'ai un certain nombre de sources différentes pour les données du journal tout aller au même cluster elasticsearch, quelles sont les conventions ou les meilleures pratiques pour la façon dont cela est organisé en index et types de document?

La valeur d'index par défaut utilisée par Logstash est "logstash-%{+YYYY.MM.dd}". Il semble donc préférable de suffixer tous les noms d'index avec la date actuelle, car cela facilite la purge des anciennes données. Cependant, Kibana permet d'ajouter plusieurs "modèles d'index" qui peuvent être sélectionnés à partir de l'interface utilisateur. Pourtant, tous les tutoriels que j'ai lu ne mentionnent que la création d'un seul modèle comme logstash-*.

Comment utiliser plusieurs modèles d'index en pratique? Aurais-je simplement donner des noms pour toutes les sources de mes données? Tels que:

BackupUtility-%{+YYYY.MM.dd} 
UserTracker-%{+YYYY.MM.dd} 
ApacheServer-%{+YYYY.MM.dd} 

J'utilise nLog dans un certain nombre de mes outils qui a une elastic search target. La convention pour nLog et d'autres cadres de journalisation similaires est d'avoir un "logger" pour chaque classe dans le code source. Ces enregistreurs devraient-ils traduire en index dans la recherche élastique?

MyCompany.CustomTool.FooClass-%{+YYYY.MM.dd} 
MyCompany.CustomTool.BarClass-%{+YYYY.MM.dd} 
MyCompany.OtherTool.BazClass-%{+YYYY.MM.dd} 

Ou est-ce trop granulaire pour les noms d'index de ElasticSearch, et il serait préférable de tenir à juste un indice unique daté pour l'application?

CustomTool-%{+YYYY.MM.dd} 

Answer 1

Je ne suis pas au courant de ces conventions, mais pour mon environnement, nous avons utilisé pour créer deux différents types d'indices logstash-* et logstash-shortlived-* en fonction du niveau de gravité. Dans mon cas, je crée le modèle d'index logstash-* car il satisfera les deux types d'indices.

Comme ces index seront stockés chez Elasticsearch et que Kibana les lira, j'imagine que cela devrait vous donner l'option de créer les index de différents modèles. Faites un essai sur votre machine locale. Pourquoi ne pas essayer logstash-XYZ si vous voulez plus de granularité sinon vous pouvez toujours créer des index avec votre nom personnalisé.

Answer 2

Dans mon environnement, nous travaillons sur une question similaire. Nous avons une combinaison de journaux système, d'alertes métriques de Prometheus et de journaux d'applications provenant d'applications client et serveur. En outre, nous avons des variables partagées entre les applications client et serveur qui nous permettent de corréler les deux (par exemple, nous savons quels journaux du serveur correspondent à une opération sur le client qui a fait des demandes audit serveur).Nous expérimentons le schéma suivant pour aider Kibana de répondre aux questions pour nous:

logs-system-{date} 
logs-iis-{date} 
logs-prometheus-{date} 
logs-app-{applicationName}-{date} 

Où:

• {applicationName} est le nom unique d'une application que nous avons écrit (ce pourrait être client ou côté serveur)
• {date} est la date que basée sur le régime utilisé pour les index

de cette façon, nous pouvons mettre en place Kibana recherche contre lo gs-app- * et recherche rapidement des journaux parmi l'une de nos applications. C'est encore nouveau pour nous, mais nous avons commencé sans ce type de schéma et nous le regrettons déjà. Cela rend la recherche de journaux corrélés entre les applications beaucoup plus difficile qu'elle ne devrait l'être.

Answer 3

Dans mon entreprise, nous avons beaucoup travaillé sur ce sujet. Nous sommes d'accord la convention suivante:

• Client - Produit --- ---- Date d'application

Dans tous les cas, il est neccesary à revoir comment les données sont organisées et comment les données sont consultées dans l'organisation

Cordialement

Dario Rodriguez