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.
moi j'utilise aussi les 2 RH et Centos. Un avantage de Centos est d'être sûr d'avoir une plateforme matérielle supportée si elle est certifiée par RH.
Je me souviens d'une partie de "plaisir" il y a quelque temps pour installer debian sur du matériel HP (pourtant certifié RH). En stable j'avais ni le réseau ni usb, et en testing j'avais pas les contrôleurs raid matériels...
De plus Centos étant basé sur les versions Advanced de RH, on évite aussi les limitations sur le nombre de socket CPU, le nombre de VM...
Les miroirs supplémentaires centosplus permettent d'être un peu fainéant en proposant les RPMs sympas comme drdb, lecture des partitions ntfs ...
# 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.
# avantage par rapport à pdsh ?
Posté par kengiskan . En réponse à la dépêche Exécution de commandes en parallèle avec ClusterShell. Évalué à 3.
L'empreinte mémoire n'est pas trop grosse en cas de gros cluster (fork ou thread) ?
[^] # Re: Centos
Posté par kengiskan . En réponse à la dépêche Red Hat Enterprise Linux 4.8. Évalué à 3.
Je me souviens d'une partie de "plaisir" il y a quelque temps pour installer debian sur du matériel HP (pourtant certifié RH). En stable j'avais ni le réseau ni usb, et en testing j'avais pas les contrôleurs raid matériels...
De plus Centos étant basé sur les versions Advanced de RH, on évite aussi les limitations sur le nombre de socket CPU, le nombre de VM...
Les miroirs supplémentaires centosplus permettent d'être un peu fainéant en proposant les RPMs sympas comme drdb, lecture des partitions ntfs ...
mes 2 centimes...