J'utilise loganalyzer pour l'analyse avec petites et grosses bases (150Go) sous prostresql. De base c'est vrai que c'est lent, mais c'est surtout parce qu'il n'y a pas d'index créés par défaut. Le mieux est de les rajouter à la création de la base (je l'ai fait ensuite, mais sans arrêter la prod c'est galère et lent), mais après ça devient tout a fait utilisable.
Ceci dit, je préconnise de ne mettre en base que ce qui est pertinent (virer les MARK/cron pollueurs...) et sur une durée de limitée ( 1 -2 mois ?) dépendant du volume à absorber, et de TOUT centraliser sous forme de fichier à plat pour 2 raisons :
un fichier est plus facile à backuper et faire tourner, et en plus
la BDD n'est pas valable pour des besoins légaux puisqu'on transforme l'info au passage.
Pour en revenir à loganalyzer, on peut facilement se créer des "parsers" et vues associées, par exemple pour avoir les différents champs de firewall, et faire des recherches sur ces éléments.
# loganalyzer
Posté par kengiskan . En réponse au journal Centralisation des logs, interface de consultation. Évalué à 3.
J'utilise loganalyzer pour l'analyse avec petites et grosses bases (150Go) sous prostresql. De base c'est vrai que c'est lent, mais c'est surtout parce qu'il n'y a pas d'index créés par défaut. Le mieux est de les rajouter à la création de la base (je l'ai fait ensuite, mais sans arrêter la prod c'est galère et lent), mais après ça devient tout a fait utilisable.
Ceci dit, je préconnise de ne mettre en base que ce qui est pertinent (virer les MARK/cron pollueurs...) et sur une durée de limitée ( 1 -2 mois ?) dépendant du volume à absorber, et de TOUT centraliser sous forme de fichier à plat pour 2 raisons : un fichier est plus facile à backuper et faire tourner, et en plus la BDD n'est pas valable pour des besoins légaux puisqu'on transforme l'info au passage.
Pour en revenir à loganalyzer, on peut facilement se créer des "parsers" et vues associées, par exemple pour avoir les différents champs de firewall, et faire des recherches sur ces éléments.