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/
--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
