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/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
