Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel :
* Les messages de debug sortent dans un fichier debug.log qui est rotaté dès qu'il dépasse 100 Mo * Les messages autres vont dans des fichiers info.log, warn.log, error.log, qui sont rotatés sur base de la date * Quand une erreur arrive, on envoie un mail
Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même).
Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
* Empêcher que les logs nuisent à l'exécution du programme en saturant l'espace disque * Être capable de gérer les erreurs par lot : si une même exception arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer.
Je suis preneur de toute proposition/retour d'expérience :)
Merci,
Bonjour,
Je pense à logstach et et l'interface web Kibana :
http://logstash.net/ http://kibana.org/
Cordialement,
Le 03/09/2013 13:32, Rémy Sanchez a écrit :
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel :
- Les messages de debug sortent dans un fichier debug.log qui est
rotaté dès qu'il dépasse 100 Mo
- Les messages autres vont dans des fichiers info.log, warn.log,
error.log, qui sont rotatés sur base de la date
- Quand une erreur arrive, on envoie un mail
Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même).
Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en
saturant l'espace disque
- Être capable de gérer les erreurs par lot : si une même exception
arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer.
Je suis preneur de toute proposition/retour d'expérience :)
Merci,
Le 03/09/2013 13:44, Grégory EPP a écrit :
Bonjour,
Je pense à logstach et et l'interface web Kibana :
http://logstash.net/ http://kibana.org/
Cordialement,
A noter que le Linux Mag de septembre parle de logstash / kibana.
Perso, je suis déçu que ça utilise une JVM (surtout que c'est codé en Ruby. Ça utilise JRuby.).
Sinon, il y a aussi Graylog2 : http://www.graylog2.org/
Toujours en Java, utilise aussi ElasticSearch.
On a installé logstash récemment et c'est vraiment génial pour la visualisation de logs. Pas testé par contre pour l'envoi de mail (qu'on gère par ailleurs avec un système qui ne dédoublonne pas, ce qui nous a permis de nous faire blacklister les ips de nos serveurs par gmail :( ).
Ca demande un peu de boulot pour être exploité pleinement, et un peu de tuning (surtout au niveau d'ElasticSearch). Au final, on a du passer un peu moins d'une semaine (pour une archi d'une dizaine de machines, avec un volume de logs "moyen"), plus autant pour ajouter des identifiants de requêtes dans notre appli web pour arriver à corréler les différents logs.
Avec un peu de background sur le tuning Java, et un ou deux articles de blog, ça passe.
A noter que c'est relativement consommateur de ressources (CPU/RAM), maintenant YMMV.
JFB
Le 3 sept. 2013 à 13:32, Rémy Sanchez a écrit :
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel :
- Les messages de debug sortent dans un fichier debug.log qui est rotaté dès qu'il dépasse 100 Mo
- Les messages autres vont dans des fichiers info.log, warn.log, error.log, qui sont rotatés sur base de la date
- Quand une erreur arrive, on envoie un mail
Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même).
Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en saturant l'espace disque
- Être capable de gérer les erreurs par lot : si une même exception arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer.
Je suis preneur de toute proposition/retour d'expérience :)
Merci,
Rémy Sanchez http://hyperthese.net/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 2013-09-03 13:32, Rémy Sanchez wrote:
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en
saturant l'espace disque
- Être capable de gérer les erreurs par lot : si une même exception
arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
On utilise chez nous Sentry, installé sur un serveur a nous, c'est leger, bien configurable. Pratique pour aller rechercher un alerte qu'un client te signale 2 jours plus tard ...
Bonjour,
Pour les applicatifs, on envoi les messages au format gelf, afin de ne pas subir la limite a 1024 octets de syslog, avoir des traces complètes et pouvoir ajouter tagger les messages. Le tout (gelf + syslog pour les logs système) est filtré par logstash qui distribue ensuite vers un cluster elasticsearch pour le stockage, et riemann pour la gestion des alertes.
Riemann est juste parfait pour traiter des flux, faire de l'analyse en temps réèl et générer les notifications sans flooder les serveurs mails, et les humains qui sont derrière, petit détail, le projet est écrit en clojure, et dans la logique "code is data", le fichier de config est du code clojure. la prise en main est dc un peu inhabituelle, il faut apprendre les bases d'un language fonctionnel, mais clairement, c'est un super outil.
on utilise kibana3 comme interface de consultation pour elasticsearch, attention, c'est de l'alpha/beta, j'ai déjà du refaire 2 fois mes dashboards pour cause de changements incompatibles.
L'ensemble se comporte bien, et a clairement amélioré la qualité de service globale depuis sa mise en place. Comme tout ceci utilise la JVM, RAM/CPU/IO sont a provisionner avec générosité si l'on veut conserver de bonnes performances sur la durée.
Stéphane
Le 3 sept. 2013 à 14:20, Thomas Pedoussaut thomas@pedoussaut.com a écrit :
On 2013-09-03 13:32, Rémy Sanchez wrote:
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en
saturant l'espace disque
- Être capable de gérer les erreurs par lot : si une même exception
arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
On utilise chez nous Sentry, installé sur un serveur a nous, c'est leger, bien configurable. Pratique pour aller rechercher un alerte qu'un client te signale 2 jours plus tard ...
-- Thomas
Liste de diffusion du FRsAG http://www.frsag.org/
On 03.09.2013 14:46, Stéphane Cottin wrote:
Bonjour,
Pour les applicatifs, on envoi les messages au format gelf, afin de ne pas subir la limite a 1024 octets de syslog, avoir des traces complètes et pouvoir ajouter tagger les messages. Le tout (gelf + syslog pour les logs système) est filtré par logstash qui distribue ensuite vers un cluster elasticsearch pour le stockage, et riemann pour la gestion des alertes.
Riemann est juste parfait pour traiter des flux, faire de l'analyse en temps réèl et générer les notifications sans flooder les serveurs mails, et les humains qui sont derrière, petit détail, le projet est écrit en clojure, et dans la logique "code is data", le fichier de config est du code clojure. la prise en main est dc un peu inhabituelle, il faut apprendre les bases d'un language fonctionnel, mais clairement, c'est un super outil.
on utilise kibana3 comme interface de consultation pour elasticsearch, attention, c'est de l'alpha/beta, j'ai déjà du refaire 2 fois mes dashboards pour cause de changements incompatibles.
L'ensemble se comporte bien, et a clairement amélioré la qualité de service globale depuis sa mise en place. Comme tout ceci utilise la JVM, RAM/CPU/IO sont a provisionner avec générosité si l'on veut conserver de bonnes performances sur la durée.
Stéphane
Merci à tous pour vos retours, je vois que le consensus est plutôt vers Logstash/Kibana3, et effectivement ça a l'air plutôt sympa.
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 ?
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 ?
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é ?
Merci encore :)
Le 6 sept. 2013 à 14:10, Rémy Sanchez a écrit :
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é ?
Comparaison vite faite en ce qui me concerne : splunk coûte une blinde (à moins de vouloir superviser un site perso) :)
Maintenant : YBMV (your budget may vary)
JFB
On 06.09.2013 14:17, JF Bustarret wrote:
Le 6 sept. 2013 à 14:10, Rémy Sanchez a écrit :
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é ?
Comparaison vite faite en ce qui me concerne : splunk coûte une blinde (à moins de vouloir superviser un site perso) :)
Maintenant : YBMV (your budget may vary)
JFB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Oh bah tant que ça coûte moins cher que le temps humain pour arriver à la même chose en utilisant autre chose... C'est peut-être full automagique et préconfiguré de partout, j'sais pas moi :D
Le 6 sept. 2013 à 14:10, Rémy Sanchez remy.sanchez@hyperthese.net a écrit :
On 03.09.2013 14:46, Stéphane Cottin wrote:
Bonjour,
Pour les applicatifs, on envoi les messages au format gelf, afin de ne pas subir la limite a 1024 octets de syslog, avoir des traces complètes et pouvoir ajouter tagger les messages. Le tout (gelf + syslog pour les logs système) est filtré par logstash qui distribue ensuite vers un cluster elasticsearch pour le stockage, et riemann pour la gestion des alertes.
Riemann est juste parfait pour traiter des flux, faire de l'analyse en temps réèl et générer les notifications sans flooder les serveurs mails, et les humains qui sont derrière, petit détail, le projet est écrit en clojure, et dans la logique "code is data", le fichier de config est du code clojure. la prise en main est dc un peu inhabituelle, il faut apprendre les bases d'un language fonctionnel, mais clairement, c'est un super outil.
on utilise kibana3 comme interface de consultation pour elasticsearch, attention, c'est de l'alpha/beta, j'ai déjà du refaire 2 fois mes dashboards pour cause de changements incompatibles.
L'ensemble se comporte bien, et a clairement amélioré la qualité de service globale depuis sa mise en place. Comme tout ceci utilise la JVM, RAM/CPU/IO sont a provisionner avec générosité si l'on veut conserver de bonnes performances sur la durée.
Stéphane
Merci à tous pour vos retours, je vois que le consensus est plutôt vers Logstash/Kibana3, et effectivement ça a l'air plutôt sympa.
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 :)
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.
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.
Merci encore :)
Rémy Sanchez http://hyperthese.net/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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,
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.sanchez@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/
On Mon, Sep 30, 2013 at 05:26:19PM +0200, Remi Paulmier wrote:
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).
Hello,
Par curiosité, tu utilises l'output elasticsearch ou elasticsearch_http ?
Pourquoi baser l'historique sur la création d'index quotidiens ?
Le 1 octobre 2013 18:50, Kevin Decherf kevin@kdecherf.com a écrit :
On Mon, Sep 30, 2013 at 05:26:19PM +0200, Remi Paulmier wrote:
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).
Hello,
Par curiosité, tu utilises l'output elasticsearch ou elasticsearch_http ?
Hello,
j'utilise l'output elasticsearch qui est donné comme étant plus performant que son pendant http. Ce faisant, l'instance logstash fait réellement partie du cluster ES et intéragit mieux avec les autres noeuds.
Principal inconvénient: cet output impose une version précise d'ES sur le cluster (ce que j'ai choisi de respecter à la lettre: je n'ai pas tenté avec une version non préconisée).
De plus, j'utilise le plugin cloud-aws pour trouver le cluster ES dans AWS, il faut donc tuner un peu logstash pour utiliser ES de cette facon.
Pourquoi baser l'historique sur la création d'index quotidiens ?
Sur ce point, je ne suis pas sur de comprendre la question. Si je ne sépare pas les données jour par jour dans un index quotidien, l'index grossira beaucoup trop fortement et ES ne tiendra pas. Si j'ai mal compris ta question, peux-tu reformuler ?
a+ -- rémi
On Wed, Oct 02, 2013 at 01:10:48PM +0200, Remi Paulmier wrote:
j'utilise l'output elasticsearch qui est donné comme étant plus performant que son pendant http. Ce faisant, l'instance logstash fait réellement partie du cluster ES et intéragit mieux avec les autres noeuds.
Intéressant, la dernière fois que j'ai utilisé l'output elasticsearch le client plombait le cluster toutes les heures (pour un débit relativement faible), et je n'ai eu aucun problème avec elasticsearch_http (et je suis libre dans mon choix de version du coup).
Pourquoi baser l'historique sur la création d'index quotidiens ?
Sur ce point, je ne suis pas sur de comprendre la question. Si je ne sépare pas les données jour par jour dans un index quotidien, l'index grossira beaucoup trop fortement et ES ne tiendra pas. Si j'ai mal compris ta question, peux-tu reformuler ?
J'ai fait le choix d'avoir un ttl sur les documents plutôt qu'avoir x indices, je trouvais ça plus simple. Mais là aussi le volume doit y être pour beaucoup.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour,
il y aurait Splunk qui pourrait faire l'affaire. Le logiciel est sujet à licence (au volume de données à indexer), mais est très bien fait. De plus il y a une énorme communauté active autour de Splunk.
Nicolas
On 9/3/2013 1:32 PM, Rémy Sanchez wrote:
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel :
- Les messages de debug sortent dans un fichier debug.log qui est
rotaté dès qu'il dépasse 100 Mo * Les messages autres vont dans des fichiers info.log, warn.log, error.log, qui sont rotatés sur base de la date * Quand une erreur arrive, on envoie un mail
Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même).
Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en
saturant l'espace disque * Être capable de gérer les erreurs par lot : si une même exception arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer.
Je suis preneur de toute proposition/retour d'expérience :)
Merci,
- -- Vos conversations sont privées, sécurisez-les. Your conversations are private, secure them. https://gpgtools.org or http://gpg4win.org
On Sep 3, 2013, at 3:18 PM, Nicolas Roosen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour,
Bonjour
il y aurait Splunk qui pourrait faire l'affaire. Le logiciel est sujet à licence (au volume de données à indexer), mais est très bien fait. De plus il y a une énorme communauté active autour de Splunk.
J'ai mis splunk la ou je travaille actuellement, on a dépassé les 500 Mo de données / j. Ce qui fait que le produit me balance une erreur mettant en cause ce dépassement. Outre le fait qu'il me faille passer sur une version pro, je ne peux même plus consulter mes logs.
Je pense que logstash avec les compléments (kibana, graylog...) est une solution intéressante. Par contre attention aux IO la concentration de log c'est tjs assez consommateur suivant la volumétrie
Nicolas
On 9/3/2013 1:32 PM, Rémy Sanchez wrote:
Bonjour à tous,
Je déploie actuellement avec grand plaisir des applications Java en charge de faire du traitement de masse sur des données.
Actuellement, on utilise log4j pour sortir ces logs, configuré grosso modo comme tel :
- Les messages de debug sortent dans un fichier debug.log qui est
rotaté dès qu'il dépasse 100 Mo * Les messages autres vont dans des fichiers info.log, warn.log, error.log, qui sont rotatés sur base de la date * Quand une erreur arrive, on envoie un mail
Donc pour les messages de debug, tout va bien, par contre pour le reste comment dire... Quand on a une erreur lancée pour chaque ligne de donnée (ce qui est arrivé plus d'une fois), alors on a grosso modo la même exception qui monte des millions de fois (mais pas exactement la même).
Cela a plusieurs effets de bord : d'une part faire tomber le serveur mail, et d'autre part saturer les disques et empêcher le fonctionnement du service.
L'idée serait donc d'externaliser la gestion des logs pour 2 raisons :
- Empêcher que les logs nuisent à l'exécution du programme en
saturant l'espace disque * Être capable de gérer les erreurs par lot : si une même exception arrive 2 millions de fois, générer une seule alerte et l'envoyer par mail à la team de maintenance, par exemple
Je cherche donc un système en mesure d'absorber des gros pics de logs, de ne pas consommer des gigas et des gigas de stockage, et de préférence avec une interface de visualisation web sympa. Possiblement compatible avec syslog ou en tout cas avec un appender log4j.
Pour l'instant j'ai trouvé http://three.kibana.org/ qui semble convenir approximativement à ces besoins. Il y a aussi un vieux thread (http://www.frsag.org/pipermail/frsag/2010-July/000226.html) qui liste pas mal de choses, mais qui n'ont pas l'air d'être adaptées au besoin de traiter les choses en bloc. À part Facebook Scribe éventuellement, mais ça a l'air trop perché par rapport au temps que je peux y consacrer.
Je suis preneur de toute proposition/retour d'expérience :)
Merci,
Vos conversations sont privées, sécurisez-les. Your conversations are private, secure them. https://gpgtools.org or http://gpg4win.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSJeG7AAoJEIylYwQV0UQc0TMH/jEzBnPp0B3/421kgfdJ2DCm Kz5m2e71GkgZpQ5dg/tPgeReAFpOf+vhjFbaYu8vOnkhF9BoYCrQd2nDTU+8qJtq 8x2YcR+Wlb5VwC2jWBRHJya8gF8lMYQNgOtfULV5GSUzGilaWl4TN4zU4yne8GS9 nys/93/9YHh9w/2ak1Gcau4aHRLkk4o9m+giBgGXlQv/yLOvxuZWZS0HhpjK0Z/6 RJr6IBVRUeTqn9Lh/jxhuudTsuVwgIleW1o5/TwUkQkrC9miEujFQvM1UApgyJOu U/EcUbG4qprhXQ72OeTLdw8vkxuqpLmKhe2fw+YNENKIuu7T/KFchcjINHDkvW0= =N2Fv -----END PGP SIGNATURE----- _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Gilles Mocellin -
Grégory EPP -
JF Bustarret -
Kevin Decherf -
Nicolas GORALSKI -
Nicolas Roosen -
Remi Paulmier -
Rémy Sanchez -
Stéphane Cottin -
Thomas Pedoussaut