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.
Bonjour ,
il me semble que la solution que vous pourrez trouver dans https://www.artofmonitoring.com/ est adaptee
vous ne pourrez pas l'utiliser "as is" mais je pense que vous pourrez vous en inspirer .
Je recommande la lecture de ce livre a tous
Bonne journee
IS
On 2017-02-06 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/
Le 06/02/2017 à 14:44, Alexandre 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.
Alexandre,
(Réponse un peu OT, désolé)
Il existe un autre moyen que tu voudra peut être tester: shipper tes logs avec filebeat directement dans un ingest node Elasticsearch.
Un ingest node est juste un node qui a des pipelines d'ingestion qui vont faire le taf de logstash, en utilisant les expressions Grok habituelles..
Plus besoin de logstash, et plus besoin de bufferiser au milieu (filebeat est normalement capable de ralentir le shipping si Elasticsearch s'etouffe).
J'ai testé un peu et ça marche plutôt pas mal. Filebeat est assez léger, et les pipelines ne font pas trop mal à Elasticsearch.
La conf coté filebeat est vraiment souple, pour peu que l'on la creuse un peu (elle n'est pas forcément très bien organisée). Tu peux par exemple shipper sur des pipelines/index dynamiques en fonction du fichier de log lu assez facilement.
Par contre il faut ES 5.x.
https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ingest-no...
A+
M -- { :github => "@leucos", :gpg => "0X24B35C22" }
On utilise aussi bien rsyslog que syslog-ng les 2 ont le même genre de fonctionnalités (ex : insertion sql, mais ça mange du cpu ...)
mais on peut aussi configurer le syslog original pour renvoyer les message au format syslog (!) vers un ou plusieurs serveurs dédié a cette tache.
Le 06/02/2017 à 14:44, Alexandre 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/
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format "classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages: - rsyslog est déjà sur toute mes machines - le fait de garder à disposition des fichiers "bruts" me permet potentiellement de faire du traitement a posteriori (sans compter que c'est plus simple, j'imagine, d'envoyer un accesslog que de le reconstruire via ELK)
À noter que plusieurs softs parlent directement le syslog, nginx par exemple
On 06/02/2017 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/
Bonjour,
(Désolé pour la pub, mais vous verrez, elle a du sens).
Nous proposons chez OVH la stack ELK avec l'hébergement dédié de vos logstash(s) sous le nom "Logs Data Platform".
Page produit: https://www.ovh.com/fr/data-platforms/logs/ Doc logstash dédié: https://docs.ovh.com/gb/en/mobile-hosting/logs-data-platform/logstash-input/
Cordialement,
Le 6 février 2017 à 15:01, frsag@jack.fr.eu.org a écrit :
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format "classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages:
- rsyslog est déjà sur toute mes machines
- le fait de garder à disposition des fichiers "bruts" me permet
potentiellement de faire du traitement a posteriori (sans compter que c'est plus simple, j'imagine, d'envoyer un accesslog que de le reconstruire via ELK)
À noter que plusieurs softs parlent directement le syslog, nginx par exemple
On 06/02/2017 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/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'aime bien avoir la main mon infra car j'ai le temps pour bien bosser. La doc semble intéressante.
On Mon, 6 Feb 2017 15:28:41 +0100 Pierre De Paepe pdepaepe@gmail.com wrote:
Bonjour,
(Désolé pour la pub, mais vous verrez, elle a du sens).
Nous proposons chez OVH la stack ELK avec l'hébergement dédié de vos logstash(s) sous le nom "Logs Data Platform".
Page produit: https://www.ovh.com/fr/data-platforms/logs/ Doc logstash dédié: https://docs.ovh.com/gb/en/mobile-hosting/logs-data-platform/logstash-input/
Cordialement,
Le 6 février 2017 à 15:01, frsag@jack.fr.eu.org a écrit :
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format "classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages:
- rsyslog est déjà sur toute mes machines
- le fait de garder à disposition des fichiers "bruts" me permet
potentiellement de faire du traitement a posteriori (sans compter que c'est plus simple, j'imagine, d'envoyer un accesslog que de le reconstruire via ELK)
À noter que plusieurs softs parlent directement le syslog, nginx par exemple
On 06/02/2017 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/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Cette technique me convient. J'ai plus qu'a versionner et push de la conf dans /etc/rsyslog.d/ et restart. J'aime bien cette technique.
On Mon, 6 Feb 2017 15:01:36 +0100 frsag@jack.fr.eu.org wrote:
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format "classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages:
- rsyslog est déjà sur toute mes machines
- le fait de garder à disposition des fichiers "bruts" me permet
potentiellement de faire du traitement a posteriori (sans compter que c'est plus simple, j'imagine, d'envoyer un accesslog que de le reconstruire via ELK)
À noter que plusieurs softs parlent directement le syslog, nginx par exemple
On 06/02/2017 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/
Bonjour;
C'est que j'ai mis en place. [Client rsyslog] --> [logstash shipper (redis pour la perf) --> logstash indexer] --> [ES]
Ca fonctionne parfaitement. J´index un demi milliard de log (srv, fw, mysql queries) par jour.
A+
Nicolas Girardi.
Le 6 févr. 2017 à 15:01, frsag@jack.fr.eu.org a écrit :
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format "classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages:
- rsyslog est déjà sur toute mes machines
- le fait de garder à disposition des fichiers "bruts" me permet
potentiellement de faire du traitement a posteriori (sans compter que c'est plus simple, j'imagine, d'envoyer un accesslog que de le reconstruire via ELK)
À noter que plusieurs softs parlent directement le syslog, nginx par exemple
On 06/02/2017 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/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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/
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/
Bonsoir,
On reste dans le traitement des logs.
J'appelle une commande subst dans un fichier syslog-ng.conf (sur Ubuntu 16.10 à jour)
Si le motif recherché est un littéral, ça marche très bien. Si le motif recherché est une expression rationnelle au format POSIX, ça marche très bien. Si le motif recherché contient ne serait-ce qu'un symbole PCRE (exemple \d ou \w) alors il N'y a PLUS AUCUNE correspondance trouvée.
Y compris si j'ajoute explicitement type("pcre"). Bien que ce soit théoriquement superflu puisque c'est le "moteur" d'expressions rationnelles que syslog-ng prétend employer par défaut.
J'ai, par acquis de conscience, lancer une commande ldd sur le binaire syslog-ng qui m'a bien confirmé que le programme était lié avec la librairie partagée libpcre.
Quasi impossible de trouver le moindre exemple d'emploi d'expressions PCRE dans une config syslog-ng (soit je cherche mal, soit personne n'emploie les expressions PCRE dans syslog-ng).
Auriez-vous une piste à me suggérer ? (Vous pouvez vous épargner la solution consistant à se contenter des expressions POSIX, c'est ce que j'adopterai en dernier recours.)
D'avance merci pour votre aide,
Yannick
Bon comme je constate que mon problème n'émeut personne, j'apporte moi-même la réponse :
Il y avait 2 soucis combinés (sans rapport direct l'un avec l'autre).
En premier, c'est posix par défaut jusqu'à la version 3.5 incluse de syslog-ng, pcre par défaut à partir de la version 3.6.
Ensuite et surtout, le motif (en premier paramètre de subst) doit impérativement être délimité par des apostrophes sans quoi les \ ne serviront qu'à banaliser le caractère qui les suit immédiatement et ne seront pas interprétés comme faisant partie de symboles PCRE.
OU ALORS, si l'on veut délimiter le motif avec des guillemets il faut alors doubler chaque .
Exemple concret de ce que je voulais réaliser (et qui désormais fonctionne) :
rewrite remove_timestamp_in_docker_events { subst('(docker/\w+[\d+]:) \d{4}-\d\d-\d\d \d\d:\d\d:\d\d,\d+', "$1", value("MESSAGE") type("pcre")); };
S'il était avéré qu'une expression rationnelle POSIX soit plus rapide à traiter alors on peut opter pour l'une des variantes ci-dessous :
subst('(docker/[^[]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
subst('(docker/[[:alnum:]]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
Merci à moi (on n'est jamais aussi bien servi que par soi-même, surtout en guise d'auto-congratulations ;)
Yannick
Le 2017-02-06 22:12, Yannick Cadin a écrit :
Bonsoir,
On reste dans le traitement des logs.
J'appelle une commande subst dans un fichier syslog-ng.conf (sur Ubuntu 16.10 à jour)
Si le motif recherché est un littéral, ça marche très bien. Si le motif recherché est une expression rationnelle au format POSIX, ça marche très bien. Si le motif recherché contient ne serait-ce qu'un symbole PCRE (exemple \d ou \w) alors il N'y a PLUS AUCUNE correspondance trouvée.
Y compris si j'ajoute explicitement type("pcre"). Bien que ce soit théoriquement superflu puisque c'est le "moteur" d'expressions rationnelles que syslog-ng prétend employer par défaut.
J'ai, par acquis de conscience, lancer une commande ldd sur le binaire syslog-ng qui m'a bien confirmé que le programme était lié avec la librairie partagée libpcre.
Quasi impossible de trouver le moindre exemple d'emploi d'expressions PCRE dans une config syslog-ng (soit je cherche mal, soit personne n'emploie les expressions PCRE dans syslog-ng).
Auriez-vous une piste à me suggérer ? (Vous pouvez vous épargner la solution consistant à se contenter des expressions POSIX, c'est ce que j'adopterai en dernier recours.)
D'avance merci pour votre aide,
Yannick
Liste de diffusion du FRsAG http://www.frsag.org/
C'est toujours bien l'égo boost, surtout quand ça laisse des traces sur l'interweb.
Alex
Le 7 février 2017 à 12:53, Yannick Cadin yannick@diablotin.fr a écrit :
Bon comme je constate que mon problème n'émeut personne, j'apporte moi-même la réponse :
Il y avait 2 soucis combinés (sans rapport direct l'un avec l'autre).
En premier, c'est posix par défaut jusqu'à la version 3.5 incluse de syslog-ng, pcre par défaut à partir de la version 3.6.
Ensuite et surtout, le motif (en premier paramètre de subst) doit impérativement être délimité par des apostrophes sans quoi les \ ne serviront qu'à banaliser le caractère qui les suit immédiatement et ne seront pas interprétés comme faisant partie de symboles PCRE.
OU ALORS, si l'on veut délimiter le motif avec des guillemets il faut alors doubler chaque .
Exemple concret de ce que je voulais réaliser (et qui désormais fonctionne) :
rewrite remove_timestamp_in_docker_events { subst('(docker/\w+[\d+]:) \d{4}-\d\d-\d\d \d\d:\d\d:\d\d,\d+', "$1", value("MESSAGE") type("pcre")); };
S'il était avéré qu'une expression rationnelle POSIX soit plus rapide à traiter alors on peut opter pour l'une des variantes ci-dessous :
subst('(docker/[^[]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
subst('(docker/[[:alnum:]]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
Merci à moi (on n'est jamais aussi bien servi que par soi-même, surtout en guise d'auto-congratulations ;)
Yannick
Le 2017-02-06 22:12, Yannick Cadin a écrit :
Bonsoir,
On reste dans le traitement des logs.
J'appelle une commande subst dans un fichier syslog-ng.conf (sur Ubuntu 16.10 à jour)
Si le motif recherché est un littéral, ça marche très bien. Si le motif recherché est une expression rationnelle au format POSIX, ça marche très bien. Si le motif recherché contient ne serait-ce qu'un symbole PCRE (exemple \d ou \w) alors il N'y a PLUS AUCUNE correspondance trouvée.
Y compris si j'ajoute explicitement type("pcre"). Bien que ce soit théoriquement superflu puisque c'est le "moteur" d'expressions rationnelles que syslog-ng prétend employer par défaut.
J'ai, par acquis de conscience, lancer une commande ldd sur le binaire syslog-ng qui m'a bien confirmé que le programme était lié avec la librairie partagée libpcre.
Quasi impossible de trouver le moindre exemple d'emploi d'expressions PCRE dans une config syslog-ng (soit je cherche mal, soit personne n'emploie les expressions PCRE dans syslog-ng).
Auriez-vous une piste à me suggérer ? (Vous pouvez vous épargner la solution consistant à se contenter des expressions POSIX, c'est ce que j'adopterai en dernier recours.)
D'avance merci pour votre aide,
Yannick
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour la liste,
Chez nous, nous utilisons GrayLog ( https://www.graylog.org/ ) qui est tout simplement super.
Il utilise notamment une base Elasticsearch pour le stockage de log et une base Mongo pour la config.
Il est capable de gérer et d’ouvrir des « listener » ( syslog, gelf, snmp, … )
Il gère la rétention des logs.
Il a une interface graphique pour la visualisation de logs, et la conception de dashboard.
Il a un système d’authentification et d’authorization.
L’API est plutôt sympa et simple à utiliser.
Il a un système de « traitement de log », pour par exemple extraire les champs en fonctions de Regex (très utile pour des logs de firewal ;) ), ou encore pour ajouter la géolocalisation aux IP récupérées.
Un système d’alerte ( X logs avec tel condition en 1 minute = une alerte )
Bref, nous en sommes fan, et il est extrêmement fiable ( jamais planté depuis plusieurs années ).
Bonne soirée.
Benjamin
De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Alexandre Legrix Envoyé : mardi 7 février 2017 13:03 À : Yannick Cadin yannick@diablotin.fr Cc : French SysAdmin Group frsag@frsag.org Objet : Re: [FRsAG] syslog-ng et PCRE ?
C'est toujours bien l'égo boost, surtout quand ça laisse des traces sur l'interweb.
Alex
Le 7 février 2017 à 12:53, Yannick Cadin <yannick@diablotin.fr mailto:yannick@diablotin.fr > a écrit :
Bon comme je constate que mon problème n'émeut personne, j'apporte moi-même la réponse :
Il y avait 2 soucis combinés (sans rapport direct l'un avec l'autre).
En premier, c'est posix par défaut jusqu'à la version 3.5 incluse de syslog-ng, pcre par défaut à partir de la version 3.6.
Ensuite et surtout, le motif (en premier paramètre de subst) doit impérativement être délimité par des apostrophes sans quoi les \ ne serviront qu'à banaliser le caractère qui les suit immédiatement et ne seront pas interprétés comme faisant partie de symboles PCRE.
OU ALORS, si l'on veut délimiter le motif avec des guillemets il faut alors doubler chaque .
Exemple concret de ce que je voulais réaliser (et qui désormais fonctionne) :
rewrite remove_timestamp_in_docker_events { subst('(docker/\w+[\d+]:) \d{4}-\d\d-\d\d \d\d:\d\d:\d\d,\d+', "$1", value("MESSAGE") type("pcre")); };
S'il était avéré qu'une expression rationnelle POSIX soit plus rapide à traiter alors on peut opter pour l'une des variantes ci-dessous :
subst('(docker/[^[]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
subst('(docker/[[:alnum:]]+[[0-9]+]:) [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]+', "$1", value("MESSAGE") type("posix"));
Merci à moi (on n'est jamais aussi bien servi que par soi-même, surtout en guise d'auto-congratulations ;)
Yannick
Le 2017-02-06 22:12, Yannick Cadin a écrit :
Bonsoir,
On reste dans le traitement des logs.
J'appelle une commande subst dans un fichier syslog-ng.conf (sur Ubuntu 16.10 à jour)
Si le motif recherché est un littéral, ça marche très bien. Si le motif recherché est une expression rationnelle au format POSIX, ça marche très bien. Si le motif recherché contient ne serait-ce qu'un symbole PCRE (exemple \d ou \w) alors il N'y a PLUS AUCUNE correspondance trouvée.
Y compris si j'ajoute explicitement type("pcre"). Bien que ce soit théoriquement superflu puisque c'est le "moteur" d'expressions rationnelles que syslog-ng prétend employer par défaut.
J'ai, par acquis de conscience, lancer une commande ldd sur le binaire syslog-ng qui m'a bien confirmé que le programme était lié avec la librairie partagée libpcre.
Quasi impossible de trouver le moindre exemple d'emploi d'expressions PCRE dans une config syslog-ng (soit je cherche mal, soit personne n'emploie les expressions PCRE dans syslog-ng).
Auriez-vous une piste à me suggérer ? (Vous pouvez vous épargner la solution consistant à se contenter des expressions POSIX, c'est ce que j'adopterai en dernier recours.)
D'avance merci pour votre aide,
Yannick
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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/
Merci pour ce retour très complet.
On Mon, 06 Feb 2017 16:27:23 +0100 "Stéphane Cottin" stephane.cottin@vixns.com 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/
-
Alexandre -
Alexandre Legrix -
Benjamin -
frsag＠jack.fr.eu.org -
Jean Théry -
Michel Blanc -
Nicolas Girardi -
Pierre De Paepe -
Raphael Mazelier -
Remy Dernat -
soltani＠imad.fr -
Stéphane Cottin -
Yannick Cadin