Forum Linux.débutant Redirection de logs sous MySql via Syslog-ng

Posté par .
Tags : aucun
0
12
jan.
2009
Messieurs, dames, bonjour,

Dans le cadre de mon stage de 2nde année de BTS IG, je dois mettre en place un serveur de log pour un firewall afin de remplacer la solution actuelle.

En effet, dans l'entreprise dans laquelle j'effectue mon stage, 6 mois de logs sont archivés sous la forme de fichier texte, à raison de 5go par jour.
L'analyse d'un ou d'une partie des logs étant quasiment impossible au vu de la taille de ceux-ci, la solution serait de les stocker dans une base de donnée.

Pour cela, j'utiliserais syslog-ng et configurerait une redirection des logs vers une base de donnée sous MySql.

Or, avant de me lancer dans les différentes manipulations, je dois effectuer une étude de faisabilité.

Ainsi, j'ai rassemblé un bon nombre d'informations sur le sujet. Cependant, certaines questions demeurent sans réponses malgré mes recherches.

En effet, j'aimerais savoir si, tout d'abord, ce basculement sous une base de donnée imposerait une contrainte de taille.

De plus, il serait utile de pouvoir compresser les logs après un certain délai. Cela est-il possible ?

Enfin, dans mes recherches j'ai noté que dans les pré-requis était mentionné un serveur LAMP (Linux, Apache, MySql, PHP). Or, l'outil Apache est-il nécessaire à la mise en place de ce projet. Et si oui, en quoi ?

Mes compétences dans ce domaine étant assez limitées, j'espère que mes questions ne vous paraîtront pas idiotes. Merci d'avance =).
  • # Logs

    Posté par (page perso) . Évalué à 2.

    Une contrainte de taille de ta base oui :) il faut prévoir assez d'espace pour accueillir les logs.
    Ensuite, il y a une contrainte de vitesse, surtout s'il y a des pics. Il faut faire en sorte que la machine qui héberge la base de données et le réseau soient suffisamment rapides pour gérer le nombre de requêtes.


    Pour stocker des logs (qui ne seront donc pas modifiés) le moteur de base de données archive ( http://dev.mysql.com/doc/refman/5.0/fr/archive-storage-engin(...) ) de mysql est adapté. Il compresse les données mais les laisse en lecture seule.


    Pour ton projet tu n'as pas besoin de apache ou php, LAMP c'est lesystème de base d'un serveur web. Ce qui n'est pas ton cas.
    • [^] # Re: Logs

      Posté par . Évalué à 1.

      Merci beaucoup =),

      Je pense que le moteur de table ARCHIVE répondra parfaitement aux exigences du projet.

      Cependant il y a quelque chose que j'ai du mal à saisir. Qu'entends-tu par "prévoir assez d'espace pour accueillir les logs" ?
      Peut-on déterminer la taille d'une base de donnée à sa création ?
      Ou parles-tu de l'espace disque ?
      • [^] # Re: Logs

        Posté par . Évalué à 2.

        Cependant il y a quelque chose que j'ai du mal à saisir. Qu'entends-tu par "prévoir assez d'espace pour accueillir les logs" ?
        Peut-on déterminer la taille d'une base de donnée à sa création ?


        tu as dis plus haut qu'il y avait 5Go de logs au format texte par jour.
        on peut donc imaginer que si on laisse les choses en l'etat
        il y aura 5Go de logs qui vont rentrer chaque jour dans la base de données

        donc je te laisse imaginer le volume qu'il faut à ta base de données pour stocker 1 Mois (30 jours ?) de logs.

        maintenant on peut aussi vouloir profiter de la bascule sur un nouveau systeme pour peaufiner les logs
        par exemple ne pas TOUT logger betement, mais plutot ce qui pourrait s'averer utile (les erreurs, les ports speciaux, certains sites ? certaines IPs ?)

        ainsi tu diminues le volume de log, donc de ta base de données.
      • [^] # Re: Logs

        Posté par (page perso) . Évalué à 2.

        Oui je parle d'espace disque. Comme dit NeoX ca s'estime.
        A une différence près, ARCHIVE permettant la compression, je te conseille de faire quelques tests pour estimer en plus le ratio de compression.

        Aussi n'oublie pas de penser ta base pour la rotation, genre une table par jour.
        • [^] # Re: Logs

          Posté par . Évalué à 1.

          Au niveau de l'espace disque je pense que ça ira, au moins pour les phases de test.

          Un maquettage est, de tout manière, prévu pour pouvoir prévenir les problèmes auxquels je n'avais pas pensé.

          Pour la rotation, j'y avais déjà réfléchi et je pensais mettre en place une table pour le jour J, dont le contenu sera basculé à la fin de la journée dans la table M du mois.
          Ensuite, à la fin du mois, la base sera archivée et deviendra M+1.
          A la fin de M+6 (soit le 6ème mois), la table sera desarchivée puis supprimée.

          Ainsi, je pourrais conserver 6 mois de logs comme il a été convenu au préalable.

          Dans l'immédiat, je vais chercher s'il est possible de trier les logs par IP source, ou ID dest une fois que ceux-ci seront intégrés à la base.
          En gros, il faudrait que je trouve un moyen de décortiquer les logs afin d'offrir des nouvelles solutions de tri.
          • [^] # Re: Logs

            Posté par (page perso) . Évalué à 1.

            Bah c'est une base de données, donc tu peux faire tout ce que tu veux à base de select :)
  • # No problemo

    Posté par (page perso) . Évalué à 2.

    J'ai déjà réalisé un tel 'projet' sur un serveur Gentoo avec non pas mySql mais un vrai SGBDR c-à-d PostgreSQL. De plus c'est tout un réseau en classe C qui était loggé y compris des machines sous Winx.
    Je n'ai pas rencontré de problème majeur et cela me semble un très bon exercice pour toi. Lances-toi à fond!
    • [^] # Re: No problemo

      Posté par . Évalué à 1.

      Je te remercie de tes encouragements =).

      Je dois avouer qu'au premier abord ce projet me semblait un peu difficile au regard de mes compétences, mais à force de réunir des infos, je commence à voir la chose d'un œil différent.

      Ce projet me semble beaucoup plus abordable que la première fois qu'il m'a été présenté.
      • [^] # Re: No problemo

        Posté par . Évalué à 3.

        si le patron le permet (a vrai dire , même si il le permet pas tu as le droit, mais c'est mieux de le faire quant tout le monde est d'accord), extrait le "how to" de ton rapport de stage et met sur le net (fait un journal ici par exemple).

        Ça pourrait en interesser certains ;)

        En tout cas bonne chance ;)

        (Et la question sur le apache : perso je ne pense pas que apache soit nécessaire, pas plus que php (toutefois j'ai pas testé). Et je conseillerais aussi une bd postgresql , mais bon, fait avec ce qui te semble le mieux ;))
        • [^] # Re: No problemo

          Posté par (page perso) . Évalué à 1.

          pourquoi postgresql ?
          as-t'il besoin de relationnel avancé pour stocker des log ? non.
          il a besoin de rapidité d'insertion, ce qui est le point fort du couple mysql/myIsam quoi qu'on en dise..
          • [^] # Re: No problemo

            Posté par . Évalué à 2.

            pourquoi postgresql ?
            Parce qu'il ne demande pas de jongler entre trois (enfin 7) types de table pour choisir lequel offre le mieux des performances vs features (par exemple Archive ne supporte pas les index...)
            Parce qu'une table postgresql qui augmente beaucoup , ça a été vu plusieurs fois sans problème, ce qui n'est pas forcément le cas de mysql (chez plusieurs personnes ils ont eu des problèmes de performances. Alors ensuite c'est peut etre du à quelque chose de complètement différent (mauvais admin , ...) mais ça a déjà été vu).

            Quant à la fameuse "vitesse" d'execution de mysql, elle est pas tellement mieux que celle de postgresql, quoi qu'on en dise, alors pourquoi se compliquer la vie (surtout si on a des besoins d'évolution)?

            allez, après avoir tapé "myIsam transaction" dans google je tombe sur
            Pour un site lambda, utiliser MyISAM permettra de se tirer de la plupart des situations. Dès que le SGBD plie sous le poids des requêtes, il faudra alors songer à revoir sa structure… ou à intégrer un système de cache.
            Il est également possible de mélanger les type de table pour les optimiser selon le contenu de chacune. Le site de MySQL suggère d'utiliser MyISAM pour la connexion et la recherche, InnoDB pour les informations de connexion et le système de publicité, et Heap pour les tables temporaires et le données très demandées.


            Ah voui, ca a l'air trop simple la gestion de MySQL, des fois faut changer le type de table, d'autres fois changer la structure, etc...


            Enfin si je me renseigne un poil sur MyIsam j'ai ça
            Raw Speed

            MySQL's MyISAM engine performs faster than PostgreSQL on simple queries and when concurrency is low or follows certain patterns (e.g. inserts are lock-free only on optimized tables, count(*) is very fast). MyISAM's speed comes at the cost of not supporting transactions, foreign keys, and not offering guaranteed data durability.*

            Moyen comme table ça quand même.

            * un exemple : http://use.perl.org/~Smylers/journal/34246

            Tu propose une table qui offre presque rien comme évolution ou ce qu'on peut attendre d'un SGDB digne de ce nom..

            ou encore, suivant la machine
            Multi-Processor

            PostgreSQL's speed advantage over MySQL can be seen drastically in a large multi-core/processor environment. [1] Even MySQL developers admit that current MySQL's use of multi-core/processor technology is not up to par. [2] Recent patches from Google and Percona hold promise of closing the gap.


            Si la machine doit supporter un nombre important de requête, il y a fort à parier qu'elle ait un nombre important de coeurs (chez un client qui utilisait mysql (et qui allez passait à autre chose à cause de la réplication qui leur convenait pas) avait un serveur maitre de 4x 4-core ....


            un liens sur mysql vs psql http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
            • [^] # Re: No problemo

              Posté par (page perso) . Évalué à 0.

              Troll detector activated ...
              Acquiring target ...
            • [^] # Re: No problemo

              Posté par (page perso) . Évalué à 2.

              Donc il ont du mysql mais ils migrent sous postgres parce que la réplication et les perfs ne leur conviennent pas ? je sais pas si tu a lu ton lien mais la réplication et postgres c'est pas vraiment son point fort,
              que ce soit niveau perfs ou efficacité.

              Quand à la complexité d'admin, va pas me dire que postgresql c'est magique et tout marche d'un seul coup je te croirais pas. C'est comme ça que certains (*) essayent de vendre l'informatique maintenant et je ne suis jamais surpris du résultat.

              >Quant à la fameuse "vitesse" d'execution de mysql, elle est pas
              > tellement mieux que celle de postgresql, quoi qu'on en dise, alors
              > pourquoi se compliquer la vie (surtout si on a des besoins d'évolution)?
              Oui bein comment dire, ça peut très bien se retourner sur postgres cette phrase. Pourquoi prendre un outil de ce type, pas simple à installer, utiliser, updater (une update majeur pgsql 7 => 8 c'était pas toujours fun au début), alors qu'on a un outil evolutif capable de se conformer à chaque besoin avec des process optimisés pour chacun ...

              *: que ce soit des éditeurs type Microsoft, ou des hebergeurs type OVH/Amen
              • [^] # Re: No problemo

                Posté par . Évalué à 2.

                je sais pas sous quoi ils migrent. Ce que je sais c'est que les perfs globales, et la réplication ne leur convient pas (1 serveur maitre 4x quad core, plus 15 esclaves. Le serveur maitre a de temps en temps des load average qui s'approche dangeureusement, voir dépasse 16).

                Quand à la complexité d'admin, va pas me dire que postgresql c'est magique et tout marche d'un seul coup je te croirais pas.
                faire "marcher" postgresql, c'est pas plus compliqué que mysql.
                Ensuite c'est plus du tuning, et ça , que ce soit postgres ou mysql ou db2 (tiens j'en ai une bonne sur le support de db2 aussi) ou oracle, ben ça demande de connaitre sa bd et les structures utilisé, les requêtes (vive le logging).
                Toujours est il que tu n'as pas te demander si "le type de base" que tu as pris est bien celle qui te convient avec postgres, mais à savoir comment tu vas pouvoir utiliser les outils de SQL pour optimiser cette base.
                Sous MySQL tu es obligé de jongler avec le type de base et ce qu'elles supportent.

                pourquoi prendre un outil de ce type, pas simple à installer, utiliser, updater (une update majeur pgsql 7 => 8 c'était pas toujours fun au début)
                Moi j'ai pas eu de problème pour faire tout ce que tu dis :P (bon c'est pas 15 db interconnecté entre elles non plus :P).

                alors qu'on a un outil evolutif capable de se conformer à chaque besoin avec des process optimisés pour chacun ...
                Evolutif ? Evolutif ou ça ? Niveau "évolution" postgres est à des années lumières de MySQL. Quant à se conformer à mes "besoins" : j'ai besoin de rapidité et de clés étrangères. Ah ben MyIsam ne convient pas.


                Pour terminer, on nous rabache sans cesse "Avec Falcon ca va etre top moumoute" depuis un certain nombre d'année (bon j'exagère peut etre là, mais pas tant que ça)!



                Ne crois pas que je pense à MySQL comme une sous merde fini (même si j'essaie d'être un peu l'avocat du diable), mais j'en ai un peu marre de voir toute le temps "MySQL" alors qu'elle n'est pas si terrible que ça, et que postgresql est bien plus avancé techniquement, et que contrairement à ce que tu crois, n'est absolument pas compliqué à installer ni à administrer (ajout de bd, d'utilisateur, ...).
                Le tuning je peux rien en dire car je suis pas un expert loin de là.


                Quand j'ai eu un projet à faire, ben j'ai utilisé les deux au départ pour laisser le choix, et j'ai poussé pour postgresql :P
      • [^] # Re: No problemo

        Posté par (page perso) . Évalué à 1.

        En même temps, si ça n'a pas été fait 30x ça n'a jamais été fait,
        utilise plutôt rsyslog, qui supporte le logging sur DB en direct:
        http://www.rsyslog.com/Documentation-/rsyslog_mysql.html.pht(...)
        • [^] # Re: No problemo

          Posté par . Évalué à 2.

          que ça a été fait 30 fois n'empeche pas de le faire une 31 fois
          Au pire : tu as un document en plus
          Au mieux : tu as un document qui correspond plus à ton problème, qui est plus explicité, qui est plus au gout du jour, ...
          • [^] # Re: No problemo

            Posté par . Évalué à 2.

            en recherchant rapidement , je suis tombé sur ça

            http://blog.toniob.net/index.php/post/2007/05/11/Syslog-ng-e(...)

            destination d_mysql {
            program(
            "mysql -u syslogfeeder --password=xxxxxxxx syslog -B > /dev/null"
            template("INSERT INTO logs (host, facility, priority,
            level, tag, datetime, program, msg) VALUES ( '$HOST', '$FACILITY', '$PRIORITY', '$LEVEL',
            '$TAG', '$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n")
            template-escape(yes)
            );
            };

            Avec ça, je crois que son stage va etre vite fait XD
    • [^] # Re: No problemo

      Posté par (page perso) . Évalué à 3.

      J'ai un peu de mal a voir en quoi le relationnel est utile dans le cas présent ...
      Bon j'ai un peu de mal a voir en quoi ce type de projet est utile tout court:

      Stockage: certes un moteur type archive va compresser les tables, mais les index vont être énormes

      Rotation: une table part jour... vraiment très mauvaise idée, ce n'est pas avec ça que tu va simplifier les recherches

      Recherche justement, vu que les données vont être non typées (basiquement une grosse chaine quoi), la seule recherche qui va marcher est le LIKE, implicant des index FULLTEXT (compatibles .. myIsam uniquement ...) une info parmi 6 mois de logs je doute que la base soit perceptiblement plus rapide que grep, ou alors la base va être 2/3 fois plus grosse que le stockage d'origine (5Go / jour => 900Go déjà).

      Quel est le besoin réel ? Est-ce vraiment une bonne approche ?
      Ne faudrait t'il pas s'orienter sur un IDS plutôt ?
      • [^] # Re: No problemo

        Posté par . Évalué à 4.

        Recherche justement, vu que les données vont être non typées (basiquement une grosse chaine quoi), la seule recherche qui va marcher est le LIKE, implicant des index FULLTEXT (compatibles .. myIsam uniquement ...)
        Euh tu as déjà lu des logs ? Parce que dire que tu n'a qu'une grosse chaine où tu es obligé de recherché en full text, je crois pas trop

        Tu as déja une date et une heure (Important)
        Ensuite tu peux avoir une IP/nom de domaine (important en cas d'aggrégation de logs)
        Tu as aussi une sévérité (index bitmap ?)
        Et une "facility" (index bitmap ?)
        Ensuite tu as un nom de soft (index bitmap ?)
        Et ensuite seulement tu as ton message! (text avec ton LIKE).
        • [^] # Re: No problemo

          Posté par (page perso) . Évalué à 2.

          >Et ensuite seulement tu as ton message! (text avec ton LIKE).
          Oui et ? c'est justement de ça dont je parle, et pour avoir des logs à traiter, centraliser et analyser je peut te dire que c'est justement là qu'il
          y a les infos intéressantes. Notamment quand tu traite des logs de firewall (ie de netfilter).

          Sauf que si tu veut centraliser du syslog, bein tu va te retrouver avec n formats différents, et donc difficilement d'optimiser ta DB, ce qui est génant quand on parle de DB de 1To.
          Hors j'ai déjà eu affaire à des DB de taille bien inférieures non/mal indexées, et ... c'est pire que du fichier plat.
          • [^] # Re: No problemo

            Posté par . Évalué à 2.

            je peut te dire que c'est justement là qu'il y a les infos intéressantes
            Ca dépend ce que tu cherche.
            Par exemple sortir les logs de tel ou tel programme entre tel et tel heure, tu t'en fous pas mal du LIKE.

            Notamment quand tu traite des logs de firewall (ie de netfilter).
            Rien ne t'empêche de faire une moulinette qui sortira les différentes info pour certains soft et utilisera un héritage de table afin d'avoir les infos les plus pertinentes pour toi.
      • [^] # Re: No problemo

        Posté par (page perso) . Évalué à 2.

        Stockage: centralisation à un endroit des logs (dans son cas il parle d'une seule machine mais ...)

        Rotation: à lui de bien définir son modèle et aussi d'utiliser les capacités de la base de données qu'il aura choisi. Perso, j'ai un système de partitionnement de table et des fonctions pl/pgsql (à choisir) pour manipuler le tout (créer les tables filles par exemple).

        Recherche: un enregistrement d'une table de log comporte énormément d'information permettant à une requête sql de bien mieux trier qu'un grep.


        Pour le choix de la base de données, chacun ses goûts mais il faut penser qu'elle sera fortement sollicitée (surtout en écriture). Pour le stockage, il est recommandé de choisir un espace de stockage conséquent et rapide.

        Et enfin syslog-ng vs rsyslog, si on mets à part les problèmes de licence / mode de développement du premier, le deuxième me semble plus adapté:
        - gestion natives des bases de données
        - et surtout plusieurs niveaux de tampons permettant de bien mieux gérer les afflux de logs sur une base chargée.
        • [^] # Re: No problemo

          Posté par (page perso) . Évalué à 2.

          > Recherche: un enregistrement d'une table de log comporte énormément d'information permettant à une requête sql de bien mieux trier qu'un grep.

          ah ? a part la date/heure qui effectivement est plus utilisable dans une DB le reste du format syslog est 'libre' ce qui veut dire pas d'optimisation du stockage possible, ou alors il faut un type de table par application ....
          • [^] # Re: No problemo

            Posté par . Évalué à 2.

            qui veut dire pas d'optimisation du stockage possible
            Oh je sais pas,par exemple une table avec l'ensemble des logiciels utilisé, et une foreign key sur la table de base. (ce qui permet de stocker une seule un varchar, et ensuite de stocker des short par exemple)?

            Un héritage de table si on veut écrire des parseurs pour quelques logiciels spécifiques (ie netfilter dans ton cas) mais conserver l'ensemble des infos identiques (date, logiciel,...) regroupé.

            On sait pas exactement ce qu'il veut faire, dans quel complexité il doit entrer, etc...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.