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.