Tout dépend ce que tu veux logguer et combien de temps, mais chez nous on utilise un mix d'un peu tout en fonction des besoins :
- logbeam -> redis <- ELK (quand on a de l'applicatif legacy) : très consommateur, logbeam est correct, logstash horrible, Kibana très pratique (mais attention aux volumes de données) Sur cette partie nous devrions utiliser plutot kafka et heka mais malheuresement pas le temps de refaire.
- fluentd (et ou envoie direct en gelf) + graylod. Ultime pour les logs mais ne fait pas de joli graph (mais le meilleur reste d'utiliser un vrai truc pour genre prometheus).
My 2 cents.
-- Raphael Mazelier
On 06/02/2017 16:27, Stéphane Cottin wrote:
fluentd est une alternative possible à logstash, beaucoup + léger.
Chez nous on envoi tout ce qui est applicatif directement à fluentd en json et au format natif lorsque c'est possible, et sinon au format syslog pour les apps legacy. De même pour nginx , haproxy, etc ... qui supportent syslog en natif. Et bien sur rsyslog pour attraper tout ce qui tombe dans /dev/log
A l'étape suivante on ne fait aucun traitement, nous voulons rester le + léger possible en input. On pousse tout en raw dans kafka, en séparant juste en plusieurs topics en fonction des sources/types de logs ( système, http, ...).
Nous utilisons ensuite d'autres instances de fluentd comme consumers kafka, pour parser / filter / pousser dans ES. A ce niveau les traitements peuvent être longs ou lourds, ça n'impacte pas l'input.
Tu peux aussi utiliser logstash, riemann ou autre en // pour consommer les topics depuis kafka.
Seul inconvénient à mon avis, cette chaine ne permet pas de "temps réel", tu as un empilement de buffers, et en fonction de ta volumétrie et de tes réglages, cela peut prendre plusieurs grosses secondes avant qu'une ligne soit indexée dans ES.
Les points positifs: scalable et souple.
On 6 Feb 2017, at 14:44, Alexandre wrote:
Bonjour à tous,
je pense que se sujet a été abordés plusieurs fois mais je n'ai pas trouvé d'informations.
Nous souhaitons centraliser nos logs (applicatifs, systèmes ...). Nous avons maquetté une solution standard avec Elasticsearh + Logstash + Kibana. Le trio fonctionne très bien, nous créons des custom logs et en y applique via logstash un template pour sortir tous les champs intéressant.
Cependant si nous devons mettre en production cette solution comme nous l'avons maquetté, il faut que nous installation un logstash sur toutes les machines. Le déploiement pose aucun problème, mais mettre du java sur toutes mes machines sachant que le process mange du CPU et la RAM, cela me plaît très moyennement.
Mon idée serait d'utiliser un outils centralisant les logs sur un cluster et d'y paramétrer un logstash qui injecterait les données venant des différents log. Il y a quelques années je m'étais bien amusé avec syslog-ng, et en production c'était pas mal.
Je me permets de vous demander si syslog-ng est toujours un outils utilisé ? ou plutôt dépassé. J'ai vu qu'il était possible de centraliser les log directement via rsyslog, pensez-vous que cela soit une bonne solution ? Il y a t'il d'autres solutions mieux que syslog-ng ou rsyslog pour centraliser les logs ?
Par avance, merci pour vos réponses.
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/