Le 06/02/2017 à 16:27, Stéphane Cottin a écrit :
fluentd est une alternative possible à logstash, beaucoup + léger.
Intéressant !
Un peu HS aussi, mais petit retour d'EX ELK :
Après avoir utilisé pendant pas mal de temps ELK, on en est revenu car la base devenait énorme. Je l'ai sûrement mal configuré, mais attention au remplissage de disque... ! Je pense que j'avais mal configuré la taille de mes shards, mais je trouve que ce n'est pas forcément très bien expliqué au départ (impossible de redimensionner après coup... Ou alors, j'avais pas compris comment faire ?...). Si tu peux rajouter facilement des machines (scale horizontal), ça va, sinon, je serai toi, soit je prévois très large en taille, soit je trace mon chemin.
https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
Pour l'utilisation, effectivement, ELK, ce n'était que du bonheur par rapport à un serveur de logs sql classique. J'ai utilisé loganalyzer couplé à rsyslog pendant des années, et pareil, je pense que je logue trop de choses/trop longtemps, mais c'était devenu inutilisable. La capacité à trouver une info dans ES est impressionnante, par rapport à un SGBD relationnel classique.
Je n'ai pas trouvé que le client bouffait tant de ressource que ça, mais je n'ai plus les valeurs en tête.
Rémy
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/