+1 pour ne pas confondre 'time series" (TSDB) fait pour accumuler des metrics (compteurs,etc) genre utilisation cpu ou température avec l'indexation et le stockage de logs (document database).
Sinon pour convertir des logs en metrics, il y a mtail ( https://github.com/google/mtail ) ou grok-exporter ( https://github.com/fstab/grok_exporter ) mtail est particulièrement simple et efficace, on peut matcher la chaine 'Port x disconnected' par exemple pour extraire le 'x' et en faire un metric. On Mon, Nov 19, 2018 at 2:39 AM DUVERGIER Claude <frnog...@claude.duvergier.fr<mailto:frnog...@claude.duvergier.fr>> wrote: Je m'incruste... > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient > plus clair. Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé de transformer un message d'événement : * "Port x disconnected" * "User x logged-in" * etc. En métrique : * "port_x_connected=false" * "port_x_disconnection_count=42" * "user_x_logged=true" * "user_x_login_count=666" Soit parce qu'on a pas le contrôle sur le générateur de l'événement (équipement fermé) soit parce qu'on pense que ça n'est pas à l'application instrumenté de se souvenir des événements -nombre d'authentification- pour les transformer en métriques). Donc je me demande si vous n'auriez pas 2/3 suggestions de solution (logiques ou logicielles) à ce "problème"... -- Duvergier Claude Le 18/11/2018 à 17:41, Raphael Mazelier a écrit : > >> >> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, >> par rapport à une time-series basique, que c'est totalement >> disproportionné. > > Désolé mon petit José mais je crois qu'on confond un peu tout la ;) > > ES et une TSDB ce sont bien évidement deux type d'outils complètement > différends qui sont parfois employé/dévoyé de leur fonction originale. > > > En très gros résumé : > > - on stocke des métriques dans un tsdb et on fait des graphs et de > l'alerting avec. Prometheux/Influxdb sont les candidats du moment. > > - on on stocke des documents indexés dans ES, parfait pour stocker des > logs structurés et faire des queries dedans. > > Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de > l'alerting avec des logs, ce qui est théoriquement assez faux. > >> >> C'est pratique à mettre en place et exploitable à petite échelle, mais >> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis >> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à >> nouveau prochainement. > > ES est le truc le plus scalable du monde. Je connais des petites société > smart qui exploitent sereinement des clusters de plusieurs Peta. > >> >> Reste à assurer la corrélation d’évènements, et le déclenchement >> d'alertes sur certains combos, mais là on rentre dans du compliqué. >> Tendance obligatoirement du code custom. Sauf si vous avez trouvé >> autre chose ? > > Comme je disais il ne faut pas. Il faudrait plutôt commencer par > transformer tes logs/déclencheurs en métriques. Après tout devient plus > clair. > > Cdt, > > -- > Raphael Mazelier > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
