Kibana Intensif

Bonjour,

Lorsqu'ELK commence à contenir beaucoup de données, ça se ressent dans les temps de réaction sur Kibana qui commencent à devenir plus longs.

J'aimerai savoir s'il existe une fonctionnalité, un plugin, ou autre, permettant de précalculer et de sauvegarder les résultats d'agrégation afin d'éviter qu'Elacticsearch recalcule cela à chaque fois.
Je suis conscient que ça enlève toute possibilité d'ajouter de nouveaux filtres ou de faire des recherches à la volée. Je bride le dashboard à un affichage sommaire, sur quelques fitres figés.
Ca permettrait de proposer des dashboards très réactifs, comme c'est souvent fait habituellement sur les sites Web de statistiques qui affichent des résultats pré-calculés (pré-aggrégées).

Ca permettrait d'avoir un nombre élevé de connexions simultanées à Kibana, dans le cadre d'un site web à fort trafic.

J'ai vu que le Rollup permettait de faire cela, c'est intéressant, j'aimerai savoir s'il existe d'autres choses.

Merci.

Il faut voir quelles viz tu utilises et sur quelle version tu es.

Si tu peux, passe tes viz sur Kibana Lens. C'est extrèmement plus rapide.
SI tu n'as pas encore la 7.10.1, passe sur cette version aussi afin d'avoir toutes les dernières évolutions.

Il faudrait en savoir un peu plus sur ton cluster.

Que donnent les commandes suivantes ?

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

Tu peux utiliser gist.github.com si c'est trop volumineux pour discuss...

1 Like

Merci.

J'ai la V7.6.1, je mettrai la V7.10.1 à l'occasion.

J'utilise plusieurs viz différentes (area, gauge, metric, et tsvb mon préféré) sur plusieurs dashboards.

En soit je suis satisfait de la rapidité des calculs d'aggrégation pour une utilisation en interne à l'entreprise, je suis conscient de la puissance du truc par rapport à une BDD relationnelle. C'est plutôt pour une utilisation intensive avec de nombreux utilisateurs, j'aimerai avoir des dashboards très rapides pour une utilisation basique, sans filtres poussés, pour les novices quoi.

GET /
{
"name" : "MediacomB1",
"cluster_name" : "Mediacom",
"cluster_uuid" : "3yRBx3-pRLGyG_NnAzJb-w",
 "version" : {
"number" : "7.6.1",
"build_flavor" : "default",
"build_type" : "tar",
"build_hash" : "aa751e09be0a5072e8570670309b1f12348f023b",
"build_date" : "2020-02-29T00:15:25.529771Z",
"build_snapshot" : false,
"lucene_version" : "8.4.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}

GET /_cat/nodes?v
ip             heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.226.17           68          99   0    1.60    0.91     0.38 dm        -      mediacomb4
192.168.226.11           52          97   1    0.73    0.65     0.51 dilm      -      MediacomB1
192.168.226.18           53          97   9    1.26    0.72     0.38 dm        -      mediacomb5
192.168.226.15           71          99   0    0.31    0.20     0.07 dm        -      mediacomb2
192.168.226.16           43          99   3    0.51    0.25     0.14 dm        *      mediacomb3

GET /_cat/health?v
epoch      timestamp cluster  status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1609879359 20:42:39  Mediacom green           5         5    680 630    0    0        0             0                  -                100.0%

GET /_cat/indices?v
    health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .triggered_watches              O1MbbEveQfGLxY3XOE_NgA   1   1         71           24      2.5mb          1.5mb
green  open   mediacom_idx_2020.10.19         Ti9l6y-sRUaHQfe41Svfrg   4   0    8483781            0     11.7gb         11.7gb
green  open   mediacom_idx_2020.10.18         o-qwgzJmQEu_eV0zTZCojA   4   0     786779            0      1.1gb          1.1gb
green  open   mediacom_idx_2020.10.17         rqUvtLTVTP6uo9x1t993Rw   4   0    2477951            0      3.4gb          3.4gb
green  open   mediacom_idx_2020.10.16         RugHDIV2Ro614F24Njeiqg   4   0    8787936            0     12.2gb         12.2gb
...

Il y a 180 index tous green.

c'est une architecture hot / warm avec 1 noeud dédié à l'injection et aux data fraiches + 4 noeuds pour les data anciennes. La Ram semble s'en sortir pas trop mal car elle ne se vide pas toutes les 5 minutes, elle atteint les 75% assez lentement et se vide bien, sauf pour le master node qui plafonne souvent à 75% et se vide toutes les 10 minutes. Je suis conscient que le master node nécessiterait plus de mémoire RAM, c'est prévu d'en ajouter. Faute de machines j'ai mis le master node éligible sur les 5 machines. Pour une raison que j'ignore le master node ne veut se mettre que sur les data nodes warm et jamais se positionner sur l'ingest node hot, qui lui a beaucoup plus de RAM que les autres machines (mais en même temps plus sollicité puisqu'il fait l'ingest, très gourmande). Et je n'ai pas 2 machines sous la main pour les dédier au master node.
Il y a près d'1 milliard de documents, qui occupent en tout 1,4TB de disque (sur 7,6 au total).
Pour la Heap : 31.1 GB / 51.6 GB. Je suis conscient aussi qu'il y a beaucoup d'index pas très volumineux en data, mais j'aimerai en avoir 1 par jour pour gérer simplement la durée de rétention en les deletant, par contre je n'ai que 5 shards par index pour compenser et éviter d'avoir trop de shards au total. pour chaque index je met 1 shard par data node pour bien équilibrer. Je segmente proprement pour n'avoir qu'un segment par shard à la fin de la journée.
Je suis preneur de tout conseil pour améliorer cette archi.

Bonne journée / soirée.

La première chose à faire je pense est de réduire à 1 seul shard tes index. 12gb pour un shard, c'est bien.
Tu y gagneras déjà en temps de réponse et en pression sur le cluster, notamment le noeud master.

Le nombre d'utilisateurs ne devrait pas vraiment poser de problème à mon avis.
Si c'était le cas, tu peux toujours augmenter le nombre de replica (ça se fait à chaud) pour servir éventuellement plus de requêtes encore...

2 Likes

Merci, je vais faire ça.