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-no...
- 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 moutonjeremy@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 moutonjeremy@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 infos@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 moutonjeremy@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 infos@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/
Bonjour à tous,
je me permets de vous dire merci, après avoir lu beaucoup de doc et avoir pris en compte vos conseils je suis parti sur quelque choses de très standard :
- rsyslog avec imfile pour lire, qualifier le log - réception du message avec logstash (shipper) + écriture dans redis - lecture depuis redis avec logstash (indexer) + qualification du log suivant le type - écriture dans elasticseach - rechercher avec kibana
J'ai pas pris kafka, car les articles parlant de Redis annonçaient des bonne perf, et puis j'avais assez de process Java sur mon infra :-). Le fait de découper le traitement des logs en 2 process rend l'infra flexible. J'aime beaucoup l'API dispo pour chaque process qui permets de savoir s'il y a des lenteurs dans les output. Ca permet aussi de savoir si j'ai des grok failures.
Avec un HAPorxy pour load balancé tout ca, rsyslog vers logstash, logstash vers elasticsearch, kibana vers elasticsearch, l'infra semble modulable. Hier j'ai fais ma première journée de prod, 35 Millions d'entrées (3 sites) et cela bronche pas. Au niveau place j'ai une utilisation de 20 GB par node sachant que j'ai 3 node ES.
Pour info, j'ai pas utilisé graylog, car il ne semble pas compatible avec ELK 5X et j'ai tout en 5.2.2.
Merci.
Alex.
On Mon, 6 Feb 2017 21:57:48 +0100 Alexandre infos@opendoc.net wrote:
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-no...
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 moutonjeremy@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 moutonjeremy@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 infos@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 moutonjeremy@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 infos@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/
Bonsoir à tous,
j'ai eu beaucoup de demande en off pour avoir quelques infos sur ce qui a été fait. J'ai mis des infos sur un github :
https://github.com/opendocnet/elk/wiki/Infrastructure-Elasticsearch-Logstash...
C'est sans prétention, c'est juste histoire d'avoir une trace de tous les échanges.
Actuellement nous sommes à environ 40 millions d'entrées par jours. J'ai testé une coupure Elasticsearch, sans problème, Redis joue très bien son rôle et temporise parfaitement. J'ai testé aussi une coupure des Logstash shipper, rsyslog est très bien car il note le pointeur du log et dès que le Logstash shipper est dispo il renvoie le delta. Par contre il ne faut pas que ce dure longtemps non pas pour des problèmes de place mais de rotation de log.
Dernier point utile, le "tag_on_failure" avec grok qui permet de pointer rapidement les messages qui ne correspondraient pas au "match".
Merci à tous pour vos retours. Cette mailing list est une pétite :-)
Alex.
On Fri, 10 Mar 2017 08:56:14 +0100 Alexandre infos@opendoc.net wrote:
Bonjour à tous,
je me permets de vous dire merci, après avoir lu beaucoup de doc et avoir pris en compte vos conseils je suis parti sur quelque choses de très standard :
- rsyslog avec imfile pour lire, qualifier le log
- réception du message avec logstash (shipper) + écriture dans redis
- lecture depuis redis avec logstash (indexer) + qualification du
log suivant le type
- écriture dans elasticseach
- rechercher avec kibana
J'ai pas pris kafka, car les articles parlant de Redis annonçaient des bonne perf, et puis j'avais assez de process Java sur mon infra :-). Le fait de découper le traitement des logs en 2 process rend l'infra flexible. J'aime beaucoup l'API dispo pour chaque process qui permets de savoir s'il y a des lenteurs dans les output. Ca permet aussi de savoir si j'ai des grok failures.
Avec un HAPorxy pour load balancé tout ca, rsyslog vers logstash, logstash vers elasticsearch, kibana vers elasticsearch, l'infra semble modulable. Hier j'ai fais ma première journée de prod, 35 Millions d'entrées (3 sites) et cela bronche pas. Au niveau place j'ai une utilisation de 20 GB par node sachant que j'ai 3 node ES. Pour info, j'ai pas utilisé graylog, car il ne semble pas compatible avec ELK 5X et j'ai tout en 5.2.2.
Merci.
Alex.
On Mon, 6 Feb 2017 21:57:48 +0100 Alexandre infos@opendoc.net wrote:
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-no...
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 moutonjeremy@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 moutonjeremy@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 infos@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 moutonjeremy@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 infos@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/
Bonjour,
Pour info j'ai privilégié UDP de mon côté pour les syslogs. Également j'ai vite été limité niveau vitesse avec le mode list de redis (perte de log constaté). Je suis en mode channel. (1 Milliard de log par jour)
Si besoin je peux fournir les conf. My2cts.
Nicolas Girardi.
Le 30 mars 2017 à 20:00, Alexandre infos@opendoc.net a écrit :
Bonsoir à tous,
j'ai eu beaucoup de demande en off pour avoir quelques infos sur ce qui a été fait. J'ai mis des infos sur un github :
https://github.com/opendocnet/elk/wiki/Infrastructure-Elasticsearch-Logstash...
C'est sans prétention, c'est juste histoire d'avoir une trace de tous les échanges.
Actuellement nous sommes à environ 40 millions d'entrées par jours. J'ai testé une coupure Elasticsearch, sans problème, Redis joue très bien son rôle et temporise parfaitement. J'ai testé aussi une coupure des Logstash shipper, rsyslog est très bien car il note le pointeur du log et dès que le Logstash shipper est dispo il renvoie le delta. Par contre il ne faut pas que ce dure longtemps non pas pour des problèmes de place mais de rotation de log.
Dernier point utile, le "tag_on_failure" avec grok qui permet de pointer rapidement les messages qui ne correspondraient pas au "match".
Merci à tous pour vos retours. Cette mailing list est une pétite :-)
Alex.
On Fri, 10 Mar 2017 08:56:14 +0100 Alexandre infos@opendoc.net wrote:
Bonjour à tous,
je me permets de vous dire merci, après avoir lu beaucoup de doc et avoir pris en compte vos conseils je suis parti sur quelque choses de très standard :
- rsyslog avec imfile pour lire, qualifier le log
- réception du message avec logstash (shipper) + écriture dans redis
- lecture depuis redis avec logstash (indexer) + qualification du
log suivant le type
- écriture dans elasticseach
- rechercher avec kibana
J'ai pas pris kafka, car les articles parlant de Redis annonçaient des bonne perf, et puis j'avais assez de process Java sur mon infra :-). Le fait de découper le traitement des logs en 2 process rend l'infra flexible. J'aime beaucoup l'API dispo pour chaque process qui permets de savoir s'il y a des lenteurs dans les output. Ca permet aussi de savoir si j'ai des grok failures.
Avec un HAPorxy pour load balancé tout ca, rsyslog vers logstash, logstash vers elasticsearch, kibana vers elasticsearch, l'infra semble modulable. Hier j'ai fais ma première journée de prod, 35 Millions d'entrées (3 sites) et cela bronche pas. Au niveau place j'ai une utilisation de 20 GB par node sachant que j'ai 3 node ES. Pour info, j'ai pas utilisé graylog, car il ne semble pas compatible avec ELK 5X et j'ai tout en 5.2.2.
Merci.
Alex.
On Mon, 6 Feb 2017 21:57:48 +0100 Alexandre infos@opendoc.net wrote:
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-no...
- 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 moutonjeremy@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 moutonjeremy@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 infos@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 moutonjeremy@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 infos@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/
Liste de diffusion du FRsAG http://www.frsag.org/
-
Alexandre -
Nicolas Girardi