Hello,

petit retour d'XP sur logstash / kibana. Ici on injecte environ 40 millions
d'évènements / jour (logs http, logs applicatifs GELF et logs système /
réseeau rsyslog). Le système grossit environ de 40 Go / jour et ca tient
sur 10 instances amazon (4 noeuds ES, et le reste qui se répartit en
brokers redis, injecteurs et filtres logstash / syslog)

On garde 15 jours d'historique environ (on voudrait garder +, mais bien
qu'ayant largement la place (qq To en stockage ephémère AWS et bien que
logstash faisant tourner les index (un par jour), si on garde trop d'index,
le cluster ES finit par mal se comporter.

J'envisage de séparer les différents types de log dans des index
différents, afin de régler un historique différent par type de log (http vs
syslog par exemple).

--
rémi




Le 8 septembre 2013 12:25, Remy Sanchez <remy.sanc...@hyperthese.net> a
écrit :

> On Friday, September 06, 2013 06:21:14 PM Stéphane Cottin wrote:
> > > Merci aussi pour le tuyau sur Riemann, qui a l'air effectivement
> vraiment adapté à ce que je veux faire, voire même donne des idées pour la
> suite. Par contre ça n'a pas l'air d'être une sinécure à mettre en place,
> et encore moins si on veut créer des alertes/indicateurs pertinents.
> J'imagine que le projet est trop récent pour être muni d'une littérature
> digne de ce nom ?
> >
> > Riemann est totalement lié au langage qu'il utilise, clojure, il faut
> obligatoirement le connaitre pour sortir des qqs exemples fournis, pour le
> coup, c'est du vrai devops
>
> J'ai noté ça, mais pour ma part ça devrait aller.
>
> > > Par contre, vous soulignez le fait que c'est assez gourmand en
> ressources, est-ce que vous auriez des chiffres à donner pour avoir une
> idée ?
> >
> > Je compare aux outils en bash/python/perl/... habituels, la JVM a besoin
> de RAM, les perfs s'écroulent au moindre début de swap.
> > Par ex sur une vm gandi pour logstash/riemann + dashboard/kibana3, 1.25G
> de ram ,  2 cores,  traite en moyenne sans aucune optimisation 100
> events/sec avec une charge ~ 0.5
> > Les nodes elasticsearch rament rapidement en dessous de 2Go de ram,
> prévoir 2 cores par instance au mini.
>
> Ah on peut faire des machines plus petites que ça ? *_*
>
> Blague à part, ok c'est pas si gourmand que ça en fait, vous m'aviez fait
> peur !
>
> > > J'entends assez peu parler de Greylog2, j'imagine que Logstash est
> sensiblement mieux ? De même pour Splunk, est-ce que quelqu'un a comparé ?
> >
> > j'ai testé graylog2 sans le retenir, trop usine-qui-fait-tout IMHO, par
> contre j'ai gardé le format GELF pour les logs applicatifs.
>
> Okay ça confirme mon impression.
>
> Merci beaucoup pour les retours,
> --
> Rémy Sanchez
> http://hyperthese.net/
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>
>
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à