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 =).
Forum Linux.débutant Redirection de logs sous MySql via Syslog-ng
12
jan.
2009
# Logs
Posté par peck (site web personnel) . Évalué à 2.
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 Grimm . Évalué à 1.
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 NeoX . É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 peck (site web personnel) . Évalué à 2.
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 Grimm . Évalué à 1.
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 peck (site web personnel) . Évalué à 1.
# No problemo
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
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 Grimm . Évalué à 1.
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 briaeros007 . Évalué à 3.
Ç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 -=[ silmaril ]=- (site web personnel) . Évalué à 1.
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 briaeros007 . Évalué à 2.
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 peck (site web personnel) . Évalué à 0.
Acquiring target ...
[^] # Re: No problemo
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 1.
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 briaeros007 . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Poster ici alors que le sujet est débattu en long/large/travers sur google
[^] # Re: No problemo
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 3.
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 briaeros007 . Évalué à 4.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 Fabien (site web personnel) . Évalué à 2.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.