Requete Timeout kibana

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

Voici mon infra :
4 noeud ElasticSearch DATA avec la config suivante :
- 6 CPU
- 62 Go de RAM (XMS et XMX configurer à 31 Go)
- 500Go de disque pour le data (Seul elasticsearch installé dessus)
2 noeud ElasticSearch Client (sans data) avec Kibana dessus (chaque kibana pointe vers le noeud elasitc de local) :
- 8 CPU
- 32 Go de RAM (XMS et XMX configurer à 16 Go)

Tous les nœuds sont en version 6.1.1 et sous Centos

Chaque jour, 4 index sont créer (composé chacun de 4 shards active et de 4 replica). Tous les jours, nous supprimons les replica de la veille pour garder que les shards actif. nous gardons les shards 5 jours
La quantité de logs est environ de :
- 1 index : 180 m de events/ jour
- 1 index : 55 m de events /jour
- 2 index : 25 m de events chacun / jour

Mon problème est lorsque j'essaie de faire une recherche sur une période supérieur à 3/4 heures et j'atteins le request timeout de kibana.
J'ai déjà essayé de l'augmenter jusqu'à 120 secs mais je l'atteins toujours.
Quelqu'un saurais t'il m'aider ?

2

copying my colleague @dadoonet

3

Bonjour Rémi

J'ai déplacé ton message dans Discussions en français

Quelques remarques:

Pour les noeuds clients, la notion d'attribuer 50% à la JVM et le reste à l'OS pour le cache FS n'a aucun intérêt ici puisqu'il n'y a pas de data sur disque.
Donc tu pourrais éventuellement augmenter la taille de la HEAP sur ces machines pour avoir d'avantage de mémoire là.

Tous les jours, nous supprimons les replica de la veille pour garder que les shards actif.

Tu veux dire que tous les jours tu supprimes les "index" les plus vieux ?
Si ce n'est pas ce que tu voulais dire, j'aimerais mieux comprendre ce que tu fais. Peux-tu donner le genre de commande tu passes à Elasticsearch pour cela ?

composé chacun de 4 shards active et de 4 replica

Donc en language elasticsearch: 4 primary shards et un replica shard (par primary), right?

Pourquoi 4 ? Comment as-tu trouvé cette valeur ?

4

Bonjour dadoonet,
Merci pour ton retour.

Pour les noeuds clients, la notion d'attribuer 50% à la JVM et le reste à l'OS pour le cache FS n'a aucun intérêt ici puisqu'il n'y a pas de data sur disque.

Je vais modifier le pourcentage de repartions de la RAM sur les nœuds client.
Quel pourcentage préconises tu ? 70% ? Sachant que sur ces machine j'ai également Kibana qui tourne.

Tous les jours, nous supprimons les "index" les plus vieux et nous retirons le replica des index de la veille.
Pour cela, nous utilisons 2 actions curator :

actions:
1:
   action: delete_indices
   description: >-
      Delete indices older than 7 days (based on index name), for logstash-
      prefixed indices. Ignore the error if the filter does not result in an
      actionable list of indices (ignore_empty_list) and exit cleanly.
   options:
   ignore_empty_list: True
   disable_action: False
   filters:
     - filtertype: pattern
        kind: regex
        value: "^(logstash-|.monitoring-es-|.watcher-history-|.monitoring-logstash|.monitoring-kibana|shrink-logstash).*$"
     - filtertype: age
       source: name
       direction: older
       timestring: '%Y.%m.%d'
       unit: days 
       unit_count: 7
2:     
   action: replicas
   description: >-
      Set the number of replicas per shard for selected indices to 'count'
   options:
   count: 0
   wait_for_completion: True
   max_wait: 600
   wait_interval: 10
   filters:
      - filtertype: pattern
        kind: regex
        value: "^(logstash-|.monitoring-es-|.watcher-history-|.monitoring-logstash|.monitoring-kibana).*$"
      - filtertype: age 
   source: creation_date
   direction: older
   unit: days
   unit_count: 1

A l'installation, nous utilisions 5 shards primary. Mais je me suis rendu compte que la répartition de la charge entre les nœuds DATA n'était pas homogène. Sur les nœuds où j'avais 2 shards d'un index qui a beaucoup d'activité, le CPU tournais autour de 80% de CPU alors que les autres était à 60%.
En utilisant 4 shards, je reparti la charge de façon homogène sur les 4 nœuds DATA

5

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