Il est vrais que les outils de la stack ELK bouffe beaucoup (trop) de ressources. Mais quand tu a beaucoup de données, La JVM tu t'y retrouve. C'est pas pour rien que les stacks big data tourne sur la JVM (le log de 700 équipements c'est pas du big data, on est d'accord).
Si tu essai de faire de grosses agrégations dans grafana, ça va exploser, mais dans ce cas, c'est à ton dataplane de faire le downsampling (time bucket et compagnie). rrd est très bien pour avoir 1 graph mais te permet pas de requêter les données et de les corréler. Perso je reviendrais pas à un temps ou tu ouvre 4 fois la même page de graph pour pouvoir regarder toi même l'iowait, le CPU, et le réseau... Si certain arrive à être productif avec des technos du 16ème siècle, franchement je leur tire mon chapeau parce que moi je suis vraiment trop bête pour ça. Toute les actions que je fais sur un monitoring m'amène une chose et une seule : diminuer la charge cognitive au maximum pour avoir à réfléchir le moins possible quand a(ux) action(s) à réaliser. Le plus complexe dans tous ces systèmes (même rrd) c'est d'arriver à sélectionner qu'elle info est pertinente et laquelle ne l'est pas. Et là on sort du champ technique :-) > Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors > qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread). Libre à toi d'utiliser un unikernel https://github.com/cloudius-systems/osv Et attend j'ai pas encore parlé de Warp10 XD https://www.warp10.io/ <pas vendredi mais> Et tkt pas des gens sont en train de recoder toutes ces stacks en Rust </pas vendredi mais> Cordialement/Best Regards, Rémi Desgrange On Apr 28 2020, at 12:47 pm, Xavier Beaudouin <k...@oav.net> wrote: > Hello, >> Sachant d'ES ne sais pas tirer partie de bécanes avec +64Go de RAM > (JVM >> heap toussa) t'es parti sur au moins 5/7 bécanes >> > > Les dernières > versions d'ES sont capables d'utiliser plus de RAM: une > grande partie des > données ont été sortie du heap JVM pour passer sur du > memory mapping. Ca > permet entre autres de s'affranchir de la "limite" de la > JVM liée à la > compression de pointeurs qui fait qu'au delà de 32Go de heap > on est souvent > perdant en espace utile, les pointeurs n'étant plus > compressés, ainsi que > de limiter les problèmes de freezes liés au garbage > collector. > La > contention sur ES est plus au niveau du CPU, dont l'utilisation est > assez > linéaire par rapport à la quantité de données indexées. Je ne sais pas si je > suis devenu un vieux con aigri ou rétrograde, mais quand je vois des > discussion ou on parle de 5/7 becannes avec +64Go de RAM pour stocker de > métriques qui seront rarement utilisées a plus d'un trimestre je suis assez > dubitatif de la débauche de jus, de place en DC et de consommation de > silicium plutôt peu optimisées... Surtout que entre ES / Cassandra et ses > amis, ont quand même un language plus que peu efficace en gestion de ram, > gc(), et de concurrence CPU. Okay rrdtool ne permet pas d'avoir des stats > journalières précises a plus d'un mois mais donnent largement ce qu'il faut > pour avoir des métriques d'utilisation d'une plateforme. Après il y a des > trucs qui scalent plus que d'autres, mais un rrdcached sur du zfs avec lz4 + > un peu de ram (et sauvés a coup de zfs send/receive) suffisent largement a > mon goût et est TRÈS facilement scalable pour s'en prendre plein la > tronche.... avec bcp moins de machines et de CPU. Après je ne parles pas des > navigateurs qui explosent quand on demande des stats sur 50 machine d'un coup > consolidées via Grafana.... Alors pourquoi utiliser un machin en java qui est > un OS sur un autre OS alors qu'on pourrais utiliser des API normales d'un OS > (oui la libc... / libthread). Pour faire un parallèle : nginx vs apache.... > voila ce que j'en pense (hormis les problèmes de licences et de FUD liées au > modele de dev). /Xavier --------------------------- Liste de diffusion du > FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
