Optimisation temps de réponse requête

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

Je travail actuellement à la conception d'une interface qui récupère des données dans une instance ElasticCloud de notre client.
Notre client indéxe des logs via filebeat. Plusieurs index par jour et par nature de logs.

mes requêtes commencent donc par GET /filebeat*/_search.

J'ai un accés à Kibana et depuis quelques jours les temps de réponse des requêtes dépassent les 2 secondes.

je dois faire plusieurs types de requête (aggregation , filtrage, etc)

Que faire pour optimise tout ça ?

Faut-il faire un seul et même index ou continuer avec une trés grande quantité d'index ?

Pour l'instant nous sommes en phase de développement et nous pouvons "casser" les index existants.

Merci d'avance pour vos réponses.

Laurent

2

Comme tu utilises cloud.elastic.co, tu devrais d'abord demander de l'aide au support. https://www.elastic.co/cloud/as-a-service/support.

Peux-tu faire:

GET /_cat/indices?v
GET /_cat/nodes?v
GET /_cat/health?v

Faut-il faire un seul et même index ou continuer avec une trés grande quantité d'index ?

Je te recommande ces ressources:

3

Bonjour David,

Merci pour tes liens que j'etudie avec attention.
Concernant les commandes voici les résultats

La commande _cat/indices?v retourne 413 lignes (trop long pour ce message)
J'ai donc résumé les résulats
267 index de log pour 13 millions de documents
146 index (.monitoring, .watcher, .reporting ) pour un total de 23.3 millions de documents.

health	:yellow
status	:open
index	:Filebeat-6.1.2-2018.02.22 
uuid	:xxxxxxx
pri	:5
rep	:1
docs.count	: 113 000
store.size	: ~ 20MB
pri.store.size	: ~ 20Mb

Les 267 lignes sont preque identiques (à part le nom de l'index et le nombre de doc qui varie)
Pour les 3 dernières infos j'ai mis la moyenne (docs.count, store.size, pri.store.size)
le max pour store.size est de 60Mb.

Pour la commande _cat/nodes?

ip	: 172.00.000.000
heap.percent	: 71
ram.percent	: 95
cpu	: 40
load_1m	: 13.37
load_5m	: 13.33
load_15m	: 14.14
node.role	: mdi
master	: *
name	: instance-0000000005

Et pour la commande _cat/health?

epoch	: 1528378945
timestamp	: 0,5711226852
cluster	: bc4701b5a057bd910f4fb20228129d96
status	: yellow
node.total	: 1
node.data	: 1
shards	: 1519
pri	: 1519
relo	: 0
init	: 0
unassign	: 1505
pending_tasks	: 0
max_task_wait_time	-
active_shards_percent	: 50.2%

A la lecture des ressources indiquées et sans être un grand spécialiste je pense que l'ensemble n'est pas vraiment optimisé.

Pour info nous n'avons pas la main sur la paramétrage d'ES cloud. le service R&D du client gére les données envoyées et l'indexation....mais pour l'instant ça rame...

Merci et à bientôt.

4

Peux-tu uploader les résultats bruts sur gist.github.com?

5

C'est fait à l'adresse :

Laurent

6

Quelques constats:

Je te conseille de virer les index .watcher-history*, éventuellement les index .monitoring-* anciens.

Tu as aussi des index filebeat de 2017. Tu en as encore besoin ?

Bref, je supprimerai énormément d'index inutiles et je changerai la configuration des index filebeat pour n'utiliser qu'un seul shard et évnetuellement (mais je n'ai pas regardé comment on fait), passer à des index mensuels vu le faible volume que tu as.

Tout ça est expliqué plus ou moins dans la vidéo que j'ai liée.

7

Grand merci David pour tes explications. il ne reste plus qu'a en discuter avec le client et passer à l'action...

8

En même temps conseille lui de prendre du support officiel de l'éditeur. Notre équipe est excellente !

9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.