Après avoir lu vos mails, il semblerait que j'ai un peu sous estimé le projet sur la partie scalable et perf.
Je vais tester : - rsyslog en natif - fluentd en alternative avec logstash (info Stéphane Cottin) - kafka (info Raphael Mazelier) - [Client rsyslog] --> [logstash shipper (redis pour la perf) --> logstash indexer] --> [ES] (info Nicolas Girardi) https://ianunruh.com/2014/05/monitor-everything-part-2.html - shipper les logs avec filebeat (info Michel Blanc) https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ingest-node.html - beats (info Pierrick Chovelon) https://www.elastic.co/products/beats Merci à tous pour vos retours toujours de qualité. Je vais prendre le temps de tester les différentes technos avant de me jeter dans un projet qui sera à refaire dans 2 mois. On Mon, 6 Feb 2017 16:15:58 +0100 Jérémy Mouton <moutonjer...@labbs.fr> wrote: > Sinon comme indiquer dans une autre réponse : > > machine (rsyslog en relp/tcp) -> rsyslog centralisé (udp 514) -> > logstash (udp 514) > > Pourquoi en udp? Pour éviter que rsyslog stale si logstash est ko ou > que tu le restart. > > Solution testé avec plus de 100Go de logs par jours. > > > Le 6 février 2017 à 16:08, Jérémy Mouton <moutonjer...@labbs.fr> a > écrit : > > > rsyslog sait bufferisé mais si ton problème réseau dure trop > > longtemps, tu risque de remplir le disque. > > > > Le 6 février 2017 à 15:50, Alexandre <in...@opendoc.net> a écrit : > > > >> J'avais vu cette méthode ou le logstash peut écouter directement > >> sur le 514 et capter l'info. Je ne sais pas si c'est mieux de > >> configurer le rsyslog en mode serveur et de donner les logs à > >> manger à logstash. > >> > >> D'ailleurs en cas de coupure réseau, rsyslog bufferise un peu ? > >> > >> Alex. > >> > >> On Mon, 6 Feb 2017 14:50:32 +0100 > >> Jérémy Mouton <moutonjer...@labbs.fr> wrote: > >> > >> > Bonjour, > >> > > >> > Tu peux utiliser rsyslog qui envera directement tes logs vers > >> > logstash. Et logstash n'aura pas besoin d'être sur chaques > >> > machines. > >> > > >> > > >> > Le 6 février 2017 à 14:44, Alexandre <in...@opendoc.net> a > >> > écrit : > >> > > 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/
